Cum să actualizați fișierele ADMX - diferite versiuni ale sistemului de operare pentru server în domeniu

Domeniul clienților mei are diverse 2012R2, 2016 și 2019 Windows Server versiuni.Două dintre cele patru controlere de domeniu rulează Windows 2012R2 și fișierele ADMX nu au fost actualizate de ani de zile. Celelalte două controlere de domeniu sunt Windows 2019 și le sunt atribuite rolurile FSMO.

Sper să se retragă definitiv toate instanțele din 2012 în scurt timp, inclusiv DC. Deoarece fișierele ADMX nu au fost actualizate de ani de zile, nu pot aplica anumite GPO-uri la instanțele din 2016 și 2019, care vor deveni o problemă de securitate în curând. Din moment ce mediul meu va constau din servere 2016 și 2019, ce este cea mai bună politică sau metodă pe care ar trebui să o folosesc pentru actualizarea fișierelor ADMX?

Din câte am citit majoritatea oamenilor sugerează Magazinul central de definiții pentru politici opțiune, dar nu eram sigur dacă aceasta este o idee bună, deoarece alerg mai multe versiuni ale sistemului de operare în mediul meu. Sunt acolo orice alte abordări la actualizarea fișierelor ADMX ar trebui să iau în considerare structura mediului meu?

Dacă eu nu folosește Magazinul central opțiunea, ar trebui să descarc fișierele ADMX în C:\Windows\PolicyDefinitions pliant la nivel local pe fiecare controlor de domeniu pentru a aplica cele mai recente setări la GPO-uri sau ar trebui să descarc fișierul ADMX în C:\Windows\PolicyDefinitions pe toți membrii domeniului/serverele pentru ca serverele să primească setări GPO actualizate?

Nu am fost niciodată nevoit să actualizez fișierele ADMX, așa că orice sfat ar fi foarte apreciat, mulțumesc!

Există un lucru cheie de înțeles despre șabloanele administrative (ADMX):

Actualizarea șabloanelor administrative NU va schimba nimic în GPO-urile pe care le-ați implementat: ADMX sunt citite de Managementul politicilor de grup Consolă (sau gpresult când generați un raport) pentru a afișa setările unui om (afișând o listă de setări, o descriere,...). Asta e!

Exemplu: luați în considerare următorul scenariu:

Creați un nou GPO cu șabloane ADMX din 2011 și implementați acest GPO.
Acum, imaginați-vă că actualizați șabloanele ADMX la o versiune mai nouă și să presupunem că Microsoft a eliminat din fișierele ADMX mai noi unele dintre setările mai vechi din epoca 2011 pe care le-ați stabilit anterior cu fișierele șablon ADMX mai vechi:
Calculatoarele/serverele nu vor observa acest lucru, deoarece nu au nevoie de ADMX pentru a aplica politica.

Cu toate acestea, data viitoare când veți deschide Consola de gestionare a politicii de grup și doriți să editați GPO-ul, NU veți vedea setările pe care le-ați setat anterior, DAR acestea vor fi afișate în „Setări suplimentare de registry” (și în raportul HTML )

Deci, cel mai rău caz pentru dvs.: veți ajunge cu politicile de grup să implementeze setări „mai vechi” pe care Microsoft le-a eliminat din ADMX și nu veți putea edita aceste setări folosind Consola pentru politici de grup.

=> Dacă utilizați Central Store: faceți o copie de rezervă a fișierelor ADMX curente și actualizați șabloanele ADMX. Dacă este necesar, puteți restaura fișierele ADMX mai vechi.

=> Dacă nu utilizați Magazinul central: rețineți că editarea unei politici de grup de pe Server 2019 va folosi fișierele ADMX Server 2019 (locale), așa că, dacă ați configurat setări „mai vechi” pe care Microsoft le-a eliminat cu Server 2019, acestea vor apar ca „Setări suplimentare de registru” atunci când sunt vizualizate de pe un server 2019, deoarece editorul de politici nu știe cum să vă arate aceste setări. Deschiderea Consolei de politici de grup de pe Server 2012R2 va folosi fișierele ADMX 2012R2 (locale). (Apropo, de aceea este recomandat Magazinul central pentru că nu doriți să vedeți comportamente diferite în consolele GPO în funcție de „unde” editați politicile...)

Poti uita-te la raspunsul meu aici de asemenea, despre o situație similară.