Crearea imaginilor de referință cu Sysprep și Unattend în Windows

Când o companie trebuie să pregătească zeci sau sute de computere cu Windows , a face acest lucru unul câte unul este o adevărată pierdere de timp. Pentru a evita acest lucru, soluția ideală este crearea unei imagini de referință bine realizate, generalizarea ei cu Sysprep și completarea ei cu un fișier de răspuns automat, Unattend.xml, care pregătește totul fără a fi nevoie să se acceseze programele vrăjitoare.

În rândurile următoare veți vedea, în detaliu, cum funcționează Sysprep, ce face exact generalizarea , cum sunt combinați diferiții pași de configurare cu fișierul Unattend.xml și ce limitări, trucuri și probleme tipice trebuie să fiți conștienți pentru a evita blocarea în mijlocul implementării.

Ce este Sysprep și de ce este esențial pentru crearea de imagini de referință?

Sysprep (System Preparation Tool) este utilitarul oficial al Microsoft, conceput pentru a pregăti o instalare Windows pentru clonare și implementare pe alte computere. Scopul său principal este de a elimina toate informațiile unice legate de mașina sursă, astfel încât imaginea să poată fi reutilizată pe mai multe dispozitive fără conflicte.

Fiecare instalare nouă de Windows generează elemente unice, cum ar fi identificatorul de securitate (SID) al computerului , numele de gazdă, anumite cache-uri de drivere, informații de activare etc. Dacă clonați un disc așa cum este, fără a rula Sysprep, reproduceți aceste informații unice și puteți cauza probleme grave de rețea, în special cu servicii precum WSUS sau servicii de domeniu care se bazează pe SID pentru a identifica computerele.

Funcția Sysprep este de a aduce instalarea într-o stare „generalizată” : șterge sau regenerează date specifice despre hardware și sistem, astfel încât la repornire să apară faza de configurare predefinită (OOBE) sau modul de audit, unde sunt generați noi identificatori și se ajustează configurația finală.

În versiunile moderne precum Windows 10, orice computer pe care doriți să distribuiți aceeași imagine trebuie să fi trecut anterior printr-un proces de generalizare, fie cu Sysprep în mod grafic, fie prin linia de comandă cu parametrii corespunzători.

Diferența dintre imaginea generalizată și imaginea specializată

Când discutăm despre implementarea în masă, este esențial să înțelegem diferența dintre o imagine generalizată și o imagine specializată . O imagine generalizată este una în care Sysprep a eliminat datele dependente de mașină, în timp ce o imagine specializată păstrează aceste informații și este concepută pentru un singur computer specific.

O imagine generalizată, odată capturată cu DISM , poate fi restaurată pe orice computer care rulează același sistem de operare, cu condiția să îndepliniți anumite cerințe hardware de bază. În schimb, o imagine specializată păstrează SID-ul, numele computerului, configurația rețelei și alte date relevante doar pentru mașina pe care a fost creată.

În Windows 10, puteți comuta o instalare dintr-o stare specializată într-o stare generalizată și invers folosind Sysprep cu opțiunile corespunzătoare. Procesul tipic este: instalați sistemul, personalizați-l, intrați în modul de audit, finalizați reglajul fin al instalării și apoi, odată ce este finalizat, rulați Sysprep cu `/generalize` și închideți sistemul pentru a captura imaginea respectivă.

Dacă optați pentru implementări foarte omogene (toate echipamentele cu același hardware), ați putea lua în considerare o imagine generalizată mai puțin „agresiv”, dar este totuși recomandabil să lăsați Sysprep să regenereze SID-urile și să curețe datele unice, astfel încât serviciile de rețea și de director să funcționeze fără surprize.

Rolul fișierului de răspuns Unattend.xml

Pe lângă simplificarea procesului de instalare, Sysprep devine mult mai puternic atunci când este combinat cu un fișier de răspuns Unattend.xml . Acest fișier este un document XML care conține o colecție de componente și setări pe care Windows le aplică în diferite etape ale instalării.

Fișierul de răspuns vă permite să răspundeți automat la întrebări tipice de instalare Windows : limbă, aspect tastatură, fus orar, acceptarea acordului de licență, nume computer, comportament preinstalat (OOBE), chei de produs, opțiuni de securitate etc. În loc să facă clic pe „Următorul”, Windows citește fișierul Unattend.xml și aplică valorile definite.

În Windows 7 , Windows 8.1, Windows 10 și versiunile server, fișierul de răspuns gestionează mai multe faze de configurare sau „pasuri”, cum ar fi generalize, specialize, auditSystem, auditUser și oobeSystem . Nu toate acestea sunt întotdeauna procesate; unele sunt executate doar atunci când Sysprep este utilizat în anumite moduri.

Un exemplu simplu de fișier Unattend.xml de bază include setări precum SkipRearm, SkipAutoActivation, setările regionale (es-ES) , comportamentul OOBE pentru a omite expertul utilizator și mașină și alte detalii care fac ca prima experiență să fie complet nesupravegheată.

Structura de bază a unui fișier Unattend.xml pentru Sysprep

Un fișier Unattend.xml complet poate fi proiectat folosind Windows System Image Manager (Windows SIM) , care face parte din kitul de implementare (ADK). Crearea manuală a fișierului de la zero este posibilă, dar destul de dificilă, deoarece necesită o înțelegere aprofundată a componentelor și a sintaxei lor XML.

Un fișier de bază tipic ar putea include, de exemplu, componenta Microsoft-Windows-Security-SPP în pasul generalize , cu eticheta SkipRearm setată la 1. În versiunile mai vechi de Windows, acest lucru permitea resetarea contorului de activare. În versiunile recente, dacă utilizați chei de licență de volum sau chei de vânzare cu amănuntul, această setare este mult mai puțin necesară, deoarece Windows se activează automat.

Pasul de specializare include adesea Microsoft-Windows-Security-SPP-UX (cu SkipAutoActivation) și Microsoft-Windows-Shell-Setup pentru lucruri precum CopyProfile, ComputerName (care poate fi un wildcard) sau fusul orar (de exemplu, „Ora standard GMT”). Toate acestea se aplică atunci când sistemul intră în această fază după generalizare.

În cele din urmă, în faza oobeSystem , parametrii de regionalizare sunt de obicei definiți prin Microsoft-Windows-International-Core (InputLocale, SystemLocale, UILangage, UserLocale în es-ES), iar parametrii OOBE în Shell-Setup, cum ar fi HideEULAPage, NetworkLocation, ProtectYourPC, SkipMachineOOBE și SkipUserOOBE , care permit omiterea unei mari părți din configurația inițială.

După ce ați pregătit fișierul XML, salvați-l pur și simplu ca „unattend.xml” în text simplu (aveți grijă ca editorul să nu adauge extensia .txt) și plasați-l în calea C:\Windows\System32\sysprep, de unde Sysprep îl va detecta sau îl puteți invoca manual folosind parametrul /unattend.

Cum se utilizează Sysprep cu un fișier de răspuns Unattend

Sysprep poate fi rulat fie folosind o interfață grafică (sysprep.exe), fie o interfață de linie de comandă . Atunci când este utilizat într-un mediu profesional, rularea sa prin linia de comandă este cea mai precisă modalitate de a controla toți parametrii.

Comanda standard pentru pregătirea unei imagini gata de captură arată de obicei astfel: `sysprep /generalize /oobe /shutdown /unattend:»C:\Windows\System32\sysprep\unattend.xml»` . Această comandă vă permite să generalizați procesul, să specificați că următoarea pornire ar trebui să fie în modul OOBE, să opriți computerul la finalizare și să utilizați fișierul de răspuns specific pe care l-ați pregătit.

Pentru a lansa Sysprep cu comanda respectivă, procedura obișnuită este să deschideți o fereastră de comandă cu privilegii de administrator, să accesați directorul C:\Windows\System32\sysprep și să tastați comanda completă cu parametrii săi . Orice eroare în parametri (sau în calea XML) va face ca Sysprep să nu facă exact ceea ce vă așteptați.

În timpul execuției, Sysprep va avea nevoie de câteva minute pentru a curăța sistemul, a procesa fișierul Unattend stocat (sau pe cel specificat de dvs.) și a pregăti imaginea într-o stare generalizată. La finalizare, va opri automat computerul dacă ați utilizat /shutdown, lăsându-l gata pentru capturare cu instrumentul de imagistică preferat.

Este important ca, odată ce mașina de referință se oprește după Sysprep, să nu o reporniți înainte de a captura imaginea. Acest lucru va întrerupe starea generalizată și va trebui să repetați întregul proces Sysprep înainte de a face captura.

Faze de configurare: generalizare, auditSystem, auditUser și oobeSystem

Nu toate fazele fișierului de răspuns sunt executate întotdeauna. Unele, cum ar fi generalize, auditSystem și auditUser , intră în joc doar atunci când este implicat Sysprep. Înțelegerea momentului în care sunt procesate vă ajută să plasați corect fiecare configurație în fișierul Unattend.xml.

Setările auditSystem și auditUser se aplică atunci când computerul pornește în modul audit , pe care îl puteți forța cu comanda Sysprep /audit. Acest mod permite tehnicienilor să adauge drivere , aplicații și setări suplimentare înainte de a le face permanente.

Pasul de configurare generalize este procesat prin executarea parametrului /generalize din Sysprep. Aici sunt eliminate datele hardware specifice, SID-urile și alte informații legate de mașină, lăsând instalarea într-o stare care poate fi clonată fără conflicte.

Faza oobeSystem se aplică la prima pornire după generalizare , când sistemul intră în modul out-of-the-box experience (OOBE). Dacă ați configurat corect fișierul Unattend.xml, acest pas poate fi aproape automat pentru utilizatorul final.

Prin urmare, dacă doriți să înlănțuiți întregul proces (personalizare, generalizare, pornire în modul audit sau OOBE etc.) într-un mod complet automatizat, trebuie să distribuiți opțiunile între etapele corespunzătoare și să vă asigurați că Sysprep rulează cu parametrii corecți.

Limite, activare și utilizare a parametrului SkipRearm

Microsoft impune anumite restricții privind numărul de utilizări ale Sysprep pe aceeași imagine. Pe Windows 8.1, Windows Server 2012 și versiunile ulterioare, îl puteți rula de până la 1001 ori; pe Windows 7 și Windows Server 2008/2008 R2, limita este de doar 3 utilizări per imagine.

În versiunile mai vechi, configurația SkipRearm din fișierul de răspuns era frecvent utilizată pentru a reseta contorul de activare. În practică, acest lucru permitea perioade de pregătire extinse în timpul testării și implementărilor, deși întotdeauna în limitele permise ale licenței.

Totuși, dacă utilizați chei de produs de volum sau chei moderne de vânzare cu amănuntul, Windows se activează automat și, de obicei, nu este nevoie să utilizați SkipRearm . Chiar și așa, opțiunea rămâne disponibilă în Componentele de securitate (Security-SPP) pentru mediile în care activarea este gestionată mai mult manual.

Dacă un proiect necesită mai multe iterații de testare Sysprep pe aceeași imagine, este recomandabil să planificați bine și să controlați câte generalizări sunt executate, pentru a nu atinge limita și a fi nevoie să reconstruiți imaginea de la zero în cel mai nepotrivit moment posibil.

Drivere Plug and Play și PersistAllDeviceInstalls

În timpul instalării Windows, sistemul detectează dispozitivele hardware și configurează automat driverele acestora . În general, Sysprep dezinstalează aceste dispozitive configurate, deși lasă driverele disponibile pe computer.

Dacă scenariul de implementare este foarte omogen și toate mașinile țintă au hardware identic cu mașina de referință, este posibil să doriți să păstrați dispozitivele deja instalate. Acesta este scopul setării PersistAllDeviceInstalls a componentei Microsoft-Windows-PnpSysprep.

În fișierul Unattend.xml, setarea PersistAllDeviceInstalls la true va face ca Sysprep să păstreze dispozitivele configurate în timpul generalizării, reducând timpul de descoperire pe mașinile finale. Aceasta este, în esență, o optimizare pentru mediile cu hardware clonat.

Totuși, dacă intenționați să implementați pe modele diferite cu hardware variat , este mai prudent să lăsați Sysprep să dezinstaleze dispozitivele și să le detecteze de la zero pe fiecare mașină, instalând driverele corespunzătoare după restaurarea imaginii.

În orice caz, rețineți că referința pentru aceste componente se află în documentația oficială de instalare neasistată Windows , unde este detaliată semnificația fiecărei etichete XML care afectează Sysprep și subsistemul Plug and Play.

Utilizarea RunSynchronous și a ferestrei AuditUI în modul audit

Când porniți Windows în modul audit, puteți utiliza componenta Microsoft-Windows-Deployment pentru a lansa comenzi secvențiale folosind RunSynchronous pe pasele auditSystem sau auditUser. Acest lucru vă permite să automatizați scripturi, instalări sau sarcini suplimentare de pregătire.

În timpul pasului auditUser, fereastra AuditUI afișează starea acelor comenzi RunSynchronous. Veți vedea o listă cu descrierea sau calea fiecărei comenzi, în ordinea definită de valoarea Order a parametrului RunSynchronousCommand.

Sysprep procesează toate comenzile secvențial . Dacă o comandă se execută cu succes, apare cu o bifă verde în AuditUI. Dacă eșuează, este marcată cu un X roșu, ceea ce facilitează identificarea părții procesului de pregătire care a cauzat probleme, chiar și atunci când scriptul nu generează niciun jurnal.

Modul în care sunt gestionate repornirile automate depinde de setarea WillReboot . Dacă este setată la Întotdeauna, computerul va reporni întotdeauna după executarea comenzii, indiferent dacă aceasta returnează 0 (succes) sau o valoare diferită de zero. Dacă este setată la Niciodată, computerul nu va reporni niciodată, chiar dacă apar erori.

Cu WillReboot setat la OnRequest, codurile de returnare 0, 1 și 2 au semnificații distincte: 0 indică un succes fără repornire, 1 determină o repornire imediată cu succes, iar 2 repornește, dar comanda este considerată încă în desfășurare, reapărând în listă după pornire. Orice alt cod este interpretat ca o eroare irecuperabilă , ceea ce poate duce la o casetă de dialog de blocare, cu excepția cazului în care există un script Errorhandler.cmd pentru a gestiona eroarea.