Adam Automatorn
detta är del II i en tvådelad serie om Active Directory-hälsokontroller. Även om det inte krävs läsning, om du vill lära dig hur PowerShell-skriptet du lär dig om i den här artikeln byggdes, uppmuntras du att kolla in att bygga ett Active Directory-Hälsokontrollverktyg : del I.
i del i lärde du dig hur många olika flera tester och varför de är viktiga. Låt oss nu dra dem alla tillsammans och bygga ett verktyg. I den här delen konverterar du alla Active Directory-hälsokontroller som förklaras i del I till ett testramverk. Du lär dig också hur du matar ut resultat från olika ANNONSHÄLSOKONTROLLER till verktyg som Pester och ett övervakningsverktyg som heter PRTG.
för att följa med eller se en färdig version av verktyget du ska lära dig om i den här artikeln, ladda ner adhealthcheck-Norresult.ps1-skriptet från GitHub.
Innehållsförteckning
definiera Output
att ha en gemensam objekttyp och ett enkelt sätt att generera det kommer att göra det mycket lättare att konvertera testresultat till det verktyg du väljer.
för att skapa en enhetlig utgång för alla potentiella verktyg har jag valt att använda en PowerShell-klass. Även om det inte krävs, det är det tillvägagångssätt Jag har valt att ta här. Huvudpoängen är att se till att alla AD-hälsokontroller returnerar samma typ av produktion.
en PowerShell-klass är ett schema som definierar hur ett PowerShell-objekt ska se ut och vad det ska göra. Varje rad du ser nedan representerar en egenskap som objektens retur kommer att ha. Du kan se nedan Jag planerar på varje annons hälsokontroll för att returnera tio fastigheter.
Class AdhcResult { $Source $TestName $Pass $Was $ShouldBe $Category $SubCategory $Message $Data ]$Tags}
för att påskynda denna klassskapande använder jag en hjälparfunktion som heter New-AdhcResult. Denna funktion skapar klassen och allt du behöver följa med. Denna funktion kommer att mata ut en anpassad
typ objekt.
kör verktyget AD Health Check
hämta och kopiera först ad health check-skriptet till en domänkontrollant. Öppna den med PowerShell ISE och kör den. Denna del av verktyget kommer inte att returnera någon information.
THS script kommer att köra och lagra resultatet av varje kontroll i $TestResults
variabel som flera objekt. Du kommer att använda dessa objekt senare för att generera rapporter eller mata ut det i olika verktyg. Om du håller hälsokontrollresultat i en variabel som denna kan du lägga till fler resultat om du väljer att skapa en annan och använda kommandot
New-AdHcResult
.
när skriptet är klart ska du nu ha en komplett uppsättning ad health check-objekt lagrade i variabeln $TestResults
. Du kan nu köra $TestResults
från konsolen och se de råa resultaten.
visar ANNONSHÄLSOKONTROLLRESULTAT i Verktyg
eftersom alla kontroller är i en vanlig objekttyp kan du bättre inspektera dem genom ett par verktyg som Pester och PRTG.
i det här avsnittet kommer du att lära dig hur du skapar en HTML-rapport med ett verktyg som heter Extension och att visa rapporten i PRTG.
skapa en nUnit XML-fil med Pester
du måste först konvertera PowerShell-objekten i ett format som dina verktyg kan förstå. De flesta verktyg förstår XML eller, mer specifikt, nUnit XML. Detta är ett format som du kan importera till olika verktyg för att visa resultat.
eftersom du arbetar med PowerShell använder du Pester testing framework för att läsa utdata från AD health check script och för att generera en nUnit XML-fil
börja med att ladda ner den senaste versionen av Pester. Du kan ladda ner Pester genom att köra Install-Module
i en förhöjd PowerShell-konsol. Kommandot nedan kommer att tvinga en installation av den senaste Pesterversionen. Eftersom utgivarcertifikatet som Pester är signerat med levereras med Windows 10 måste vi använda parametern SkipPublisherCheck
för att installera den.
PS51> Install-Module Pester -Force -Verbose -SkipPublisherCheck
när Pester är tillgängligt kan du sedan köra skriptet och dynamiskt skapa en uppsättning Pestertester.
Obs: Du kan också skapa Pestertester själv utan att ens använda PowerShell-skriptet jag har tillhandahållit.
nedanstående PowerShell-skript kommer att använda Pester för att generera en nUnit XML-fil från utmatningen från variabeln $TestResults
definierad i adhealthcheck-Norresult.ps1-skriptet.
spara den här filen som Pester.ps1 i samma mapp som AD health check script.
# dot source in the ADHealthCheck file. $PSScriptRoot\ADHealthCheck-NoResult.ps1$Grouped = $TestResults | Group-Object CategoryForeach($Category in $Grouped) { Describe -Name $Category.Name -Tags ($Category.Group.Tags | Select -Unique) { Foreach($Result in $Category.Group){ Context "$($Result.Source) - $($Result.TestName)" { It -Name "Should've passed" { $Result.Pass | Should -Be -ExpectedValue $True -Because $Result.data } } } }}
slutligen, kör Invoke-Pester
nedan för att åberopa Pesteren.PS1 fil och spara resultaten i NUnitXml
format.
PS51 > Invoke-Pester -Script @{Path = '.\Pester.ps1'} -OutputFile .\NunitReport.xml -OutputFormat NUnitXml
bygga en HTML-rapport med verktyget utsträckning
när du har NUnit XML-filen kan du nu använda den här filen för att skicka till ett verktyg som kan konvertera det till HTML. Ett av dessa verktyg kallas utsträckning. Extension är ett praktiskt verktyg för att skapa HTML-rapporter från Nunit XML-filer.
först, ladda ner utsträckning till samma katalog som NunitReport.xml-fil skapad tidigare. Kör sedan följande kommandon i en PowerShell-session. Dessa kommandon skapar katalogen för att lagra HTML-filerna och sedan utföra omfattning.exe för att göra konverteringen.
# Create report directoryPS51> mkdir .\HTMLReports# Create the reportPS51> .\extent.exe -i .\NunitReport.xml -o .\HTMLReports\
när du är klar hittar du två HTML-filer i htmlreports-katalogen. Dessa filer ser ut som nedanstående skärmdumpar du öppnar dem med en webbläsare.
intag av ANNONSHÄLSOKONTROLLRESULTAT i PRTG
PRTG är ett populärt övervakningsverktyg utvecklat av Paessler som du kan använda för att övervaka din infrastruktur och tjänster. I det här avsnittet lär du dig att driva hälsokontrollresultaten till PRTG när hälsokontrollskriptet har körts.
Pushing resultat till PRTG tar mer arbete snarare än att ha verktyget dra information men du kommer så småningom se installationen är väl värt den tid som spenderas.
förutsättningar
för att framgångsrikt ställa in PRTG som ett övervakningsverktyg för AD health check script byggt i den här artikeln, se till att du har:
- PRTG installerat och konfigurerat
- alla domänkontrollanter som inrättats i PRTG
- Send-AdhcResultToPrtg.ps1 PowerShell script hämtas från GitHub
- URL och port y0ur PRTG sensor
om du har var och en av prereqs gjort, kan du sedan följa nedanstående steg-för-steg-instruktioner om hur jag rekommenderar att driva dessa AD hälsokontrollresultat till PRTG.
- skapa en enhet i PRTG som heter domän eller vilket namn du föredrar.
- skapa en avancerad HTTP push-sensor med en IdentityToken av directory-adhealthcheck. Observera att detta är skiftlägeskänsligt!
- för varje domänkontrollant enhet i PRTG, skapa en avancerad HTTP push sensor. För varje IdentityToken, bifoga varje sensor med-adhealthcheck såsom dc01-adhealthcheck.
- Lägg till innehållet i Send-AdhcResultToPrtg.ps1 PowerShell-skriptet till slutet av ADHealthCheck-Norresult.ps1 PowerShell-skriptet vi har täckt.
- ändra variabeln
$PRTGUrl
till webbadressen och porten på din PRTG-sensor. - kör skriptet.
när det är klart, när ad health check-skriptet är klart, ska det nu trycka status till dina PRTG-sensorer som visas nedan.
schemaläggning av Active Directory Health Check Script
övervakning av ANNONSHÄLSA är en pågående process. Du bör köra tester hela tiden snarare än ad hoc-instanser. Låt oss schemalägga Active Directory hälsokontroll skript för att köra med jämna mellanrum.
det enklaste sättet att automatisera dessa kontroller är att lägga till skriptet i Schemaläggaren och låta det köras under ett AD-användarkonto eller ett Grupphanterat servicekonto.
att använda ett Grupphanterat servicekonto (Gmsa) är det säkrare sättet att utföra schemalagda aktiviteter autonomt eftersom endast angivna datorkonton som kan hämta lösenordet från AD. Men vissa organisationer kanske inte har denna lyx.
skapa ett AD-användarkonto
låt oss först bryta ner vad som krävs för att få ett AD-användarkonto konfigurerat för att köra den schemalagda aktiviteten.
om du ska köra en schemalagd aktivitet som ett användarkonto, kör det inte som ditt eget konto! Skapa alltid ett separat användarkonto för detta ändamål.
för att spara tid kommer du att se ett PowerShell-skript nedan. Det här är ett exempelskript som du kan använda för att skapa ett AD-användarkonto som ingår i gruppen domänadministratörer. Du kan sedan använda det här kontot för att köra schemalagd aktivitet med.
# Change this to the OU of your service accounts$OU = "OU=Service Accounts,DC=contoso,DC=com"# Change this to the password that you want to use for the account$Password = "JägareTvå"$SecureString = $Password | ConvertTo-SecureString -AsPlainText -ForceNew-ADUser -Enabled $True -Path $OU -Name svcADHealthCheck -AccountPassword $SecureString# Restrict account to only Domain Controllers$DomainControllers = (Get-ADDomainController -Filter *).NameSet-ADAccount -Identity svcADHealthCheck -LogonWorkstations ($DomainControllers -Join ",")# Making it Domain Admin (Sorry)Add-ADGroupMember -Identity "Domain Admins" -Members svcADHealthCheck
skapa ett Grupphanterat servicekonto
att använda en gMSA för att köra hälsokontrollen är lite svårare om du inte använder gMSA i din miljö redan, men det är mycket säkrare.
skapa en KDS-Rotnyckel
för att skapa ett gmsa-konto för att köra ad health check-skriptet, lägg först till en KDS-rotnyckel om du inte redan har en. Du kan kontrollera om du har en KDS-rotnyckel genom att köra PowerShell-kommandot Get-KDSRootKey
på en domänkontrollant.
om du inte har en KDS-rotnyckel skapar du en genom att köra Add-KDSRootKey -EffectiveImmediately
under ett användarkonto som ingår i annonsgruppen domänadministratörer på en domänkontrollant för 2012R2 eller senare.
nyckeln måste replikera ut till de andra domänkontrollanterna för att få full effekt. Mer information om denna process finns i Microsoft-dokumentationen.
skapa gmsa
när KDS-rotnyckeln har skapats är du redo att skapa gmsa-kontot med PowerShell. Nedan kan du se ett exempelskript som ska användas för att skapa gmsa-kontot som endast får autentiseras från en domänkontrollant i gruppen domänadministratörer.
# Change to your domain$Domain = "contoso.com"$AccountName = "svcadhealthcheck"# Create a GMSA called svcadhealthcheck (or in reality svcadhealthcheck$) and allow only Domain Controllers to fetch the passwordNew-ADServiceAccount $AccountName -DNSHostName "$AccountName.$Domain" –PrincipalsAllowedToRetrieveManagedPassword "Domain Controllers"# Add the GMSA to Domain Admins# Note that we're adding the the account by it's true SamAccountName 'svcadhealthcheck$'Add-ADGroupMember -Identity "Domain Admins" -Members "$AccountName`$"
installera och testa gmsa
nu skapas gMSA, det sista steget är att installera och testa det på alla domänkontrollanter. Ett sätt att göra detta är att använda kommandot Invoke-Command
PowerShell. Nedan kan du se ett PowerShell-skript som installerar gMSA på alla DCs och ser till att det fungerar korrekt.
# This will run on all Domain ControllersInvoke-Command -ComputerName (Get-ADDomainController -Filter *).Name -ScriptBlock { $Account = Get-ADServiceAccount -Filter { Name -eq 'svcadhealthcheck'} Install-ADServiceAccount $Account # Tests that the GMSA works on the computer # Returns $True if tests are OK $Test = Test-ADServiceAccount -Identity $Account.Name if($Test){ Write-Output "GMSA test OK on $env:computername" } else { Write-Output "GMSA test FAILED on $env:computername" }}
ge Gmsa behörighet att köra som ett batchjobb
när gMSA är installerat måste du nu ge det behörighet att köra som ett batchjobb på DCs. Kontot behöver denna rättighet eftersom det kommer att köras autonomt i bakgrunden i en schemalagd uppgift.
du kan ställa in denna behörighet via en befintlig GPO eller genom att skapa en ny GPO och länka den till Domänkontrollanternas OU. Om du inte redan har en GPO att använda, nedan är några steg du kan vidta för att skapa en.
- starta grupprincipredigeraren på en DC.
- högerklicka på Domänkontrollanterna OU och välj Skapa GPO i den här domänen och länka den här.
- namnge det DC-inloggning som batch eller ett annat namn du föredrar
- högerklicka på GPO och klicka på Redigera.
- gå till Datorkonfiguration – > Windows –Inställningar –> säkerhetsinställningar – > tilldelning av användarrättigheter.
- vänsterklicka på Logga in som batchjobb och klicka på Egenskaper.
- klicka på Lägg till användare eller grupp.
- klicka på objekttyper, välj endast Servicekonton och klicka på OK.
- Sök efter svcADHealthCheck-servicekontot som skapats tidigare, välj det och klicka på OK.
du bör nu se gMSA under listan över ANNONSOBJEKT som visas nedan.
skapa den schemalagda aktiviteten
nu när du har skapat ett konto för att köra de schemalagda aktiviteterna kan du nu skapa den schemalagda aktiviteten själv på en domänansluten server efter eget val.
du kan skapa den schemalagda uppgiften via GUI men det är för mycket att klicka! Istället rekommenderar jag att du skapar det med PowerShell. Varför? Eftersom du helt enkelt kan kopiera koden du ser nedan och göras med den.
nedan hittar du två skript; båda skripten är likartade men man antar ett AD-användarkonto och det andra antar en gMSA. Var noga med att använda rätt skript baserat på vilket konto du använder.
# Replace with the path to your script$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"# Replace with the username of the account that you created to run the task$UserName = "svdADHealthCheck"# Replace with the password that you set for above account$Password = "JägareTvå!"# Create the action that launches the script$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"# Create the trigger that starts the task$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)# Create settings for the scheduled task$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd# Create the scheduled task using a splat for readability$Splat = @{ User = "$env:USERDOMAIN$UserName" Password = $Password TaskName = "ADHealthCheck" Action = $Action Trigger = $Trigger RunLevel = "Highest" Settings = $Settings}Register-ScheduledTask @Splat
# Replace with the path to your script$ScriptPath = "C:\Scripts\ADHealthCheck.ps1"# Replace with the username of the account that you created to run the task$UserName = "svdADHealthCheck$"# Create the action that launches the script$Action = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-ExecutionPolicy bypass -File '$ScriptPath'"# Create the trigger that starts the task$Trigger = New-ScheduledTaskTrigger -Once -At "12:00" -RepetitionInterval (New-TimeSpan -Hours 12)# Create settings for the scheduled task$Settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -StartWhenAvailable -RunOnlyIfNetworkAvailable -DontStopOnIdleEnd# Create principal that defines the GMSA$Principal = New-ScheduledTaskPrincipal -UserID "$env:USERDOMAIN$UserName" -LogonType Password -RunLevel Highest# Create the scheduled task using a splat for readability$Splat = @{ Principal = $Principal TaskName = "ADHealthCheck" Action = $Action Trigger = $Trigger RunLevel = "Highest" Settings = $Settings}Register-ScheduledTask @Splat
du är klar! Vid den här tiden kommer den schemalagda uppgiften att utföras med det intervall som anges i ett av skripten ovan.
Sammanfattning
Whew! Om du har följt hela vägen från del I, du borde veta nu att ANNONSHÄLSA är ett djupt ämne. Det finns så mycket att detta ett ämne som inte ens två långa blogginlägg kan täcka.
men nu borde du ha tillräckligt med kunskap och en förbyggd PowerShell-ram som du kan ansluta till andra Active Directory-hälsokontroller när de uppstår.
Vidare läsning
- några saker du kanske inte vet om AD och katastrofåterställning
- Vad gör DCDIAG faktiskt… gör?