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. 🙂
