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

Lämna ett svar

Your email address will not be published.

Fyll i svar på den enkla captcha-frågan nedan för att få kommentera * Time limit is exhausted. Please reload CAPTCHA.