Gruppenrichtlinien ohne Funktion nach Umzug

Guten Morgen,
nach einer Umzugsaktion, von einem Hyper V--> auf einen ESXI, treten nun leider Probleme auf, die vorher nicht vorhanden waren und wo ich nun am Ende Ideen bin.

Ausgangssituation:
Hyper V Server mit 9 VMs. Unter anderem auch zwei Terminalserver. Ein DC01, wurde irgendwann mal so eingerichtet, hatte zuletzt ja auch sauber funktioniert.
Die Maschinen wurden durch den Stand Alone Converter ausgeschaltet auf einen ESXI konvertiert.
Alle Maschinen wurden gestartet und VMWare Tools wurde installiert.
Ich habe denn getestet, ob alles erreichbar und funktionsfähig ist.
Danach wurde der Hyper V zum ESXI umgestellt und die VMs wurden erneut ausgeschaltet vom ESXI zum neuen ESXI konvertiert.
Hier wurden alle VMs erneut eingeschaltet und es wurde alles auf Funktion geprüft und soweit ist auch alles ok.

Nun sollte eine Änderung innerhalb der Ordner durchgeführt werden, sprich es sollte ein Ordner angelegt werden für 2 Gruppen. Soweit so gut.
Gruppenrichtlinie erstellt, Gruppen erstellt und zugewiesen. Gruppenrichtlinie wurde verknüpft.

Leider greifen die neuen Einstellungen nicht, die neuen Laufwerke werden bei den entsprechenden Gruppen nicht angewendet. Um Fehler auszuschließen noch mal probiert, jedoch ohne Erfolg.
gpresult zeigt denn aber auch bei der Ausführung: das die Gruppenrichtlinien nicht angewendet werden.

nach einigen Stunden der Ursachen, dann dcdiag ausgeführt, was zu einer Reihe von Fehlern führt, jedoch der wichtigste über den ich stolperte ist:

Starting test: DFSREvent
         Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse
         vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.

da hier im Grunde die Möglichkeit des Fehlers bereits genannt wird, liegt hier mein Augenmerk, jedoch finde ich keine plausible Lösung, hat hier jemand eine Idee?

Ein weiterer sich wiederholender Fehler lautet:

Starting test: SystemLog
         Fehler. Ereignis-ID: 0x00009006
            Erstellungszeitpunkt: 01/18/2024   06:55:30
            Ereigniszeichenfolge:
            Schwerwiegender Fehler beim Zugriff auf den privaten Schlüssel der Server-Anmeldeinformationen für TLS. Der vom kryptografischen Modul zurückgegebene Fehlercode lautet 0x8009030D. Der interne Fehlerstatus ist 10001.
         Fehler. Ereignis-ID: 0xC0003AAD
            Erstellungszeitpunkt: 01/18/2024   06:55:30
            Ereigniszeichenfolge:
            Bei der Verwendung der SSL-Konfiguration für den Endpunkt 0.0.0.0:11000 ist ein Fehler aufgetreten. Der Fehlerstatuscode ist in den zurückgegebenen Daten enthalten.
         Fehler. Ereignis-ID: 0x00009006
            Erstellungszeitpunkt: 01/18/2024   06:55:30
            Ereigniszeichenfolge:
            Schwerwiegender Fehler beim Zugriff auf den privaten Schlüssel der Server-Anmeldeinformationen für TLS. Der vom kryptografischen Modul zurückgegebene Fehlercode lautet 0x8009030D. Der interne Fehlerstatus ist 10001.
         Fehler. Ereignis-ID: 0xC0003AAD
            Erstellungszeitpunkt: 01/18/2024   06:55:30
            Ereigniszeichenfolge:
            Bei der Verwendung der SSL-Konfiguration für den Endpunkt 0.0.0.0:11000 ist ein Fehler aufgetreten. Der Fehlerstatuscode ist in den zurückgegebenen Daten enthalten.
         Fehler. Ereignis-ID: 0x00009006
            Erstellungszeitpunkt: 01/18/2024   06:59:39
            Ereigniszeichenfolge:
            Schwerwiegender Fehler beim Zugriff auf den privaten Schlüssel der Server-Anmeldeinformationen für TLS. Der vom kryptografischen Modul zurückgegebene Fehlercode lautet 0x8009030D. Der interne Fehlerstatus ist 10001.

Dies wiederholt sich über gefühlt 100 Meldungen und wird beendet mit:

 ......................... Der Test SystemLog für DC01 ist fehlgeschlagen.

Mir fehlt nach aktuell der Ansatz und ich habe das Gefühl was völlig logisches zu übersehen.

Über Den Wink mit dem Zaunpfahl würde ich mich freuen.

LG
Thabs

Please also mark the comments that contributed to the solution of the article

Content-Key: 22114708630

Url: https://administrator.de/contentid/22114708630

Printed on: April 27, 2024 at 17:04 o'clock

7 Comments

Latest comment

Moin,

„Spannend“.
Würde zunächst einmal „ins Blaue“ prüfen, ob alle Systeme auch die korrekte Uhrzeit haben.
Abweichungen sind grundsätzlich Mist.

Ferner: stimmen an den NICs der DCs die hinterlegten DNS-Server? Wenn migriert wird, gibt es meistens ja neue NICs. Prüfe auch im GeräteManager, ob da die alten NICs noch drin sind. Die dann löschen:
https://support.microsoft.com/en-us/topic/device-manager-does-not-displa ...

Ich denke auch, eins von den dreien.

1. timestamp
2. DNS
3. Authentifizierung

Zu Punkt 3 von Tobi. Hast Du in der Ereignisanzeige unter Windows-Protokolle\System Eeignis-ID 4625 (...nach ID Filtern)?

Moin,

wurden denn nach der Installation der VMWare Tools die Netzwerkkarten neu konfiguriert? Das würde ich als erstes mal überprüfen.

Und als nächste die Eventlogs. Angefangen vom DC und dann alle Server.

Als Tipp noch: Wenn du nur einen DC hast, kannst du dessen DFS-R Events ignorieren (weil er ja eh keinen Replikationspartner hat)

lg,
Slainte

Zitat von @em-pie:

Moin,

„Spannend“.
Würde zunächst einmal „ins Blaue“ prüfen, ob alle Systeme auch die korrekte Uhrzeit haben.
Abweichungen sind grundsätzlich Mist.

Ferner: stimmen an den NICs der DCs die hinterlegten DNS-Server? Wenn migriert wird, gibt es meistens ja neue NICs. Prüfe auch im GeräteManager, ob da die alten NICs noch drin sind. Die dann löschen:
https://support.microsoft.com/en-us/topic/device-manager-does-not-displa ...

Ja, wobei ich solche Spannung weniger mag ;)
Also, ich habe mal die Zeit geprüft, die ist auf allen System richtig.
DNS 1. eigene IP (v4)
DNS 2. 127.0.0.1 (war vorher 8.8.8.8 lief aber auch damit)

Was meinst Du mit Authentifizierung genau?

Alse NICs habe ich entfernt im Gerätemanager, die waren ausgeblendet, daran habe ich nicht gedacht.

Der Fehler DFSR bleibt jedoch:

 Starting test: DFSREvent
         Für den Zeitraum der letzten 24 Stunden seit Freigabe des SYSVOL sind Warnungen oder Fehlerereignisse
         vorhanden. Fehler bei der SYSVOL-Replikation können Probleme mit der Gruppenrichtlinie zur Folge haben.
         ......................... Der Test DFSREvent für DC01 ist fehlgeschlagen.

Nun kommt ein weiterer Fehler hinzu:

 Starting test: KccEvent
         Warnung. Ereignis-ID: 0x80000BEB
            Erstellungszeitpunkt: 01/18/2024   09:27:14
            Ereigniszeichenfolge:
            Das Verzeichnis wurde so konfiguriert, dass bei LDAP-Add-Vorgängen keine Autorisierung pro Attribut erzwungen wird. Warnungsereignisse werden protokolliert werden, es werden jedoch keine Anforderungen blockiert.
         Warnung. Ereignis-ID: 0x80000BEE
            Erstellungszeitpunkt: 01/18/2024   09:27:14
            Ereigniszeichenfolge:
            Das Verzeichnis wurde so konfiguriert, dass implizite Besitzerberechtigungen beim anfänglichen Festlegen oder Ändern des nTSecurityDescriptor zugelassen werden. attribut während LDAP-Hinzufüge- und -Änderungsvorgängen. Warnungsereignisse werden protokolliert, aber es werden keine Anforderungen blockiert.
         Warnung. Ereignis-ID: 0x80000B46
            Erstellungszeitpunkt: 01/18/2024   09:27:24
            Ereigniszeichenfolge:
            Sie können die Sicherheit dieses Verzeichnisservers deutlich verbessern, indem Sie den Server so konfigurieren, dass SASL-Bindungen (Verhandlung, Kerberos, NTLM oder Digest), LDAP-Bindungen ohne Anforderung einer Signatur (Integritätsüberprüfung) und einfache LDAP-Bindungen über eine Klartextverbindung (ohne SSL-/TLS-Verschlüsselung) zurückgewiesen werden. Selbst wenn keine Clients derartige Bindungen nutzen, erhöht sich die Sicherheit des Servers durch diese Konfiguration beträchtlich.
         Warnung. Ereignis-ID: 0x80000BE1
            Erstellungszeitpunkt: 01/18/2024   09:27:24
            Ereigniszeichenfolge:
            Die Sicherheit dieses Verzeichnisservers kann erheblich verbessert werden, wenn der Server so konfiguriert wird, dass er  die Validierung von empfangenen Kanalbindungstoken erzwingt, die über LDAPS-Verbindungen gesendet werden. Selbst wenn keine Clients LDAP-Bindungsanforderungen über LDAPS ausgeben, wird die Sicherheit dieses Servers verbessert,  wenn der Server so konfiguriert wird, dass er Kanalbindungstoken überprüft.
         ......................... DC01 hat den Test KccEvent bestanden.

DNS Test:

PS C:\Users\administrator.xxxxx> dcdiag /test:dns

Verzeichnisserverdiagnose

Anfangssetup wird ausgeführt:
   Der Homeserver wird gesucht...
   Homeserver = DC01
   * Identifizierte AD-Gesamtstruktur.
   Sammeln der Ausgangsinformationen abgeschlossen.

Erforderliche Anfangstests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\DC01
      Starting test: Connectivity
         ......................... DC01 hat den Test Connectivity bestanden.

Primärtests werden ausgeführt.

   Server wird getestet: Default-First-Site-Name\DC01

      Starting test: DNS

         DNS-Tests werden ordnungsgemäß ausgeführt. Warten Sie einige Minuten...
         ......................... DC01 hat den Test DNS bestanden.

   Partitionstests werden ausgeführt auf: ForestDnsZones

   Partitionstests werden ausgeführt auf: DomainDnsZones

   Partitionstests werden ausgeführt auf: Schema

   Partitionstests werden ausgeführt auf: Configuration

   Partitionstests werden ausgeführt auf: xxxxx

   Unternehmenstests werden ausgeführt auf: xxxxx.local
      Starting test: DNS
         Testergebnisse für Domänencontroller:

            Domänencontroller: DC01.xxxxx.local
            Domäne: xxxxx.local


               TEST: Dynamic update (Dyn)
                  Warning: Failed to delete the test record dcdiag-test-record in zone xxxxx.local

         Zusammenfassung der Testergebnisse für die von den oben aufgeführten Domänencontrollern verwendeten DNS-Server:

            DNS-Server: 192.168.10.254 (<name unavailable>)
               1 Testfehler auf diesem DNS-Server
               PTR record query for the 1.0.0.127.in-addr.arpa. failed on the DNS server 192.168.10.254
               DC01                         PASS PASS PASS PASS WARN PASS n/a
         ......................... xxxxx.local hat den Test DNS bestanden.

DNS-Server: 192.168.10.254

wer ist die 192.168.10.254
Der DC oder ein Router (sieht nach Lancom aus)?

das ist eigentlich die Firewall, wo er das her holt ist mir auch gerade schleierhaft

254 ist weg. War die eingetragene Weiterleitung in den DNS Einstellungen (Firewall) für DNS Einträge die durch den Server nicht aufgelöst werden können.

Soooo: ALso es muss was mit dem DNS zutun haben, denn ich habe einfach mal als Laufwerksmapping die IP angegeben und siehe da, Laufwerk wurde sofort gemapped.
Gestolpert bin ich darüber gpresult zeigte einen Konflikt, ob der vorher schon da war und ich den übersehen habe, weis ich nicht.
Aber zumindest das ist jetzt geklärt, warum das mit dem DNS alles nicht läuft, muss ich rausfinden, aber vielleicht findet sich ja noch eine Idee hier bei jemandem.

German Question Windows Server