Automatisk tilldelning av Office365 licenser med Powershell

När man kör Office365 men har ett eget on-premise Active Directory, så använder man Azure AD Sync (AADSync) för att automatiskt synkronisera kontoinformationen till Azure AD så att kontona kan användas i Office365. Vad som dock inte sker automatiskt med något av de verktyg vi får från Microsoft, är tilldelning av licenser till dessa konton. Detta måste man manuellt gå in i Office365-portalen och göra i efterhand.

Men nu är Azure och Office365 så fantastiskt att vi även kan hantera allting med Powershell. Vilket betyder att automatisering plötsligt blir både möjligt och enkelt.

Det vi behöver göra är följande:

  1. Förbereda konton och lösenord som ska användas till scriptet
  2. Skapa ett Powershell-script
  3. Skapa en schemalagd aktivitet som kör scriptet

Förbered konton och lösenord

Vi behöver två konton:

  • Ett admin-konto med tillräckliga behörigheter att ändra licensinformationen i Office365
  • Ett konto som ska köra den schemalagda aktivitet som vi använder för att schemalägga scriptet

Vi kan naturligtvis använda samma konto för båda dessa syften, det är valfritt. Eftersom vi redan använder AADSync så har vi redan ett konto där som vi lämpligtvis kan använda som admin-konto även för det här ändamålet. Men om detta konto t.ex. bara ligger i molnet och inte finns i vårt lokala AD, då blir det svårt att använda för vår schemalagda aktivitet, varpå vi behöver ett separat konto för detta.

Jag gillar att köra mina aktiviteter med datorns egna konto, alltså Local System, för att slippa ha ett dedikerat användarkonto, och kommer göra så i det här exemplet.

Nästa steg är att spara ned lösenordet för detta admin-konto på ett säkert sätt så att vi kan använda oss av det i scriptet. Här är nu det viktiga att se till att det konto vi använder för att köra den schemalagda aktiviteten kan läsa detta lösenord. Eftersom vi kommer spara lösenordet i krypterad form så kommer enbart detta utvalda konto att kunna läsa det.

Eftersom jag vill köra med kontot Local System måste jag därmed skapa det krypterade lösenordet med System-kontot. Ett enkelt sätt att göra detta är att ladda ned PsExec och sen köra:

psexec.exe -i -s powershell.exe

På så vis startar jag Powershell med System-kontot. Detta gör vi på den maskin där den schemalagda aktiviteten ska köras (lämpligtvis samma server som kör AADSync). Lösenordet kommer nämligen bara att kunna läsas av detta konto, på just denna dator, och ingen annanstans.

I Powershell kör vi nu följande:

I prompten skriver vi nu in lösenordet för det admin-konto vi kommer använda oss av i scriptet. Detta kommer sparas i krypterad form i filen C:\Scripts\DirSyncCreds.txt och bara vara läsbart för System-kontot på just den här datorn.

Skapa scriptet

För att tilldela en licens till en användare i Office365 behöver vi göra två saker:

  • Välja en licens och tilldela denna. Detta görs med cmdleten Set-MsolUserLicense 
  • Välja en location, dvs förmodligen Sverige för oss, som användaren tillhör. För detta används cmdleten Set-MsolUser

Så i grund och botten är det bara två enkla cmdlets vi behöver köra. För att göra en lite mer komplett lösning kan det vara en bra idé att lägga till lite logging och liknande i scriptet. Eftersom hela det här exemplet förmodligen är mest intressant för små och mellanstora organisationer, där man kanske inte har så mycket bra övervakningsverktyg, och där konton inte skapas så ofta, så har jag i mitt script-exempel lagt med att scriptet helt enkelt mailar någon administratör varje gång en licens tilldelats någon användare, eller om någonting har misslyckats. För att detta ska fungera måste det finnas en SMTP-server någonstans på nätverket som vi kan skicka mailet genom. Har du ingen sådan kan du enkelt lägga till en, då det finns en färdig sådan roll i Windows Server. Detta är dock utanför den här guiden.

Vi behöver också ett sätt att urskilja vilka användare som faktiskt ska få en licens, och det lättaste sättet här är att använda en vanlig AD-grupp. Har vi flera olika licenser som vi vill använda så skapar vi helt enkelt flera grupper. I det här script-exemplet utgår vi dock från bara en enda licens, men det är väldigt enkelt att lägga till fler om man så vill.

Scriptet ser ut så här:

Scriptet kräver följande för att fungera:

Spara ned scriptet och ändra variablerna högst upp i scriptet och fyll i korrekt admin-konto, sökväg till lösenordsfilen (som vi skapade tidigare), licens, AD-grupp, mailadresser, osv.

Kontrollera att allting fungerar genom att köra scriptet manuellt. Lägg till flaggan -Verbose så loggas hela förloppet i konsolen.

Skapa schemalagd aktivitet

När scriptet är testat och fungerar så är det bara att schemalägga det med en vanlig Windows schemalagd aktivitet. Hur ofta den ska köras är såklart valfritt, men AADSync körs t.ex. som standard var 3:e timme, så att matcha det schemat kan vara en ide.

Konfigurera följande i aktiviteten:

  • Kontot som köra aktiviteten (SYSTEM i det här exemplet)
  • Schema
  • Action:
    Program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
    Argument: -NoProfile -ExecutionPolicy Bypass -File C:\Scripts\Set-O365License.ps1

Ändra namn och sökväg till scriptet så att det matchar din miljö. Därefter kan vi luta oss tillbaka och se hur det trillar in ett litet mail i vår inkorg varje gång vi skapar en ny användare, som berättar att denne automatiskt fått sin O365-licens tilldelad.

 

Facebooktwitterredditpinterestlinkedinmail

Del 1 – Automatisera bygget av dina referensimages

Att bygga sin referensimage som man sedan rullar ut med sin OS deployment lösning är en återkommande uppgift för varje IT-avdelning. Microsoft släpper som bekant uppdateringar varje månad, varpå imagen helst bör byggas om varje månad så att den alltid är fullt uppdaterad. Det är naturligtvis fullt möjligt att släpa efter lite, och installera de uppdateringar som saknas vid själva installationstillfället av imagen istället. Men finns det någon anledning till att ha det så? Finns det något bra skäl till att inte uppdatera sin image varje månad?

De flesta gör nämligen inte det. Det sker istället ad-hoc när man har tid, eller i bästa fall har man en rutin där man gör detta en eller några gånger om året. Och man gör det manuellt. Eller rättare sagt, väldigt många har lyckats automatisera själva byggprocessen, men man startar igång den manuellt.

I den här guiden ska vi titta på hur vi väldigt snabbt och enkelt kan automatisera ett schema som spottar ur sig en rykande färsk image varje månad direkt efter Patch Tuesday.

Det här går naturligtvis att göra på många olika sätt och med många olika verktyg. Men vi börjar från början och gör det så enkelt som möjligt. Så i den här första delen kommer vi använda följande tekniker och verktyg:

  • MDT
  • Hyper-V
  • Powershell
  • Scheduled tasks

Förbered byggmiljön

För att bygga vår referensimage använder vi oss av MDT. Vi skapar alltså en task sequence som installerar Windows på en virtuell maskin, installerar alla uppdateringar och eventuella programvaror, gör eventuella anpassningar, och sparar sedan hela installationen i en imagefil någonstans på nätverket. I den här guiden kommer vi inte gå igenom exakt hur man gör allt detta. Vi utgår istället för att du redan har en sådan här task sequence på plats, och kommer istället fokusera på hur vi kör denna task sequence automatiserat och schemalagt.

Om du inte redan har ett deployment share färdigt i MDT för detta ändamål så är en bra plats att börja på här: https://technet.microsoft.com/en-us/library/dn744290.aspx

Det viktiga är att task sequencen och deployment sharet kör hela processen helt automatiskt, dvs utan att det krävs något manuellt meck, såsom frågor i Lite touch wizarden, eller pauser i task sequencen eller liknande. Har du några manuella anpassningar du gör i din image idag så är det första du måste göra att bygga script som fixar detta. Men normalt sett är det rekommenderat att försöka hålla imagen så ren och enkel som möjligt, och det ska vara enkelt att bygga den automatiskt.

Din CustomSettings.ini bör se ut ungefär så här:

Dessa inställningar resulterar i en helt automatisk installation som avslutas med att referensdatorn stängs ned.

Namnet på imagen kommer innehålla datumet då task sequencen kördes, vilket gör att vi får en enkel versionshantering.

Förbered den virtuella referensmaskinen

Vi använder oss här av Hyper-V som vi kan hantera helt och hållet via Powershell, och därför är underbart enkelt att automatisera. Hyper-V är gratis så du kan köra allt det här på din egen arbetsstation (om du har Windows 8 eller nyare), på någon överbliven dator, eller varför inte köpa in en liten NUC för ett par tusenlappar som får stå som dedikerad byggmaskin?

Så i Hyper-V, gör följande:

  1. Skapa en virtuell maskin. Ge den gärna 2 vCPU och 4 GB RAM (och helst inte mindre än 1 GB) om du har hårdvara som räcker. Skapa och lägg till en virtuell hårddisk med standardinställningarna, dvs en dynamisk expanderbar disk som är helt tom.
  2. När maskinen är skapad och medan den fortfarande är nedstängd, och hårddisken är helt tom, ta en snapshot som du kallar t.ex. ”Blank HD”. Den här snapshoten kommer vi använda för att återställa maskinen från början varje gång vi bygger en ny image.
  3. Om deployment sharet ligger på en annan dator än den dator som kör Hyper-V, så behöver du fixa så att du kan mounta ISO-filen över nätverket:
    1. Ge Hyper-V datorns datorkonto i domänen fulla behörigheter på Boot-katalogen i deploymentsharet.
    2. På Hyper-V datorns datorkonto i domänen, lägg till MDT-serverns datorkonto under fliken Delegation och välj tjänsten cifs.

Så kort och gott bör du nu ha en virtuell maskin, som heter t.ex. ImageFactory eller något liknande, men en snapshot och som ska kunna mounta boot-imagen från ditt deploymentshare. Testa manuellt att allt fungerar, att du kan boota maskinen från ISO-filen och att du kan backa tillbaka snapshoten.

Hantera den virtuella maskinen med Powershell

Spara scriptet nedan som Build-ReferenceImage.ps1 och lagra det i någon lämplig katalog på MDT-servern.

Vad scriptet gör är helt enkelt att återställa snapshoten på den virtuella maskinen, mounta en ISO-fil vilket i det här fallet ska vara boot-imagen från MDT, och sen startar igång den virtuella maskinen. Vidare raderar den alla sparade image-filer, baserat på hur många dagar tillbaka i tiden man vill ha historik, så att vi slipper ha image-filer som fyller upp disken i all oändlighet. Vill vi alltså bara ha de senaste två månadernas image-filer så raderar vi allting som är äldre än 62 dagar.

Allting styrs med parametrar till scriptet, såsom namn på virtuella maskinen, namn på snapshot, namn på Hyper-V datorn, sökvägar osv.

Exempel:

Testa att kör scriptet manuellt från MDT-servern och ange parametrar som stämmer överens med din miljö. Verifiera att den virtuella maskinen verkligen återställer sin snapshot, mountar ISO-filen och startar upp och bootar från ISOn ordentligt.

Schemalägg scriptet

När vi nu har alla byggstenar på plats så behöver vi bara schemalägga scriptet med en helt vanlig scheduled task, så att det körs en gång i månaden, direkt efter Patch Tuesday. Börja med att skapa ett lämpligt servicekonto som har behörighet att köra denna scheduled task på MDT servern, samt behörighet att på Hyper-V datorn att starta igång den virtuella maskinen. Kopiera sedan texten nedan och spara den som BuildReferenceImage.xml på MDT-servern.

Denna XML-fil innehåller hela den schemalagda aktiviteten. Ändra alla script-parametrar efter <Arguments> så att de passar i din miljö och kör sedan följande kommando för att skapa den schemalagda aktiviteten:

Ändra kontot och lösenordet och eventuellt namnet på den scheduled task som kommer att skapas.

Voilá det var det hela. Klockan 03:00 den andra onsdagen varje månad kommer nu automatiskt en ny referensimage att skapas och ligga och vänta på dig när du kommer in till jobbet på morgonen.

Slutsats

Som vi ser kan man med otroligt enkla medel göra så mycket som underlättar vår stressade IT-vardag. I det här exemplet har vi med bara tre ynka rader Powershell (ok 5 rader inklusive logiken för att ta bort gamla filer) samt en gammal hederlig scheduled task, automatiserat en uppgift som de flesta IT-avdelningar regelbundet utför, men som de flesta gör manuellt.

Vad är nästa steg, kan man utveckla det här och göra det ännu bättre? Självklart, och det är det som är så roligt med automatisering. Det är bara fantasin som sätter gränserna. Varför inte skicka ett mail till dig när bygget är klart som berättar om allting gick bra? Varför inte automatiskt lägga in den nya imagen i en task sequence i MDT och/eller SCCM? Kanske testa att deploya imagen med denna task sequence på en virtuell testmaskin, och sen skicka ett till mail och berätta om testet gick bra? Och så vidare och så vidare…

I nästa del ska vi titta på hur man gör detta med Service Management Automation istället.

 

Facebooktwitterredditpinterestlinkedinmail

SCCM 2012 R2 CU4 finns nu tillgänglig

Igår släpptes Cumulative Update 4 till SCCM 2012 R2.

Läs mer och hämta hem uppdateringen här: http://support.microsoft.com/kb/3026739/en-us

Läs mer om alla förändringar och buggfixar för PowerShell här: http://support.microsoft.com/kb/3031717/en-us

Uppdateringen innehåller en lång rad buggfixar och inga direkta nyheter i funktionalitet. KB3007095 ingår i paketet, vilket är bra då detta är en mycket bra buggfix för de eviga problemen som varit med att installera Applications i en Task Sequence. Vi får också stöd för lite nyare versioner av OSX och Linux, men i övrigt är det inte så jättemycket intressant som ingår, för de flesta av mina kundmiljöer i alla fall.

Vad gäller Powershell är det lite mer intressant. Förutom en lång rad buggfixar i olika cmdlets, där bl.a. min rapporterade bugg nu har fixats (alltid glädjande när Microsoft lyssnar på ens feedback), så har vi även fått hela 35 nya cmdlets.

 

Facebooktwitterredditpinterestlinkedinmail

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:

JavaFolders

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

 

Facebooktwitterredditpinterestlinkedinmail

SCCM 2012 Import Computer Tool

När man kör Zero Touch OS deployment i SCCM måste man som bekant först importera in datorinformationen till SCCM, i form av ett datornamn och en MAC adress eller GUID. Alternativet är att använda ”Unknown Computer support” varpå man inte behöver importera något, men istället behöver skapa någon form av lösning för att t.ex. namnge datorn.

Som alltid går den här import-processen att effektivisera med lite scriptande, framför allt om man samtidigt vill göra lite fler inställningar för datorn. Vanliga saker man ofta vill göra är t.ex. att på något sätt bestämma vilken OU datorn ska hamna i, osv.

Jag har skapat verktyget SCCM 2012 Import Computer Tool, som är ett enkelt, grafiskt verktyg byggt helt och hållet i Powershell. Jag har inspirerats av, och ger cred till, https://gallery.technet.microsoft.com/Import-Computers-via-a-df450468 som är ett liknande verktyg, samt http://itmicah.wordpress.com/2013/10/29/active-directory-ou-picker-in-powershell/ som hjälpte mig göra en snygg lösning med att lista OUs grafiskt.

Verktyget klarar av att göra följande:

  • Importera en ny dator till SCCM
  • Lägga till datorn till en collection (valfritt)
  • Välja en OU där datorn ska hamna när den läggs med i domänen (valfritt)
  • Associera datorn med en ”source computer” som används i ett ”Replace computer”-scenario (valfritt)
  • Lägga till en ”primary user” till datorn (valfritt)

Allt detta gör man i GUIt, men vissa inställningar styrs också med script-parametrar som måste anges. Till exempel måste site code, site server och liknande anges. Det går också att styra om man t.ex. bara vill se en del av Active Directory i GUI, vilken default collection som ska visas, och vilken mapp i SCCM som innehåller OSD collectioner (dessa kommer då automatiskt enumreras och visas i comboboxen i GUIt).

Scriptet kräver att följande är installerat på datorn där det körs:

  • System Center 2012 R2 Configuration Manager Console
  • Active Directory Users and Computers
  • PowerShell v3.0 eller högre (OBS enbart testat och verifierat på v4.0, men borde funka på v3.0 också)
  • .Net Framework

I övrigt så är allting förhoppningsvis ganska självförklarande. Exempel och liknande finns i hjälptexten i scriptet.

Som vanligt tar jag jättegärna emot feedback om ni upptäcker några buggar, eller har önskemål om ny funktionalitet.

Happy deploying!

SCCM 2012 Import Computer Tool

Nedladdning

Jag har lagt upp scriptet på Technet Gallery här.

 

Facebooktwitterredditpinterestlinkedinmail

SCCM 2012 Application Creator

Automatisering, och då gärna med PowerShell, är inte bara vansinnigt roligt utan också såklart nyttigt. För hur mycket är det inte värt att kunna spara hundratals eller kanske tusentals timmar per år med lite smarta verktyg och lösningar?

Eftersom jag spenderar den mesta av min tid med SCCM så är det där jag oftast bygger automatisering. Ett exempel på en återkommande uppgift i SCCM är det här med att skapa och deploya applikationer. Det går att effektivisera oerhört mycket. För det ändamålet finns redan diverse script och verktyg som gör jobbet enklare. Till exempel finns det ett ganska känt verktyg, skrivet i C#, som kan hjälpa till med att skapa både applikationer, collectioner, osv. Men jag ville ha lite mer flexibilitet, och så vill jag ha allt i PowerShell så att det är enkelt för vanliga SCCM administratörer att göra små modifieringar efter sina behov.

Därför skapade jag SCCM 2012 Application Creator. Det är helt och hållet skrivet i PowerShell och har ett enkelt GUI där man som administratör fyller i nödvändiga parametrar för applikationen.

Det är gjort för att vara enkelt att använda, men samtidigt flexibelt. Det mesta kan man ändra direkt i GUIt, men andra saker som man kanske inte ändrar så ofta i sin miljö, styrs med scriptparametrar. Allt som scriptet gör i SCCM och även i AD, utförs med standard-cmdlets, så att det ska vara enkelt att begripa och modifiera för en administratör.

Scriptet kan göra följande:

  • Skapa en applikation i SCCM
  • Skapa en MSI deployment type
  • Distribuera applikationen till en distribution point group
  • Skapa en grupp i Active Directory
  • Skapa en collection baserad på AD gruppen
  • Deploya applikationen till collectionen

Eftersom jag väldigt ofta använder PowerShell App Deployment Toolkit (som jag tidigare skrivit om här) när jag deployar applikationer, så har jag lagt med stöd för detta i scriptet. Genom att klicka på knappen ”Use PADT” så ändras installation program, uninstallation program och sökvägen, dessutom sätts flaggan ”Run installation and uninstall program as 32-bit process on 64-bit clients”.

Scriptet kräver att följande är installerat på datorn där det körs:

  • System Center 2012 R2 Configuration Manager Console
  • Active Directory Users and Computers
  • PowerShell v3.0 eller högre (OBS enbart testat och verifierat på v4.0, men borde funka på v3.0 också)
  • .Net Framework

I övrigt så är allting förhoppningsvis ganska självförklarande. Exempel och liknande finns i hjälptexten i scriptet.

Om ni använder det här scriptet, så får ni jättegärna ge feedback till mig och berätta om ni hittar några buggar, eller om ni vill lägga till någon funktionalitet, osv.

Happy deploying!

SCCMApplicationCreator

Nedladdning

Jag har lagt upp scriptet på Technet Gallery här.

 

Facebooktwitterredditpinterestlinkedinmail

Ny hotfix för Applications i en task sequence i SCCM 2012 R2 CU3

En ny hotfix släpptes igår, den 10 december 2014, som förhoppningsvis löser lite av de problem som finns med att installera en Application i en OSD task sequence.

Ladda ned hotfixen här:

http://support2.microsoft.com/kb/3007095/en-us

 

Facebooktwitterredditpinterestlinkedinmail

SCCM 2012 R2 CU3 för Linux/Unix klienter finns tillgänglig

Läs mer och hämta uppdateringen här:

https://support.microsoft.com/kb/2998616

 

Facebooktwitterredditpinterestlinkedinmail

Guide: Hur man återanvänder task sequences i SCCM 2012 med PowerShell

När man som jag sätter upp nya SCCM-installationer på löpande band, både ute i verkligheten och i labb/test/demo-miljöer, så blir det snabbt väldigt tradigt att sitta och klicka runt i konsolen för att göra samma saker om och om igen. Tänk om det bara fanns något bra sätt att automatisera saker och ting…

PowerShell to the rescue!
Det mesta, men långt ifrån allt, som kan konfigureras i SCCM går att göra med färdiga cmdlets. En av de lite knepigare sakerna är att skapa task sequences. De färdiga möjligheter vi har innefattar cmdleten New-CMTaskSequence, men den räcker inte för mina och förmodligen de flestas behov. Jag vill normalt integrera MDT med SCCM och använda en MDT-baserad task sequence. Sen finns det ett antal saker som jag alltid gör i mina task sequences, såsom att lägga till diverse variabler, ändra eller ta bort vissa av de inbyggda stegen samt lägga till egna. Vidare finns det saker som jag alltid vill lägga till eller ändra i de standardpaket som används av task sequencen, såsom boot imagen och MDT Settings- och Toolkit-paketen.

Det jag vill uppnå är alltså möjligheten att skapa en bra mall med en task sequence och alla tillhörande paket, som jag enkelt kan återanvända i nya SCCM-miljöer. Använder man bara MDT som fristående verktyg är ju detta väldigt tacksamt eftersom allting man gör bara sparas i en mapp som man kan kopiera om och om igen. Men SCCM är trixigare eftersom task sequencen bl.a. innehåller referenser till paket ID’n i databasen.

Vi kan använda oss av de inbyggda cmdleterna Export-CMTaskSequence och Import-CMTaskSequence (går också att göra i konsolen), men dessa är inte tillräckligt bra och flexibla i min mening. De har haft, och har fortfarande en del buggar, och exporten blir i form av en zip-fil som blir omständig att redigera och uppdatera på ett automatiserat sätt innan en import.

Så istället ska vi titta på hur vi kan göra detta själva med lite knåpande i PowerShell.

Det vi gör i den här guiden är följande:

  1. Skapa en bra task sequence som vi vill använda som mall och exportera denna. Exportfilen generaliseras sedan så att den går att använda för framtida importer i nya miljöer.
  2. Importera in de till task sequencen tillhörande paketen till den nya SCCM-miljön.
  3. Uppdatera export-filen som innehåller task sequencen som ska importeras med korrekta paket ID’n som matchar den nya SCCM-miljön, och importera denna.

I det här exmplet kommer jag använda en helt vanlig MDT-baserad task sequence som innehåller följande paket:

  • Boot image
  • Windows image
  • SCCM klient
  • MDT Toolkit paket
  • MDT Settings paket
  • USMT paketet kommer jag i det här exemplet använda det som är färdigskapat i SCCM

Scripten nedan är alltså ett enkelt exempel, så vill man t.ex. ha fler paket än så här får man lägga till dem i scripten.

Exportera task sequencen

Vi börjar med att manuellt skapa en task sequence i SCCM baserad på MDT (MDT integrationen måste alltså vara gjord) genom att stega igenom wizarden. Vi skapar de paket som behövs, såsom boot imagen och MDT-paketen. Jag har i det här exemplet också skapat ett eget paket för SCCM klienten där jag har lagt med senaste cumulative update. Vi modifierar task sequencen och de tillhörande paketen och lägger till och ändrar allt som vi tycker är bra. När vi känner oss nöjda och har en bra mall som vi vill återanvända så exporterar vi den med följande script:

Vi använder oss här alltså inte av Export-CMTaskSequence. Istället hämtar vi värdet från attributet Sequence från Get-CMTaskSequence, vilket innehåller just hela task sequencen i xml-format.

Uppdatera variablerna i början så att site code, namn på task sequencen, namn och sökväg till exportfilen samt namnen på paketen i task sequencen matchar din miljö.

Efter att scriptet körts har vi fått en xml-fil som innehåller hela task sequencen. Alla paket ID’n har bytts ut mot unika påhittade strängar, som vi enkelt kan hitta och byta ut igen när task sequencen ska importeras till en ny miljö. Den här filen sparar vi tillsammans med alla paket som används i task sequencen, så att vi har en liten mapp som innehåller allt som vi vill återanvända.

Importera paketen

I vår nya miljö där vi vill återanvända vår task sequence med tillhörande paket så börjar vi med att importera in paketen med följande script:

Ändra site code, namn på distributionspunktsgrupp samt namn och sökvägar till paketen så att de matchar din miljö.

Scriptet kommer skapa Windows image, boot image samt de övriga paketen som Packages. Boot imagen kommer konfigureras med flaggan för att det ska disttribueras från PXE, samt aktivera stöd för kommandoprompt med F8.

Till sist kommer samtliga paket att distribueras till den distributionspunktsgrupp som vi angett (jag skapar ALLTID en grupp även om det bara finns en enda DP).

Importera task sequencen

När nu alla paket finns på plats kan vi importera in vår sparade task sequence med följande script:

Ändra site code, namn på exportfilen och den task sequence som ska skapas, samt namnen på paketen i task sequencen så att de matchar din miljö.

Scriptet kommer göra en kopia av exportfilen, så att vi inte förstör orginalet, och uppdatera denna med de riktiga paket ID’n som vi nu har i vår nya miljö. Därefter kommer en ny task sequence att skapas, med det namn som vi har valt, baserad på denna exportfil. Till sist kommer vår boot-image att associeras med task sequencen.

Vóila! Nu har vi en fullt fungerande task sequence, med korrekta paket-referenser, som är redo att börja användas direkt. Inte ett enda klick har vi behövt göra i konsolen.

Ladda ned scripten här

 

Facebooktwitterredditpinterestlinkedinmail

PowerShell cmdleten Set-CMClientPushInstallation i SCCM 2012 förstör andra cmdlets

Uppdatering 2014-12-05: Microsoft har nu återkommit med svar på min rapportering om denna bugg, och meddelar att man har löst problemet och att det kommer en hotfix som löser detta. Exakt när fixen kommer är dock okänt än så länge.

Uppdatering 2015-02-03: Uppdatering för denna hotfix ingår nu i CU4 som släpptes igår. Läs mer här.

Powershell cmdleten Set-CMClientPushInstallation, som används för att konfigurera Client Push, förstör vissa andra cmdlets. De cmdlets jag har upptäckt drabbas är Add-CMFallbackStatusPoint och Set-CMDiscoveryMethod, men det kan finnas fler.

Felet uppstår när man gör följande:

  1. Kör kommandot: Set-CMClientPushInstallation -SiteCode <sitecode> -ChosenAccount ”domain\account”
  2. Kör sen kommandot: Add-CMFallbackStatusPoint -SiteCode <sitecode> -SiteSystemServerName server.domain.local -StateMessageNum 10000 -ThrottleInterval 3600
  3. Kommandot kommer returnera felet: ”Object reference not set to an instance of an object.”
  4. Startar man nu om PowerShell konsolen och kör Add-CMFallbackStatusPoint igen så fungerar det utan problem.

Problemet finns i R2 och även i senaste uppdatering som i dagsläget är CU3. Jag har inte testat tidigare versioner än så.

Jag har rapporterat buggen till Microsoft och kommer uppdatera denna bloggpost om det kommer någon lösning.

 

Facebooktwitterredditpinterestlinkedinmail