Freigeben über


Szenariohandbuch: Hintergrundrichtlinienobjekt gilt nicht auf einigen Clientcomputern

In diesem Szenario wird erläutert, wie Sie TroubleShootingScript (TSS) verwenden, um Daten zu sammeln, um ein Problem zu beheben, bei dem das Hintergrundgruppenrichtlinienobjekt (Group Policy Object, GPO) auf einigen Clientcomputern nicht angewendet wird.

Anwenden von Gruppenrichtlinien auf Clientcomputern

  1. Der Gruppenrichtliniendienst auf dem Clientcomputer listet den distinguished name (DN) des Benutzerkontos auf.
  2. Der Gruppenrichtliniendienst listet die GPLINK - und GPOptions-Attribute des Benutzerkontos in der Reihenfolge des lokalen Gruppenrichtlinienobjekts, des Websiterichtlinienobjekts, der Domäne und der Organisationseinheit (OU) auf.
  3. Der Gruppenrichtliniendienst erstellt eine Liste der GPOs, die angewendet oder verweigert werden sollen.

Weitere Informationen finden Sie unter Anwenden von Gruppenrichtlinien und Filtern des Gültigkeitsbereichs eines Gruppenrichtlinienobjekts.

Handbuch zur Problembehandlung

Bevor Sie fortfahren, lesen Sie den Leitfaden zur Problembehandlung von Gruppenrichtlinien.

Umgebung

  • Domänenname: contoso.com
  • Active Directory-Standorte: vier Standorte (zwei Domänencontroller pro Standort) (Phoenix, London, Tokio und Mumbai)
  • Anzahl der Domänencontroller: acht
  • Betriebssystem des Domänencontrollers: Windows Server 2019
  • Betriebssystem des Clientcomputers: Windows 11, Version 22H2

Diagramm der Topologie der Umgebung.

Inhalt dieses Szenarios

Bevor wir mit der Problembehandlung beginnen, finden Sie hier einige Bereichsfragen, die uns helfen können, die Situation zu verstehen und die Ursache des Problems einzugrenzen:

  1. Was sind die Client- und Serverbetriebssysteme?
    Antwort: Windows Server 2019-Domänencontroller und Windows 11, Version 22H2-Clientcomputer.

  2. Haben alle Benutzer das Problem oder nur einige Benutzer?
    Antwort: Das Problem tritt auf, wenn sich ein Benutzer am Standort Tokio bei einem Clientcomputer anmeldet. Wenn sich derselbe Benutzer jedoch von einem Clientcomputer auf der Phoenix-Website anmeldet, gilt die Hintergrundbildrichtlinie in Ordnung.

  3. Welche Einstellungen werden mit dem Wallpaper-GPO-Tokyo-GPO konfiguriert?
    Antwort: Es gibt einige Einstellungen, und die wichtigste einstellung ist eine benutzerseitige Einstellung mit der folgenden Konfiguration:

    • Pfad: Benutzerkonfiguration\Administrative Vorlagen\Desktop\Desktop\Desktop-Hintergrundbild
    • GPO-Einstellung: Aktiviert
    • Hintergrundbildspeicherort: \contoso.com\netlogon\home.jpg
    • Hintergrundformat: Anpassen

    Screenshot der GPO-Einstellungen.

  4. Ist das Wallpaper-GPO-Tokyo GPO ein neues GPO oder ein altes GPO im Bereich der Tokyo OU?
    Antwort: Dies ist ein neues Gruppenrichtlinienobjekt, das wir auf der Phoenix-Website konfiguriert haben, und dieses Gruppenrichtlinienobjekt wurde vor ein paar Tagen erstellt.

  5. Wenn Sie ausgeführt werden gpupdate /force /target:user, beobachten Sie Fehlermeldungen auf den funktionierenden und fehlerhaften Computern?
    Antwort: Es tritt kein Fehler auf, wenn wir auf dem funktionierenden oder dem fehlerhaften Clientcomputer ausgeführt gpupdate /force werden.

  6. Werden die alten GPOs angewendet, und nur dieses Gruppenrichtlinienobjekt ist nicht?
    Antwort: Wir stellen fest, dass die alten GPOs angewendet werden, und nur dieses neue Hintergrundrichtlinienobjekt wird nicht angewendet.

  7. Beachten Sie, dass alle Benutzer, die dieses Gruppenrichtlinienobjekt aus Tokio haben, nicht angewendet werden, oder wird dieses Problem nur für einige Teilmengen von Benutzern beobachtet?
    Antwort: Alle Benutzer im Umfang dieses Gruppenrichtlinienobjekts von der Tokyo-Website haben dieses Problem, aber die gleichen Benutzer, wenn sie sich von einem Clientcomputer auf der Phoenix-Website anmelden, treten das Problem nicht auf.

Problembehandlung

Zunächst müssen wir Daten sowohl auf einem Clientcomputer auf Phoenix als auch auf einem Clientcomputer auf Tokio sammeln. Führen Sie die folgenden Schritte auf jedem Computer aus:

  1. Laden Sie TSS herunter, und extrahieren Sie die ZIP-Datei in den Ordner "C:\temp". Erstellen Sie den Ordner, falls er nicht vorhanden ist.

  2. Melden Sie sich mit dem Benutzerkonto an, das das Problem auftritt.

  3. Öffnen Sie einen PowerShell-Befehl mit erhöhten Rechten, und führen Sie den Befehl aus:

    Set-ExecutionPolicy unrestricted
    

    Screenshot des Befehlsergebnisses

  4. Wechseln Sie zu "c:\temp\TSS", wo Sie die TSS-ZIP-Datei extrahiert haben.

  5. Führen Sie .\TSS.ps1 -Start -Scenario ADS_GPOEx aus. Akzeptieren Sie den Vertrag, und warten Sie, bis das TSS mit dem Sammeln von Daten beginnt.

    Screenshot des TSS-Tools.

  6. Öffnen einer normalen Eingabeaufforderung als Benutzer und Ausführen gpupdate /force /target:user

  7. Wenn die Verarbeitung abgeschlossen ist, drücken Sie Y auf dem PowerShell-Befehl, in dem Sie TSS ausführen.

    Screenshot des TSS-Toolergebnisses.

  8. TSS beendet das Sammeln von Daten, und die gesammelten Daten befinden sich im Ordner "C:\MSDATA " als ZIP-Datei oder als Ordner mit dem Namen TSS_<Machinename>_<Time>_ADS_GPOEx.

Weitere Informationen zu TSS finden Sie in der Einführung in das TroubleShootingScript-Toolset (TSS).

GPResult vergleichen

Wechseln Sie auf beiden Computern zum Ordner "c:\msdata ", in dem TSS alle Berichte gespeichert hat, und extrahieren Sie dann den Inhalt der ZIP-Datei. Überprüfen Sie die Datei mit dem Namen <Clientmachinename>_<Time>GPResult-H_Stop.html.

Wechseln Sie zum Abschnitt " Benutzerdetails ". Das betreffende GPO, Wallpaper-GPO-Tokyo, ist in der angewendeten Liste auf der Arbeitsmaschine und nicht in der defekten Maschine vorhanden.

Notiz

Es gibt andere GPOs wie Mapped-Drive und Phoenix-SiteGPO auf den angewendeten Computern. Diese beiden GPOs sind jedoch GPOs auf Standortebene und gelten nur, wenn der Gruppenrichtlinienclient erkennt, dass sich der Clientcomputer auf dem Phoenix-Standort befindet. Daher sind sie für unseren Problembehandlungsbereich nicht relevant.

Screenshot der Ergebnisse des gpresult-Befehls.

Vergleichen von Ereignisprotokollen

Die Betriebsprotokolle für Gruppenrichtlinien enthalten weitere Informationen zur Verarbeitung. Öffnen Sie beide GPO-Betriebsprotokolle, um die <Datei Machinename-Microsoft-Windows-GroupPolicy-Operational.evtx> aus der TSS-Ausgabe zu vergleichen.

Tipp

Die Gruppenrichtlinien-Startereignis-ID ist 4116, und das Endereignis der Gruppenrichtlinie ist 8005.

Sortieren Sie die Ereignisprotokolle in chronologischer Reihenfolge. Suchen Sie nach Ereignis 4116, und führen Sie einige wichtige Ereignisse in richtung aufwärts. Bei der Überprüfung der Funktionierenden und der fehlerhaften Clients besteht der einzige Unterschied darin, dass der fehlerhafte Clientcomputer seine Gruppenrichtlinie von DC6.contoso.com auf dem Standort Tokio erhält.

Screenshot der Betriebsereignisprotokolle.

Die Ereignis-ID 5312 gibt an, dass der Gruppenrichtliniendienst festgestellt hat, dass er fünf GPOs auf dem Arbeitscomputer und drei GPOs auf dem fehlerhaften Computer verarbeiten muss. Wie wir bereits diskutiert haben, sind die Phoenix-SiteGPO und Mapped-Drive GPOs gpOs auf Standortebene, und der einzige Unterschied besteht darin, dass das Wallpaper-GPO-Tokyo-GPO nicht angewendet wird.

Zusammenfassung

Wenn wir die Ereignis-ID 5312 vom Arbeitscomputer mit dem fehlerhaften Computer vergleichen, stellen wir fest, dass der Gruppenrichtlinienclientdienst den Wallpaper-GPO-Tokyo nicht aufgezählt hat, wenn er mit DC6 verbunden ist. Wir bestätigen auch, dass der GPO-Bereich korrekt ist. Daher kann die Ursache des obigen Szenarios ein Problem mit der Active Directory-Replikation (AD) sein.

Das DFSR-Modul (Distributed File System Replication) ist von der AD-Replikation abhängig. Wenn die AD-Replikation unterbrochen wird, wird auch die DFSR-Replikation unterbrochen. Dies könnte zu dem Problem in unserem Szenario führen, bei dem sich das Gruppenrichtlinienobjekt nicht in der Liste "Angewendet" oder "Abgelehnt" befindet.

Notiz

Wenn die AD-Replikation einwandfrei funktioniert und DFSR-Unterbrechungen auftreten, tritt möglicherweise ein weiteres Problem auf, bei dem sich das Gruppenrichtlinienobjekt in der Liste "Verweigern" befindet.

Informationen zur Problembehandlung des AD-Replikationsproblems finden Sie unter Active Directory-Replikationsfehler 1722: Der RPC-Server ist nicht verfügbar. In diesem Szenariohandbuch haben wir einen fehlerhaften Router entdeckt, der den RPC-Port zum Tokio-Standort blockiert, was zu einem AD-Replikationsproblem führte.