Sfaturi necesare pentru migrarea acțiunilor de la un DC 2003 la un nou 2012: cum pot evita întreruperea GPO-urilor mele de instalare de software?

Am virtualizat în sfârșit întreaga infrastructură de server și sunt gata să încep migrarea la serverul Windows cumpărat 2019. Deoarece configurația noastră actuală se bazează pe Windows Server 2003, evident că trebuie să facem pasul de migrare printr-o instalare intermediară de exemplu 2012 R2. (Ar fi ok și AFAIK 2016).

Problema mea este urmatoarea. DC din 2003 găzduiește o serie de partajări de fișiere. Unele dintre ele sunt foarte ușor de copiat în instalarea 2019 și pur și simplu îmi schimb GPO-urile existente pentru a se referi la numele serverului 2019, în loc de 2003.

Problema mea constă în anumite GPO de instalare de software, pentru care pachetele de instalare MSI relevante nu se află pe SYSVOL, ci pe o partajare accesibilă ca \srv2003\installers. Evident, asta se va termina ca \srv2019\installers\ dar cum se trece unul de la unul la altul? Dacă „modific” sarcinile noastre de instalare GPO pentru a face referire la noile căi de instalare, voi produce o furtună de instalare peste toți clienții noștri...

Îmi puteți oferi vreun sfat despre cum pot îndeplini această sarcină? Și, eventual, o modalitate mai bună de a avea GPO-urile noastre MSI pregătite pentru instalare (în SYSVOL, poate în loc de o altă partajare)?

EDITARE: Deoarece întrebarea mea a fost închisă și pentru a evita aglomerarea OP-ului cu motivele pentru care ar trebui redeschis, verificați explicația mea de ce ar trebui să rămână asta.

Primul lucru important de reținut: este foarte recomandat să nu utilizați niciun rol de server pe controlerele de domeniu, cu excepția „Server DNS” și „Servicii de domeniu Active Directory”.

Dacă ați migrat de la un server de fișiere 2003 la un server de fișiere 2019, v-aș recomanda să utilizați expertul de migrare a spațiului de stocare care este inclus cu Windows Server 2019. Acesta ajută la migrarea partajărilor și, de asemenea, poate redirecționa utilizatorii către noul server după trecerea de la serverul de fișiere original. În acest caz, nu cred că această abordare poate fi recomandată (migrarea de la un controler de domeniu).

Prima mea înclinație a fost să le pun pe ambele ca comentarii în loc de răspuns, dar în acest moment, ar fi într-adevăr soluția „potrivită” de a construi un server de fișiere, de a copia fișierele de instalare într-o nouă partajare pe el (puteți chiar utilizați același nume de partajare), apoi editați GPO-urile pentru a înlocui numele DC cu noul nume de server de fișiere în UNC al programului de instalare.

Deoarece acest upgrade implică o instalare intermediară a Windows Server 2012R2, m-am gândit la o posibilă cale. Avertismentul este că nu există nicio marjă de eroare, deoarece întreg procedura trebuie efectuată într-un singur pas. Prin urmare, planificarea ar trebui să fie luată pentru, de exemplu, să găzduiască schimbarea la DFS-R. Și toată această procedură ar trebui efectuată în timpul orelor libere.

Să presupunem că serverele AD actuale sunt srv1 și srv2 (Windows Server 2003R2) și că primul oferă o partajare cu scopul instalării software-ului bazat pe GPO.

Mai întâi, backup undeva la share-uri. Apoi introduceți două (și nu unul, deoarece dacă lucrurile merg pe o parte, suntem condamnați) servere Windows 2012R2 în domeniu. Evitați să utilizați Server 2016 pentru acest pas, cred a încetat să mai sprijine FRS.

Mutați rolurile și faceți tot ce este necesar pentru a promova unul dintre cele două servere noi, transferați roluri etc. și apoi retrogradați srv1 și srv2. Eliminați ambele servere 2k3 din domeniu. Ridicați nivelul funcțional la 2008 R2 (de exemplu), înlocuiți FRS cu DFS. În sfârșit, faceți două noi instalări de server 2019, având grijă să:

• numiți primul cu numele primului server 2k3 vechi, adică srv1, iar al doilea server ca srv2
• configurați adresele IP ale acestor două servere noi să corespundă celor vechi (pas opțional, dar aș face-o pentru orice eventualitate)

Refaceți calea de migrare, de data aceasta de la serverele temporare la noile srv1 și srv2 și, în final, retrogradați/eliminați serverele intermediare. Recreați acțiuni pe srv1 și populați-le.

Nu este o soluție super curată, dar îmi va permite să-mi păstrez GPO-urile de instalare fără nicio schimbare de nume/reinstalare.

EDIT: Tocmai am terminat această procedură.A funcționat impecabil, cu noi sisteme client care descărcau pachete de instalare GPO. Toți sunt fericiți!

Sunt de acord cu SturdyErde că ar trebui să evitați să aveți partajări de fișiere pe DC, dar mi-am migrat compania de pe SBS08 acum câțiva ani și înțeleg că uneori este ceea ce este. O descriere de nivel înalt a căii de upgrade propuse este:

• Adăugați serverul 2012 R2 la domeniu ca controler de domeniu
• Oglindiți-vă acțiunile
• Dezafectare srv2003
• Adăugați serverul dvs. 2019 la domeniu
• Creați un alias DNS al lui srv2003 care indică srv2019
• Promovați 2019

Acolo se vor ridica pașii la nivel de domeniu funcțional, dar principalul aspect este să creați un alias DNS de srv2003 pentru a indica noile partajări imediat ce dezafectați vechiul server.

De asemenea, sunt de acord cu SturdyErde că ar trebui să te uiți la expertul de migrare a stocării. Cred că există o opțiune care redenumește noul server cu numele vechiului server, dar sunt puțin nervos la ideea de a face asta cu un DC.

Noroc!

Nu cunosc o soluție curată la problema ta actuală. Dar vă pot oferi un indiciu pentru viitor:

Utilizați un nume specific în acest scop, cum ar fi install.your.domain și setați o înregistrare DNS la srv2019 cu acest nume. Data viitoare când vă mutați cota de instalare, schimbați această înregistrare DNS.

Pentru problema dvs. actuală, ceva de genul acesta ar putea fi considerabil:

• Asigurați-vă că srv2003 mai este folosit doar pentru această partajare.
• Oglindiți share la srv2019
• Schimbați înregistrarea DNS pentru srv2003 la IP-ul lui srv2019.
• Dezafectare srv2003
• Creați noi GPO-uri pentru clienții instalați proaspăt și software nou, utilizați numele specific menționat mai sus aici

Pe măsură ce clienții vechi sunt înlocuiți sau sunt complet configurați noi, utilizarea vechiului dvs. GPO se reduce până când acesta poate fi șters la un moment dat.