Bist du verantwortlich für Dienste wie Active Directory oder Azure AD? Dann hast du sicher schon viel Zeit mit der Fehlersuche verbracht. Glücklicherweise gibt es für das Troubleshooting Werkzeuge, die das Leben jedes Administrators einfacher machen.  

Verzeichnisse stellen eine zentrale Grundlage für die Identitätsverwaltung von Unternehmen dar, unabhängig davon, ob der Verzeichnisdienst von Active Directory (AD) oder Azure AD (AAD) bereitgestellt wird. Die Fehlerbehebung oder Identifizierung von Problemen ist eine wichtige Aufgabe, die von den für das Verzeichnis Verantwortlichen durchgeführt werden muss. Die Verwendung des richtigen Tools (oder der richtigen Tools) kann helfen, diese Aufgabe zu bewältigen, und mit den richtigen Skripten (PowerShell oder andere) geht es einfacher.

In diesem Artikel wird untersucht, wie PowerShell bei der Fehlerbehebung von häufigen Problemen in Active Directory verwendet werden kann. Es ist erwähnenswert, dass nicht alles, was zur Behebung von AD-Problemen erforderlich ist, direkt mit PowerShell durchgeführt werden kann. Wir können jedoch PowerShell verwenden, um einen "Wrapper" um andere Prozesse zu legen und PowerShell zum Abrufen von Daten für eine erfolgreiche Fehlerbehebung zu verwenden.

AD-Standorte und Dienstverknüpfungen

Ein häufiger Fehler, der bei Site-to-Site-Replikationslinks gemacht wird, besteht darin, ein Replikationsproblem mit einem manuellen Link zu beheben, anstatt sich auf die automatisch erzeugten Links zu verlassen, die KCC (Knowledge Consistency Checker/Wissenskonsistenzprüfung) erstellt. Manuelle Links werden nicht automatisch aktualisiert oder funktionieren nicht gut bei Topologie Änderungen, so dass die Identifizierung manuell erstellter Links hilft, die Umgebung zu stabilisieren.

Autogenerierte Links finden

So können wir alle AD-Replikationsverbindungen auflisten, mit ihrer GUID, den To- und From-Servern und auch feststellen, ob die Verbindung automatisch generiert wurde:

Get-ADReplicationConnection -Filter * |

    Select-Object -Property Name, AutoGenerated, ReplicateFromDirectoryServer, ReplicateToDirectoryServer |

    ForEach-Object {

        $From = $_.ReplicateFromDirectoryServer
        $To = $_.ReplicateToDirectoryServer

        $_.ReplicateFromDirectoryServer = (($From -Split ',')[1] -Split '=')[1]

        $_.ReplicateToDirectoryServer = (($To -Split ',')[0] -Split '=')[1]

        Return $_ 

    }

Beispielhafter Output

Wenn eine oder mehrere Verknüpfungen bei AutoGenerated den Wert "False" haben, sollte untersucht werden, warum diese Verknüpfungen erstellt wurden. Möglicherweise gibt es dafür einen triftigen Grund, auch wenn dieser von Microsoft nicht unterstützt wird.

Replikation

Zusätzlich zu Site Links kann die Überprüfung der Replikation, die diese Links durchläuft, eine wichtige Komponente der AD-Fehlerbehebung sein. In diesem Abschnitt werden wir einige Möglichkeiten zur Verwendung von PowerShell als Wrapper für native Windows-Tools untersuchen, um die Kommunikation zwischen Domänencontrollern (DC) in einer Umgebung zu untersuchen. Die in diesem Abschnitt verwendeten Tools sind dsquery, repadmin und dcdiag. Mit PowerShell können wir die Ergebnisse dieser Tools in eine Ausgabedatei exportieren, damit ein erfahrener AD-Administrator sie analysieren kann.

Dsquery

Unser erstes Tool ist dsquery, das zur Abfrage von Informationen im AD verwendet wird. In diesem Fall werden nur die Domänencontroller in AD abgefragt. Mehr zu diesem Einzeiler finden sich in den Microsoft Docs.

'dsquery server -o rdn'

Repadmin

Das Tool repadmin kann verwendet werden, um einige der tiefgreifenden Replikationsprobleme aufzudecken, die zwischen DCs auftreten können, sowohl bei eingehenden als auch bei ausgehenden Daten. Repadmin kann kritische Probleme mit DCs aufdecken, die nicht mehr replizieren können, Topologieprobleme identifizieren und vieles mehr. Im Folgenden findest du ein Basis-Set von Cmdlets, die über ein PowerShell-Skript ausgeführt werden können. Beachte, dass jede Zeile die Ergebnisse in eine zu untersuchende Datei exportiert:

$ADCmdletDestination =  'ADReplicationOutput.txt '

Check replication for all servers, cross all sites
C:\Windows\System32\repadmin.exe /syncall /e >> $ADCmdletDestination

Check Naming Context Replication
C:\Windows\System32\repadmin.exe /syncall /A >> $ADCmdletDestination

Sync using DN and not GUID DNS
C:\Windows\System32\repadmin.exe /syncall /d >> $ADCmdletDestination

Concise Replication Summary
C:\Windows\System32\repadmin.exe /replsummary * >> $ADCmdletDestination

Forces KCC to recalculate topology
C:\Windows\System32\repadmin.exe /kcc * >> $ADCmdletDestination

Shows last AD backup
C:\Windows\System32\repadmin.exe /showbackup * >> $ADCmdletDestination

Checks replication status for last inbound replication
C:\Windows\System32\repadmin.exe /showrepl * >> $ADCmdletDestination

Displays any inbound queued requests
C:\Windows\System32\repadmin.exe /queue * >> $ADCmdletDestination

Checks AD Bridgehead servers for issues
C:\Windows\System32\repadmin.exe /bridgeheads * /verbose >> $ADCmdletDestination

Returns Intersite Topology Generator (ISTG) server
C:\Windows\System32\repadmin.exe /istg * /verbose >> $ADCmdletDestination

"A list of the entries in the DS Bind cache."
C:\Windows\System32\repadmin.exe /showoutcalls * >> $ADCmdletDestination

Lists KCC Failures
C:\Windows\System32\repadmin.exe /failcache * >> $ADCmdletDestination

Lists known AD trusts
C:\Windows\System32\repadmin.exe /showtrust * >> $ADCmdletDestination

Displays replication features for a DC
C:\Windows\System32\repadmin.exe /bind * >> $ADCmdletDestination

Wenn es Probleme gibt, sollten diese Befehle generell anzeigen, das etwas nicht korrekt ist. Wenn zum Beispiel die Zeit eines DCs nicht stimmt, zeigt die Replikationsübersicht Synchronisationsfehler an. Möglicherweise wird sogar ein DC angezeigt, der in Tombstone gesperrt wurde, weil er nicht innerhalb des konfigurierten Tombstone-Zeitlimits repliziert hat. Fehlermeldungen im Ereignisprotokoll werden ebenfalls angezeigt und helfen bei der Ursachenanalyse.

Beispiel für den Schalter /replsummary

Dcdiag

Mit dem Tool dcdiag können wir eine Reihe von Domain-Controller-Tests durchführen, die uns dabei helfen, die relative Hilfe der einzelnen DCs zu bestimmen. Der folgende Einzeiler führt alle dcdiag-Tests wie hier beschrieben aus [/c], führt die Tests für alle DCs aus, unabhängig davon, in welcher Site sie sich befinden [/e], und verwendet eine ausführliche Ausgabe [/v]. Beachte, dass das Ergebnis auch in eine Datei zur Analyse exportiert wird. Die Ausführung dieses Befehls und die Analyse der exportierten Ergebnisse kann in größeren Umgebungen durchaus einige Zeit in Anspruch nehmen.    

 
dcdiag /c /e /v >> $ADCmdletDestination

Beispielhafte Bildschirmausgabe

Inzwischen gibt es einige direkte Ersatzlösungen für diese Tools in PowerShell. Zum Zeitpunkt der Erstellung dieses Artikels bieten diese Cmdlets jedoch einen tieferen Einblick in die AD-Replikation für die Fehlerbehebung.

DNS-Zustand

DNS ist wichtig für den Active Directory-Zustand und Administratoren können ihren DNS-Server mit einigen Tools testen. In der nativen PowerShell steht das Cmdlet 'Test-DNSServer' zur Verfügung, das zwar recht begrenzt ist, aber einen schnellen Test eines bestimmten DNS-Servers ermöglichen kann.

Sample 'Test-DnsServer' cmdlet

Um jedoch etwas tiefer einzutauchen, können wir PowerShell verwenden, um Windows-Tools von DNSLint bis dcdiag auszuführen, da diese Tools auch mit der PowerShell weiterhin gültig sind.

 
$DC = Get-ADDomainController $Env:ComputerName

$IPs = @()

$IPs = $DC.IPv4Address

$Server = $IPs[0]

$DNSLint = .\DNSLint.exe /ad $Server /s $Server /r dnslint /no_open /y

Um noch mehr Informationen zu erhalten, können wir dcdiag verwenden, um die Funktionalität des DNS-Servers zu testen.   

Beispiel eines DNSLint-Fehlerberichts

Function GetInfo {

    DCDiag /s:$DC /Test:dns /v /q /i /x:$DNSXMLDestination

    $Data = @($DC,$Domain,$Site)

    $Xml = $DNSXMLDestination

    [Xml]$DCDiag = Get-Content $xml

    $Summary = $dcdiag.DCDIAGTestResults.DNSEnterpriseTestResults.Summary.Domain.DC.test

    Foreach ($line2 in $summary) {

      $Data += @($Line2.Status)

    }

    $Rowline = $Data -join ","

    Add-Content $DNSDestination $Rowline

    $Rowline = $Null

}



# Main Script Body

$DNSDestination = 'DNSTestResults.csv'

$DNSXMLDestination = 'DNSTestResults.xml'

$Rows = "DC," + "Domain," + "Site," + "Auth," + "Basc," + "Forw," + "Del," + "Dyn," + "Rreg," + "Ext"

Add-Content -Path $DNSDestination $Rows



$Domains = (Get-ADForest).Domains

Foreach ($Domain in $Domains) {

    $DomainControllers = Get-ADDomainController -Server $Domain -Filter *

    Foreach ($Line in $DomainControllers) {

        $Dc = $Line.HostName

        $Domain = $Line.Domain

        $Site = $Line.Site

        GetInfo

    }

}

Mit Hilfe dieser beiden Skripte können wir uns nun ein Bild des DNS machen und durch Überprüfung der Protokolle die DNS-Infrastruktur validieren.  

Beispiel einer DCDiag-Ergebnisdatei

Netzwerk-Konfiguration

Ein Domänencontroller mit aktiviertem DHCP oder mit zu vielen Gateways kann alle möglichen Probleme mit der Replikation, der Benutzerauthentifizierung und auch Anwendungsprobleme verursachen. Ein guter Überblick über die Konfiguration der einzelnen Server kann einem Administrator helfen, ein Problem mit seinen Domänencontrollern aufzuspüren. Das folgende Skript untersucht jede Netzwerkkarte (NIC) auf einem Server und meldet die Eigenschaften zur Überprüfung zurück:

# Variables

$Rows = 'Computer,' + 'IPAddress,' + 'Subnet Mask,' + 'Default Gateway,' + 'DHCP,' + 'DNS Servers'

$NICDestination = 'DC-NetworkConfig.csv'

Add-Content -Path $NICDestination $Rows



$Domains = (Get-ADForest).Domains

Foreach ($Domain in $Domains) {

    $Rows = "Domain - $Domain"

    Add-Content -Path $NICDestination $Rows



    $DomainControllers = Get-ADDomainController -Server $Domain -Filter *

    # Foreach ($Computer in $ComputerNames) {

    Foreach ($DomainController in $DomainControllers) {

        $Computer = $DomainController.HostName

        $Server = $DomainController.Name



        $Networks = Get-WmiObject Win32_NetworkAdapterConfiguration -ComputerName $Computer -EA Stop |

            Where-Object { $_.IPEnabled }



        Foreach ($Network in $Networks) {

            $IPAddress = $Network.IpAddress[0]

            $SubnetMask = $Network.IPSubnet[0]

            $DefaultGateway = $Network.DefaultIPGateway

            $DNSServers = $Network.DNSServerSearchOrder

            $IsDHCPEnabled = $false

            If ($Network.DHCPEnabled) {

                $IsDHCPEnabled = $true

            }

            $MACAddress = $Network.MACAddress 

            $OutputObj = New-Object -Type PSObject

            $OutputObj | Add-Member -MemberType NoteProperty -Name ComputerName -Value $Server.ToUpper()

            $OutputObj | Add-Member -MemberType NoteProperty -Name IPAddress -Value $IPAddress

            $OutputObj | Add-Member -MemberType NoteProperty -Name SubnetMask -Value $SubnetMask

            $OutputObj | Add-Member -MemberType NoteProperty -Name Gateway -Value ($DefaultGateway -join ',')

            $OutputObj | Add-Member -MemberType NoteProperty -Name IsDHCPEnabled -Value $IsDHCPEnabled

            $OutputObj | Add-Member -MemberType NoteProperty -Name DNSServers -Value ($DNSServers -join ',')

            $OutputObj | Format-Table -AutoSize

            $Row = "$Server," + "$IPAddress," + "$SubnetMask," + "$DefaultGateway," + "$ISDHCPEnabled," + "$DNSServers"

            Add-Content -Path $NICDestination $Row

        }

    }

}

Beispielhafter Output (alle DCs verweisen auf einen zentralen DC und auf sich selbst für DNS)

Diese Konfiguration kann erwünscht sein, sie kann aber auch eine ungünstige Konfiguration sein, abhängig von der Umgebung und/oder den Zielen der IT-Abteilung.

Strenge Replikation

Die in Windows 2003 eingeführte Funktion zur Verhinderung von Störungen in Active Directory ist nach wie vor eine notwendige und lohnenswerte Einstellung, die aktiviert bleiben sollte. Bei Replikationsproblemen und möglicherweise verbleibenden alten Objekten im AD ist es sinnvoll zu überprüfen, bei welchen DCs diese Einstellung aktiviert ist und bei welchen nicht. Als Best Practice sollte dies aktiviert sein. 

Mit dem folgenden Code können wir die Einstellung 'Strict Replication Consistency' für alle DCs in einer Domäne überprüfen:

$DCs = (Get-ADDomainController -Filter *).Name | Sort-Object

Foreach ($DC in $DCs) {

    $Script = {

        $Name = 'Strict Replication Consistency'

        $RegistryPath = 'HKLM:\System\CurrentControlSet\Services\NTDS\Parameters\'

        $Val = (Get-ItemProperty -Path $RegistryPath -Name $Name).$Name
        Return $Val

    }

    $StrictCheck = Invoke-Command -ComputerName $DC -ScriptBlock $Script

    If ($StrictCheck -eq '1') {

        Write-Host " * Strict Replication Consistency is enabled on the $DC Domain Controller." -ForegroundColor Cyan

    }

    Else {

        Write-Host " * Strict Replication Consistency is disabled on the $DC Domain Controller." -ForegroundColor Yellow

    }

} 

Konkrete Ergebnisse dieses PowerShell-Codeblocks

Zur Überprüfung mehrerer Forests/Domänen, sind einige Codeanpassungen erforderlich.

Best Practices Analyzer 

Schließlich enthalten Windows-Server einen eingebauten Best Practices Analyzer für jede Rolle, die auf einem Server installiert ist; im Folgenden sind zwei Beispiele:

Active Directory und DNS BPA GUI

Diese sind auch über PowerShell mit Invoke-BPAModule und Get-BPAResult zugänglich. BPAs arbeiten mit einem System von "Modellen", die der Windows-Rolle entsprechen, die auf einem Server installiert ist. Die DNS-Rolle hat zum Beispiel den Modellnamen DNSServer und das Modell von AD-Domain-Services lautet DirectoryServices. Mit dem Cmdlet 'Get-BPAModel' können wir diese Modellnamen abrufen, um sie zu buchstabieren. Im folgenden Code werden zwei Rollen (DNS und DC) abgefragt, und wenn sie installiert sind, wird der Modellname für jede Rolle zu einer Variablen hinzugefügt, die von den beiden zuvor genannten Cmdlets verarbeitet wird. Die Ausgabe dieses Vorgangs besteht aus einer CSV-Datei für jedes ausgeführte BPA-Modell.

Sample Code:

# Variables

$FilePath = (Get-Item -Path ".\" -Verbose).FullName 

$Server = $Env:ComputerName

$BPA = @() 

If ((Get-WindowsFeature AD-Domain-Services).Installed) {$BPA += "Microsoft/Windows/DirectoryServices"} 

If ((Get-WindowsFeature DNS).Installed) {$BPA += "Microsoft/Windows/DNSServer"} 

 

Foreach ($Model in $bpa) {

  $Name = $Model.Replace("Microsoft/Windows/","") 

  $CSV = "BPA-Results-$Name-$Server.csv"  

  Invoke-BPAModel $Model -ErrorAction SilentlyContinue

  Get-BPAResult -BestPracticesModelId $Model -ErrorAction SilentlyContinue |

    Where-Object {$_.Problem -ne $Null} |

    Select-Object ResultNumber,Severity,Category,Title,Problem,Impact,Resolution |

    Export-Csv $CSV -NoTypeInformation -Encoding UTF8

}

Fazit

Dieser Artikel bietet zwar nicht PowerShell für jedes Szenario, deckt aber die Grundlagen ab, wie PowerShell beim Troubleshooting verwendet werden kann, sogar in Verbindung mit Nicht-PowerShell-Tools. Active Directory kann von Natur aus sehr komplex sein, und aufgrund dieser Komplexität wird oft eine Vielzahl von Tools zur Fehlerbehebung verwendet. Hinweise liefern uns manchmal Anwendungsprobleme, Beschwerden von Benutzern oder Benachrichtigungen der Überwachungssoftware. Letztendlich ist es Sache des Administrators, das beste Tool für die Aufgabe auszuwählen und manchmal eine bestimmte Richtung des Troubleshootings zu verwerfen, zurückzugehen und mit neuen Tools, Skripten usw. von vorne zu beginnen, um ein Problem zu lösen. PowerShell kann für diese Szenarien eine Vielzahl von Informationen liefern, aber auch auf ältere Tools zurückgreifen. Viel Spaß und vor allem Erfolg bei der Suche!

Weiterführende Links

• ScriptRunner Active Directory ActionPacks
• Auf einen Klick: So sieht ScriptRunner aus, leg los ganz ohne Download! So kann das Leben eines Administrators mit ScriptRunner aussehen 
• Buche hier eine ScriptRunner Demo