SCCM 2012 R2 CU1 har släppts idag

Cumulative Update 1 för SCCM 2012 R2 finns från och med idag tillgängligt här:
http://support.microsoft.com/kb/2938441

Som vanligt för alla cumulative updates är rekommendationen att endast installera om man upplever något av de problem som uppdateringen löser, eller om stöd för någon ny produkt som man vill använda har lagts till.

Men då den här uppdateringen innehåller en hel del trevligheter såsom de två ”måste-ha” OSD-patcharna KB2905002 och KB2907566, stöd för App-V 5.0 SP2, uppdaterad Endpoint Protection, uppdateringar för Powershell, osv så kommer jag förmodligen installera den här uppdateringen som standard. Får se om den fungerar bra, uppdaterar första servern nu.

 

Facebooktwitterredditpinterestlinkedinmail

Hantering av applikationer med Ninite Pro

Kör ni Adobe Reader, Flash Player och Java på era datorer? Grattis, då gör ni likadant som precis varenda företag i världen då detta kanske är de absolut vanligaste applikationerna, som inte kommer från Microsoft, som installeras som standard på en typisk företagsdator (och privata datorer också för den delen). Kanske kör ni också en uppsjö andra väldigt vanliga gratisapplikationer som finns där ute? Någon webbläsare som inte börjar på ”Internet” och slutar på ”Explorer” kanske, såsom Chrome, Firefox eller Opera? Eller Skype? CutePDF? Hör ni kanske till ett av de där snälla företagen som har paketerat Spotify (och upptäckt hur jäkla omständigt det är)?

Säkerligen har ni ett tiotal, eller fler av den här typen av vanliga programvaror. Och som alla andra IT-tekniker runt om i världen så spenderar ni en avsevärd mängd tid att paketera dessa applikationer för installation, för att sen göra om jobbet igen nästa vecka då det har släppts en uppdatering. Och plötsligt känns ”gratis” inte så billigt längre, då din tid, eller den där dyra paketeringskonsultens tid, är allt annat än gratis…

Till poängen. Det finns ett antal verktyg ute i världen som försöker underlätta det här jobbet, och installera och uppdatera programvaror på ett automatiserat sätt, så att vi kan göra bättre saker med vår tid. Jag har tittat lite på ett mycket enkelt och billigt sådant alternativ som heter Ninite Pro (ninite.com/pro).

Sammanfattning

Min bedömning av Ninite är att det har följande styrkor och fördelar:

  • Billigt, snudd på gratis. Priset kommer aldrig vara en avgörande fråga om huruvida man vill använda det här verktyget eller inte.
  • Oerhört enkelt att använda och att lära sig. Man är igång i princip direkt.
  • Inga installationer behövs, det är bara en exe-fil som körs. Kan därför användas tillsammans med vilket annat verktyg som helst (SCCM, MDT, osv).
  • Stabilt och väl fungerande enligt vad jag sett än så länge. Inga konstigheter.

Finns det då några nackdelar? Tja, inte många ärligt talat vad jag har hittat än så länge. Men det blir naturligtvis en aning begränsat då det är Ninite som ”paketerar” installationerna åt oss. Så hade man själv velat installera en applikation på ett annorlunda sätt, säg exempelvis installera applikationen i en icke standardkatalog, så går inte det. Vad gäller övrig anpassning för applikationen så går nog det mesta att lösa genom att i efterhand skicka ut en registerinställning eller konfigfil eller vad det nu kan vara. Men installationspaketet som kommer från Ninite är vad det är och det är bara att gilla läget.

Överhuvudtaget är det ett oerhört simpelt verktyg med ytterst få möjligheter till några avancerade inställningar eller anpassningar, men det är liksom hela poängen med Ninite. Keep it simple. Passar inte detta för era behov så ska ni använda något annat. Punkt. Men chansen är stor att det faktiskt passar alldeles utmärkt för säkert 95% av er där ute.

Sen ringde 90-talet och ville ha tillbaka designen på Ninites webbsida, och för övrigt det lilla grafiska gränssnitt som finns i verktyget också… Att säga att det ser amatörmässigt ut är en underdrift. Men det kan jag bortse från så länge det funkar och gör mitt liv lättare.

Rent generellt skulle jag säga att det här först och främst är ett utmärkt verktyg för små och mellanstora företag, som inte har anställda eller konsulter som bara sitter och paketerar på löpande band. Men egentligen kan nog även ganska stora företag ha nytta av detta.

Hur funkar det?

Så hur funkar då Ninite. Kort och gott stöder man en hyfsat lång lista på många av de vanligaste gratisapplikationerna. Ninite kan helt automatiskt ladda ned och installera var och en av dessa applikationer, och i priset prenumererar man även på alla uppdateringar. Så när en uppdatering kommer till applikationen så kan alltså Ninite automatiskt installera denna, utan att vi behöver göra någonting. Låter det bra? Här är en kort sammanfattning på funktionaliteten vi får:

  • Både ett grafiskt gränssnitt och kommandoverktyg.
  • Kan installera, uppdatera och avinstallera alla applikationer som stöds både lokalt på datorn och över nätverket på andra datorer. Kan även övervaka status på installerade applikationer. Ofantligt enkelt, bara att markera en eller flera datorer, markera en eller flera applikationer i listan och sen välja installation/uppdatering/avinstallation/övervaka och trycka på en knapp. Klart. Alternativt skriva ett motsvarande mycket enkelt kommando.
  • Väljer automatiskt samma språk, om det finns tillgängligt, som operativsystemet för varje applikation. Väljer även rätt plattform (x86 eller x64).
  • Kan stänga av automatiska uppdateringsfunktioner för många applikationer, såsom Java och Adobe Reader och liknande, så att användarna inte störs av sådana notifieringar.
  • Kan lagra alla nedladdade paket på en mapp på nätverket så att nedladdning endast behöver göras en gång för varje applikation. Alla installations görs sedan från den mappen.
  • Möjlighet att frysa en viss version av en applikation om man inte automatiskt vill ha den senaste.
  • Möjlighet att lägga till egna applikationer som inte redan stöds av Ninite. Du måste då själv ladda ned applikationen och skriva ditt egna installationsscript.
  • Lite annat smått och gott som möjlighet att ta bort genvägar till applikationer, stöd för proxy, loggning, osv.
Ninite GUI
D
et grafiska gränssnittet. Markera datorer och applikationer och tryck på en knapp. Kan inte bli enklare.
Låt oss titta på några scenarion hur vi skulle kunna använda detta i verkligheten.

I en Task Sequence

Så ni använder MDT och/eller SCCM för att installera datorer? Grattis, då gör ni rätt. Förmodligen lägger ni då också med ett antal vanliga applikationer i task sequencen, antingen den som bygger referensimagen eller den som installerar datorerna, eller både och.

Då Ninite bara består av en liten .exe-fil så är det enda du behöver göra att lägga in den i ett Package i SCCM, eller som en Application i MDT eller helt enkelt kopiera in filen direkt i t.ex. Scripts-katalogen i ditt Deploymentshare. Oavsett vilket alternativ du väljer så är det bara ett enda kommando som behöver köras och därmed bara ett enkelt steg som du behöver lägga till i din task sequence:

Niniteinstaller.exe /select Flash ”Flash (IE)” Java ”Java x64” ”Reader 11” /silent /cachepath \\MyServer\Ninite /disableautoupdate

Ovanstående exempel kommer ladda den senaste versionen av Flash Player (både ActiveX-komponenten för IE och plugin för övriga webbläsare), Java (32- och 64-bit) och Adobe Reader 11. Paketen kommer lagras på \\MyServer\Ninite, om inte senaste versionen redan finns där då görs ingen ny nedladdning, och sen installeras helt automatiskt från den sökvägen.

Applikationerna jag valde här var alltså bara ett exempel, vilka du vill ha väljer du själv och skriver in direkt efter ”/select” på kommandoraden. Varje gång det här kommandot körs kommer alltså den senaste versionen av dessa applikationer installeras. Du behöver inte göra någonting alls, ingen ny paketering, ingen uppdatering av några paket, ingen förändring i task sequencen. Ganska trevligt va?

I en Group Policy

Om ni inte kör SCCM eller liknande verktyg för att hantera applikationer så är Group Policies utmärkt för mindre och mellanstora företag. Här kan vi tänka oss två scenarion. Antingen finns applikationerna redan installerade på datorerna, genom att ni t.ex. kör MDT och installerar allt i task sequencen, enligt exemplet ovan. I så fall så vill vi bara hålla dem uppdaterade i framtiden. Eller så vill ni skicka ut en applikation som inte redan finns på datorerna. Eller en kombination av båda.

Hur vi gör det här med group policies är helt enkelt att vi skapar en GPO som innehåller ett Startup-script. Där i lägger vi Niniteinstaller.exe och en simpel liten bat-fil som innehåller kommandoraden och som körs av GPOn.

Om jag nu vill installera nya applikationer den här vägen så kan jag använda exakt samma kommandorad som i task sequence-exemplet ovan, och bara specificera de applikationer jag vill ha i kommandoraden. Här kanske vi dock också vill ha loggningsmöjligheter för att kunna se om installationerna lyckats som de ska. Lägg då till en sökväg efter /silent-flaggan så att kommandoraden ser ut t.ex. så här:

Niniteinstaller.exe /select Flash ”Flash (IE)” Java ”Java x64” ”Reader 11” /silent \\MyServer\NiniteLogs\%ComputerName%.log /cachepath \\MyServer\Ninite /disableautoupdate

Ska olika datorer ha olika applikationer? Bara VD’n och den snygga tjejen i receptionen som ska få Spotify? Inga problem, gör flera GPO’er och i varje script specificerar du just bara den eller de appar som hör till den GPOn, sen filtrerar du bara förslagsvis på AD-grupper.

Oavsett om du har installerat några applikationer med en GPO på det här sättet, eller om samtliga har installerats redan i imagen eller task sequencen, så vill du sannolikt skapa en egen GPO som bara ser till att uppdatera allting till senaste versionen. Då behöver du bara ange följande kommandorad i ditt startup-script:

Niniteinstaller.exe /updateonly /silent /cachepath \\MyServer\Ninite

Vóila! Varje gång datorn startas kommer nu automatiskt den senaste versionen av alla applikationer som Ninite hanterar att uppdateras till senaste version.

Då det alltid är den första datorn som kör GPOn som kommer ladda ned installationspaketet från Internet och lagra det på den nätverkssökväg du anger så måste du alltså se till att ”Domain Computers” har skrivrättigheter på denna mapp.

Tillsammans med SCCM

Så ni använder SCCM för all hantering av datorer och applikationer? Då är det bara att gratulera till ett bra beslut. Paketering av applikationerna blir man ju dock tyvärr ändå inte av med, men Ninite går utmärkt att köra tillsammans med SCCM. I SCCM kan vi som bekant antingen använda oss av gamla klassiska Packages and Programs, eller den nya Application-modellen.

Packages and Programs

Skapa ett Package som innehåller Ninites .exe-fil och lägg sen till så många Programs som du behöver. Du kommer vilja ha minst ett, nämligen det som håller dina datorer uppdaterade. Så skapa ett Program som heter exempelvis ”Update Core Applications” med följande kommandorad:

Niniteinstaller.exe /updateonly /silent /cachepath \\MyServer\Ninite

Gör sedan en Deployment av detta Package/Program till alla dina datorer och gör ett återkommande schema som körs förslagsvis en gång om dagen.

Lägg sedan till Programs för var och en av de applikationer som du vill köra. Så för till exempel Java, kör följande kommando:

Niniteinstaller.exe /select Java ”Java x64” /silent /cachepath \\MyServer\Ninite /disableautoupdate

Eller kanske ett Program som heter bara ”Core Applications” som innehåller alla dina standardapplikationer som samtliga datorer ska ha, och sen ytterligare Programs för övriga applikationer?

Dessa Programs är sen bara att skicka ut med Deployments precis som vanligt eller lägga med i din task sequence.

Applications

Ninite lämpar sig inte så jättebra för att köras som en Application, då vi faktiskt inte har ett installationspaket att arbeta med utan bara en .exe-fil som gör allt jobbet åt oss. Så t.ex. Detection Rules blir ett litet aber då versionen av applikationen vi installerar ständigt kommer förändras (det är ju liksom poängen).

Men vi kanske ändå vill ha en Application för vissa programvaror, för att t.ex. kunna publicera dem snyggt i vår Application Catalog, så då måste vi hantera detta.

Jag roade mig med att publicera Spotify, som är en underbar programvara men jobbig liten j*vel att paketera.
Jag använde följande inställningar:

Installation Program: Niniteinstaller.exe /select Spotify /silent /cachepath \\MyServer\Ninite
Uninstall program: Niniteinstaller.exe /select Spotify /uninstall /silent

Detection method: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Uninstall\Spotify\DisplayName

Installation behaviour: Install for User

Det hela tog bara någon minut vilket inte direkt är konsultvänligt men bra mycket roligare än att spendera ett par timmar på att skapa ett eget MSI-paket.

Spotify in Application Catalog
Spotify publicerad i Application Catalog

 

På det här viset kan alltså enkelt publicera en massa trevliga gratisprogramvaror till våra användare som de kan välja att installera från portalen. Och varje gång någon väljer att installera en applikation kan vi vara säkra på att det är den senaste versionen som installeras, utan att vi behöver lyfta ett finger. Och genom att kombinera detta med att köra ett återkommande paket dagligen med /updateonly-flaggan så blir också alla befintliga installationer hela tiden uppdaterade.

Slutsats

Jag gillar vad jag ser. Jag har tidigare testat gratisversionen av Ninite som är tillgänglig för privatpersoner, men har inte förrän nyligen när jag träffade en kund som körde Pro-versionen i sitt företag tänkt tanken på att använda det professionellt. Det är ingen tvekan om att det här kan spara ganska mycket tid och att man därmed får igen det löjligt låga inköpspriset många gånger om. Jag kommer fortsätta testa och utvärdera Ninite och förmodligen rekommendera det till en hel del av mina kunder.

 

Facebooktwitterredditpinterestlinkedinmail

Azure + Clavister = Sant

Att sätta upp site-to-site VPN mellan olika brandväggsfabrikat fungerar nuförtiden (annat var det för 10 år sen) oftast bra. De flesta följer numera de standarder som finns, men utmaningarna kan vara att terminologin mellan de olika leverantörerna kan skilja sig en hel del.

Den här veckan fick jag möjlighet att testa att koppla en Clavister-brandvägg till Azure och slutsatsen blev att det fungerar utmärkt. Har man inte en Juniper eller Cisco brandvägg, vilka är det enda fabrikat som Microsoft har färdiga konfigurationsscript för så får man bygga konfigurationen själv manuellt.

Det som jag först missade var att Microsoft använder lite olika konfiguration baserat på om man valt att skapa sin gateway i Azure med ”Dynamic routing” eller ”Static routing”. Om man väljer ”Dynamic routing”, vilket är ett krav för point-to-site vpn, så används version 2 av IKE-protokollet. Kruxet är att Clavister enbart stöder version 1 i dagsläget.

Efter att jag ändrat till ”static routing” så började det omedelbart fungera och tunneln etablerades som den skulle.

Dokumentation över konfiguration och protokoll osv. som Azure använder hittas här: http://msdn.microsoft.com/en-us/library/windowsazure/jj156075.aspx

Stöd för IKEv2 kommer i nästa uppdatering till Clavister, som är på gång och väntas inom en snar framtid.

 

Facebooktwitterredditpinterestlinkedinmail

Bugg i SCCM 2012 R2 – Use Toolkit Package misslyckas med 80072ee2

Förra veckan höll jag på med en ny SCCM 2012 R2 installation hos kund då jag stötte på ett skumt problem. Den task sequence jag hade skapat, baserad på MDT 2013, misslyckades med ett visst steg, nämligen ”Use Toolkit Package”. I det här steget laddas paketet som innehåller MDT scripten ned och det är något som görs flera gånger i task sequencen. Det roliga var att problemet uppstod alltid på samma ställe, nämligen direkt efter att Windows imagen applicerats. Men att köra samma steg tidigare i task sequencen, i Windows PE läget, fungerade varje gång.

Paketet innehåller ganska många små filer (vbs-script, xml-filer, osv) och när jag tittade i loggarna så var det alltid olika filer som misslyckades. Felet som loggades var 80072ee2, alltså ”The operation timed out”. Nätverksproblem alltså. I IIS-loggarna på servern såg allting bra ut, man kunde se att klienten försökte hämta filen men inget fel loggades.

För att göra det ännu roligare så körs ett antal steg i slutet av task sequencen som enbart körs om någonting misslyckats tidigare i sekvensen. Och då görs också en ”Use toolkit package”, och den fungerade minsann också varje gång.

Så alltså, att ladda ned exakt samma lilla paket med script lyckades 3 av 4 gånger i samma task sequence, men misslyckades alltid på samma ställe. För att göra det ytterligare lite värre så fungerade det dock faktiskt ibland, kanske en gång av tio.

Just att det var lite slumpmässigt gjorde det svårare att felsöka, då det flera gånger fungerade direkt efter att jag testat någon ny förändring och jag därmed trodde jag var en lösning på spåret. Men vid ett upprepat försök så misslyckades det genast, och då var det bara att testa något nytt.

Så det blev det ett antal försök med olika drivrutiner/datormodeller, jag skapade om paketet, gjorde om task sequencen, flyttade runt på nätverket, testade ny image (ett tag verkade det funka perfekt med en ”ren” Windows image direkt från media), osv osv. Det verkade fungera bra på en virtuell maskin som låg på samma host och samma nät som SCCM-servern, vilket fick mig att tro att det var ett nätverksproblem i kundens miljö (all trafik från klientnätet till servernätet passerade genom brandväggar), men sen uppstod samma problem även där.

Vid det laget var jag övertygad om att det rörde sig om en bugg, och det visade sig stämma. Microsoft känner till buggen och har lyckats återskapa problemet. Det finns ännu ingen lösning eller KB-artikel, men gissningsvis och förhoppningsvis kommer det en hotfix inom en snar framtid.

Tills vidare kan man köra följande workaround. Det finns ett par nya variabler i R2 som gör att task sequencen kan försöka igen när någonting misslyckas med att ladda ned. Så skapa följande två variabler högst upp i början av task sequencen:

SMSTSDownloadRetryCount = 5
SMSTSDownloadRetryDelay = 15

Med dessa två variabler så fungerar det perfekt.

 

Facebooktwitterredditpinterestlinkedinmail

CU4 för SCCM 2012 SP1 R2 och Update Rollup 1 för System Center 2012 R2

Nya uppdateringar har precis blivit tillgängliga.

Cumulative Update 4 for System Center 2012 Configuration Manager Service Pack 1 –
http://support.microsoft.com/kb/2922875

Update Rollup 1 for System Center 2012 R2 –
http://support.microsoft.com/kb/2904734/en-us

 

Facebooktwitterredditpinterestlinkedinmail

En titt på PowerShell Application Deployment Toolkit

Ganska ofta när man sysslar med ”application deployment” uppstår lite mer avancerade behov än vad applikationens installationsprogram klarar. Typiskt sett innebär det att man ofta vill göra något på datorn innan installationen startar och/eller efter att installationen är färdig. Några vanliga exempel kan vara:

  • Ställa om en terminal server till installationsläge
  • Skapa eller ta bort genvägar till applikationen (när man inte kan eller orkar redigera själva installationspaketet)
  • Avinstallera gamla versioner av applikationen
  • Stänga applikationer som är igång på datorn och som hindrar installationen
  • Utföra någonting på en server (i typiska client/server-applikationer) såsom att registrera klienten i någon databas eller några andra dumheter som utvecklarna har hittat på

Lösningen på detta är att man använder en s.k. ”wrapper”, det vill säga ett script som startar själva installationsprogrammet men också innehåller kod för att göra allt det andra.

Jag har under ett antal månader arbetat en hel del med verktyget PowerShell Application Deployment Toolkit som är skapat just för det här ändamålet och som dessutom är gratis och open source, och som namnet antyder helt baserat på PowerShell.

Verktyget finns att ladda ned från CodePlex här: http://psappdeploytoolkit.codeplex.com/

I början var det ganska buggigt, men nu fungerar det riktigt bra och har snabbt blivit ett av mina standardverktyg som jag använder just för alla lite mer avancerade applikationsbehov. Jag har själv försökt bidra en del till projektet med bl.a. diverse buggfixar, svensk översättning och betatestning.

Så låt oss ta en titt på vad man kan göra med detta trevliga verktyg.

Funktionalitet

GUI

Vi får ett GUI som vi kan välja att visa för användaren när en installation startar, körs och avslutas. Vi kan ge användaren möjlighet att skjuta upp installationen x antal gånger under en viss tidsperiod, eller så kan vi använda oss av en nedräkning innan installationen startar, osv. En mycket trevlig funktion här är att vi har stöd för flera språk, så all text visas automatiskt på det språk som är valt i Windows. Ett antal språk följer med från början, däribland svenska (skyll på mig om du inte gillar översättningen, det är nämligen jag som har gjort den :)) men vill du lägga till ett nytt språk eller ändra någonting i texterna så är det enkelt. Allting ligger nämligen i en xml-fil. Vidare kan vi även personifiera utseendet enkelt genom att lägga till en egen logga, det är bara att byta ut en bildfil.

PS-App-Deploy-Toolkit-GUI
Exempel på dialogruta som visas för användaren

 

Blockering och stängning av applikationer

Här har vi hela huvudanledningen till att jag personligen började använda detta toolkit. Vi kan alltså stänga ned applikationer som igång på datorn och som hindrar installationen. Det är framförallt här det är trevligt med ett GUI så att vi kan varna användaren att en viss applikation kommer att stängas, och om vi så vill ge denne möjlighet att skjuta upp installationen. Inte nog med det, vi kan blockera applikationen från att startas under tiden som installationen pågår, så att den klåfingriga användaren inte drar igång den direkt efter att den stängts ned och därmed pajar allting ändå. Det finns diverse smart logik här som gör att det hela fungerar bra, som t.ex. en städningsrutin om datorn skulle stängas av mitt under installationen så kommer blockeringen att tas bort automatiskt vid uppstart och inte blockeras igen förrän installationen startar nästa gång.

Stöd för SCCM

Eftersom man naturligtvis använder SCCM (vad annars?) för att hantera sina applikationer är det viktigt att verktyget fungerar bra tillsammans med SCCM. Även om det är egentligen inte är några större konstigheter då SCCM sällan bryr sig om så mycket annat än att den kan exekvera ett kommando, så är det ändå skönt att veta att PS App Deployment Toolkit utvecklades med just SCCM i åtanke. Man har t.ex. tänkt på att man ska kunna göra både installation och avinstallation med samma script så att vi enkelt kan utnyttja detta i Applications, och exit koder hanteras bra, som t.ex. Fast Retry (1618) och Reboot (3010). Vidare känner verktyget automatiskt av om installationen körs av en task sequence eller utan att någon användare är inloggad på datorn, och kommer isåfall inte visa något GUI. Mer om detta längre ned.

Övrigt

Det finns en lång rad små smarta funktioner du kan använda direkt i scriptet, och räcker inte dessa så är det bara att lägga till egna Powershell kommandon eller exekvera andra verktyg eller vad du nu vill göra. Några exempel på inbyggda funktioner:

  • Kontrollera diskutrymme som krävs för installationen och meddela användaren om det inte räcker till
  • Läsa innehåll i ini-filer
  • Söka efter installerade applikationer på datorn
  • Avinstallera applikationer på datorn baserat på namnmatchning (”Java” kommer t.ex. avinstallera alla applikationer som innehåller namnet Java)
  • Trigga SCCM tasks, som t.ex. att göra en hardware inventory efter installationen
  • Skapa/ta bort genvägar på t.ex. skrivbordet och/eller ”pinna” dessa på ”taskbar”
  • Skapa registernycklar
  • Uppdatera group policy

Och mycket annat.

Hur det funkar

När du laddar ned och packar upp PS App Deployment Toolkit får du en mapp som innehåller tre undermappar. I toppmappen ligger också följande två filer:

Deploy-Application.ps1 – Det här är scriptet som gör själva installationen av applikationen. Det är här du gör alla ändringar som är specifika för varje applikation. Scriptet innehåller fyra avsnitt: PRE-INSTALLATION, INSTALLATION, POST-INSTALLATION och UNINSTALLATION. Under respektive avsnitt anger man kommandon för att utföra installation och avinstallation samt vad som ska ske före och efter installationen. Vidare kan du skriva in lite information om själva applikationen som installeras, såsom namn och version osv. Viss del av denna information kommer att visas i det GUI som presenteras för användaren.

Deploy-Application.exe – Denna fil har som enda syfte att exekvera scriptet Deploy-Application.ps1, men utan att öppna ett Powershell konsolfönster. Det är den här filen du anger som installationskommando i dina SCCM-applikationer.

De tre katalogerna är följande:

AppDeployToolkit – Här ligger huvudfilerna i verktyget som används av Deploy-Application.ps1.

Files – I denna katalog lägger du installationsfilerna för applikationen som ska installeras. Mappen är tom från början.

SupportFiles – Här kan du lägga eventuella andra filer/script/verktyg som du vill använda under installationen. Mappen är tom från början.

Huvudfilerna som alltså ligger i katalogen AppDeployToolkit är följande:

AppDeployToolkitMain.ps1 – Huvudscriptet som innehåller all logik och alla funktioner som används under installationen. Detta script används av Deploy-Application.ps1-scriptet.

AppDeployToolkitConfig.xml – Här i ligger bl.a. alla texter som visas i det GUI som presenteras för användaren, med översättningar för de språk som följer med. Vill du ändra någon av texterna eller översätta till ett nytt språk så är det bara att redigera denna fil.

AppDeployToolkitExtensions.ps1 – All egen eventuell PowerShell-kod du vill skriva kan du lägga i det här scriptet och det kommer automatiskt att användas av Deploy-Application.ps1.

AppDeployToolkitHelp.ps1 – En hjälpfil som grafiskt visar och förklarar alla funktioner i verktyget.

AppDeployToolkitBanner.png – Detta är den bild som visas i ”bannern” högst upp i i rutan som visas för användaren. Den kan du alltså byta ut mot ditt eget företags logotype eller vad du vill.

AppDeployToolkitLogo.ico – Ikonfil som visas uppe i hörnet i användarens GUI. Även denna kan du byta ut om du vill.

Så processen för att installera en applikation med PS App Deployment Toolkit och SCCM är typiskt sett följande:

  1. Skapa en ny mapp för applikationen och kopiera dit alla filerna och mappstrukturen för verktyget. Kopiera in källfilerna för applikationen under mappen Files.
  2. Redigera Deploy-Application.ps1 och ange som minimum kommandot för att exekvera själva installationen (typiskt sett ett MSI-paket eller liknande) och eventuellt vad som ska ske före och efter installationen.
  3. Skapa en ny Application i SCCM med mappen du skapade ovan som källkatalog. Ange Deploy-Application.exe som installationskommando och Deploy-Application.exe Uninstall som avinstallationskommando.

När du laddar ned verktyget så medföljer en utmärkt guide som beskriver hur allting fungerar mycket mer i detalj.

PS-App-Deploy-Toolkit-Folders
Innehållet i verktyget

Session 0 problematiken

Som standard så döljer ju SCCM all form av GUI som visas av applikationsinstallationer. Men då en stor poäng med att man vill använda PS App Deployment Toolkit är just att kunna visa dialogrutor för användaren som varnar dem för att applikationer måste stängas osv, så måste vi se till att SCCM tillåter detta. Här finns en liten komplikation p.g.a. en fullständigt helidiotisk begränsning i SCCM. Det går nämligen utmärkt att göra detta med gamla klassiska Packages/Programs, men inte lika bra med nya modellen Applications (som vi ju såklart föredrar p.g.a. alla fördelar man får där).

Först lite kort teknisk bakgrund till hur det fungerar.
Från och med Vista och framåt så infördes en ny säkerhetsmodell i Windows, som innebär att systemtjänster (services) körs under en egen session kallad Session 0. När en användare loggar in tilldelas denna en högre session (session 1 och uppåt) och alla applikationer och processer som startas körs under användarens session. Just session 0 är dock alltså speciell från och med Vista då den är isolerad (kallas ”Session 0 isolation”) just för att skydda systemtjänsterna. En del av denna isolering innebär att ingenting som körs under session 0 kan presentera något som helst gränssnitt på skärmen.

SCCM-klienten består som bekant av en tjänst (”SMS Agent Host”) som körs av ”Local System” i Windows. SCCM kan antingen exekvera installationer under session 0, varpå inga dialogrutor eller någonting visas på skärmen, eller under den inloggade användarens session, då dialogrutor kan tillåtas att visas. Notera att detta inte påverkar några behörigheter, det är fortfarande ”Local System” som kör installationen oavsett vilken session den startar i, så länge vi inte aktivt väljer att köra med användarens konto istället.

För båda dessa inställningar, vilken session och vilken användare som ska köra installationen, kan vi alltså konfigurera för varje applikation vi distribuerar med SCCM. Med ett Package/Program gör vi detta under programmets egenskaper under fliken Environment. Om vi kryssar i rutan Allow users to interact with this program så kommer alltså installationen köras under användarens session, och dialogrutor tillåtas att visas.

Med en Application gör vi detta under vår Deployment Type i fliken User Experience. Här finns motsvarande kryssruta som heter nästan likadant: Allow users to view and interact with the program installation. Men nu kommer vi alltså till den korkade begränsningen. Microsoft är så fullkomligt insnöade på att Applications alltid ska installeras mot en användare att man har missat att ge oss möjligheten att aktivera den här inställningen om man samtidigt vill att installationen ska kunna köras oavsett om någon är inloggad på datorn eller inte. Alltså, om vi väljer alternativet Logon requirement: Whether or not a user is logged on så blir genast alternativet Allow users to view and interact with the program installation gråmarkerat och går inte längre att välja. Det här är naturligtvis fullständigt jubelidiotiskt i de fall när vi vill rikta installationen mot datorer, vilket fortfarande är det absolut vanligaste i de flesta företag, och framförallt för basapplikationer som t.ex. Flash player, Java osv.

Packages/programs har inte denna begränsning. Vi måste alltså välja mellan att använda denna äldre och sämre modell, och gå miste om alla underbara funktioner i Applications, eller försöka gå runt denna begränsning på något sätt. Vi kan göra på många olika sätt som att t.ex. använda oss av flera Deployment Types, eller bara rikta installationer mot användare, men inget av detta blir riktigt lika bra som om vi faktiskt skulle ha samma möjlighet som ett traditionellt Package.

SCCM-Program-Environment
Valmöjligheterna för ett ”Program”
SCCM-App-DT-UE
Samma alternativ för en Application, men med korkad begränsning

Lösningen

Det går faktiskt att rent programmatiskt bryta sig ut ur session 0 isoleringen och få fram ett GUI från en process som startats där. Vi försökte under en period lösa detta på olika sätt direkt i PS App Deployment Toolkit, och jag samarbetade tillsammans med utvecklarna för att försöka få med denna funktion. Ett tag såg det ut som om vi lyckades och under några versioner av verktyget fanns denna funktion med. Men sen upptäcktes det att det tyvärr inte fungerade helt bra i alla scenarion, så utvecklarna har tills vidare tagit bort den här möjligheten.

Lösningen är istället att använda ett till litet verktyg, en liten exe-fil från Microsoft som är skapad för exakt detta ändamål. Filen heter ServiceUI.exe, är ca 70 kb stor, och följer med Microsoft Deployment Toolkit. Så vi plockar helt enkelt denna lilla fil från MDT och lägger med den i installationskatalogen för varje applikation. Sen ändrar vi installationssträngen för applikationen i SCCM till ServiceUI.exe Deploy-Application.exe och vóila så fungerar det perfekt.

 

Facebooktwitterredditpinterestlinkedinmail

Vila i frid UAG

Som de flesta säkert vet så lade Microsoft ned TMG för inte så längesen. Trots löften om att systerprodukten UAG skulle fortsätta leva och utvecklas, har man nu tagit död även på den produkten: http://blogs.technet.com/b/server-cloud/archive/2013/12/17/important-changes-to-the-forefront-product-line.aspx

Två fantastiska produkter från Microsoft går i graven, och jag vet att jag inte är den enda som sörjer. Jag har jobbat med både TMG (och tidigare ISA) och UAG i många år och gillar dem båda skarpt.

För mig är det här helt obegripligt, och även för resten av världen tycks det. Microsoft har inte lyckats förklara hur man tänker, och tyvärr lämnar det här ett hål efter sig som bara kan fyllas med produkter från konkurrerande företag.

 

Facebooktwitterredditpinterestlinkedinmail

Uppdaterad version av ADK 8.1 är släppt

ADK 8.1 som släpptes skarpt bara här om dagen har precis uppdaterats. Lite tråkiga nyheter för alla oss som kastade oss över ADK 8.1 RTM som nu bör ladda ned och installera den på nytt.

Ladda ned ADK 8.1 gör du här: http://www.microsoft.com/en-us/download/details.aspx?id=39982
Och här kan du läsa lite mer om uppdateringen: http://blogs.technet.com/b/mniehaus/archive/2013/10/21/the-adk-for-windows-8-1-has-been-updated.aspx

 

Facebooktwitterredditpinterestlinkedinmail

MDT 2013 finns nu tillgängligt

För bara några minuter sen släpptes MDT 2013, den sista pusselbiten i vågen av uppdateringar av Windows och System Center det senaste dygnet.

Finns att hämta här: http://www.microsoft.com/en-us/download/details.aspx?id=40796

Happy deploying!

 

Facebooktwitterredditpinterestlinkedinmail

Guide: Uppgradera SCCM 2012 till SCCM 2012 R2

Uppdaterad 2013-12-17: Diverse nya erfarenheter och uppdateringar från Microsoft. Även lagt till MDT 2013 som bör uppgraderas samtidigt.

Nu när System Center R2 är släppt vill man förstås uppgradera så fort som möjligt. Att uppgradera SCCM är förhållandevis enkelt, men räkna ändå med att det tar några timmar. Här kommer en övergripande guide för hur det går till.

Installera Windows Assessment and Deployment Kit (Windows ADK) for Windows 8.1

Börja med att hämta och installera Windows Assessment and Deployment Kit (Windows ADK) for Windows 8.1 som finns här: http://www.microsoft.com/en-us/download/details.aspx?id=39982

OBS! Microsoft släppte en uppdaterad version av ADK kort efter, se till att du har rätt version. Läs mer här: http://www.infogeek.se/os-deployment/uppdaterad-version-av-adk-8-1-ar-slappt/

Den har precis blivit tillgänglig publikt, tidigare fanns den bara på MSDN/Technet. Då hade Microsoft gjort sitt bästa för att gömma den. Den låg nämligen inte som en separat nedladdning utan den hittades istället under ”Details” under Windows 8.1. Det var inte direkt någon nobelpristagare som kom på den idén om man säger så.

Se till att avinstallera den gamla versionen av ADK först. Kör sedan adksetup.exe och lägg som ett minimum till följande komponenter:

adksetup

Kontrollera din SQL version

Nu kan vara ett bra tillfälle att kontrollera att din SQL server kör en supportad version, med rätt service packs och uppdateringar osv. Den informationen hittar du här:
http://technet.microsoft.com/en-us/library/gg682077.aspx#BKMK_SupConfigSQLDBconfig

 

Installera SCCM 2012 R2

När ADK 8.1 väl är installerat är det dags att göra själva uppgraderingen av SCCM.

  1. Om du har en hiearki med siter så gör du uppgraderingen uppifrån och ned. Det vill säga, om du har en CAS så börjar du med den innan du fortsätter med underliggande primära siter.
  2. I det här läget kan det vara bra att kontrollera att du har en fungerande backup på din SCCM. Det är möjligtvis lite fegt men kan vara ack så skönt. Sätt sedan in ditt SCCM 2012 R2 media i site servern och starta splash.hta. Välj Install.
    SCCM 2012 R2 Setup
  3. Välj Upgrade this Configuration Manager site.
    SCCM 2012 R2 Setup
  4. Fortsätt installationen genom att gå igenom wizarden.
    1. Ange din licensnyckel och godkänn alla licensvillkor som du naturligtvis läst igenom noggrant.
    2. Ladda ned nya prerequisite filer i någon lämplig mapp.
    3. Välj de språk du vill ha på servern/konsolen samt på klienterna.
    4. Kontrollera eventuella varningar och problem i ”prerequisite checken” och slutför sen installationen. Det kommer ta några minuter.
  5. Upprepa proceduren på övriga eventuella siter. Servrar inom siten, såsom distributionspunkter och liknande, kommer automatiskt att uppgraderas.
  6. Uppgradera konsolen. Alla datorer som har konsolen installerad behöver få den uppgraderade versionen installerad, den gamla konsolen kommer inte längre att fungera. Detta gör du förslagsvis genom att lägga upp konsolen som en applikation i SCCM och skicka ut.
  7. Uppgradera alla klienter. Om du använder Automatic Client Upgrade, vilket jag rekommenderar, kommer detta ske automatiskt. Detta aktiverar du under Sites |Hierarchy Settings.Automatic Client Upgrade
Installera MDT 2013

Om du använder MDT tillsammans med SCCM, vilket du med all sannolikhet gör, så bör du nu passa på att uppgradera till MDT 2013.

  1. Börja med att avlägsna integrationen i SCCM konsolen på Site Servern genom att köra Configure ConfigMgr Integration från Start-menyn.
    Remove ConfigMgr Integration
  2. Avinstallera den gamla versionen av MDT, förmodligen kör du MDT 2012 idag.
  3. Installera MDT 2013.
  4. Lägg tillbaka MDT-tilläggen i SCCM konsolen genom att återigen köra Configure ConfigMgr Integration.
  5. Skapa ny boot image för WinPE 5.0, som är den senaste versionen som du nu kommer använda i och med att ADK har uppgraderats:
    1. Under Boot Images, klicka på Create Boot Image using MDT i verktygsfältet i konsolen.
    2. Följ wizarden och ange sökväg, namn, extra filer (som minimum vill du alltid ha med CMTrace.exe i din boot image).
    3. Lägg till alla drivrutiner du behöver i boot-imagen. Använder du t.ex. HP eller Dell så har de färdiga paket med just WinPE drivrutiner.
    4. Skicka ut till alla DP’s. Glöm inte att även kryssa i Deploy this boot image from the PXE-enabled distribution point under Data Source-fliken på imagen, så att PXE-boot fungerar.
  6. Skapa en ny Task Sequence. Detta är nödvändigt för att få med alla förändringar i task sequence-mallen som skett i MDT 2013, samt för att skapa nya versioner av vissa av de paket som används.
    1. Under Task Sequences, klicka på Create MDT Task Sequence i verktygsfältet i konsolen.
    2. Välj Client Task Sequence och gå igenom wizarden.
    3. Välj din nya boot image som du skapade ovan.
    4. Välj att skapa ett nytt MDT Toolkit Files Package.
      OBS!
       Om du gjort några förändringar i ditt gamla MDT Toolkit Files Package, t.ex. modifierat UDI wizarden, så måste du kopiera över dessa förändringar till ditt nya paket.
    5. Välj att skapa ett nytt USMT Package.
  7. Gå nu igenom din gamla Task Sequence och kopiera över alla steg och villkor och liknande som du själv har skapat till din nya Task Sequence. Kopiera alltså inte hela task sequencen rätt upp och ned, utan bara de förändringar som du själv lagt till, som t.ex. steg som installerar applikationer eller drivrutiner osv.
  8. Testa att deploya din nya Task Sequence till någon testmaskin och kontrollera att allting fungerar ordentligt. Är du riktigt noggrann ska du testa en gång på varje datormodell du har i produktion, för att se att alla drivrutiner fungerar ordentligt i nya boot imagen.
  9. När allt fungerar deployar du den nya Task Sequencen till alla collections där den gamla pekade, och tar sen bort alla deployments för den gamla. Arkivera den gamla under någon period. Upprepa ovanstående steg för alla Task Sequences du har.
Uppdateringar och buggfixar

Microsoft har kort efter att R2 kom släppt ett par uppdateringar med buggfixar. Följande finns tillgängliga:

  1. An update is available for the ”Operating System Deployment” feature of System Center 2012 R2 Configuration Manager – http://support.microsoft.com/kb/2905002/en-us
    Denna uppdatering löser framförallt prestandaproblem med OS deployment som uppstår efter att R2 har installerats. Jag har behövt installera denna uppdatering på flera ställen, och chansen är stor att du kommer behöva göra det också.
  2. Per-computer variables for imported computers are not read in System Center 2012 R2 Configuration Manager – http://support.microsoft.com/kb/2907591/en-us
    Om du inte använder variabler på datorobjekt så kan du strunta i den här uppdateringen. Jag har själv än så länge inte behövt installera den i någon skarp miljö.

Det finns också en känd bugg som innebär att ditt Network Access Account helt enkelt slutar att fungera. För detta finns för närvarande ingen lösning från Microsoft. Man får istället göra en workaround genom att helt enkelt ta bort sitt Network Access Account och sen skapa ett nytt konto och lägga till detta.

Nu ska allt vara klart. Viktigaste tipset är, som alltid, testa, testa och testa allting noga. Kontrollera status överallt och se att allting fungerar som det ska.

[notice]På första servern jag uppgraderade kraschade faktiskt installationsprogrammet precis i slutet, men uppgraderingen fungerade ändå. Kontrollera efteråt att allting gått bra genom att bl.a. undersöka loggen (tryck på View log i slutet av installationen, eller så hittar du den normalt på C:\ConfigMgrSetup.log) samt under Monitoring i konsolen. Kolla alla komponenter och servrar att det inte dykt upp några fel. Följ sen uppgraderingen av dina klienter och se till att alla får den nya versionen.[/notice]

 

Facebooktwitterredditpinterestlinkedinmail