okt 08

Verifiera sökvägar till drivrutiner i SCCM 2012 med PowerShell

Att importera in drivrutiner i SCCM 2012 och använda dessa vid OS deployment går till ungefär så här:

  1. Drivrutinerna för den aktuella datormodellen laddas ned och placeras i en katalog.
  2. I konsolen väljer man ”Import Drivers” och pekar ut UNC-sökvägen till denna katalog.
  3. Drivrutinerna kategoriseras vid importen, normalt med en kategori för operativsystemet och en kategori för datormodellen.
  4. Vi väljer ett drivrutinspaket att spara drivrutinerna i. Normalt ett paket per operativsystem och datormodell. Dessa paket anvnänder vi sedan i våra task sequences.
  5. När en ny datormodell tillkommer så följs samma process igen. Ny kategori och nytt drivrutinspaket skapas.

I databasen sparas informationen om drivrutinen, såsom namn, versionsnummer m.m. och även sökvägen till mappen som vi angav vid importen. När drivrutinspaketet skapas används denna sökväg för att kopiera drivrutinsfilerna till paketets egna källkatalog, som är en helt annan mapp. Därefter kan paketet distribueras till en distributionspunkt och börja användas i en Task Sequence.

Så långt allt väl. Men vad händer om katalogen dit den sparade sökvägen i databasen pekar försvinner?

Befintliga drivrutinspaket som innehåller drivrutinen kommer fortsätta fungera utan problem. Drivrutinspaketen har ju alltså en egen sökväg dit drivrutinsfilerna kopierades vid importen.

Så varför behöver vi bry oss?

Problemet uppstår i två specifika scenarion:

  1. Vid en framtida migrering
  2. När vi lägger till samma drivrutin igen

När man migrerar SCCM 2007 till 2012 kommer sökvägen som står i databasen att användas för att migrera över drivrutinsfilerna till nya servern. Sannolikt kommer detta också att behövas vid migrering till framtida versioner.

Men det andra scenariot då? Varför skulle man vilja lägga till samma drivrutin igen?

Många datormodeller innehåller ju samma hårdvara, såsom likadana grafikkort eller ljudkort osv. Så när vi börjar lägga till drivrutiner för en ny datormodell är chansen stor att någon av dessa drivrutiner redan finns importerade i SCCM sedan tidigare, för någon annan modell. Vad händer i det läget? Kommer drivrutinen importeras igen och ligga på två platser i databasen?

Svaret är nej. SCCM kommer känna av att drivrutinen redan finns och därmed inte importera den igen (men vi kommer inte att få något felmeddelande, så som det var på gamla SCCM 2007 tiden). Den befintliga drivrutinen kommer istället att uppdateras med de kategorier vi valde under importen. Så vi kan nu se att vissa drivrutiner är taggade med flera kategorier, för flera olika datormodeller. Därav att det är väldigt viktigt att använda sig av kategorier, för att det inte ska bli omöjligt att veta vilka drivrutiner som hör till vilken datormodell.

Men vad som inte uppdateras är sökvägen till drivrutinen. Så trots att vi anger en sökväg där vi har våra drivrutiner som vi vill importera, så kommer alla befintliga dubblett-drivrutiner att använda den befintliga sökvägen. Så när vi kör importen och försöker skapa ett nytt drivrutinspaket kommer alltså alla drivrutiner som redan fanns i databasen att kopieras från den sökväg som är sparad för dem, och alla nya drivrutiner kommer kopieras från den nya sökvägen.

Börjar ni se problemet? Vi får alltså problem i framtiden när vi försöker importera in drivrutiner till nya datormodeller om vissa av dessa drivrutiner redan finns i SCCM sedan gammalt, och dessa drivrutiners orginalsökvägar inte finns kvar av någon anledning.

Felet vi får i import-wizarden är i vanlig ordning inte helt självförklarande:

DriverImportFail

Genom att titta i SMSProv.log så ser vi lite tydligare vad som är felet, men inte exakt vilken sökväg som är felaktig. Har vi valt en mapp med en väldig massa drivrutiner i kan det vara svårt att se exakt vilken eller vilka som misslyckades.

Slutsats: Det är kort och gott ganska viktigt och intressant att veta att de drivrutiner som ligger i databasen är korrekta och fortfarande giltiga. Det vore alltså ganska trevligt att kunna verifiera detta på något sätt, och hitta eventuella sökvägar som inte längre funkar.

PowerShell to the rescue! Följande rader kommer stega igenom alla sökvägar i databasen och tala om vilka som eventuellt inte går att nå:

Räkna med att scriptet kan ta en stund att köra om du har många drivrutiner i databasen.

 

Facebooktwitterredditpinterestlinkedinmail

okt 01

Windows 7 uppdateringar tillsammans med språkpaket resulterar i svart skärm

Uppdatering 2014-12-05: Det tog många veckors harvande fram och tillbaka med Microsoft innan de till slut lyckades förstå och återskapa problemet (skulle jag återberätta alla turer om hur Microsofts tekniker inte kan följa en busenkel steg-för-steg instruktion, inte kan använda verktyg som MDT, inte vet vad ett språkpaket är eller hur det installeras, inte vet var de laddar ned sina egna programvaror osv, så skulle det bli en hel bloggpost i sig…). Men nu är alltså problemet bekräftat av Microsoft och eskalerat till ansvarigt produktteam, så förhoppningsvis dyker det inte upp i framtida patchar.

Jag har den senaste tiden spenderat en hel del tid hos en kund med att felsöka ett mycket irriterande problem. För ett par år sedan byggde jag åt denna kund en mycket komplex och avancerad deployment lösning baserad på MDT. Den är komplex för att kunden har många väldigt specifika krav och behöver kunna hantera en lång rad olika typer av scenarion. Under åren som gått har jag regelbundet uppdaterat, vidareutvecklat och byggt vidare på denna lösning, för att hantera nya funktioner och krav. Allting följer mycket noggranna processer med versionshantering, förändringshantering, dokumentation och testning innan någonting får släppas till produktion. En återkommande del i detta underhållsarbete är att uppdatera Windows imagen, så att den innehåller de senaste uppdateringarna från Microsoft.

Så långt allt väl, och allting har fungerat utmärkt. Fram till i somras då det åter igen var dags för mig att släppa en ny deployment version, som innehöll diverse nya programvaror, diverse ny konfiguration samt en ny uppdaterad Windows image. Först såg allting ut att gå bra. Men kundens testavdelning är extremt noggrann och professionell, och efter en hel del testning upptäckte en testare att en nyinstallerad dator, med den nya imagen, inte gick att starta. Installationen hade slutförts, datorn befann sig inne i Windows, testaren gick på lunch, kom tillbaka och startade om datorn. I det läget kunde inte längre Windows starta, utan allt som visades var en svart skärm och en muspekare. Ingen blåskärms-krasch eller liknande alltså, bara denna svarta skärm och ingenting mer.

Andra datorer som installerades visade inte upp samma problem, och först tänkte man inte så mycket mer på detta. Tiden gick, det blev semestrar osv. I produktion körde man vidare på den äldre imagen, och där var allt frid och fröjd. Men efter sommaren fortsatte testerna med den nya imagen (samt alla andra nyheter såsom nya programvaror och konfiguration, osv). Och nu började man se ”svartskärms-buggen” oftare.

Just för att det är en såpass komplex deployment lösning, bl.a. så använder man ca 15 olika språk, samt en uppsjö olika konfigurationer som man kan välja för en dator, så tog det tid att ringa in problemet. Ibland verkade det hända och ibland inte.

Efter tag stod det dock klart att problemet uppstod och kunde återskapas om följande var sant:

  • Ett språk annat än US English (detta är det språk som imagen är byggd på) valdes. Samma problem med alla övriga 14 språk.
  • Strömkabeln sitter i.
  • Låt datorn stå påslagen en timme efter installation, starta om den. Voilá, en svart skärm.

Just att strömkabeln måste vara i kändes mycket märkligt, och ledde först misstankarna till strömsparfunktionerna i Windows. Vi har nämligen byggt helt egna energisparscheman som installeras under deployment. Men att testa att återställa dessa till Windows default hjälpte inte.

Så varför uppstår problemet bara när datorn varit påslagen en viss tid, och varför bara med strömkabel i, och aldrig på batteri? Och varför bara när ett språkpaket är installerat?

I det här scenariot används Windows 7, men inte Enterprise som tillsammans med Ultimate är de enda editions som kan ha flera språk installerade samtidigt. Det går dock, tvärtemot vad många tror, alldeles utmärkt att byta språk även i andra editions av Windows 7. Det bör helst göras i offline läge innan Windows setup-program körs, men går faktiskt att göra ”online” också, efter att Windows har installerats. Så följaktligen, kör man MDT använder man sig av steget ”Install updates offline” för att applicera ett språkpaket i Windows PE läget, så kommer setup-programmet sen gladeligen att installera detta språk.

Men vad som sen händer, som är lite mer hemligt, är att Windows kommer skapa en schemalagd aktivitet som körs en gång exakt 25 minuter efter att Windows startat första gången. Denna aktivitet kör filen %Windir%\System32\Lpremove.exe. Detta lilla jobb har som uppgift att rensa ut de sista resterna av orginalspråket som låg i imagen, om detta är något annat språk än det aktuella språkpaketet som är installerat.

Det vi upptäckte efter en hel del felsökande var att det var just detta lilla schemalagda jobb, som är konfigurerat att köras endast på AC power, som var boven. Så fort vi körde det jobbet (eller bara manuellt startade Lpremove.exe) och sen startade om datorn, så hamnade vi i svart-skärms-träsket.

Ok, så nu visste vi i alla fall vad det var som utlöste problemet, men varför det kunde ske kvarstod att utreda. Vi kunde snabbt konstatera att den deployment-version som användes i produktion inte hade problemet. Alltså låg problemet i någon av de förändringar som jag hade gjort i senaste uppdateringen, vilket alltså bl.a. innefattade en uppdaterad Windows image.

I det här läget vill man ju gärna börja misstänka drivrutiner eller någon 3:e-partsprogramvara. Men efter en hel del testande kunde jag konstatera att problemet uppstår på vilken hårdvara som helst, och även i virtuella maskiner, utan att några som helst drivrutiner installeras, eller några programvaror eller någon konfiguration eller någonting. Alltså bara en ”ren” installation av Windows och ett språkpaket.

Slutsatsen blev alltså att det måste vara en uppdatering i imagen som var den skyldige. Jag testade med den äldre image som användes i produktion, och även med en image helt utan uppdateringar, och då försvann genast problemet. Så därmed började det mödosamma arbetet med att hitta exakt vilken eller vilka uppdateringar som var problemet.

Efter mycket tidskrävande sökande har jag till slut funnit att det är inte mindre än FYRA olika uppdateringar, som var och en orsakar detta problem. Dessa är:

Alla dessa uppdateringar, varav tre är Security Updates, är släppta mellan maj och september i år. Är detta ännu ett tecken på att kvaliteten på Microsofts uppdateringar har nått nya bottennivåer (ni minns säkert uppdateringarna i somras som drogs tillbaka)? Har man helt gett upp all form av test- och kvalitetsarbete på Microsoft?

Så lösningen nu är att exkludera dessa fyra uppdateringar från imagen och sen köra Lpremove.exe som ett steg under deployment. Därefter kan dessa uppdateringar installeras utan att det blir något problem.

Känns stabilt? Inte särskilt. Om fyra uppdateringar i rad under fem månader har orsakat detta problem, vad händer då nästa månad? Vi har i alla fall meddelat Microsoft om detta och har ett öppet ärende, så får vi se vad som händer. Jag kommer posta eventuella uppdateringar i ärdendet här.

PS. För övrigt anser jag att det faktum att man nu måste installera över 200 uppdateringar efter Windows 7 SP1 är rena skämtet, och Microsofts vägran att släppa en ny service pack är förkastligt. Jag förstår att man inte vill förlänga supporttiden, men släpp då allting som en stor ”cumulative update rollup” i så fall.

 

Facebooktwitterredditpinterestlinkedinmail

sep 23

SCCM 2012 R2 CU3 finns nu tillgänglig

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

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

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

 

Facebooktwitterredditpinterestlinkedinmail

sep 10

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.

SUP-SMSProv

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:

PS-SMS_UpdateCategoryInstance

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:

PS-SMS_UpdateCategoryInstance2

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:

SUP-SMSProv2

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.

 

Facebooktwitterredditpinterestlinkedinmail

aug 30

SCCM 2012 konsolen ljuger om namnet på Default Client Settings

Miljö 

SCCM 2012 R2 CU2

Scenario

Du försöker ändra någon Client Setting i Default Client Settings med hjälp av Powershell cmdleten Set-CMClientSetting, exempelvis:

Resultatet blir följande felmeddelande:

DefaultClientSettingPowershellBug

Orsak

Namnet som visas i konsolen är Default Client Settings, men Powershell avslöjar att det riktiga namnet i själva verket är Default Client Agent Settings.

DefaultClientSettingPowershellVsConsole

 

Lösning

Ange -Name ”Default Client Agent Settings” som parameter så fungerar det.

 

Facebooktwitterredditpinterestlinkedinmail

aug 21

Del 1 – Den ultimata guiden till Java deployment med SCCM

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

Java runtime environment. Ofta räcker det med att bara nämna dessa tre förhatliga ord för en IT-ansvarig för att totalt förstöra dennes dag. Denna ondskefulla lilla plug-in är ett helt kapitel för sig och för med sig en hel del utmaningar och huvudvärk, och det är väldigt ofta jag får frågan hos kunder hur man bäst hanterar och uppdaterar detta herke.

Det jag bland annat ser många brottas med är hur man blir av med den automatiska uppdateringsfunktionen. Installationsväxlarna till EXE-filen fungerar inte så som folk tror, varpå man börjar knacka ihop något script som ska radera funktionen i efterhand. Vidare har man det gamla klassiska problemet med att webbläsarna inte får vara igång när Java-installationen körs, och så har vi alla nya säkerhetsfunktioner som har kommit som få verkar ha koll på hur de fungerar och hur de ska hanteras. Dessutom är det väldigt vanligt att jag brukar se gamla versioner av Java, såsom Java 6 eller ännu äldre ute på datorerna, och dessa avinstalleras inte automatiskt när man installerar en ny Java 7 version, varpå de ligger kvar och skräpar som en trevlig liten säkerhetskatastrof som väntar på att hända.

 

Så kort och gott, följande är ungefär vad de flesta brukar vilja uppnå när man deployar Java till klientdatorer:

  • Automatisk installation på datorn, registrera Java med IE och övriga webbläsare som stöds.
  • Crapware som ”Ask Toolbar” ska INTE installeras.
  • Gamla versioner ska alltid automatiskt avinstalleras när en ny version installeras.
  • Känn av processer som stör installationen och döda dessa. Meddela dock användaren om att så sker och ge denne en chans att skjuta upp installationen en begränsad tid.
  • Inaktivera automatiska uppdateringar.
  • Stäng av säkerhetsfunktionen som inaktiverar Java om inte senaste version är installerad på datorn. Denna funktion är bra i teorin och för hemanvändare, men knappast på ett lite större företag som behöver tid för att testa och rulla ut en ny version.
  • En lista med vitlistade webbsidor ska finnas där en administratör kan lägga till osignerade sidor som annars blockeras av säkerhetsinställningarna i Java.

 

Vi uppnår alla dessa önskemål genom att:

  • Inte använda .exe-filen för installation, utan istället MSI-paketet som ligger gömt inuti. Då slipper man direkt t.ex. det förhatliga automatiska uppdateringsjobbet som annars installeras.
  • Använda konfigurationsfilerna deployment.properties och deployment.config för att ställa in säkerhetsinställningarna. Läs mer om dessa filer här.
  • Lägga till alla vitlistade webbsidor i filen exception.sites och distribuera denna till klienterna. Här finns en kraftullare funktion som heter Deployment Rule Set men som är betydligt mer komplicerad och bl.a. kräver certifikat, och jag väljer att inte ta med det ännu i den här guiden. Det kanske kommer i en senare del. Att hantera undantag med exception.sites räcker för de flesta.
  • Använda ett intelligent wrapper-script för installationen, som kontrollerar öppna processer, eventuellt meddelar användaren om att dessa behöver stängas, samt kopierar konfigurationsfilerna till rätt platser, osv. För detta ändamål använder jag PS App Deployment Toolkit som jag också skrivit om tidigare här.

 

Följ stegen nedan för att komma igång.

  1. Ladda ned den bifogade filen DeployJava.zip längst ned i den här bloggposten, och packa upp den i någon lämplig katalog där du förvarar källfiler för SCCM-applikationer.
  2. Ladda ned offline installern av senaste versionen här: http://www.java.com/en/download/windows_offline.jsp I skrivandets stund är Java 7 Update 67 den senaste officiella versionen, men Java 8 har faktiskt släppts och går att ladda ned här.
  3. Starta installationsprogrammet och avbryt det direkt. MSI-paketet har nu extraherats upp till en mapp under %UserProfile%\Appdata\LocalLow\Sun\Java. Mappen kommer ha motsvarande namn som den aktuella versionen, t.ex. jre1.7.0_67. Hämta MSI-filen och CAB-filen från denna katalog och placera i Files-mappen i den katalog där du packade upp filerna i Steg 1.
  4. Döp om MSI-paketet så att det heter kort och gott Java.msi (anledningen till detta kommer i del 2 av denna guide).
  5. I mappen SupportFiles ligger följande tre filer som kommer kopieras in till C:\Windows\Sun\Java\Deployment på klienterna av installationsscriptet:deployment.config

    deployment.properties

    exception.sites

    Gå igenom filerna och ändra vid behov någon av inställningarna, och lägg till eventuella vitlistade webbsidor i exception.sites.
  6. Skapa en ny Application i SCCM. Peka ut Java.msi från Steg 4 ovan som källfil, och låt applikationen skapas med alla default inställningar baserat på MSI-paketet. Använd med fördel mitt script eller något annat favorit Powershell-script för detta.
  7. Redigera deployment typen för applikationen (behövs inte om du använder mitt script).
    1. Under fliken Content ändra Content location så att sökvägen inte pekar till Files-mappen där MSI-paketet ligger, utan ett steg ovanför. Alltså, om MSI-paketet ligger under \\SCCM-SERVER\Source\Java\Jre7u67\Files så ändra så att sökvägen istället pekar mot \\SCCM-SERVER\Source\Java\Jre7u67.
    2. Under fliken Programs, skriv in följande rader för installation och avinstallation, samt kryssa i kryssrutan:
      Java-DT
  8. Skicka ut applikationen till distributionspunkterna och testa att deploya.

 

Ladda ned filen här

 

Facebooktwitterredditpinterestlinkedinmail

jun 28

SCCM 2012 R2 CU2 är släppt

Läs mer och hämta hem uppdateringen här: http://support.microsoft.com/kb/2970177

 

Facebooktwitterredditpinterestlinkedinmail

jun 19

Dell XPS 13 9333 och SCCM 2012 OSD

Jag har spenderat den senaste veckan med ännu en SCCM 2012 implementation ute hos kund. En av de datormodeller som skulle certifieras för OS deployment var Dell XPS 13 9333 som jag personligen aldrig certifierat förut, och som jag spenderat ett antal timmar med idag, kliandes i huvudet. Det här är en sån där ultratunn datormodell som inte innehåller något nätverkskort. Istället hade kunden inhandlat dockningsstationer och USB/Ethernet-adaptrar till varje dator.

Det här skapar ju vissa utmaningar om man t.ex. vill PXE-boota men också om man t.ex. byter adapter eller dockningsstation mellan datorer. Om en dator redan har installerats med en adapter/docka och man sen försöker installera en ny dator med samma adapter/docka så finns ju redan den MAC-adressen i databasen knuten till en annan dator…. Det behöver inte vara ett jätteproblem, men något man ska vara medveten om och ta hänsyn till.

Hur som helst, allt går att lösa. Att lägga med drivrutinerna för USB/Ethernet-adaptern var inga konstigheter. Vad gäller dockningsstationen så är Dell ”vänliga” nog att skicka med drivrutinerna på en CD-skiva som innehåller endast en enda fil – Setup.exe. Tackar. Blev till att extrahera ut drivrutinerna därifrån och det var lite krångel med att hitta rätt drivrutin som sparkade igång nätverkskortet i dockan. När den väl var lokaliserad behövde den läggas till i både boot-image och drivrutinspaketet för datormodellen. Setup.exe, som visade sig vara en helt tyst unattended installation, behövdes alltså inga speciella parametrar för den, fick åka med i task sequencen som en villkorad installation för den här datormodellen, för att få in samtliga drivrutiner för HDMI-adaptrar osv.

Nu hade jag alltså en fungerande drivrutin för både adaptern och dockan i min boot-image och drivrutinspaket och kunde börja sparka igång en installation.

Det första problemet jag stötte på var det numera bekanta 80072ee2 vid steget Use toolkit package, som jag skrivit om här tidigare: http://www.infogeek.se/sccm/bugg-i-sccm-2012-r2-use-toolkit-package-misslyckas-med-80072ee2

Det löste sig snabbt genom att modifiera variablerna SMSTSDownloadRetryCount  och SMSTSDownloadRetryDelay. Dessa två variabler har från och med nu förärats en plats i min standardmodell för SCCM implementationer, och jag kommer alltså alltid att använda dem och rekommenderar alla andra att göra detsamma.

Därefter upptäckte jag att datorn inte lades med i domänen utan hamnade utstött och ensam i en liten workgroup. En snabb koll i setupact.log visade att domänen inte kunde hittas (DsGetDcName failed: 0x54b), alltså problem med nätverkskontakten och/eller namnuppslag. Klassiskt drivrutinsproblem. Men när jag kollade i Windows fanns varenda drivrutin så fint där, inklusive nätverkskortet, och det var inga som helst problem med att hitta domänen.

Det visade sig att nätverkskortet/drivrutinen av någon anledning inte hinner initialisera sig ordentligt vid första uppstarten när Windows ska ansluta till domänen. Däremot när task sequencen sen fortsätter så har nätverkskontakten hunnit etableras och installationen fortsätter.

Lösningen på detta blev att lägga till ett steg efter Setup Windows and ConfigMgr med MDT-scriptet ZTIDomainJoin.wsf, som alltså är till just för att kontrollera om datorn har lyckats ansluta till domänen, och om inte så gör scriptet detta. Det här fungerade utmärkt och maskinen blev nu medlem i domänen som förväntat.

Till sist skulle ett antal applikationer installeras i task sequencen. Jag använder mig alltid av Applications och inte gamla Packages/Programs för att hantera applikationer, men som säkert många har upptäckt så finns det en hel del problem och buggar med att installera just Applications i en Task Sequence. Där funkar däremot Packages alldeles utmärkt. Jag vägrar dock benhårt att köra Packages, jag vill ha Applications. Punkt. 🙂 Och än så länge har jag aldrig behövt ge mig på den punkten, men ja Microsoft har definitivt inte gjort ett perfekt jobb här.

Så i min task sequence hade jag först ett par Packages som skulle installeras (hårdvarurelaterade programvaror och dylikt kör även jag alltid som Packages, i den här datormodellens fall var det alltså programvaran för dockningsstationen) och sedan ett tiotal Applications. Det här funkade hur bra som helst för alla datormodeller utom just denna Dell XPS… Den vägrade helt enkelt att installera några Applications, men Packages gick alltså bra. Kul.

Det första jag såg när jag gick igenom smsts.log var: Policy Evaluation failed, hr=0x87d00269, vilket betyder Required management point not found. Det här felet försvann efter att jag ökade värdet för variabeln SMSTSMPListRequestTimeout till 180 (default är 60 sekunder).
Men problemet kvarstod, inga Applications ville installeras. Mer letandes i loggarna och nu rapporterades bl.a.: Execution status received: 24 (Application download failed). I bland annat CAS.log och LocationServices.log kunde jag se att en distributionspunkt inte gick att hitta.

Den här typen av fel kan man få framförallt om ens boundaries är felkonfigurerade, men i det här fallet var jag hundra på att all konfiguration överallt var helt korrekt (och alla andra datormodeller fungerade som sagt i 100% av fallen). Men jag testade faktiskt ändå att modifiera mina Applications och ändra Content-inställningarna till att tillåta fallback locations och även att nedladdning får ske om man sitter på en slow boundary, osv. Men det hjälpte inte.

Det märkliga var att jag provade att öppna en kommandoprompt och ha den öppen när task sequencen kördes och skulle börja installera applikationerna, och jag kontrollerade då att nätverkskontakten fungerade, och det gjorde den. Men eftersom jag haft problemen med att ansluta till domänen och även att hitta en MP innan jag ökade värdet för SMSTSMPListRequestTimeout så började jag misstänka ett tajming-problem. Jag provade därför att lägga in en liten fördröjning i task sequencen precis innan steget som skulle börja installera alla Applications (det kan man göra med ett enkelt Run command line-steg med kommandot: powershell.exe -Command Start-Sleep 120), och se då ÄNTLIGEN fungerade det perfekt. Alla Applications installerades, datorn anslöt fint till domänen och allt var frid och fröjd.

Så sammanfattningsvis, för att få Dell XPS 13 9333 utan nätverkskort att fungera med SCCM 2012 R2 OSD med en dockningsstation och/eller USB/Ethernet-adapter, så behövde jag göra följande:

  • Extrahera och lägg till nätverksdrivrutinerna för docka och adapter i både boot-image och drivrutinspaket. Lägg till installationspaket för programvaran för dockningsstationen i task sequencen.
  • Lägg till och modifiera variablerna SMSTSDownloadRetryCount, SMSTSDownloadRetryDelay och SMSTSMPListRequestTimeout i task sequencen.
  • Lägg till ett steg för ZTIDomainJoin.wsf i task sequencen.
  • Lägg till en fördröjning på två minuter (fungerar förmodligen med betydligt kortare tid än så) efter Setup Windows and ConfigMgr-steget i task sequencen.

Slutsats? Köp för f-n alltid datorer med inbyggt nätverkskort i företagsmiljöer. 🙂

 

Facebooktwitterredditpinterestlinkedinmail

maj 26

Bugg i SCCM 2012 konsolen ändrar ”detection method”

Jag upptäckte det här beteendet när jag höll på och uppdaterade och förändrade diverse Applications i SCCM 2012 med hjälp av PowerShell. Jag kallar upptäckten för en bugg då det är ett oönskat och ologiskt beteende som kan ställa till med lite problem.

Det som händer är att när man redigerar en deployment type för en Application inne i konsolen så ändras detection metoden till att plötsligt bli av typen ”enhanced detection method”, trots att det är felaktigt och trots att man inte redigerar själva detection metoden. Förändringen syns inte någonstans i konsolen utan bara via PowerShell.

Gör så här för att upprepa och verifiera beteendet:

  1. Skapa en ny Application i konsolen och peka ut något MSI-paket. Låt hela applikationen samt deployment type skapas automatiskt i wizarden baserat på MSI-paketet.
  2. Starta PowerShell och kör följande kommando:

    Notera datat i värdet SDMPackageXML. Här lagras alla egenskaper för deploymenttypen, inklusive detection metoden som nu består av product code för MSI-paketet.
  3. Redigera deployment typen för applikationen i konsolen. Ändra t.ex. något värde under fliken ”User Experience”. Var noga med att också klicka på fliken ”Detection Method” men ändra ingenting där. Genom att bara klicka på den fliken, men ändra någonting i en annan flik, så tycks problemet uppstå.
  4. Kör steg 2 ovan igen och notera förändringen i SDMPackageXML. Nu har detection metoden plötsligt förändrats till en ”enhanced detection method”.

Så varför är detta ett problem? Det är förmodligen inte många som någonsin kommer lida av detta, men det är så att om man vill använda sig av PowerShell cmdleten Set-CMDeploymentType för att ändra på detection metoden, så fungerar inte detta om det är en ”enhanced detection method”. Då måste man göra på ett betydligt jobbare sätt.

Lösningen? Gör ALLTING i PowerShell så är detta aldrig ett problem. 🙂 Alternativt, var försiktig när du redigerar en applikation i konsolen, undvik ”detection method”-fliken om du inte har tänkt ändra något där.

 

Facebooktwitterredditpinterestlinkedinmail

maj 09

Script för att skapa Applications i SCCM 2012

Uppdatering 2014-12-18: Det här scriptet har pensionerats till förmån för ett nyare och mycket bättre script, som du hittar här.

Jag har letat efter ett bra script för att enkelt skapa en Application i SCCM, men inte hittat något (finns gott om exempel på hur man gör, men ont om bra kompletta script som går att använda) så då får man göra ett eget istället. Det här scriptet skapar alltså en Application baserat på ett MSI-paket och fyller i all information såsom namn, installationsparametrar, detection method osv automatiskt baserat på egenskaperna från MSI-paketet. Allting styrs dock av parametrar till scriptet, så vill man byta ut någon av egenskaperna från MSI-paketet till något annat så anger man bara den parametern.

Två parametrar är tvingande, nämligen ContentSourcePath (sökvägen till applikationens källkatalog) och MSIPackagePath (fullständig sökväg och namn på MSI-paketet). Övriga parametrar är frivilliga, och anges de inte kommer som sagt informationen hämtas från MSI-paketet istället.

Exempel 1: Skapa en Application och fyll i namn, versionsnummer och tillverkare automatiskt med information från MSI-paketet. Detection metod skapas automatiskt baserat på produktkoden i paketet och vidare skapas automatiskt installations och avinstallations kommandon.

Exempel 2: Skapa applikationen med alla standardvärden men byt ut namnet och skriv även en description.

Exempel 3: Skapa applikationen med alla standardvärden men byt ut installationskommandot.

Ladda ned filen CreateCMMSIApplication.txt från länken nedanför och döp om den till CreateCMMSIApplication.ps1. Redigera scriptet och ändra variablerna för SiteServer och SiteCode så att de stämmer med din miljö. Kör sedan scriptet på en dator med SCCM konsolen installerad.

 

Facebooktwitterredditpinterestlinkedinmail