Dacă aveți o infrastructură WSUS ramificată, cu un server central și un număr de servere slave, probabil că utilizați politici de grup pentru a centraliza gestionarea clienților WSUS. Odată cu introducerea unor mecanisme de Preferințe politica de grup (APE) avem o oportunitate în loc de o multitudine de politică de grup este stabilit seturi diferite de calculatoare client pentru următorul server WSUS pentru a le - utilizează o politică de grup cu un număr de setări legate în funcție de aceste sau alte condiții. Să luăm în considerare un exemplu de a crea o politică de grup unică cu următoarele date inițiale:
Pentru a distinge toți clienții, folosim mecanismul standard pentru crearea grupurilor de computere pe serverul WSUS. De exemplu, creați grupuri separate pentru fiecare locație fizică și, în plus, creați două grupuri auxiliare:
- KOM-All-Test-New-Updates - pentru testarea noilor actualizări
- KOM-All-Not-Install-IE9 - pentru a configura interzicerea instalării IE9
Grupurile sunt create pe serverul principal și replicate cu motorul de sincronizare pentru toate serverele slave.
Crearea grupurilor WSUS vă permite nu numai să gestionați mai flexibil aprobarea / respingerea anumitor actualizări, ci și să obțineți informații despre situația sumară despre rezultatele integrității instalării actualizărilor în consola WSUS
Deci, hai să mergem la stabilirea politicii de grup. Pentru a face acest lucru, deschideți Consola de gestionare a politicii de grup (gpmc.msc) și creați un nou obiect de politică de grup, în care puteți dezactiva imediat setările de configurare a utilizatorului, deoarece vom folosi doar secțiunea Configurare computer
În Șabloanele de administrare standard pentru această politică, setăm setările de bază pentru configurarea clientului WSUS care pot fi aplicate tuturor clienților WSUS, fără excepție. Imaginea de ecran prezintă un exemplu de setare a unor astfel de parametri generali:
Toate celelalte setări, care pot varia în funcție de condițiile oferite de clienții WSUS, pe care le facem în GPP în secțiunea de setări Preferințe> Setări Windows> Registru
Creați două setări la rădăcina copacului de setări - 4 setări ale cheilor de registry (2 taste pentru clienți pe 32 de biți și 2 chei pentru clienți pe 64 de biți) cu următoarele setări:
Registry Hive: HKEY_LOCAL_MACHINE
Registrele sucursalelor
pentru x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
pentru x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Tasta de registry: TargetGroupEnabled REG_DWORD = 1
Registrele sucursalelor
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdateAU
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdateAU
Tasta de registry: UseWUServer REG_DWORD = 1
Acești doi parametri sunt plasați la nivelul superior al setărilor pentru claritate și vor fi aplicați tuturor computerelor pe care această politică va funcționa
Parametrii sunt făcuți separat pentru sistemele pe 32 de biți (x86) și 64 de biți (x64), deoarece se folosesc ramificații de registru diferite, în funcție de bitul sistemului de operare. Pentru clienții WSUS pe 64 de biți, se adaugă o altă condiție de direcționare la toate celelalte chei de registry din amonte care au fost orientate la nivel de element
Această condiție se bazează pe verificarea prezenței sucursalei de registru SOFTWAREWow6432Node în HKEY_LOCAL_MACHINE. adică dacă această ramură există, atunci procesarea politicii are loc pe un client pe 64 de biți
Acum uita-te în interiorul oricare dintre aceste grupuri de servere. În cadrul fiecărui grup, sunt făcute setări pentru un anumit server, astfel încât clienții să știe unde merg pentru actualizări și unde să trimită informații despre stare. Acestea sunt 2 parametri - 4 setări pentru chei de registry (2 chei pentru clienți pe 32 de biți și 2 chei pentru clienți pe 64 de biți) cu următoarele setări:
Registry Hive: HKEY_LOCAL_MACHINE
Registrele sucursalelor
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
În interiorul subgrupului, creați parametrii pentru direcționarea către clientul WSUS:
Registry Hive: HKEY_LOCAL_MACHINE
Registrele sucursalelor
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Tasta de registru: TargetGroup REG_SZ = KOM-AD01
Tasta de registru: TargetGroup REG_SZ = COM-AD01; KOM-All-Test-New-Updates
Tasta de registru: TargetGroup REG_SZ = COM-AD01; KOM-All-Not-Install-IE9
Dacă clientul trebuie să fie în mai mult de un grup, numele sunt enumerate în valoare printr-un punct și virgulă. În acest caz, dacă grupurile WSUS au o structură imbricată, se specifică numele final al grupului (fără informații despre ierarhie). Această caracteristică trebuie luată în considerare la planificarea și crearea unei structuri de grup WSUS.
De asemenea, este important să rețineți că ordinea de aplicare a APE (Ordin) are de asemenea valoarea definitorie.
La acest nivel, în exemplul nostru, vom combina diferite versiuni ale valorilor aceeași cheie de registry, în funcție de diferite condiții. De exemplu, o condiție suplimentară pentru calitatea de membru este luat din contul computerului în grupul de securitate domeniu. Aceasta este, în acest caz, TargetGroup valoarea cheii este setată la „KOM-AD01; KOM-All-test-New-Actualizări“ cu condiția ca computerul are un sistem de operare pe 64 de biți și este inclus în grupul respectiv de calculatoare de testare în domeniu.
Acordați atenție faptului că atunci când specificați un grup de securitate a domeniului, este mai bine să nu introduceți numele acestuia direct în câmpul Grup, dar utilizați butonul Răsfoiți pentru a permite Editorului Tardeting să identifice corect SID-ul acestui grup.
În acest APE setare poate fi considerată completă și pentru setările de registry pentru mecanismul de auto-atribuire la grupul WSUS aplicat pe calculatoarele client a început să lucreze - este necesar pentru a comuta în modul serverul WSUS Group Policy Management. Pentru a face acest lucru, consola WSUS - Opțiuni> Computere (Opțiuni> Calculatoare), inclusiv setarea corespunzătoare:
Rețineți că această setare trebuie modificată pe toate serverele WSUS.
wuauclt / resetauthorization / detectnow
Nu uitați faptul că, pentru ca politica de grup pe care am creat-o să funcționeze cu succes, clienții trebuie să poată lucra cu GPP, în special pentru sistemele învechite, cum ar fi Windows XP.
Este posibil să apară situații în care trebuie să configurați Permiteți non-administratorilor să primească grupul de notificări actualizate separat de Șabloane de administrare (în secțiunea Configurare computer> Șabloane administrative> Componente Windows> secțiunea Windows Update). Această opțiune indică posibilitatea de a vedea utilizatorii neavizați care notifică clientul WSUS despre disponibilitatea noilor actualizări și despre inițierea procesului de instalare a actualizărilor. Pentru stațiile de lucru aceasta este o situație normală, dar pe serverele terminale aceasta poate fi o adevărată durere de cap și, prin urmare, este mai bine ca serverele să oprească această opțiune. Aceasta înseamnă că puteți lăsa acest parametru neconfigurat în Șabloanele administrative și configurați-l cu cheia de registry prin intermediul mecanismului GPP descris mai sus:
Registry Hive: HKEY_LOCAL_MACHINE
Registrele sucursalelor
x86: SOFTWAREPoliciesMicrosoftWindowsWindowsUpdate
x64: SOFTWAREWow6432NodePoliciesMicrosoftWindowsWindowsUpdate
Tasta de registry: ElevateNonAdmins REG_DWORD 1 sau 0
Valorile cheie posibile:
- 1 - Activat. Utilizatorii primesc notificări de client WSUS despre disponibilitatea unor actualizări proaspete și pot iniția procesul de instalare a actualizărilor
- 0 - Dezactivat. Utilizatorii nu văd notificări și numai administratorii pot gestiona instalarea actualizărilor.
În acest fel, puteți crea reguli adecvate de procesare GPP cu direcționarea, spre exemplu, versiunea sistemului de operare (server / non-server) sau, de exemplu, numele computerului, dacă există anumite convenții standard de numire standard în organizația dvs. Aici totul depinde de imaginația ta.
În cazul meu, am rezolvat această problemă puțin diferit: pentru serverele terminale, am o politică separată a grupului cu închiderea procesării parametrilor pentru mine, adică parametrii săi se vor suprapune întotdeauna parametrilor politicii generale WSUS. Și deja în această politică specială acest parametru este dezactivat și utilizatorii serverului terminal nu deranjează alertele client WSUS.
Ca epilog, previzionând replici de tip "Totul este mai flexibil în SCCM", remarcăm imediat că această notă este destinată celor care, din anumite motive, nu pot folosi astfel de soluții. După cum puteți vedea, toate setările sunt făcute în cadrul funcționalității standard a Windows Server.
Distribuiți acest post:
Întotdeauna am crezut că dacă computerele sunt împrăștiate în jurul sistemului de operare și toată lumea este legată de o politică cu TargetGroup, atunci când muți un computer de la un sistem de operare la altul, acesta va cădea într-un alt grup la WSUS - este o iluzie?
O privire de ansamblu excelentă asupra aplicării obiectivului GPP vizat la nivel de element!
Mulțumesc!
Cum se rezolvă această problemă? Împărtășește experiența de implementare descrisă în articol ..
Implementăm sistemul de operare dintr-o imagine pregătită, cu sistemul în care această actualizare este preinstalată. Dacă instalați sistemul de operare manual, atunci, desigur, pentru ca GPP să funcționeze - trebuie să instalați manual actualizarea necesară.
Vă mulțumim, această opțiune este de înțeles ..
Trimiteți-le prietenilor: