Zmiany wprowadzone w menedżerze są ignorowane

Zmiany wprowadzone w menedżerze ignorowane wskazują na politykę GPO o wyższym priorytecie nadpisującą lokalną konfigurację.

Dlaczego ustawienie z menedżera nie zostaje zapisane

Komunikat lub objaw polegający na ignorowaniu zmian wprowadzonych w menedżerze systemu Windows zwykle oznacza, że wybrane ustawienie jest kontrolowane przez zasady grupy, czyli mechanizm Group Policy. Zasada może pochodzić z konfiguracji lokalnej komputera albo z zasad przypisanych do użytkownika lub urządzenia w środowisku zarządzanym centralnie. W takiej sytuacji wartość widoczna w menedżerze nie musi być wartością nadrzędną. Interfejs pozwala czasem wprowadzić zmianę, ale późniejsze przetworzenie zasad przywraca wartość określoną przez administratora.

Group Policy służy do wymuszania ustawień systemowych i aplikacyjnych. Może określać między innymi dostęp do funkcji systemu, ustawienia zabezpieczeń, konfigurację składników Windows, zachowanie usług oraz wybrane parametry programów obsługujących zasady administracyjne. Jeżeli lokalna konfiguracja wskazuje jedną wartość, a zasada grupy inną, system stosuje regułę o wyższym priorytecie. Dlatego ponowne wpisanie tej samej wartości w menedżerze nie rozwiązuje problemu, jeśli źródło ustawienia znajduje się poza tym interfejsem.

Hierarchia zasad i ponowne przetwarzanie konfiguracji

Zasady grupy są przetwarzane według określonej hierarchii. W środowisku domenowym znaczenie mogą mieć zasady lokalne, zasady witryny, domeny oraz jednostki organizacyjnej. Obowiązuje model LSDOU: Local, Site, Domain, Organizational Unit. Zasady przetwarzane później mogą zastąpić wcześniejsze, jeżeli dotyczą tego samego ustawienia. Dodatkowo administrator może użyć dziedziczenia, wymuszenia zasady albo filtrowania zabezpieczeń, przez co konkretne urządzenie lub konto otrzymuje konfigurację inną niż pozostałe komputery.

Sam fakt, że zmiana była możliwa w konsoli administracyjnej, nie oznacza, że została zaakceptowana przez system jako obowiązująca. Po odświeżeniu zasad ustawienie może zostać nadpisane ponownie. Przetwarzanie odbywa się między innymi podczas uruchamiania komputera i logowania użytkownika, a także po ręcznym odświeżeniu. Do tego celu służy polecenie gpupdate /force. Polecenie wymusza ponowne zastosowanie zasad, więc w opisanym przypadku może ujawnić problem: po odświeżeniu wartość wraca do poprzedniego stanu.

Nie każde ustawienie jest widoczne w ten sam sposób. Zasada może być skonfigurowana jako włączona, wyłączona albo nieustawiona. W wielu szablonach administracyjnych stan „włączona” nie oznacza uruchomienia funkcji, lecz aktywowanie konkretnej wartości konfiguracyjnej. Z tego powodu trzeba sprawdzić nazwę zasady, jej stan oraz ustawienie, które zasada faktycznie modyfikuje. Błędna interpretacja tych trzech elementów może prowadzić do wniosku, że menedżer działa nieprawidłowo, choć system wykonuje przypisaną regułę.

Ustalenie źródła nadpisywanej wartości

Pierwszym krokiem diagnostycznym jest porównanie wartości przed odświeżeniem zasad i po wykonaniu gpupdate /force. Jeżeli ustawienie zmienia się ponownie po odświeżeniu, prawdopodobną przyczyną jest aktywna zasada grupy albo inny mechanizm zarządzania konfiguracją. Pomocne jest polecenie gpresult /r, które pokazuje skrócone informacje o zastosowanych zasadach dla komputera i użytkownika. Raport HTML można wygenerować poleceniem gpresult /h raport-gpo.html, uruchomionym w odpowiednim kontekście administracyjnym.

W przypadku komputera działającego bez domeny należy sprawdzić zasady lokalne w Edytorze lokalnych zasad grupy, uruchamianym poleceniem gpedit.msc w edycjach Windows, które udostępniają ten komponent. Konfiguracja komputera i konfiguracja użytkownika są rozdzielnymi gałęziami, dlatego trzeba przeanalizować obie. Warto również ustalić, czy problem dotyczy jednego konta, wszystkich kont, czy tylko jednego urządzenia. Taki podział pomaga rozróżnić zasadę użytkownika od zasady komputera.

Jeżeli raport zasad nie wskazuje oczekiwanego ustawienia, nie można automatycznie uznać, że problem nie jest związany z zarządzaniem konfiguracją. Niektóre programy korzystają z własnych mechanizmów polityk, wpisów rejestru, plików konfiguracyjnych albo ochrony przed zmianami. Wtedy trzeba zidentyfikować dokładny menedżer, nazwę ustawienia i moment, w którym wartość wraca do poprzedniego stanu. Usuwanie wpisów rejestru lub przypadkowe wyłączanie usług bez ustalenia źródła zasady może spowodować dodatkowe problemy.

Naprawa konfliktu konfiguracji w systemie Windows

Trwałe usunięcie objawu wymaga zmiany konfiguracji w miejscu, które ma prawo nadpisywać ustawienie. Jeśli wartość pochodzi z domenowej zasady grupy, korekta musi zostać wykonana w odpowiednim obiekcie zasad przez administratora środowiska. Zmiana lokalna na komputerze nie zastąpi reguły domenowej. Jeśli problem powoduje zasada lokalna, można przejrzeć właściwą gałąź Edytora lokalnych zasad grupy i ustawić politykę jako „Nie skonfigurowano”, o ile nie koliduje to z wymaganiami bezpieczeństwa lub konfiguracją organizacji.

Po korekcie należy ponownie odświeżyć zasady, sprawdzić raport gpresult i zweryfikować wartość w menedżerze, którego dotyczył problem. Gdy ustawienie nadal jest przywracane, trzeba porównać zakres zasady, filtrowanie, dziedziczenie oraz ewentualne zasady wymuszone. Warto też sprawdzić Podgląd zdarzeń, szczególnie dzienniki związane z przetwarzaniem zasad grupy, ponieważ mogą wskazać błąd dostępu, niedostępność kontrolera domeny albo problem z zastosowaniem określonego rozszerzenia zasad.

Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, w tym diagnostykę problemów z konfiguracją systemu Windows. W przypadku ignorowanych zmian analizuje się zależność między interfejsem menedżera, lokalnymi zasadami grupy, raportem zastosowanych polityk oraz zachowaniem systemu po ponownym uruchomieniu lub odświeżeniu konfiguracji.