Del 2 – Den ultimata guiden till Java deployment med SCCM

Det här är del 2 i serien: Den ultimata guiden till Java deployment med SCCM
Del 1 hittar du här.

I den första delen tittade vi på hur vi förbereder Java för att installeras med hjälp av SCCM. Huvudpunkterna är att vi extraherar ut MSI-paketet från den nedladdade EXE-filen, definierar Javas konfigurationsfiler för att sätta säkerhetsinställningarna till en nivå som passar på företag, samt installerar allting med PS App Deployment Toolkit.

När nu en ny version av Java dyker upp betyder det att vi på nytt måste ladda ned installlationspaketet, extrahera MSI-filen, skapa en ny källkatalog där vi lägger PS App Deployment Toolkit, MSI-filen och konfigurationsfilerna. Därefter skapar vi förmodligen en ny Application i SCCM och gör kanske en supersedence-regel som gör att vår nya Java-application ersätter alla gamla versioner, och deployar denna till våra klienter.

Inga konstigheter så långt. Men eftersom det är Java vi pratar om här så betyder det att vi kommer behöva göra det här om och om och om igen. Nya versioner släpps ungefär lika ofta som man borstar tänderna (ok, inte riktigt). Roligare saker kan man ägna sin tid åt. Men eftersom vi kommer göra exakt likadant varje gång så betyder det att den här uppgiften lämpar sig utmärkt för automatisering.

Powershell to the rescue!

Oracle har gjort en enda bra sak här i världen, och det är att alltid tillgängliggöra senaste Java-versionen från samma nedladdningslänk (till skillnad från t.ex. Adobe, som släpper sina uppdateringar minst lika ofta men alltid från nya nedladdningslänkar). Så vi kan alltså enkelt med ett script ladda ned den senaste versionen, vilket bara det spar en del tid. Däremot gillar man inte sina kunder tillräckligt för att låta oss extrahera ut MSI-paketet på något automatiserat sätt (nytt från och med Java 8 är att Oracle faktiskt erbjuder en MSI installer men bara om man betalar för ett supportavtal, det låter som ett dåligt skämt men det är det dessvärre inte), men det finns det faktiskt också intelligenta människor som har löst.

Så kort och gott, det mitt script gör är följande:

1. Laddar ned den senaste Java-versionen från Internet.
2. Extraherar ut MSI-paketet och läser ut versionsnummer och produktkod.
3. Skapar en ny källkatalog, med versionsnumret som namn.
4. Kopierar dit PS App Deployment Toolkit filerna samt det nya MSI-paketet (innehållet i zip-filen i Del 1)
5. Uppdaterar den befintliga Java applikationen i SCCM med nytt versionsnummer, ny källkatalog samt ny detection method (produktkoden för det nya MSI-paketet).
6. Uppdaterar distributionspunkterna.

Tanken är alltså att istället för att bygga nya Applications för varje ny version, och använda sig av Supersedence, så uppdaterar man bara samma Application istället. Detta fungerar för att:

• Avinstallation av äldre versioner sköts av PS App Deployment Toolkit scriptet
• Installationen sker likadant varje gång. Installationsscriptet Deploy-Application.ps1 behöver aldrig förändras (strunta i att skriva in versionsnummer i scriptet). MSI-paketet kommer alltid heta ”Java.msi”.
• Detection metoden uppdateras vilket betyder att installationen automatiskt kommer köras på alla klienter nästa gång de kör sin ”Application Deployment Evaluation Cycle” (körs som default en gång i veckan, jag brukar alltid ändra detta till en gång om dagen)

Känns det läskigt att uppdatera Java-applikationen? Ha två applikationer då, en för test och en för produktion. Vilken applikation som uppdateras styrs av en parameter, så det är bara att först köra Update-Java.ps1 -ApplicationName ”Java – Test” och när man känner sig nöjd och har testat osv så kör man igen med Update-Java.ps1 -ApplicationName ”Java – Prod”.

Så det du behöver för att köra detta är alltså att ha skapat en Application i SCCM enligt instruktionerna i Del 1, och sparat innehållet i den zip-filen i en lämplig katalog som kommer fungera som mall. Det innehållet kommer scriptet att kopiera till den nya katalog som skapas för varje ny version. Lämpligtvis har du en toppkatalog som kommer innehålla underkataloger för varje version, och så placerar du även mall-katalogen här. Det kommer alltså se ut ungefär så här:

I det här exemplet anger jag alltså JavaBaseSourcePath = ”\\sccm01\Sources\Applications\Java” och JavaTemplatePath = ”\\sccm01\Sources\Applications\Java\Template” som parameterar till scriptet. Jag måste också ange ApplicationName, vilket alltså är namnet på min Java Application i SCCM, och DeploymentTypeName, som är namnet på applikationens deployment type. Eftersom de här parametrarna oftast kommer förbli oförändrade i en miljö så är det förmodligen enklast att skriva in värdena direkt i scriptet.

OBS! Ett par saker att vara medveten om.

1. Scriptet fungerar enbart med Java version 7. Någon gång efter Java 8 (tror det var Java 8 Update 20) så gjorde Oracle om sin installer, och bakade även in CAB-filen direkt i MSI-paketet. Scriptet hanterar inte detta ännu. Har du börjat köra Java 8 måste du alltså manuellt ladda ned och extrahera MSI-paketet, enligt beskrivningen i Del 1. Jag hoppas få tid att uppdatera scriptet så att även Java 8 hanteras inom snar framtid.
2. Var försiktig med att redigera applikationens deployment type i konsolen så att du inte råkar ut för den här buggen. Då kommer inte scriptet klara att uppdatera detection metoden och du måste skapa om din applikation från början.

Ladda ned scriptet nedan och döp om det till Update-Java.ps1.

Ladda ned scriptet här