Tags: Active Directory, PowerShell
PowerShell bietet nicht nur zahlreiche Cmdlets, um Objekte im Directory anzulegen, zu ändern oder zu löschen. Vielmehr kann man damit auch die AD-Infrastruktur weitgehend verwalten und dafür einige wesentliche Einstellungen auslesen.
Wenn man herausfinden möchte, welche Rollen und Dienste des Active Directory auf welchen Domänen-Controllern laufen, dann empfiehlt sich dafür das Cmdlet Get-ADDomainController. Es kann viele dieser Informationen auslesen.
DCs mit Get-ADDomainController abrufen
Ruft man es ohne Parameter auf, dann gibt es den Namen und eine ganze Reihe anderer Eigenschaften jenes DCs aus, der für die aktuelle Sitzung zuständig ist. Wenn man jedoch ermitteln möchte, welche AD-Services auf welchem Server aktiviert sind, dann wird man mit dem Befehl alle DCs einer Struktur anfragen und deren Eigenschaften auswerten.
Zu diesem Zweck eignet sich der Parameter Identity nicht, weil er nur den Namen, die IP-Adresse, den Distinguished Name oder einen anderen Bezeichner eines einzelnen Servers nimmt. Dagegen kann man mit Hilfe des Arguments Filter mehrere DCs nach verschiedenen Kriterien auswählen. Der Aufruf von
Get-ADDomainController -Filter *
gibt sämtliche DCs einer Struktur zurück. Möchte man nur Read Only DCs angezeigen, dann hilft der Aufruf
Get-ADDomainController -Filter {isreadonly -eq $true}
Global Catalog orten
Entsprechend würde der Filter {isGlobalCatalog -eq true} dafür sorgen, dass nur solche Domänen-Controller im Ergebnis auftauchen, bei denen der Globale Katalog (GC) aktiviert wurde.
Einige Dienste, die typischerweise auf einem DC laufen, lassen sich dagegen mit dem Parameter Discover abfragen. Dazu zählt erneut der GC, aber auch der TimeService, der PDC, das Key Distribution Center (KDC) oder der AD Web Service:
Get-ADDomainController -Discover -Service TimeService, GlobalCatalog
Dieser Befehl zeigt alle DCs an, auf den der NTP-Service und der GC läuft. Discover lässt sich alternativ mit dem Parameter DomainName kombinieren, um alle DCs auszugeben, die einer bestimmten Domäne angehören:
Get-ADDomainController -Discover -DomainName "contoso.com"
Analog dazu lassen sich alle DCs ermitteln, die einer Site zugeordnet sind, indem man anstelle von DomainName den Parameter SiteName verwendet.
Anstatt, wie oben gezeigt, die Eigenschaft IsReadOnly abzufragen, um beschreibbare DCs von RODCs zu unterscheiden, kann man auch die Kombination aus -Discover und -Writeable nutzen.
FSMO-Rollen auslesen
Die Operation Masters, auch als Flexible Single Master Operations bzw. FSMO bekannt, gelten als Rollen und nicht als Dienste. DCs lassen sich daher nicht über den Parameter Service nach SchemaMaster oder RIDMaster filtern. Vielmehr enthält ein Objekt vom Typ ADDomainController ein Array namens OperationMasterRoles, dessen Elemente Aufschluss über die FSMO-Rollen geben.
Möchte man sich für jeden DC anzeigen lassen, für welche dieser Rollen er zuständig ist, dann kann man zugunsten einer besseren Darstellung über die Ausgabe von Get-ADDomainController -Filter * iterieren und die Eigenschaften Name sowie OperationMasterRoles ausgeben:
Get-ADDomainController -Filter *| %{$_.Name + ": " + $_.OperationMasterRoles + "`n"}
Wenn man einfach nur PDCs finden möchte, dann erledigt dies der folgende Befehl:
Get-ADDomainController -Filter {OperationMasterRoles -like "PDC*"} | Select Name
Benötigt man keine Filter zur Auswahl bestimmter DCs und möchte man nur die Verteilung der FSMO-Rollen in der Domäne herausfinden, dann kann man dies alternativ über die Cmdlets Get-ADDomain und Get-ADForest tun:
Get-ADDomain | Select InfrastructureMaster, RIDMaster, PDCEmulator
Get-ADDomain gibt keine Auskunft über SchemaMaster und DomainNamingMaster. Diese muss man durch einen ergänzenden Aufruf von Get-ADForest ermitteln:
Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster
AD-Version und Funktionsebene ausgeben
Eine weitere bedeutende Information für das Management des AD ist die Funktionsebene. Get-ADDomainController kennt zwar den Parameter MinimumDirectoryServiceVersion (zulässige Werte: Windows2003, Windows2008, Windows2012, Windows2012R2), aber das Ergebnis klärt erwartungsgemäß nur über die Version das AD auf.
Um die Funktionsebene für Forest und Domäne zu ermitteln, muss man daher die Cmdlets Get-ADForest bzw. Get-ADDomain bemühen:
Get-ADForest | Select ForestMode
oder
Get-ADDomain | select DomainMode
Die Eigenschaften ForestMode bzw. DomainMode enthalten den gewünschten Wert.
Täglich Know-how für IT-Pros mit unserem Newsletter
Verwandte Beiträge
- Security- und Health-Checks für Active Directory mit PowerShell-Scripts
- Split-brain DNS in Active Directory einrichten
- AD-Konten mit DES- und RC4-Algorithmus für Kerberos-Verschlüsselung finden
- UserAccountControl: Sicherheitseinstellungen für AD-Konten prüfen und ändern
- Gruppen in Azure Active Directory mit PowerShell verwalten
Weitere Links
6 Kommentare
Danke für den tollen Artikel! Konnte das Auslesen der FSMO soeben testen - funktioniert super. Der nächste Schritt wäre dann die FSMO zu seizen und transferieren. Sollte mit 'Move-ADDirectoryServerOperationMasterRole' klappen.
Man muss Microsoft langsam ein Kränzchen winden: PS wird immer mehr ausgebaut.
Hallo,
nach Ausführen von Get-ADDomainController bekomme ich IPv4Address 169.254.106.165 angezeigt und das ist die falsche.Ich habe den Eindruck das sowohl NTP, GPO Sync nicht richtig funktionieren. Wenn ich mit dcdiag die Domäne teste (2 Controller) ist angeblich alles in Ordnung. An welcher stelle müsste ich die IP Adresse ändern?
Ich muss an dieser Stelle, bei diesem Artikel (eigentlich egal bei welchem Artikel) endlich mal ein Loblied auf diese Seite loswerden. Mir hat diese Webseite schon bei so manchem Problem, speziell im Bereich Active Directory, Windows Server und Powershell, extrem geholfen. Die Artikel sind klipp und klar strukturiert, verständlich und sehr sehr hilfreich. Jedes Mal wenn ich etwas spezifisches im Internet suche, bekomme ich Ergebnisse von adminis***.de und mcseb*** eingeblendet und bekomme, auch ob der Arroganz mancher Autoren dort, schon das kalte Grauen, ganz zu schwiegen von den maschinell übersetzten Beiträgen von microsoft. Umso mehr freue ich mich, wenn ich dann einen Artikel vom windowspro finde. Dann weiß ich, dass ich genau das finde, wonach ich suche. Daher aus meinem tiefsten Administrator-Herzen: Vielen Dank ♥
Einen solchen Kommentar wünscht sich jeder Autor :-) Danke für das tolle Lob!
An dieses Lob möchte ich mich gerne anschließen. Wirklich toll Eure Artikel! Danke für Eure Arbeit und den netten Umgangston. Ist alles andere als üblich, wie schon der "Vorschreiber" bemerkt hat.
Vielen Dank! Wenn das so weitergeht mit den Lobpreisungen, dann kriege ich noch einen roten Kopf vor Verlegenheit ;-)