Guide: Hur man hanterar Software Updates Component i SCCM 2012 R2 med PowerShell och WMI

Nästan varenda liten grej man kan göra i SCCM 2012-konsolen kan man också göra med en färdig PowerShell cmdlet. Nästan, men inte riktigt allt ännu. Men de få saker det inte finns en cmdlet för går att fixa ändå, vanligtvis genom att gå via WMI.

I den här lilla guiden ska vi därför gå igenom:

1. Hur man hittar var någonstans i WMI SCCM skriver/läser något
2. Hur man läser och skriver data i WMI med PowerShell
3. Hur man anropar en metod i WMI med PowerShell

Jag kommer använda Software Updates komponenten som ett exempel.

För att lägga till en Software Update Point använder vi oss av cmdleten Add-CMSoftwareUpdatePoint och för att konfigurera komponenten kan vi använda Set-CMSoftwareUpdatePointComponent. Med den kan vi välja vilka språk och kategorier av uppdateringar vi vill synkronisera, samt ett schema för hur ofta synkronisering ska ske.

Men ett par saker vi INTE kan göra är att välja vilka produkter som ska hanteras i Software Updates (Windows, Office, osv) samt trigga igång en synkronisering manuellt.

Om man nu är som jag och vill bygga ALLT med PowerShell utan att behöva göra ett enda musklick, så är detta en ganska vital sak att kunna konfigurera. Så hur gör man, och var börjar vi?

Det vi gör är att titta i loggfilen SMSProv.log på Site servern (eller rättare sagt den server där providern är installerad, vilket normalt är site servern). Genom att göra en ändring någonstans i konsolen så ser vi genast i loggfilen hur providern kommunicerar med WMI för att utföra ändringen i databasen. Så vi tar och lägger till någon produkt i listan i Software Updates komponenten (varför inte t.ex. den fantastiska Bing Bar som alla naturligtvis vill ha på sina datorer, eller inte…) och kikar i loggen.

Genast dyker ovanstående rader upp i loggfilen. Aha, vi ser att ändringen har gjorts i WMI-klassen SMS_UpdateCategoryInstance, det var den ledtråd vi letade efter.

Låt oss nu undersöka den klassen lite. Det finns många verktyg för att titta i WMI, min personliga favorit är WMI Explorer. Man kan också använda de gamla inbyggda Windows-verktygen wbemtest eller wmic, men år 2014 använder vi PowerShell. 🙂

Så låt oss använda cmdleten Get-WMIObject för att se vad SMS_UpdateCategoryInstance innehåller.
Alla WMI-klasser för SCCM hittas under namespacet Root\SMS\site_<sitecode>, så detta måste vi ange för att hitta vår klass.

Låt oss börja med att testa följande (byt alltså ut ”S01” till din sitecode):

Det gav en väldig massa information. Det som scrollade förbi på skärmen var alltså alla produkter i listan för Software Updates. Den sista produkten i min lista var Visual Studio 2013:

Vi ser att varje produkt har ett antal attribut, och själva namnet hittar vi i attributet LocalizedCategoryInstanceName. Men vad betyder allt det andra? En snabb sökning på SMS_UpdateCategoryInstance leder oss till denna MSDN artikel där allt är dokumenterat. Vi kan se att IsSubscribed är ett läs/skriv värde som tycks vara det som bestämmer om en produkt ska få uppdateringar eller inte.

Låt oss se efter vilka produkter som har detta värde satt till ’True’ genom att lägga till ett filter:

Återigen en massa text som scrollar förbi på skärmen, jag vill inte se all information, jag vill bara se namnet på produkterna och inget annat. Jag använder därför cmdleten Select-Object (eller aliaset ’Select’) för att bara visa den information jag vill se:

Det var bättre, men notera att vi också ser kategorierna för uppdateringar (Critical Updates, Security Updates, osv). Om jag verkligen bara vill se produktnamnen och inget annat så får vi bättra på filtret lite grann:

När jag nu lade till CategoryTypeName = ’Product’ i mitt filter så fick jag till slut det jag vill ha:

I mitt fall tycks alltså Office 2013, Windows 8.1 och Windows Server 2012 R2 vara valda. En snabb koll i konsolen visar att den här listan stämmer helt överens med de produkter som är ikryssade i Software Updates komponenten.

Bra, så nu vet vi var vi hittar informationen i WMI och hur vi kan läsa ut den med hjälp av PowerShell. Vi vet vilket attribut vi behöver ändra, nämligen IsSubscribed. Så vi behöver en metod för att kunna sätta den här lilla flaggan till ”True” eller ”False”. Och hur gör vi det?

Vi börjar med att skapa ett object som vi kan arbeta med, där vi med hjälp av Get-WmiObject och ett filter väljer vilken produkt vi vill ändra, precis som vi gjort ovan. Jag väljer här Bing Bar som exempel:

Sen sätter vi flaggan IsSubscribed till True:

Och till sist sparar vi förändringen med hjälp av metoden Put:

Det var allt. En snabb kontroll i konsolen visar att Bing Bar nu mycket riktigt är ikryssat och kommer få uppdateringar.

Vill vi använda det här i lite mer i praktiken i något script så lägger vi lämpligtvis in den här koden i en funktion som tar emot produktnamn och flaggan som parametrar. Till exempel så här:

Nu har vi gjort en enkel funktion som vi kan anropa inne i ett script eller från script-parametrar. Funktionen kan ta emot mer än ett produktnamn och stega igenom alla som man anger. Så om jag t.ex. vill ta bort alla produkter som är aktiverade som default från början i SCCM, så kan jag bara skriva:

Då så, då har vi gått igenom hur man väljer produkter i Software Updates genom att ändra ett värde i WMI. Men det var ju ytterligare en sak med Software Updates som vi inte kunde göra med någon färdig cmdlet, nämligen att sparka igång en synkronisering. Låt oss därför försöka lista ut hur det går till.

Vi börjar på samma sätt som förut, genom att kika i loggfilen SMSProv.log. Vi startat en synkronisering i konsolen (genom att klicka på knappen Synchronize Software Updates under Software Library | All Software Updates) och ser vad som händer. Resultatet ser ut så här:

Ok det finns tydligen en WMI-klass som heter SMS_SoftwareUpdate och den har en metod som heter SyncNow. Den här klassen med alla attribut och metoder finns dokumenterad på MSDN här. Och dokumentationen bekräftar det vi såg i loggfilen, att den här metoden mycket riktigt används för att starta en synkronisering. Metoden är av typen boolean och vi behöver därför bara sätta den till True för att starta.

Och hur gör vi då det? Man skulle ju kunna tro att man kan använda Put() som vi gjorde ovan, men Put är till för att ändra ett värde i ett attribut, inte för att anropa en metod.

Istället kan vi använda cmdleten Invoke-WmiMethod i PowerShell:

Och svårare än så är det inte. En titt i loggfilen wsyncmgr.log visar att en synkronisering omedelbart sätter igång.