AD-Site

Eigentlich sollte die Einrichtung von AD-Standorten und Diensten für jeden Windows Administrator und erst Recht für Exchange Administratoren zum Grundwissen gehören, wenn Sie mehrere Standorte haben. Leider treffe ich immer wieder bei Neukunden und Supporteinsätzen auf Umgebungen, in denen die "AD-Sites & Services" nicht gepflegt oder aktualisiert werden.

Unwissend oder untätig?

Ich frage mich natürlich, warum es solche Umgebungen gibt und ich bin zum Schluss gekommen, dass die jüngeren Administratoren einfach nicht mehr mit begrenzten Bandbreiten umgehen mussten. Ich kann mich noch gut daran erinnern, wie ich bei den ersten Windows 2000 Installationen über mehrere Standorte sehr genau die AD-Sites mit Subnetzen und Site-Links gepflegt habe, damit nicht nur die Domain Controller eine effektive und bandbreitenschonende Replikation aufbauen können sondern auch die Clients zuverlässig den "nächsten" DC/Netlogon/SYSVOL-Share im gleichen Standort genutzt haben. Das war essentiell für eine schnelle Anmeldung und optimierte Zugriffe auf Dienste.

Heute redet aber niemand mehr von Kilobit sondern eher von Megabit und Gigabit im WAN und Bandbreite ist angeblich immer "genug da". Wobei wir doch bitte zwischen Bandbreite und Latenzzeit unterscheiden müssen. Vielleicht fällt es aufgrund von weniger als 20ms innerhalb Europas auch einfach nicht mehr auf, wenn ein Zugriff zu einem falschen Standort geht. Gerade beim Discovery des nahestehenden DCs arbeitet der Windows Client mit einem LDAP-PING und findet meistens tatsächlich einen lokalen DC. Wenn es dann nur die "Default-First-Site-Name" gibt, dann bleibt er meist auch bei dem DC.

Eigene Site ermitteln

Die Informationen im Active Directory sind nicht "geheim" und können durch jeden Anwender einfach ermittelt werden. Seit Windows 2000 gibt es mit NLTEST.EXE eine Kommandozeile:

nltest /dsgetsite

NLTEST fragen aber den lokalen Cache ab, d.h. wenn ich den Computer aus dem Schlafmode aufwecke, dann bekomme ich oft dennoch die frühere Site zu sehen, selbst wenn ich im Homeoffice ohne VPN arbeite.

Ein PowerShell-Commandlet habe ich noch nicht gefunden aber über folgenden Aufruf erhalten Sie den Namen der Site.

[System.DirectoryServices.ActiveDirectory.ActiveDirectorySite]::GetComputerSite().Name

Das Object "GetComputerSite()" hat natürlich noch einige andere Properties:

Anders als der NLTEST-Aufruf frage ich hier in Echtzeit die aktuelle Konfiguration ab. Wenn ich keine Verbindung zum Domain Controller habe, dann sehe ich eine Fehlermeldung:

Wer hier also als Antwort ein "Default-First-AD-Site" erhält und mehr als einen Standort mit entsprechenden WAN-Verbindungen hat, kann seinem Administrator ja mal einen Tipp geben.

Hinweis
Wenn Sie mit VPNs arbeiten, dann können Sie den VPN-Anwendern auch ein eigenes Subnetz und damit auch eine eigene AD-Site zuordnen.

Einsatzzweck

Die Einrichtung und vor allem auch die Pflege von AD-Sites ist also keine Kür, wenn Sie WAN-Verbindungen mit verteilten Domain Controllern haben. Ich möchte ihnen ein paar Beispiele für die Auswirkungen geben:

  • AD-Replikation
    Verteilte Domain Controller orientieren sich an den Standorten, um Replikationsringe innerhalb einen Standorts zu bilden und dann zwischen den Standorten effektive zu übertragen. Im Standard werden damit aber Replikationen zwischen Standorten auf 180Min verzögert. Dies kann aber durch Anpassen der AD Sitelink Replication Notification reduziert werden.
  • Client Zugriffe
    Aber auch die Windows Domainmitglieder suchen per DNS nach einer Liste von DCs, von denen dann per LDAP-Ping der schnellste genutzt wird um dann die AD-Site-Definition zu erhalten. Mit dem Wissen um die Site kann der Client dann den wirklich "nächsten" DC für die eigentliche Anmeldung per Netlogon/SYSVOL etc. nutzen.
  • Gruppenrichtlinien
    Die Verarbeitung von Gruppenrichtlinien ist natürlich auch schneller, wenn Sie vom lokalen Server geliefert wird. Aber sie können auch Gruppenrichtlinien an ADSites binden und damit Die Konfiguration des Clients von der Lokation im Netzwerk abhängig machen. Früher wurde dies z.B. zur Konfiguration eines HTTP-Proxy-Servers o.ä. genutzt. Das würde ich heute per Geo-DNS oder WPAD machen.
  • Exchange Mailrouting
    Bis einschließlich Exchange 5.5 haben die Exchange Administratoren das Routing zwischen Standorten selbst im Produkt konfiguriert. Mit Exchange 2000 wurde aber nicht nur das Active Directory der Verzeichnisdienst für alle Empfänger und die Exchange-Konfiguration. Das Routing von Mails zwischen Servern innerhalb der gleichen Organisation wird auch über die AD-Sites gesteuert. Wer also mehrere Exchange Server an unterschiedlichen Standorten betreibt, muss die AD-Sites korrekt pflegen, damit das Mailrouting optimiert möglich ist. Wenn ein Exchange Server seinen Standort nicht ermitteln kann, dann starten die Dienste nicht.

Davon losgelöst soll es auch Kunden geben, die eine Pflege automatisiert haben, indem Sie vom Netzwerk-Team entsprechende Listen bekommen oder ihrerseits die hoffentlich korrekten Daten aus dem AD-Forest für eigene Zwecke weiter verarbeiten. Es gibt durchaus andere Produkte, die eine Zuordnung von IP-Adressen/IP-Subnetzen zu Standorten benötigen. Weder Skype for Business noch Microsoft Teams greifen allerdings direkt auf die Informationen zu, sondern nutzen ihren eigenen Speicherort. Sie könnten daher drüber nachdenken, die Daten aus den AD-Sites regelmäßig zu exportieren.

AD-Site Namen

Wer bis jetzt noch keine AD-Sites hat oder die Daten veraltet sind, sollte diese Einstellungen zeitnah korrigieren.

Achtung: Nicht alle Produkte mögen es, wenn Sie plötzlich zu einer anderen Site gehören. Bei Exchange ist immer ein Neustart erforderlich, da zu viele Dienste von der Site-Konfiguration abhängig sind und diese nicht mal eben geändert werden kann.

Ansonsten ist die Verwaltung per MMC relativ einfach und die MMC verhindert auch die meisten Fehler. Eine AD-Seite ist nicht nur ein Eintrag im Active Directory sondern landet auch Teil des Namens in der DNS-Zone. Daher sind nicht alle Zeichen und alle Längen erlaubt. Microsoft schreibt dazu u.a.

Allowed characters: DNS names can contain only alphabetic characters (A-Z), numeric characters (0-9), the minus sign (-), and the period (.). Period characters are allowed only if they're used to delimit the components of domain style names. Windows DNS supports Unicode characters. Other implementations of DNS don't support Unicode characters. Avoid Unicode characters if queries will be passed to the servers that use non-Microsoft implementations of DNS. For more information, see RFC 952 and RFC 1123.
Quelle: https://learn.microsoft.com/en-us/troubleshoot/windows-server/identity/naming-conventions-for-computer-domain-site-ou#site-names

Interessanterweise führt Microsoft aber der gleichen Stelle noch auf, welche Zeichen "disallowed" sind. Das finde ich suspekt, dass beide Extreme beschrieben werden. Der "Unterscore" hat zudem noch eine besondere Funktion.

Ich würde ich auf die regulären Zeichen 2a-zA-Z0-9" und "-" beschränken. Die Einträge sieht ein Benutzer ja sowieso nicht.

Natürlich habe die die Eingabeüberprüfung gestresst aber die MMC fängt die meisten Fehler ab. Die maximale Länge von 63 Zeichen wird sogar noch etwas ausführlicher hinsichtlich anderer Zeichensätze beschrieben.

Auch bei den Sonderzeichen ist die MMC konsequent.

Allerdings erkennt der erfahrene Administrator dass hier einige Zeichen nicht ausgeschlossen sind und sie können tatsächlich auch verwendet werden

Der Name wird sogar im Windows-DNS angelegt.

Ich habe nun nicht geprüft, ob diese Zeichen auch generell für DNS-Einträge gültig sind. Ich würde aber nicht darauf setzen und mich wirklich auf normale Zeichen beschränken

Autoritative Quelle

Allerdings liegt die Verwaltung und Vergabe von IP-Adressen oft bei der "Netzwerktruppe", die nicht unbedingt Active Directory Administrator sind. Damit ist natürlich das Risiko vorhanden, dass beim Export der Sites nicht alle IP-Netzwerke in der Liste erscheinen. Das fällt natürlich später auf, wenn IP-Adressen von Clients im IISLog oder SMTP-Log erscheinen, die nicht zugeordnet werden können.

Eine gute Quelle um die Konsistenz zu prüfen ist das NETLOGON.LOG auf den Domain Controllern. Hier protokolliert jeder Server Anfragen von Clients aus nicht definierten Subnetzen. Zudem wird ab uns an ein Event 5807 im System-Eventlog dazu hinterlassen.

Event Type: Warning
Event Source: NETLOGON 
Event Category: None 
Event ID: 5807 
User: N/A 
Computer: w2008r2dc.msxfaq.net 
Description: During the past 4.23 hours there have been 30 connections to this Domain Controller from 
client machines whose IP addresses don't map to any of the existing sites in the enterprise. 
Those clients, therefore, have undefined sites and may connect to any Domain Controller including 
those that are in für distant locations from the clients. A client's site is determined by the mapping 
of its subnet to one of the existing sites. To move the above clients to one of the sites, please 
consider creating subnet object(s) covering the above IP addresses with mapping to one of the 
existing sites. The names and IP addresses of the clients in question have been logged on this 
computer in the following log file '%SystemRoot%\debug\netlogon.log' and, potentially, in the 
log file '%SystemRoot%\debug\netlogon.bak' created if the former log becomes full. The log(s) may 
contain additional unrelated debugging information. To filter out the needed information, please 
search für lines which contain text 'NO_CLIENT_SITE:'. The first word after this string is the 
client name and the second word is the client IP address. The maximum size of the log(s) is controlled 
by the following registry DWORD value 
'HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\LogFileMaxSize'; 
the default is 20000000 bytes. The current maximum size is 20000000 bytes. To set a different 
maximum size, create the above registry value and set the desired maximum size in bytes

Wer dann in C:\Windows\Debug\netlogon.log nachschaut, sollte hier auch die Clients mit ihrer IP-Adresse finden:

10/03 11:02:32 FX: NO_CLIENT_SITE: MSXFAQVM1 192.168.101.4
10/03 11:23:33 FX: NO_CLIENT_SITE: MSXFAQVM2 192.168.101.8

Da in den meisten Firmen ein Active Directory vorhanden ist und nahezu alle relevanten Client-Subnetze auch ab und an von einem Domänen-Mitglied benutzt werden, ist die Sammlung dieser Events und Dateien über alle Domaincontroller hinweg in der Regel eine zuverlässige Quelle eine halbwegs komplette Liste zu erhalten. Natürlich bekommen Sie keine Transfernetzwerke, Management-Netzwerke o.ä. mit, in denen sich keine Clients bekommen.

Exchange PowerShell

Das neben den Domain Controllern auch Microsoft Exchange OnPremises die ADSites und Sitelinks nutzt, sollten nicht neu sein. Überraschend ist aber, dass die PowerShell-Commandlets mit Bezug zu den ADSites und ADSiteLinks nicht Bestandteil der Active Directory PowerShell-Module sind, sondern mit der Exchange PowerShell mitkommen.

Achtung
Wenn Sie Subnetze bei AD Sites ändern, so dass Exchange in einer anderen Site landen, dann erkennt Exchange dies erst nach einem Neustart des msExcahngeADTopology-Dienst, was einem Exchange Neustart gleich kommt und wenn die IP-Adresse eines Exchange Servers keiner AD-Site zugeordnet ist, dann starten die Dienste nicht mehr.

Das ist natürlich verständlich, da Exchange Administratoren hiermit weitere Einstellungen zum Exchange Routing, z.B. Kosten definieren können.

Export mit Check (dump-adsite.ps1)

Die AD-Site und Subnet-Information (ohne Links) nutze ich z.B. um basierend darauf dann Skype für Business Sites (CAC) anzulegen oder das Exchange Messagetracking oder IISLogs auszuwerten. Um dazu nicht jedes mal den LDAP-Server zu befragen und auch offline in einer Testumgebung Auswertungen proben zu können, habe ich mir zuerst ein Export-Script gebaut, welches alle AD-Sites mit den Subnetzen als CSV-Datei ausgibt. Zusätzlich betreibe ich aber noch den Aufwand, das Subnetz als auch das Netzwerk in einen UINT32 als Zahl umzurechnen. jede IPv4-Adresse wird dazu zu einer 32bit-Zahl. das hat zwei Vorteile:

  • Konsistenzprüfung
    Wenn man die Netzwerkadresse mit der Subnet-Maske binär "UND-verknüpft, muss wieder die Netzadressen heraus kommen. Das wäre bei einer Subnetzdefinition 192.168.100.3/24 ja nicht der Fall. Hier müsste die letzte Stelle eine "0" sein. Mit vom Standard abweichenden Netzmasken ist das aber nicht mehr so einfach. Windows 2012R2 prüft das schon bei der Eingabe aber das muss ja nicht immer so sein. Eine Kontrolle kostet nur wenig.
  • IP-Adress-Matching
    Ich möchte diese Datenbank später nutzen, um sehr schnell eine IP-Adresse zu einer Site zuordnen zu können. Und da ist ein Vergleich und eine Sortierung über "String" nicht geeignet. Da ist es besser die Liste nach der Länge der Subnet-Maske zu sortieren und dann mit einen "binären UND" den Hostanteil der IP-Adresse abzuschneiden und nur noch das Subnetz zu vergleichen.

Das Skript "Dump-ADSite" erstellt so eine CSV-Datei für einen späteren Import.

Ich habe das Skript noch nicht öffentlich gemacht.

Eine Datei hat den Vorteil, dass Sie nach dem Export den Inhalt überprüfen und ggfls. sogar manuell um Einträge erweitern können, die es im AD nicht gibt, ehe Sie diese Daten woanders weiter verwenden

IP-Lokation per AD-Site

In verschiedenen Skripten wird nun diese Liste wieder importiert und mit wenigen Zeilen Code kann zu jeder IP-Adresse der zugehörige AD-Standort ermittelt werden. für Analysen mit Exchange ist dies oft nicht erforderlich, da ein Exchange Server alleine schon seine AD-Site kennt und ein Postfächer über die Datenbank zum Server zugeordnet werden kann. Aber selbst mit Exchange gibt es Protokolle, in denen die Client-IP vorliegt. Interessant ist die IP-Zuordnung zu einer Site z.B. für:

  • IISLogs, Exchange RPC-Logs
    Wenn Sie die Logs ihrer Webserver auswerten, dann finden Sie dort auch die Client-IP. Über die Zuordnung auf eine ADSite können Sie die Nutzung entsprechend gruppieren.
  • POP/IMAP/SMTP-Logs
    Auch solche Clients hinterlassen Spuren in Exchange, die eine Analyse nach Source-Site interessant erscheinen lassen
  • Exchange Messagetracking
    Auch Clients, die per SMTP ihre Mails einliefern, können aus dem Messagetrackinglogs mit der Client-IP auf einen Standort umgesetzt werden.
  • Skype for Business CAC - Call Admission Control
    Wenn Sie in SfB die Überlastung von WAN-Verbindungen kontrollieren wollen, dann müssen Sie in Skype die Standorte und Links bereitstellen. Wenn ihre Domain Admin diese Informationen in AD Sites&Services korrekt pflegt, ist dies eine gute Datenquelle
  • Skype for Business LIS - Location Information Service
    Für Notrufe ist auch eine Zuordnung des Clients zu einem Standort erforderlich.
  • SfB Media Bypass
    Wenn Sie mit Skype for Business eine direkte Audio-Verbindung zwischen Client und SBC/Gateway erlauben wollen, dann müssen Sie in SfB entsprechende Network-Sites pflegen. Da liegt es ja nahe, die Daten aus den Sites&Services zu nutzen
  • SfB CQD - Call Quality Dashboard
    Auch für die Auswertungen der Anrufe nach Standorten ist eine separate Liste der IP-Netzwerke erforderlich
  • Teams Verbindungsdaten
    Was für SfB gilt, ist auch für Teams relevant. Wobei sie hier die Netzwerk und Topologie in der Cloud verwalten müssen

Sie sehen, dass eine gut gepflegte Liste der Subnetze mit Standorten nicht nur im Active Directory für die AD-Replikation und Exchange Routing relevant ist, sondern auch die Daten für viele andere Dienste davon abgeleitet werden können. Sie könnten als Windows Admin ihre ADSite-Liste natürlich aus autoritative Quelle festlegen. Wenn die Firma aber größer ist, dann liegt die Hoheit über IP-Subnetze und Routing eher beim Netzwerk-Team. Dann sollten Sie darauf drängen, dass ihr Netzwerk-Team diese Daten in einer leicht und möglichst automatisch konsumierbaren Form als IP-Subnetz Liste bereitstellt. Die entsprechenden Auswerte-Programme sind natürlich noch zu schreiben.

Weitere Links