Zmiana rejestru nie wpływa na system

Zmiana rejestru niewpływająca na system wskazuje na nadpisanie wartości przez politykę GPO o wyższym priorytecie zasięgu.

Dlaczego wartość rejestru wraca do poprzedniego stanu

Zmiana rejestru nie wpływa na system wtedy, gdy edytowana wartość nie jest ostatecznym źródłem konfiguracji. W środowisku Windows ustawienie może być zapisane lokalnie w rejestrze, ale jednocześnie podlegać zasadom skonfigurowanym w zasadach grupy. Zasada grupy, czyli Group Policy, może podczas przetwarzania konfiguracji komputera albo użytkownika ponownie zapisać określoną wartość. W takiej sytuacji ręczna modyfikacja rejestru może zostać przyjęta chwilowo, po czym utracić znaczenie po odświeżeniu zasad, ponownym zalogowaniu lub uruchomieniu systemu.

Nie zawsze oznacza to, że edytor rejestru działa nieprawidłowo. Często zmiana została zapisana poprawnie, lecz później nadpisał ją mechanizm zarządzania konfiguracją. Zasada może ustawiać wartość na konkretny stan albo usuwać ją, gdy jej definicja przewiduje brak danego wpisu. Dlatego sam odczyt klucza przed i po ręcznej edycji nie wystarcza do ustalenia przyczyny. Trzeba sprawdzić, który składnik systemu ustawia wartość oraz w jakim momencie następuje ponowne zastosowanie konfiguracji.

Priorytet zasad grupy a lokalna konfiguracja

Zasady grupy są przetwarzane według określonej kolejności. W uproszczeniu najpierw stosowane są zasady lokalne, a następnie zasady związane z lokacją Active Directory, domeną i jednostkami organizacyjnymi. Zasada zastosowana później może zastąpić ustawienie pochodzące z wcześniejszego poziomu. Znaczenie mają również dziedziczenie, wymuszenie zasady oraz filtrowanie zabezpieczeń. Jeżeli kilka obiektów zasad grupy definiuje tę samą konfigurację, skuteczny wynik nie musi odpowiadać wartości widocznej w lokalnej zasadzie ani ręcznie wpisanej w rejestrze.

Ważne jest także rozróżnienie konfiguracji komputera i konfiguracji użytkownika. Ustawienie zapisane w gałęzi dotyczącej komputera może być stosowane niezależnie od konta, natomiast ustawienie w części użytkownika może obowiązywać tylko podczas sesji konkretnego użytkownika. W niektórych środowiskach działa również przetwarzanie zwrotne zasad użytkownika, w którym zasady są dobierane na podstawie lokalizacji komputera. Błędna interpretacja tej różnicy prowadzi do wniosku, że system ignoruje rejestr, choć w rzeczywistości stosuje inną gałąź konfiguracji lub inną zasadę.

Jak ustalić rzeczywiste źródło ustawienia

Pierwszym krokiem jest odtworzenie problemu z pełnym rozróżnieniem czasu zmiany. Należy sprawdzić, czy wartość pozostaje zmieniona bezpośrednio po zapisie, czy wraca po wylogowaniu, ponownym uruchomieniu albo ręcznym odświeżeniu zasad. Do odświeżenia konfiguracji można użyć polecenia gpupdate /force. Jeżeli po tym poleceniu wartość ponownie przyjmuje wcześniejszy stan, jest to istotna wskazówka, że konfiguracja jest zarządzana przez zasady grupy albo zależny mechanizm systemowy.

Raport zastosowanych zasad można wygenerować poleceniem gpresult /h raport-gpo.html, uruchomionym w odpowiednim kontekście uprawnień. Raport pokazuje zasady zastosowane dla komputera i użytkownika oraz pomaga wskazać, która konfiguracja ma wpływ na działanie systemu. Przydatna jest również konsola Resultant Set of Policy, uruchamiana poleceniem rsop.msc, ponieważ przedstawia wynikową konfigurację zamiast samej listy dostępnych obiektów zasad. W bardziej szczegółowej analizie warto porównać czas modyfikacji wpisu z dziennikami zdarzeń związanymi z przetwarzaniem Group Policy oraz sprawdzić, czy wartość nie jest ustawiana przez skrypt logowania, zadanie harmonogramu, usługę zarządzającą albo aplikację wdrażającą własną konfigurację.

Bezpieczna korekta konfliktu konfiguracji

Jeżeli ustalono, że wpis rejestru jest kontrolowany przez zasadę grupy, ręczna edycja rejestru nie jest właściwą metodą trwałej korekty. Zmiana powinna zostać wykonana w źródle, które zarządza ustawieniem, czyli w odpowiednim obiekcie zasad grupy, skrypcie lub narzędziu wdrożeniowym. Przed modyfikacją należy ustalić, czy zasada dotyczy komputera, użytkownika, konkretnej jednostki organizacyjnej oraz czy nie jest wymuszana z wyższego poziomu. Usunięcie wpisu z rejestru może dodatkowo spowodować powrót wartości domyślnej albo ponowne utworzenie wpisu podczas kolejnego przetwarzania zasad.

Jeżeli komputer nie powinien otrzymywać danej zasady, przyczyną może być błędne członkostwo w jednostce organizacyjnej, niewłaściwe filtrowanie zabezpieczeń lub niezamierzone dziedziczenie. Korekta wymaga wtedy weryfikacji struktury zasad, a nie przypadkowego nadpisywania wartości lokalnie. Po zmianie konfiguracji należy ponownie wykonać odświeżenie zasad, wygenerować raport wynikowy i sprawdzić zachowanie systemu po ponownym zalogowaniu. Jeżeli wartość nadal jest nadpisywana, trzeba kontynuować śledzenie źródła zapisu, ponieważ podobny efekt może powodować skrypt, usługa albo aplikacja uruchamiana przy starcie systemu.