Det här inlägget är en uppföljning från det tidigare inlägget SCCM 2012: Datorvariabler fungerar inte efter en återställning från backup. Problemet jag beskrev där var hur det blir en mismatch på versionshanteringen för en tabell i databasen då man återställer en backup som innehåller avsevärt färre objekt. Tabellen i fråga berör policies för datorvariabler, och senaste versionen av denna tabell lagras även i registret. När man återställer databasen är alltså värdet annorlunda i registret och databasen, varpå datorvariabler inte kommer fungera förrän databasen har ”kommit ikapp” det värde som står i registret.
Min frågeställning var om detta scenario kan undvikas beroende på hur man gör sin återläsning från backup. I scenariot som min kund hade råkat ut för hade man enbart läst tillbaka databasen, utan att köra setup-programmet för SCCM och välja ”Recover site”.
Jag har nu haft tid att testa igenom lite fler scenarion i min testmiljö för att studera det här lite närmare.
Testscenario och metodik
I min testmiljö skapade jag några datorobjekt och lade till variabler till dem i SCCM-konsolen. Jag höll ögonen på vad som hände i databasen med följande queries:
|
1 2 3 |
select * from MEP_MachineExtendedProperties order by rowversion select @@DBTS select * from MEP_MachinePolicies |
Dessa queries visar alla datorobjekt som fått en variabel sorterat efter ”rowversion”, det senaste globala rowversion-värdet i databasen, samt vilka datorobjekt som det genererats en policy för, och därmed alltså kommer fungera. Jag kontrollerade också ”Last Row Version”-värdet i registret, som återfinns här:
HKLM\Software\Microsoft\SMS\Components\SMS_Policy_Provicer\MEPHandler som alltså alltid ska matcha det senaste värdet i MEP_MachineExtendedProperties.
Jag provade sedan att skapa 1000 nya datorobjekt i SCCM, och även att importera in 1000 nya användare. Som väntat ökas det globala rowversion-värdet i databasen kraftigt, då alla nya objekt genererar en massa transaktioner i databasen. Jag skapade sen manuellt ytterligare ett datorobjekt och lade till en datorvariabel. Rowversion-värdet för detta datorobjekt i tabellen MEP_MachineExtendedProperties var nu minst 1000 högre än objektet innan, vilket naturligtvis är förväntat. Jag kontrollerade också att värdet sparades även i registret.
Jag testade sedan att återskapa från en backup som jag tog innan jag importerade in mina 1000 objekt. Jag testade de olika supportade varianter som finns för att återställa en SCCM-installation som finns dokumenterade på Technet. Detta gör man genom att starta setup-programmet för SCCM och välja ”Recover a site”:
Vad jag hoppades upptäcka var om det i något scenario inte blir en mismatch mellan värdet i databasen och i registret.
Resultat
Så länge SCCM finns installerat på servern finns enbart valet ”Recover the site database…” tillgängligt i wizarden. För att återställa även site servern från en befintlig backup (som måste tas med det inbyggda jobbet i SCCM) så måste man avinstallera SCCM först (alternativt ominstallera Windows).
Jag började med att enbart återställa databasen från wizarden. Jag testade både varianten med att peka ut en backup som jag gjort med det inbyggda SCCM-backupjobbet, och även att manuellt återställa databasen från SQL Management Studio och sen välja Use a site database that has been manually recovered från wizarden.
Resultatet från båda dessa metoder blev exakt detsamma. Återläsningen gick bra, SCCM fungerade fint, mina 1000 importerade objekt var borta, och alla ”rowversion”-värden i databasen ställdes tillbaka till där de var innan de 1000 objekten importerades.
Men, registret återställdes inte och problemet med mismatchen uppstår alltså i det här scenariot – oavsett om man använt SCCMs inbyggda backup eller en vanlig SQL-backup.
Jag gick sen vidare med att börja om med en ominstallerad server, köra setupen igen, och den här gången välja scenariot att återställa hela site servern från backupen.
En liten fotnot här är att jag använde mig av en databas med splittade databasfiler. Detta lyckades setup-programmet inte att återläsa, så wizarden misslyckades. Med en icke splittad databasfil går det dock bra. Jag fick därför först manuellt återställa databasen i SQL Management Studio. Det här problemet måste jag testa mer och återkomma om.
Registernyckeln HKLM\Software\Microsoft\SMS\Components\SMS_Policy_Provicer\MEPHandler finns inte när man gör en ny installation av SCCM, utan skapas första gången man skapar en ny datorvariabel. Jag hade dock förväntat mig att nyckeln skulle finnas från början efter att ha läst tillbaka backupen, men det visade sig att så var inte fallet. Det förvånade mig då man kan se att detta värde tas med i backupjobbet, det återfinns nämligen i filen SMSbkSiteRegSMS.dat som ligger i backupkatalogen. Däremot skapades nyckeln lydigt på nytt när jag lade till en ny datorvariabel, och ”last row version”-värdet pekade korrekt mot det senaste värdet i databasen.
Alltså ingen mismatch mellan registret och databasen i det här scenariot, så datorvariabler kommer fungera som de ska.
Hur registervärdet återskapas vet jag dock inte, det måste finnas någon logik som helt enkelt tittar på det senaste värdet i MEP_MachineExtendedProperties och skriver in detta i registret.
Slutsats och rekommendation
Resultatet blev alltså att genom att enbart återläsa databasen så kommer det alltid bli en mismatch mellan värdet i registret och databasen. Om man återläser hela servern kommer värdet i registret att genereras på nytt och fungera som det ska. Dock skiljer sig inte detta från att göra en ren installation av SCCM och bara återläsa databasen, då registervärdet kommer återskapas även då.
Så vad blir lärdomen och rekommendationen? Om man vill backa tillbaka t.ex. någon ändring man gjort i SCCM, ska vi då enbart läsa tillbaka databasen? Eller ominstallera hela servern? Ska vi använda det inbyggda SCCM-backupjobbet, tillför det något?
Som jag skrev i förra inlägget är förmodligen scenariot som min kund råkat ut för ytterst ovanligt. Det är förmodligen mycket sällan någon läser tillbaka en backup med syfte att radera hundratusentals användarobjekt. Därför kommer mismatch-problemet med datorvariabler knappast vara ett vanligt problem i praktiken.
Detta blir alltså mer ett teoretiskt problem, och min förra slutsats med att detta är ett designfel av Microsoft kvarstår. Värdet borde lagras i databasen där det hör hemma, och inte i registret.
Kan man då känna sig trygg med att enbart läsa tillbaka en databas, utan att ominstallera hela servern? Min åsikt måste bli ”ja” på den frågan. Framför allt om det är en backup från enbart någon dag tillbaka i tiden, och om inga gigantiska förändringar skett. Det finns en rad andra ”rowversion”-värden i registret, så det här teoretiska problemet kan eventuellt uppstå med andra saker. Men det känns alltså osannolikt i de flesta scenarion.
Tillför då det inbyggda SCCM-backupjobbet överhuvudtaget något längre? Svaret måste bli nej från mig, jag ser ingen anledning till att använda det längre. Behöver man återställa hela servern gör man en ren installation och återställer sen databasen, och får på så vis tillbaka allting. De registernycklar som tas i backupen tycks ändå inte läsas tillbaka (vilket verkligen är helknäppt), och i övrigt så tar backupjobbet bara med loggfiler och lite annat som inte känns tillräckligt relevant för att det ska vara värt det.
Rekommendationen blir alltså, fortsätt gör rena databasbackuper och använd dessa för återställning. Databaserna måste som bekant tas om hand om, där backup bara är en del av underhållsjobbet. Favoritmetoden i SCCM-världen är att använda sig av Ola Hallengrens utmärkta lösning för databasunderhåll. Använd denna och ta backuper varje dag. Vill man kan man även ta backup på site servern med det inbyggda backupjobbet eller någon annan metod, men detta blir alltså kaka på kaka som förmodligen aldrig kommer behövas. Dock ska man naturligtvis ha backup på sina source filer, och eventuella andra saker såsom script man har skapat och dylikt.
