14 min read
Der Schlüssel zu produktiver Softwareverwaltung: winget & PowerShell
Steigere die IT-Effizienz mit Winget und PowerShell! Lies, wie du Installationen, Updates und die Verwaltung von...
ScriptRunner Blog
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.
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.
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 $_
}
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.
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.
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'
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
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 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
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.
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.
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
}
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!
Die Verwaltung von Active Directory ist eine der zeitaufwändigsten wiederkehrenden Aufgaben für viele IT-Administratoren und System Engineers.
Die Erstellung und Verwaltung von Benutzern und Gruppen, die Administration von OUs und Computer Accounts sowie die Generierung detaillierter AD-Berichte stehen ständig auf der To-Do-Liste.
Wir zeigen dir, wie du alle Active Directory-Prozesse und Aufgaben optimieren, automatisieren, delegieren und überwachen kannst.
Spare Zeit, reduziere Fehler und konzentriere dich auf wichtige IT-Projekte.
Wir senden übrigens über unseren Newsletter die Termine und Themen der nächsten Webinare.
Dez 19, 2024 by Jeffery Hicks
Steigere die IT-Effizienz mit Winget und PowerShell! Lies, wie du Installationen, Updates und die Verwaltung von...
Dez 19, 2024 by Damian Scoles
Mit Microsoft Purview verstehst und verwaltest du Daten in deinem gesamten Datenbestand – wie kannst du PowerShell...
Dez 17, 2024 by Sonny Jamwal
Erweitere PowerShell mit .NET für eine leistungsstarke Ereignisautomatisierung. Systemereignisse wie ein Profi...
Damian Scoles ist ein zehnfacher Microsoft MVP mit Spezialisierung auf Exchange, Office 365 und PowerShell, der über 25 Jahre Erfahrung in der IT-Branche mitbringt. Er ist im Großraum Chicago ansässig und begann mit der Verwaltung von Exchange 5.5 und Windows NT. Im Laufe der Jahre hat er mit Office 365 seit BPOS gearbeitet und darüber hinaus Erfahrung mit Azure AD, Security and Compliance Admin Centers und Exchange Online. Zu seinem Engagement in der Community gehören Beiträge in TechNet-Foren, die Erstellung von PowerShell-Skripten, die in seinen Blogs zu finden sind, das Schreiben von ausführlichen PowerShell/Office365/Exchange-Blogartikeln, Tweets und die Erstellung von PowerShell-Videos auf YouTube. Er hat fünf PowerShell-Bücher geschrieben und arbeitet außerdem aktiv an dem Buch "Microsoft 365 Security for IT Pros".