Windows Server 2022 nu mai pornea: aproape 10 ore de recovery și 90 de minute pentru reinstalare

Totul a început după un restart al unui server fizic cu Windows Server 2022, folosit ca host Hyper-V. Pe el rulau mai multe mașini virtuale, printre care două Domain Controllere, un server RDS cu FSLogix și serviciile de monitorizare și administrare.

După restart, Windows nu a mai pornit. Eroarea afișată era 0xC000021A.

În momentul respectiv nu știam dacă problema putea fi reparată relativ simplu sau dacă urma să ajungem la reinstalare. Cum mașinile virtuale erau stocate pe un volum separat de sistemul de operare, datele lor nu păreau afectate, așa că am încercat mai întâi să recuperăm instalarea existentă de Windows Server.

A urmat o sesiune de troubleshooting care s-a întins până la aproape zece ore.

Primele verificări

Am început cu verificarea diskurilor, identificarea instalării offline de Windows și rularea SFC. Sistemul de operare era pe E:, iar mașinile virtuale Hyper-V erau păstrate pe D:.

SFC a găsit fișiere corupte și a reparat o parte dintre ele, dar după restart situația nu s-a schimbat. Serverul continua să intre în aceeași eroare.

Am trecut apoi la DISM și la verificarea pachetelor Windows instalate. Am încercat revenirea modificărilor pending și eliminarea update-urilor care ar fi putut avea legătură cu problema.

La un moment dat, dezinstalarea unui update ajungea până la 100%, dar CBS refuza commit-ul cu eroarea 0x800f082f.

Așa că am continuat.

Câteva ore doar pentru imaginea WIM

Pentru următoarea etapă aveam nevoie de o sursă de componente potrivită pentru DISM. Sistemul instalat era build 10.0.20348.5386, iar imaginea Windows Server pe care o aveam nu se afla la aceeași versiune.

Aici am pierdut probabil cea mai mare parte din timp.

Nu era suficient să montăm ISO-ul și să indicăm DISM către un install.wim. A trebuit să identificăm indexul potrivit, să pregătim imaginea și să o aducem la buildul de care aveam nevoie prin aplicarea update-urilor necesare.

Între montarea imaginii, injectarea pachetelor, commit, verificarea rezultatului și câteva încercări care nu au ieșit din prima, aproximativ 3–4 ore s-au dus numai pe pregătirea fișierului WIM.

După ce am ajuns, în sfârșit, la versiunea potrivită, am reluat DISM folosind noua imagine drept sursă.

Nu a rezolvat problema.

Au continuat să apară erori legate de CBS și componente pe care Windows nu reușea să le repare.

Registry, fișiere de sistem și alte încercări

În continuare am verificat registry-ul offline, hive-urile Windows și fișierele de sistem implicate în eroarea 0xC000021A.

Am ajuns inclusiv la înlocuirea manuală a unor fișiere corupte cu versiuni sănătoase și la parcurgerea mai multor proceduri de recovery pentru situații în care SFC și DISM nu mai reușesc să repare instalarea.

Unele lucruri păreau să se rezolve pe parcurs, dar rezultatul după restart rămânea același.

Windows nu pornea.

După aproape zece ore ajunseserăm în punctul în care mai existau, probabil, și alte lucruri pe care le puteam încerca, dar nu mai aveam o indicație clară că următoarea variantă avea șanse mai bune decât cele de până atunci.

Așa că am decis să reinstalăm.

Reinstalarea hostului Hyper-V

Partea bună era că VM-urile nu fuseseră afectate. Diskurile lor se aflau în continuare pe D:, separat de instalarea Windows Server.

Am făcut o instalare curată de Windows Server 2022, am reinstalat rolul Hyper-V, am refăcut configurația necesară și am readus mașinile virtuale.

Apoi am verificat serviciile pe rând: Domain Controllerele, Active Directory și DNS, serverul RDS cu FSLogix, monitorizarea și accesul utilizatorilor.

De la momentul în care am început reinstalarea până când serviciile au fost din nou funcționale au trecut aproximativ 90 de minute.

Ce am reținut din incident

Ca timp, diferența a fost destul de mare: aproape zece ore încercând să recuperăm instalarea Windows, dintre care aproximativ 3–4 ore numai cu pregătirea imaginii WIM, și aproximativ o oră și jumătate pentru reinstalarea hostului și readucerea serviciilor.

Privind în urmă, probabil că puteam lua decizia de reinstalare mai devreme.

În același timp, la început nu aveam de unde să știm cât de adâncă era problema. SFC găsise fișiere corupte, existau indicii legate de update-uri și CBS, iar DISM era o variantă rezonabilă de încercat înainte să renunțăm la instalarea existentă.

Partea utilă a incidentului a fost mai degrabă confirmarea unui lucru destul de banal: separarea sistemului de operare de storage-ul VM-urilor ne-a simplificat foarte mult revenirea.

Hostul a trebuit reinstalat.

Mașinile virtuale nu.