Guide: Exekvera site maintenance tasks i SCCM 2012 med PowerShell

Då tidigare inlägg som går lite mer på djupet i SCCM har varit populära så tänkte jag slå till med ännu ett i samma tema. Den här gången tänkte jag att vi skulle titta ned lite i databasen igen, och se hur vi letar oss fram till rätt information, och hur vi sedan utför något som inte går att göra direkt i SCCM via PowerShell.

Som exempel kommer jag använda en s.k. ”site maintenance task” i SCCM, och visa hur vi kan starta den manuellt från PowerShell.

Disclaimer: Fippla aldrig runt i databasen om du inte vet vad du gör eller har bra backuper. Det är inte supportat av Microsoft. Det vi går igenom i den här guiden kan betraktas som säkert, om man inte gör fel, men du gör det på egen risk.

Bakgrund

Om man använder Asset Intelligence i SCCM så tillkommer en hel del möjligheter för inventeringen. Man lägger till nya klasser i WMI, dvs utökar vad som inventeras på klienterna, man kan kategorisera och sammanställa inventerade programvaror på snyggare sätt, och man kan importera in licensinformation om ens applikationer, och på så vis följa upp installerade programvaror kontra faktiska licenser.

När man jobbar med SCCM lär man sig snabbt att saker och ting går långsamt. Allting måste hända i en viss ordning innan ett resultat spottas ut på andra sidan. En del av att vara en uber-administratör för SCCM är att lära sig hur saker och ting hänger ihop under skalet, så att man bl.a. kan trigga igång någonting som man vill ska ske omedelbart. Vilket ju är ett ganska vanligt önskemål. Vem har lust att vänta timmar eller dagar på att en applikation ska installeras, eller en rapport om hur många som installerat den, när chefen står och hänger i dörren och frågar?

Många saker i SCCM bygger på att någonting ska flyttas från en plats till en annan i databasen. Just Asset Intelligence är ett sådant exempel. AI har sina egna tabeller, vyer och stored procedures osv i databasen, och hämtar mycket av sin information från andra tabeller, där inventeringsdata lagras.

Scenario

Vi ska titta lite just på Asset Intelligence. Låt oss säga att vi har installerat en viss programvara på en klient. Vi kör en hardware inventory och ser hur programvaran dyker upp i t.ex. Resource Explorer. Inventeringen har alltså körts, och vi kommer också kunna hitta programvaran i vissa rapporter. Men om vi tittar i vissa Asset Intelligence rapporter så ser vi den däremot inte. Exempelvis om vi har licenser importerade för den här programvaran, och t.ex. tittar på rapporten License 15B – General license reconciliation report by computer. Så varför syns den inte här? Det ska vi ta reda på i den här guiden, och vi ska ta fram en metod för att snabbt uppdatera den här informationen, så att rapporterna börjar funka.

Hur funkar AI?

Lite kort om hur det funkar, och vad som behöver ske i SCCM för att en nyinventerad programvara ska börja dyka upp i AI-rapporterna.

Vi kan enkelt kontrollera vilka programvaror som AI ”känner till” genom att titta under Asset Intelligence och Inventoried Software i SCCM konsolen, under vyn Assets and Compliance. Syns inte programvaran där, så kommer heller inte rapporterna att funka.

Så vad är det för mekanism som ”flyttar” informationen från den vanliga inventeringen till AI? När kan jag förvänta mig att AI har uppdaterats?

En ledtråd till hur man kan tänka här är, att de flesta typer av sådana här aktiviteter, när tabeller i databasen ska uppdateras, sker med s.k. Maintenance Tasks i SCCM. Alla Maintenance Tasks hittar vi genom att högerklicka på Siten i konsolen, under Administration, och välja Site Maintenance.

Tittar vi vilka jobb som finns här så hittar vi ett jobb i listan som heter Summarize Installed Software Data. Det låter ju som det vi vill göra, och jag kan avslöja att mycket riktigt är det detta jobb som ansvarar för att uppdatera programvarorna i AI. Om vi tittar på när detta jobb körs så ser vi att standardinställningen är att köra mellan kl. 00-05 varje dag.

Doh! Vi måste alltså vänta till imorgon innan våra AI rapporter är uppdaterade med dagens alla installationer. Och chefen som ville ha svar ASAP…

Microsoft har tyvärr inte gett oss någon ”Run-right-now-I-don’t-want-to-wait-god-damnit”-knapp för att köra dessa maintenance tasks. Det enda sättet vi kan kicka igång dem från GUI’t är att gå in och ändra schemat till ett par minuter fram i tiden. Detta funkar och kan vara ”good enough” som metod någon gång ibland. Men det är inte helt optimalt. Dels måste man komma ihåg att ställa tillbaka schemat igen efter jobbet är klart, och dels funkar det faktiskt inte alltid helt bra om man t.ex. inte ställt in tidsintervallet, alltså fönstret som jobbet får köras under, tillräckligt långt.

Låt oss nu skapa vår egen ”Run-right-now-I-don’t-want-to-wait-god-damnit”-knapp.

Steg för steg…

Vi börjar med att köra jobbet, genom att som jag skrev ovan, ändra schemat inne i konsolen. När jobbet väl körs vill vi ta reda på vad som faktiskt händer i databasen. Det kan vi göra på lite olika sätt. Vi kan köra SQL Profiler och övervaka allt som sker i databasen, och där garanterat få vårt svar. Det är dock inget jag rekommenderar att börja med. Informationen man får kan vara ganska överväldigande, så man kan behöva filtrera och söka ganska länge innan man finner det man letar efter.

Istället tittar vi i SCCMs loggfiler, och den fil vi vill ha heter smsdbmon.log. Här loggas allting som SCCM gör just mot databasen, så låt oss se vad som händer när vi kör Summarize Installed Software Data-jobbet.

Lämpligtvis använder vi av oss t.ex. Highlight-funktionen i CMTrace och markerar orden ”Summarize Installed Software Data”. Vad vi ser ovan är att jobbet har körts och i det här fallet lagt till 0 rader i en tabell som heter INSTALLED_SOFTWARE_DATA_Summary.

Det var den första ledtråden, bra. Nu vet vi var datat lagras. Men vad använde SCCM för metod för att uppdatera denna tabell? Det ser vi tyvärr inte i loggen. Men SCCM använder sig av Stored Procedures i SQL för den här typen av uppgifter, så allt vi behöver göra är att leta upp rätt SP. Hmm, finns några hundra, så var börjar vi?

In i SQL Management Studio.
Vi vet ju nu vad tabellen heter, så låt oss titta på den. Vi kan ju börja med att högklicka på den och välja Select top 1000 rows så ser vi innehållet. Det vi ser här är en lista med exakt samma programvarutitlar som vi ser i SCCM-konsolen under Inventoried Software. Det verkar ju lovande, men vi vet fortfarande inte hur tabellen uppdateras. Vi högerklickar därför på tabellen och väljer View Dependencies.

Aha, det finns en stored procedure som heter spLoadInstalledSoftwareDataSummary. Låt oss undersöka den, genom att leta upp den i den lååånga listan med stored procedures, högerklicka på den och välja Modify.

När vi tittar närmare på koden ser vi att vad denna SP gör lite kortfattat är att ta en del information från tabellen INSTALLED_SOFTWARE_DATA, lagra resultatet i en temporär tabell och sedan jämföra med innehållet i INSTALLED_SOFTWARE_DATA_Summary. Programvarutitlar som lags till eller tagits bort kommer att uppdateras i INSTALLED_SOFTWARE_DATA_Summary.

Om vi tittar i INSTALLED_SOFTWARE_DATA så ser vi här samtliga inventerade programvaror från alla datorer. Med andra ord är INSTALLED_SOFTWARE_DATA_Summary en summering av INSTALLED_SOFTWARE_DATA (duh! därav tabellens namn) där ett hashvärde används för att identifiera varje unik programvara.

Jaha, det verkar ju logiskt hur det hänger ihop. Vi testar väl att köra denna stored procedure då, högerklicka och välj Execute Stored Procedure.

Tada! Om vi tittar i tabellen INSTALLED_SOFTWARE_DATA_Summary igen så har mycket riktigt vår saknade programvara dykt upp där. Var det verkligen så enkelt? Låt oss titta i SCCM-konsolen också för säkerhets skull. Jajamen, under Inventoried Software har applikationen dykt upp. Strålande.

Var det någon som sa PowerShell?

Nu hade ju jag lovat att vi skulle göra detta med PowerShell också. Vem vill hålla på och hoppa in i SQL Management Studio hela tiden för att göra sådana här saker? Det är ju PowerShell vi vill använda för allt. Så kan man köra en stored procedure i SQL med PowerShell? Jajamen. Vi kan göra det på lite olika sätt, men jag tänker nöja mig med att visa det enklaste sättet här.

Vi använder oss av cmdleten Invoke-Sqlcmd från modulen SQLPS som medföljer när man installerar SQL.

Svårare än det lilla simpla exemplet ovan är det inte. Byt ut CM_S01 mot namnet på din databas (alltså din sitekod), och spara scriptet som t.ex. Update-InventoriedSoftware.ps1 så kan du när som helst köra det.

Slutsats

Genom att ta sig tid att titta lite ”under skalet” kan man lära sig mycket. Och kunskap är nyckeln till hur vi förenklar vårt arbete, vår vardag och våra liv. Den här lilla guiden hade som syfte att hjälpa till att utveckla ett tankesätt, hur man börjar leta efter information i SCCM och hur man tar sig framåt och finner det man söker.

Det här exemplet är också förhoppningsvis till faktisk nytta för någon, i alla fall för er som använder sig flitigt av AI.

Hur skulle man kunna bygga vidare på det här och förfina lösningen?

Genom att använda samma metodik kan vi leta fram hur andra site maintenance tasks fungerar, och t.ex. låta namnet på stored proceduren vara en parameter till vårt script. På så vis kan vi enkelt starta igång olika maintenance tasks. Skulle man kunna lägga till detta i SCCM-konsolen så att man bara behöver klicka någonstans och få upp en lista på våra maintenance tasks, och då kunna köra igång dem direkt? Jajamen, visst kan vi göra det.

Det är, som alltid, bara vår fantasi som sätter gränserna.