SCOM Vedligeholdelsestilstand: Guide & Løsninger

System Center Operations Manager (SCOM) er et utroligt kraftfuldt værktøj til overvågning af en organisations IT-infrastruktur. Men enhver administrator ved, at en af de største udfordringer er at håndtere planlagt nedetid. Uden korrekt styring kan planlagte opdateringer, genstarter eller hardwarevedligeholdelse udløse en sand storm af advarsler, der skaber unødig støj og risikerer at skjule reelle problemer. Løsningen er SCOMs vedligeholdelsestilstand, men at bruge den effektivt, især i ældre versioner eller komplekse miljøer, kræver viden og de rette værktøjer. Denne artikel er en dybdegående guide til, hvordan du mestrer planlagt vedligeholdelsestilstand, automatiserer processen med PowerShell og navigerer i de faldgruber, der findes i højtilgængelige SQL Server Always On-miljøer.

Hvad er vedligeholdelsestilstand og hvorfor er den kritisk?

I sin kerne er vedligeholdelsestilstand en funktion i SCOM, der midlertidigt deaktiverer regler, skærme og notifikationer for et specifikt overvåget objekt eller en gruppe af objekter. Når en server, en applikation eller en netværksenhed sættes i vedligeholdelsestilstand, holder SCOM op med at generere alarmer for den. Dette er afgørende af flere årsager:

• Forebyggelse af alarm-storme: Under en planlagt Windows Update-session, hvor hundredvis af servere genstarter, ville et SCOM-miljø uden vedligeholdelsestilstand blive oversvømmet med 'Heartbeat Failure' og 'Computer Not Reachable' alarmer. Dette skaber panik og gør det umuligt at se, om der opstår et reelt problem.
• Sikring af nøjagtige data: Ved at ekskludere planlagt nedetid fra overvågningen sikrer du, at dine tilgængelighedsrapporter og SLA-beregninger forbliver præcise og ikke bliver forvrænget af planlagte hændelser.
• Reduceret arbejdsbyrde: IT-teams undgår at spilde tid på at undersøge og lukke hundreder af forventede alarmer, så de kan fokusere på deres egentlige opgaver.

Kort sagt, korrekt brug af vedligeholdelsestilstand er forskellen mellem en kaotisk, støjende overvågning og en rolig, effektiv og troværdig platform.

Udfordringen: Planlægning af vedligeholdelse før SCOM 2016

En af de mest markante mangler i SCOM-versioner før 2016 var fraværet af en indbygget funktion til at planlægge vedligeholdelsestilstand i fremtiden. Man kunne kun aktivere den øjeblikkeligt. Dette var en stor frustration for administratorer, der f.eks. ønskede at sætte en gruppe servere i vedligeholdelse kl. 02:00 om natten til patching. Løsningen krævede ofte tredjepartsværktøjer eller komplekse Orchestrator-runbooks. Heldigvis findes der en elegant og kraftfuld løsning ved hjælp af værktøjer, du allerede har: PowerShell og Windows Opgavestyring.

Trin-for-trin guide: Automatiseret vedligeholdelse med PowerShell

Denne metode giver dig mulighed for at oprette en fuldt automatiseret proces til at sætte enhver gruppe af computere i vedligeholdelsestilstand på et hvilket som helst tidspunkt. Processen består af tre hoveddele.

Trin 1: Opret en dynamisk gruppe i SCOM

Før du kan sætte noget i vedligeholdelse, skal du definere, hvad 'noget' er. Den mest fleksible måde at gøre dette på er ved at oprette en dynamisk gruppe i SCOM. Dette giver dig mulighed for automatisk at inkludere eller ekskludere medlemmer baseret på specifikke kriterier. Et godt eksempel er at gruppere servere baseret på deres placering i Active Directory (Organizational Unit, OU).

1. Naviger til Authoring-ruden i din Operations Console.
2. Højreklik på Groups og vælg Create a new Group....
3. Giv gruppen et sigende navn, f.eks. "Citrix-servere til natlig genstart", og gem den i en passende Management Pack.
4. Under Dynamic Members skal du bygge en formel. For at inkludere alle Windows-computere i en bestemt OU, kan formlen se sådan ud:
   ( Object is Windows Computer AND ( Organizational Unit Matches wildcard *OU=Citrix* ) )
5. Du kan tilføje servere, der skal udelukkes, under fanen Excluded Members.
6. Gem gruppen. SCOM vil nu automatisk vedligeholde medlemskabet af denne gruppe.

Trin 2: PowerShell-scriptet der udfører magien

PowerShell-modulet til SCOM indeholder en cmdlet kaldet Start-SCOMMaintenanceMode, som er nøglen til vores automatisering. Nedenstående script er en parametriseret version, der gør det nemt at genbruge.

Gem følgende kode i en .ps1-fil, f.eks. Start-SCOMMaintenance.ps1:

param( [Parameter(Mandatory=$true)] [string]$ManagementServer, [Parameter(Mandatory=$true)] [string]$GroupName, [Parameter(Mandatory=$true)] [int]$Minutes, [Parameter(Mandatory=$true)] [string]$Reason, [Parameter(Mandatory=$true)] [string]$Comment)Try { Import-Module OperationsManager -ErrorAction Stop New-SCOMManagementGroupConnection -ComputerName $ManagementServer -ErrorAction Stop Write-Host "Forbinder til SCOM Management Server: $ManagementServer" $SCOMGroup = Get-SCOMGroup | Where-Object { $_.DisplayName -eq $GroupName } if ($SCOMGroup) { Write-Host "Gruppe '$GroupName' fundet." $EndTime = (Get-Date).AddMinutes($Minutes) Write-Host "Sætter gruppen i vedligeholdelsestilstand i $Minutes minutter indtil $EndTime." Start-SCOMMaintenanceMode -Instance $SCOMGroup -EndTime $EndTime -Reason $Reason -Comment $Comment Write-Host "Vedligeholdelsestilstand er startet succesfuldt." } else { Write-Host "Fejl: Gruppen '$GroupName' blev ikke fundet." }}Catch { Write-Host "Der opstod en fejl under udførelsen af scriptet: $_" Exit 1}

Trin 3: Konfiguration af Opgavestyring (Task Scheduler)

Nu skal vi have Windows til at køre vores script på det ønskede tidspunkt.

1. Åbn Task Scheduler (Opgavestyring) på en server, der har SCOM-konsollen installeret (så PowerShell-modulet er tilgængeligt).
2. Opret en ny opgave (Create Basic Task eller Create Task).
3. Under fanen Triggers skal du definere, hvornår opgaven skal køre (f.eks. dagligt kl. 01:55).
4. Under fanen Actions skal du oprette en ny handling:
   • Program/script:powershell.exe
   • Add arguments (optional): Her indsætter du kommandoen til at kalde dit script med de korrekte parametre. Det er vigtigt at bruge den fulde sti til din scriptfil.

   Eksempel på argumenter:

   -ExecutionPolicy Bypass -File "C:\Scripts\Start-SCOMMaintenance.ps1" -ManagementServer 'din-scom-server.ditdomæne.local' -GroupName 'Citrix-servere til natlig genstart' -Minutes '30' -Reason 'PlannedApplicationMaintenance' -Comment 'Natlig planlagt genstart'

5. Under fanen General skal du sikre, at opgaven kører med en konto, der har de nødvendige rettigheder i SCOM til at starte vedligeholdelsestilstand, og vælg "Run whether user is logged on or not".

Med denne opsætning vil dine Citrix-servere nu automatisk blive sat i vedligeholdelsestilstand i 30 minutter hver nat, lige før deres planlagte genstart.

En særlig fælde: SCOM med SQL Server Always On

Mens PowerShell-metoden løser planlægningsproblemet, opstår der en anden, mere snigende udfordring i moderne, højtilgængelige miljøer. Hvis din SCOM-database er hostet på en SQL Server Always On-tilgængelighedsgruppe, skal du være ekstremt opmærksom på, hvordan planlagt vedligeholdelse fungerer.

Problemet ligger i, hvor SCOM gemmer informationen. Når du opretter en planlagt vedligeholdelsesopgave i SCOM, sker der to ting:

1. Selve tidsplanen og definitionen gemmes i OperationsManager-databasen.
2. Et tilsvarende SQL Server Agent-job oprettes i MSDB-databasen på den på det tidspunkt aktive SQL-node. Dette job er ansvarligt for rent faktisk at starte og stoppe vedligeholdelsestilstanden.

Kernen i problemet er, at mens OperationsManager-databasen replikeres på tværs af alle noder i din Always On-gruppe, gør systemdatabasen MSDB det ikke. Det betyder, at det SQL-job, der styrer din vedligeholdelse, kun eksisterer på den SQL-node, der var primær, da du oprettede tidsplanen. Hvis din Always On-gruppe foretager en failover til en sekundær replika, vil SQL-jobbet ikke eksistere på den nye primære node, og din planlagte vedligeholdelse vil fejle uden varsel. Resultatet er en pludselig og uventet alarm-storm.

Løsningen: Manuel synkronisering af SQL-jobs

Løsningen er desværre manuel, men ligetil. Hver gang du opretter en ny planlagt vedligeholdelsesopgave i SCOM, skal du manuelt synkronisere det tilhørende SQL-job til alle sekundære replikaer.

1. Identificer jobbet: Kør en forespørgsel på din primære SQL-node for at finde navnet på jobbet. Jobnavnet er identisk med ScheduleId i SCOM-databasen.
   SELECT * FROM [OperationsManager].[dbo].[MaintenanceModeSchedule]
   Tag noter af et ScheduleId.
2. Script jobbet: I SQL Server Management Studio på den primære node, naviger til SQL Server Agent -> Jobs. Find jobbet med navnet fra forrige trin. Højreklik på det, vælg Script Job as -> CREATE To -> File... og gem det som en .sql-fil.
3. Opret jobbet på sekundære noder: Forbind til hver sekundær replika i din Always On-gruppe. Åbn den .sql-fil, du lige har gemt. Sørg for, at konteksten er sat til MSDB-databasen, og kør scriptet.
4. Verificer: Opdater joblisten på de sekundære noder for at bekræfte, at jobbet nu er oprettet.

Denne proces skal gentages for hver ny planlagt vedligeholdelse og for hver sekundær replika. Det er en god idé at samarbejde med din DBA for at udvikle en mere automatiseret proces til at holde disse jobs synkroniserede.

Tabel over godkendte vedligeholdelsesårsager

Når du bruger PowerShell-scriptet eller API'et, skal du angive en gyldig årsagskode. Her er en tabel over de accepterede værdier:

Ofte Stillede Spørgsmål (OSS)

Sp: Er PowerShell-metoden stadig relevant for SCOM 2016 og nyere versioner?

Sv: SCOM 2016 og nyere versioner har en indbygget planlægningsfunktion i brugergrænsefladen, hvilket gør denne PowerShell-metode mindre nødvendig for simple opgaver. Dog tilbyder scripting stadig langt større fleksibilitet og er ideel til komplekse automatiseringsscenarier, integration med andre systemer (som et CMDB eller et patch-styringssystem) og til at håndtere situationer, der går ud over, hvad UI'en kan klare.

Sp: Hvad sker der, hvis jeg glemmer at synkronisere MSDB-jobbet i mit Always On-setup?

Sv: Hvis du glemmer at synkronisere jobbet, og din SQL Always On-gruppe fejler over til en sekundær replika, vil din planlagte vedligeholdelse simpelthen ikke køre. De servere eller objekter, du forventede blev sat i vedligeholdelsestilstand, vil forblive aktivt overvåget. Dette vil med stor sandsynlighed resultere i en bølge af falske alarmer, når den planlagte aktivitet (f.eks. genstart) begynder.

Sp: Kan jeg bruge andre kriterier end OU til min dynamiske gruppe?

Sv: Absolut. Den dynamiske gruppekonstruktion i SCOM er meget fleksibel. Du kan bygge regler baseret på en lang række attributter, såsom computerens navn (f.eks. alle servere der starter med 'SQL'), IP-adresse, installeret software, Windows-version eller endda brugerdefinerede værdier, du selv har tilføjet til objekterne.