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.
