Bitdrop

Ich hab mich etwas falsch ausgedrückt. Der DC zieht die neu angelegte GPO nicht. sondern ausschlieslich die Default Policy. In dieser ist eben wie in der Anleitung auf gruppenrichtlinien.de die Konfiguration für alle anderen Mitglieder der Domäne enthalten (z.B. NTP Typ=NT5DS und das darf ja für den DC nicht sein da er sich die Zeit ja von der Firewall holen soll und diese mit NTP="IP Adresse der Firewall" angegeben ist.)


Arrrghh... manchmal muss man echt alles 3 mal lesen. Ich habe meinen Fehler gefunden. Das Problem war einfach die ganze Zeit das abarbeiten der GPO's. Was für ein sch**** ich ärger mich selbst über mich. Au man. Mir hat die ganze Zeit die Default Domain Policy dazwischen gefunkt. Ich hab das jetzt mal angepasst und schon funktioniert alles so wie es soll.

Ich frage mich allerdings warum das Problem erst jetzt aufgetreten ist. Hmmm oder es wurde vorher einfach nie bemerkt.

Besten Dank für eure Hinweise und Hilfestellungen.

Ich habe mal mit rsop auf dem DC nach gesehen.
Jetzt ist mir aufgefallen das der DC die Default Domain Policy zieht, statt die extra erstelle neue GPO mit dem WMI Filter.

 

Das dürfte wohl der Grund sein warum das Ganze nicht funktioniert. Jetzt muss ich ja nur noch raus finden warum der DC die Default Policy zieht und nicht die für ihn vorgesehene Policy

Okay also ich habe das Ganze jetzt mal so ausgeführt, wie es hier https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo beschrieben ist.

Im Log des DC tauchen 5 Ereignisse auf:

 

-Der Zeitdienst wird als Zeitquelle angekündigt.

-Der Zeitdienst wird als gute Zeitquelle angekündigt.

-Aufgrund eines Ermittlungsfehlers konnte von "NtpClient" kein Domänenpeer als Zeitquelle festgelegt werden. In 15 Minuten wird ein weiterer Versuch ausgeführt und das Intervall für weitere Versuche anschließend verdoppelt Fehler: Der Eintrag wurde nicht gefunden. (0x800706E1)

-Dienst "Windows-Zeitgeber" befindet sich jetzt im Status "Ausgeführt".
-Aufgrund eines Ermittlungsfehlers konnte von "NtpClient" kein Domänenpeer als Zeitquelle festgelegt werden. In 15 Minuten wird ein weiterer Versuch ausgeführt und das Intervall für weitere Versuche anschließend verdoppelt Fehler: Der Eintrag wurde nicht gefunden. (0x800706E1)

 

Die neue Gruppenrichtlinie wurde laut Log angewandt.

Die Zeit hinkt nach wie vor eine knappe Minute hinterher.

 

Nur mal zum Verständnis (ich zweifel hier schon an mir selbst)

Sollte die GPO nicht die Einstellungen in der Registry, die ich vorher per Hand abgeändert habe, überschreiben? Denn dort stehen noch die alten Werte drin (NTP Server)

Zitat

Ja, links im Ergebnis zeigt er die lokale Zeit an, in diesem Fall die falsche.

Richtig, was bringt mir dann aber das Kommando?

 

Zitat

Wo warst du denn die letzten 22 Jahre? ;)

Ohweh... Ich hab glaub ich schon Matsch im Kopf :-D Ich werd es mal damit probieren.

Moin,

besten Dank schon mal für die Antworten.
 

Zitat

Vielleicht hilft ja das, anstatt da von Hand rumzufummeln. https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo

Werden die Einstellungen nicht von den "Händischen" überschrieben? Ansonsten würde ich das nochmal versuchen.

Ein Neustart hat leider auch nicht geholfen.

Zitat

Ansonsten sicherstellen, dass deine VM definitiv die Zeit nicht vom VMware-Host erhält

Das ist nicht der Fall. Also die Zeit wird definitiv nicht vom VMware Host geholt.
 

Zitat

w32tm /stripchart /computer:<IP-der-Firewall>

Das zeigt mir witzigerweise, genau die falsche Zeit an. Also nicht die Zeit der Firewall, sondern die Zeit des PDC.

Ich habe es nun schon mit /unregister und /register versucht, wie es halt viele Anleitungen im Netz beschreiben. Alles ohne Erfolg. Die Zeit bleibt "falsch" und die Quelle bleibt Local CMOS Clock.

 

Da werd ich mich mal mit den GPO's beschäftigen.

Hallo miteinander,

 

ich bin langsam echt am verzweifeln. Ich hoffe ihr könnt mir hierbei helfen.

 

Folgende Lage:
Windows Server 2016 (PDC, Zeitserver für alle andere Clients/Server in der Domäne). läuft als VM in VMware.

Die Uhrzeit auf dem Server geht um circa 45 Sekunden "hinterher". Ist es auf dem Server 15:00, ist es auf allen anderen Geräten schon 15:01. Das klingt erst mal nicht schön, aber eigentlich auch nicht richtig schlimm. Die Sache ist aber das sich auch unsere Zeiterfassung die Uhrzeit vom PDC holt. Somit könnte einem theoretisch jeden Tag eine knappe Minute Arbeitszeit fehlen. (Ja... es gibt Menschen die nach Punkt 8 Stunden den Hammer fallen lassen wollen).
 

Der Aufbau ist folgender:

Firewall holt sich aus dem Internet die korrekte Zeit <-- Funktioniert

Server 2016 (PDC) soll sich die Zeit von der Firewall holen <-- Funktioniert nicht

Alle anderen holen sich die Zeit vom Server 2016 (PDC) <-- Funktioniert

 

Die Firewall holt sich die korrekte Zeit aus dem Internet, das klappt. Jetzt fängt es aber schon an:

Wenn ich auf dem Server 2016 in der Registry schaue steht dort folgendes:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters

NtpServer: (IP der Firewall) 1.pool.ntp.org 2.pool.ntp.org

 

Also insgesamt 3 Zeitserver die theoretisch zum holen der Zeit da wären.

 

 Type = NTP

 

soweit so gut.

 

Also weiter in der Powershell/CMD

w32tm /query /status

 

Sprungindikator: 0(keine Warnung)
Stratum: 1 (Primärreferenz - synchron. über Funkuhr)
Präzision: -6 (15.625ms pro Tick)
Stammverzögerung: 0.0000000s
Stammabweichung: 10.0000000s
Referenz-ID: 0x4C4F434C (Quellname:  "LOCL")
Letzte erfolgr. Synchronisierungszeit: 24.01.2023 15:49:55
Quelle: Local CMOS Clock
Abrufintervall: 6 (64s)

 

Jetzt ist die Frage warum hier auf einmal Local CMOS Clock steht

 

Also weiter in der Powershell/CMD
 

 

w32tm /query /peers

Anzahl Peers: 1

Peer:
Status: Ausstehend
Verbleibende Zeit: 1753.7860163s
Modus: 0 (Reserviert)
Stratum: 0 (nicht angegeben)
PeerAbrufintervall: 0 (nicht angegeben)

 

Da sollte doch bei Peer: Zumindest die IP der Firewall drin stehen (steht ja so auch in der Registry)

 

net stop w32time

net start w32time

 

Dienste gestoppt und erneut gestartet. Aber keine Veränderung.

 

Quelle bleibt auf Local CMOS Clock und in den Peers steht nichts drin.

Hat hier noch jemand eine Idee? Hab ich irgend etwas über sehen? Server wird heute Abend einmal neu gestartet aber ich denke daran wird es nicht liegen.

 

Beste Grüße

Ich habe nun eine neue VM erstellt und diese zum "nächsten" DC gemacht. Hat alles sehr gut funktioniert. Vielen Dank für die hilfreichen Antworten und Links hier .

 

 

Ja ist korrekt, es gibt noch einen zweiten DC. Deshalb brannte das Ganze jetzt noch nicht "komplett". Aber darauf möchte man sich auf dauer ja auch nicht verlassen.
 

Es wird dann auf eine neue VM und demzufolge auf einen neuen DC hinaus laufen.
 

vor einer Stunde schrieb NilsK:

 

Die Master-Rollen werden meist völlig überschätzt, so auch hier. Die sind kein Hindernis.

https://www.faq-o-matic.net/?s=betriebsmaster

 

Vielen Dank für den Hinweis

Mal sehen ob alles glatt geht .

Hallo Nobby,

 

das mit IPv6 ist mir auch aufgefallen. (Ich muss dazu sagen ich hab das hier so übernommen, bin noch nicht so lang hier - ist wohl Historisch gewachsen).
Allerdings machte das keinen Unterschied ob IPv6 nun aktiviert ist oder nicht.

 

Hier ist die Konstellation nun mal so das auf dem DC noch ein DHCP und ein DNS läuft. Sonst aber nix weiter.

 

vor 34 Minuten schrieb NilsK:

Moin,

 

warum würdest du das umgehen wollen?

 

Gruß, Nils

 

Einfach nur um 1. das Problem zu verstehen und 2. weiteren möglichen Problemen aus dem Weg gehen wenn man den PDC (Schemamaster etc. pp.) weg haut und einen Neuen aufsetzt. Gemacht ist das natürlich erst mal schnell. Ob dann aber alles so läuft wie es soll ist die Frage

Daher erst mal der Versuch das eigentliche Problem zu reparieren, statt radikal "neu" zu machen.

Hallo NorbertFE,

 

das war natürlich auch einer der ersten versuche. Das Problem ist das beim Installieren keine Auswahl für den Datei- und Druckerfreigabe-Dienst gibt.

Daher habe ich mir sogar schon die dazugehörige .inf Datei des zweiten DC's genommen. Allerdings funktionierte das auch nicht, da auch hier keine Auswahl für die Datei- und Druckerfreigabe da ist.

Hallo Nils,

 

ja, diese Option steht noch im Raum. Allerdings würde ich gern versuchen das zu umgehen. Daher auch die Frage hier im Forum.

 

Gruß

Bitdrop

Hallo,

 

ich benötige mal euer Schwarmwissen.

Seit kurzem ist es nicht mehr möglich per UNC auf einen Domaincontroller (DC01) bei uns im Netz zu kommen.

 

Also per \\DC01

 

Als Antwort erhält man nur "Konnte nicht zugegriffen werden" Fehlercode 0x80070035 Der Netzwerkpfad wurde nicht gefunden".

Also die üblichen verdächtigen abgeklappert. Es Handelt sich um einen alten Windows 2012 Server der noch als Domaincontroller fungiert.

Nun musste ich folgendes feststellen. In den Eigenschaften des Netzwerkadapters ist der Dienst "Datei- und Druckerfreigabe für Microsoft-Netzwerke" einfach gar nicht vorhanden. (Anhang Bild ETH2.png)

Normalerweise sollte das ja mehr oder weniger so aussehen wie im Anhang Bild ETH1

 

Hat hier jemand eine Idee? Oder bin ich einfach auf dem falschen Weg weil es nur ein Symptom eines anderen Fehlers ist?

 

Das Problem ist einfach das es sich um einen DC handelt und man per UNC nirgends hin kommt. Nicht mal auf den eigenen Sysvol oder NETLOGON Pfad kommt man per UNC. Folgt man dem Pfad "lokal" ist alles vorhanden und auch der Zugriff funktioniert. Sobald es über das Netzwerk geht, nicht mehr.

Die üblichen verdächtigen habe ich bereits kontrolliert.

Dienste (LanmanService, UPnP, SSDP, DCOM usw.)
Firewall ist deaktiviert

Antivirus (ausgeschaltet)

Netzwerkprofil (Domain)

Ereignisanzeige schmeißt nur folgefehler. (Kann auf Pfad \\domain.local\ordnerA\ordnerA\ nicht zugreifen. Nichts sinnvolles...

 

Auch wurde versucht den Dienst manuell über eine .inf Datei zu "installieren". Leider ohne Erfolg.

Achja: Das Ganze fing an als letzte Woche Updates installiert wurden. Diese sind mitlerweile deinstalliert, jedoch ohne Erfolg.
 

Um Hinweise wäre ich Dankbar...

 

Gruß

Bitdrop