Der Exchange ADAccess Dienst prüft beim starten bzw. in regelmäßigen Abständen, welche Server mit welchen Rollen vorhanden sind (DC/GC) und auch ob diese Verfügbarkeit sind. Werden mehrere Server gefunden, verwendet Exchange die Server die in der eigenen site vorhanden sind. Die Auswertung der Server wird im Eventlog mit der ID 2080 protokolliert.
In einem Fall trat jedoch die Tage das Phänomen auf, dass Exchange aller Server mit der DC/GC Rolle fand, jedoch die in der eigenen site nicht akzeptierte. Das Problem ließ sich über die EventID 2080 lokalisieren. Auf den In-Site Servern fehlte die SACL Berechtigung
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=xxxx). Exchange Active Directory Provider has discovered the following servers with the following characteristics: (Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version) In-site: xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 0 1 7 1 xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 0 1 7 1 Out-of-site: xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 1 1 7 1 xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 1 1 7 1 xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 1 1 7 1 xxxxxxxxxxxxxxxxxxxxxx CDG 1 7 7 1 0 1 1 7 1For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
Aufgefallen ist dies, nachdem versucht wurde die Exchange Server über den Befehl Set-ExchangeServer an die In-Site DomainController bzw. GCs zu binden und die Server anschließend beim reboot hängen blieben. Nach dem setzten der Werte ergab das auslesen dieser, dass angeblich keine Server für StaticDomainControllers und StaticGlobalCatalogs gesetzt wurde. Der Reboot bestätigte jedoch, dass sie dennoch gesetzt worden sind. Angeblich sind die Werte nur über „| format-list“ sichtbar, was ich im nach hinen nicht mehr prüfen kann.
Die Lösung des Problems war auf jeden Fall, das setzten der Leseberechtigung auf den nTSecurityDescriptor für die Gruppe der Exchange Servers über ADSIEdit (Windows 2003 Support Tools x32, x64) sowie das anschließende ausführen des Setups mit dem Parameter /PrepareDomain.
setup.com /PrepareDomain
Dies kann entweder für einzelne Server (grün) oder für die OU (rot) der DomainController erfolgen.
Anschließend sollten die entsprechenden Domaincontroller neu gestartet werden. Ein Neustart der Exchange Server ist nicht notwendig gewesen, da der ADAccess Dienst diese Änderung selbstständig erkennt. Es kann jedoch etwas dauern, bis diese Änderung der Berechtigung sich auf die Exchange Server auswirkt. In meinem Fall haben die ersten Systeme nach 15-20 Minuten diese Änderungen bemerkt. Der letzte Server hat dies nach 1 1/2 Stunden mitbekommen.
Gruppenmitgliedschaft prüfen
Sollte dies nicht geholfen haben, prüfen Sie ob die Exchange Server Mitglied der Gruppe „Exchange Servers“ sind.
Default Domain Controllers Policy
Der nächste Schritt wäre die „Default Domain Controllers Policy“ zu kontrollieren. Unter folgendem Pfad gibt es die Richtlinie „Manage auditing and security log„. In dieser muss die Gruppe der Exchange Server auftauchen.
Nachdem dies nun sichergestellt ist, prüfen Sie bitte noch ob die DomainController auch die richtige Policy anwenden. Führen Sie dazu auf einem der CDs rsop.msc aus und navigieren zu erneut zur Policy „Manage auditing and security log„. Hier sollte nun zu erkennen sein, dass der DC die Richtlinien der „Default Domain Controllers Policy“ anwendet. Ist dies nicht der Fall, kontrollieren Sie bitte über gpmc.msc die Berechtigungen für die Policy. Die Gruppe „Authenticated Users“ muss read & apply permissions für die „Default Domain Controllers Policy“ besitzen.