Jump to content

Revan

Newbie
  • Content Count

    147
  • Joined

  • Last visited

Community Reputation

11 Neutral

About Revan

  • Rank
    Newbie

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Bei uns ist es so das die UTM als Zeitquelle für die DCs dient und selber mit ntp pool synchronisiert. Trotzdem muss man in der UTM selber dem DC den Zeitabgleich erlauben. Da die DCs eben nicht mit ntp pool kommunizieren kam mir der Gedanke halt erst später ;)
  2. Möchte mich noch mal bei allen bedanken für die Hilfe
  3. Die VMWare Hosts haben die DCs als Zeitquelle. Habe gerade die Settings vom KB Article in die VM eingetragen (Danke für den Tip) und die GPO wieder aktiviert. Leider keine Änderung, w32tm zeigt immer noch Local CMOS Clock Die anderen VMs (und auch die physischen Clients) haben nun alle den zweiten DC als Zeitquelle. Dieser hat die UTM als Zeitquelle. Der war allerdings noch nie PDC Emulator noch ist er es jetzt. Edit: Während ich diesen Text schreibe fällt mir ein das ich in der UTM dem neuen DC noch erlauben muss das er als NTP Client Zeit abholen darf. Nachdem ich den neuen DC eingetragen habe funktioniert es jetzt.
  4. Da stehts richtig drin NTPServer und Type. Sonst keine Einträge Nochmal Edit: Habe testweise die GPO mal deaktiviert und nochmal per w32tm /config... manuell gesetzt, Dienst neu gestartet. Trotzdem gibt ein query immer noch Local CMOS Clock aus. Kann das ein Anzeigefehler sein?
  5. HKEY_LOCAL_MACHINE\SYSTEM\CUrrentControlSet\Services\W32Time\Parameters Unregister/register eben probiert, ohne Erfolg Habe jetzt doch mal versucht, den Eintrag manuell zu setzen mit w32tm /config /syncfromflags:manual /update /reliable:yes /manualpeerlist:"vutm.xxx.xx" Befehl wurde erfolgreich ausgeführt, dann starte ich den Zeitdienst neu, gebe w32tm /query /source ein und bekomme immer noch Local CMOs Clock zurück.
  6. ok, in der Registry steht unter NTP server immer noch time.windows.com und als Type NT5DS Dann wird die GPO doch nicht übernommen obwohl der Richtlinienergebnissatz was anderes sagt Meine GPO sieht so aus:
  7. Tjaa, die Idee hatte ich natürlich auch. Im Eventlöog steht dies, zum Zeitpunkt, an dem ich dem Server die PDC Rolle übergeben habe: Zeitanbieter "NtpClient": Dieser Computer ist für die Verwendung der Domänenhierarchie zum Ermitteln der Zeitquelle konfiguriert. Er ist aber der PDC-Emulator der Domäne, der erste Computer in der Gesamtstruktur. Daher gibt es keinen Computer oberhalb der Domänenhierarchie, der als Zeitquelle verwendet werden kann. Es wird empfohlen, dass Sie entweder einen zuverlässigen Zeitdienst in der Stammdomäne konfigurieren oder den PDC manuell zur Synchronisierung der externen Zeitquelle konfigurieren. Andernfalls wird dieser Computer als verbindliche Zeitquelle in der Domänenhierarchie ausgeführt. Wenn keine externe Zeitquelle konfiguriert ist, bzw. von dem Computer nicht verwendet wird, kann der NtpClient deaktiviert werden. Ansonsten noch einige Male: Der Zeitdienst wird als gute Zeitquelle angekündigt. Nach einem Server Neustart gibt die Abfrage nach der Zeitsource nun sogar "Local cmos clock" an.
  8. GPO wurde auf dem neuen DC übernommen und auf dem alten DC entfernt. Geht jetzt nach >1h aber noch immer nicht
  9. Hallo, ich möchte meine alten DCs (2008R2) durch neuere (2012R2) ersetzen. Der neue DC hat die FSMO Rolle PDC Emulator bekommen und ich habe eine GPO in der per WMI Filter der PDC Emulator einen Zeitserver zugewiesen bekommt. Alle anderen DCs sollen sich die Zeit vom PDC holen. Das hat bisher mit dem alten PDC einwandfrei funktioniert. Leider zeigt der neue DC immer noch auf den alten PDC Emulator und dieser wie gehabt auf die externe Zeitquelle. Ich möchte dem neuen DC nun nicht gerne manuell eine peerlist zuteilen sondern weiterhin meine GPO dafür nutzen. rsop zeigt auch das die Richtlinie übernommen wurde Dauert die Übernahme einfach noch eine Weile oder muss der Server dafür neu gestartet werden?
  10. Das war der richtige Tip, wir benutzen die Sophos UTM als Smarthost. Hier gibt es eine Funktion, den Header zu modifizieren und ich konnte damit den ersten Hop mit der internen IP entfernen. Vielen Dank für deine Hilfe
  11. Ja genau, der zweite ist die externe IP. Get-SendConnector "Internet" | Get-ADPermission | Where-Object { $_.extendedrights -like "*routing*" } | fl user User : domain\Exchange Servers User : MS Exchange\Partner Servers User : MS Exchange\Hub Transport Servers User : MS Exchange\Edge Transport Servers User : MS Exchange\Externally Secured Servers User : MS Exchange\Legacy Exchange Servers Sollte so passen oder? Noch mal entfernen schlägt jetzt wieder fehl mit der gleichen Fehlermeldung wie aus Post 1 Ich hab testweise die Berechtigung wieder erteilt. Get-SendConnector "Internet" | Add-ADPermission -User "NT-AUTORITÄT\ANONYMOUS-ANMELDUNG" -ExtendedRights ms-Exch-Send-Headers-Routing Jetzt bekomme ich in Hop1 den fqdn des Exchange, in Hop2 den fqdn + interne IP, in Hop3 den externen hostnamen + interne ip und in Hop4 den externen hostnamen + externe ip >Get-SendConnector "Internet" | Get-ADPermission | Where-Object { $_.extendedrights -like "*routing*" } | fl user zeigt jetzt: User : NT-AUTORITÄT\ANONYMOUS-ANMELDUNG User : domain\Exchange Servers User : MS Exchange\Partner Servers User : MS Exchange\Hub Transport Servers User : MS Exchange\Edge Transport Servers User : MS Exchange\Externally Secured Servers User : MS Exchange\Legacy Exchange Servers Es ändert sich also schon etwas. Ich dachte allerdings das die interne IP gar nicht mehr mitgesendet wird wenn das Recht entzogen wurde
  12. Entschuldige, was meinst du damit? Ein Header, 5 Hops, im ersten Hop steht die interne IP des sendenden Exchange
  13. Nein, leider nicht. Habe jetzt auch mal den Transport Service neu gestartet. Hat aber auch nicht geholfen.
×
×
  • Create New...