Dupa cum stiti fiecare domeniu AD are asociata si o zona DNS folosita in special pentru a localiza serviciile si sistemele din domeniu.

In majoritatea cazurilor aceasta zona este de tipul AD Integrated (poate fi si standard) adica zona e stocata in AD, replicata pe toate DC-urile, si incarcata automat la pornirea serviciului DNS. Fiind stocata in AD, backup-ul zonei este integrat in backup-ul de AD (systemstate) si bineinteles ca si restore-ul urmareste aceeasi procedura. Problema cu restore-ul de AD e ca trebuie sa restartezi DC-ul in modul de restore si in unele cazuri poate fi destul de neplacut. Plus ca trebuie sa faci restore la intreg systemstate-ul.

Deci, ce metoda mai buna de restore as avea daca accidental sterg zona sau o parte din ea?

Ideea ar fi sa creez o zona de tip standard secondary pe un alt server Windows:

Setez ca serverul sa traga o copie a zonei de pe un DNS server existent (domain controller).

Si pe serverul care are deja zona setez “allow zone transfers” sa imi permita transferuri catre noul server.

La scurt timp pot vedea o copie a zonei pe noul server:

Zona fiind de tip standard, o gasim aici:

Iar continutul arata cam asa:

Acest fisier se updateaza pe baza informatiilor din zona din AD, deci va fi necesar sa ii facem un backup schedulat. Nu o sa mai detaliez procesul pentru ca e banal.

Acum sa explic si in ce ar consta procesul de restore. Considerand ca informatiile din zona din AD au “disparut”, luam fisierul cu numele zonei de pe noul server, il copiem pe un DC unde facem urmatoarele:

-stergem zona existenta

-o recream cu acelasi nume dar de nu AD Integrated. In felul acesta zona va fi stocata in %windir%\system32\dns\

-inlocuim fisierul cu numele zonei folosind fisierul de pe serverul de backup

-schimbam modul de storage din nou ca AD Integrated

Nu spun ca e cea mai buna metoda, ci doar un mod de a realiza ceva. Acum daca stau sa ma gandesc as gasi metode chiar mai bune. As putea face backup-ul in felul urmator:

- schimb temporar zona de pe DC in standard primary

- fac backup

- schimb la loc in AD Integrated

Problema care o vad eu cu toate aceste metode, e cu permisiunile pe inregistrari. In momentul in care zona ajunge in AD, fiecare inregistrare de acolo reprezinta un obiect in AD cu ACL-uri la fel ca orice alt obiect. Daca ai apucat sa te folosesti de aceste ACL-uri (iar unele servicii se folosesc automat) atunci toate aceste proceduri iti vor sterge ACL-urile and it sucks!

Tocmai din cauza asta recomand ca restore-ul sa se faca via systemstate pe cat posibil.

Si ar mai fi si alte metode de a face backup/restore la zonele DNS. Dar … data viitoare.

Poate fi folosita ca si referinta pentru majoritatea seterilor din GPO.

Si merge adaugata ca si search provider in Internet Explorer.

Un must have pentru orice GPO admin.

Tineti minte ca poate fi rulat si intr-o infrastructura fara EBS. Singurul scenariu in care nu merge este atunci cand domeniul AD e la functional level Windows 2008R2 (dar probabil ca la urmatorul release o sa mearga).

Mai jos aveti cateva imagini cu tool-ul. Comentariile sunt de priosos.

De retinut ca userenv.log nu logheaza actiunile specifice GPP, insa poate fi folosit si acesta, deoarece GPP se aplica ca si parte a unui GPO.

Pentru a loga actiunile ce fac parte din aplicarea unui GPP e nevoie sa aplicam un GPO peste client care sa activeze tracing-ul peste o anumita componenta din GPO. De retinut ca se poate face tracing separat pentru fiecare componenta. Pot face tracing numai pentru Scheduled Tasks sau numai pentru Drive Mappings.

Toate aceste optiuni le gasim in GPO la rubrica Computer Configuration/Policies/Administrative Templates/System/Group Policy/Logging and Tracing.

In exemplul meu am activat tracing pentru Drive Mappings.

Ca sa functioneze si sa nu aveti probleme e bine sa specificati calea exacta catre locatia in care sa se salveze log-ul.

Dupa ce politica a fost aplicata pe client putem vedea cum arata log-ul pentru GPP-ul facut de test.

Dupa cum vedem GPP-ul nostru sa aplica OK.

2010-05-09 22:52:08.492 [pid=0x144,tid=0x6ec] EVENT : The user ‘X:’ preference item in the ‘GPP Test {D68144D1-8065-4D0D-9827-D869A6A5323F}’ Group Policy object applied successfully.
2010-05-09 22:52:08.492 [pid=0x144,tid=0x6ec] Completed class <Drive> – X:.
2010-05-09 22:52:08.492 [pid=0x144,tid=0x6ec] {935D1B74-9CB8-4e3c-9914-7DD559B7A417}
2010-05-09 22:52:08.492 [pid=0x144,tid=0x6ec] Starting class <Drive> – Y:.
2010-05-09 22:52:08.492 [pid=0x144,tid=0x6ec] Set user security context.
2010-05-09 22:52:08.523 [pid=0x144,tid=0x6ec] Set system security context.
2010-05-09 22:52:08.523 [pid=0x144,tid=0x6ec] Properties handled.
2010-05-09 22:52:08.523 [pid=0x144,tid=0x6ec] Handle Children.
2010-05-09 22:52:08.523 [pid=0x144,tid=0x6ec] EVENT : The user ‘Y:’ preference item in the ‘GPP Test {D68144D1-8065-4D0D-9827-D869A6A5323F}’ Group Policy object applied successfully.
2010-05-09 22:52:08.523 [pid=0x144,tid=0x6ec] Completed class <Drive> – Y:.
2010-05-09 22:52:08.523 [pid=0x144,tid=0x6ec] Completed class <Drives>.
2010-05-09 22:52:08.523 [pid=0x144,tid=0x6ec] Completed package execution.
2010-05-09 22:52:08.523 [pid=0x144,tid=0x6ec] Completed execution of apply package.

Pentru un incepator, informatiile din aceste fisiere pot fi foarte criptice, iar in unele cazuri chiar si un avansat o sa aiba probleme in a le citi – in cazul asta apelati la MS Support. Aceste loguri de diagnostic au fost gandite in special pentru cei din support.

Ce mai putem observa in fisierul de diagnostic, locul in care sunt stocate informatiile de despre mapped drives se afla in acelasi loc in care se afla GPO-ul, mai exact in cazul nostru in:

\\winadmin.local\SYSVOL\winadmin.local\Policies\{D68144D1-8065-4D0D-9827-D869A6A5323F}\User\Preferences\Drives

Fisierul se numeste drives.xml si arata cam asa:

In cazul unui client care nu primeste maparile verificati daca puteti sa accesati acest fisier. Atentie ca la drive mappings nu conteaza daca ai permisiune pe share sau nu, maparea trebuie sa se faca oricum.

Cam atat deocamdata, pentru ca nu am lucrat suficient incat sa ma lovesc de probleme majore cu GPP.

Despre gasiti aici:

http://technet.microsoft.com/en-us/library/cc738772(WS.10).aspx

Si download aici:

http://www.microsoft.com/downloads/details.aspx?familyid=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en

Parte din acest packet este si Acctinfo.dll care adauga un nou tab in AD Users and Computers destul de folositor pentru taskurile de administrare.

Problema e ca acest dll functioneaza numai pe Windows x86 si cum W2K8 R2 vine numai in versiune x64 nu o sa mai functioneze. Mai nou umbla pe net si versiunea Acctinfo2.dll care mai avea cateva optiuni in plus dar nu era suportata de MS.

Recent am gasit si versiunea x64 a lui Acctinfo2.dll care merge inclusiv pe W2K8 R2. O gasiti aici http://www.activedir.org/ACCTINFO2_64BIT.zip

Pentru prima versiune era nevoie doar sa inregistrezi dll-ul, acum e nevoie de mai multi pasi. Ii gasiti pe toti in documentul din arhiva.

Dupa ce faceti ce scrie acolo tab-ul din ADUC o sa arate cam asa:

Optiunea Most Recent Logon iti arata serverul care a autentificat ultima data acel cont.

Poti vedea si replication metadata pentru acel obiect fara a mai fi nevoie de repadmin.

Si pe baza lui lastlogon poti afla site-ul in care se afla utilizatorul si ii poti schimba parola chiar in acel site.

Nota: Acctinfo2.dll nu este suportat de MS. Nu numai ca nu e suportat, MS nu a publicat niciodata oficial acest dll. So use it on your own risk.

Spor!

Andrei.

In general servicedesk-ul primeste dreptul de a reseta parole pentru ca asta e unul din rolurile lor de baza (trist dar adevarat), nu si unlock, probabil pentru ca nu exista un atribut anume pentru a fi delegat.

In cazul asta sa explicam cum se face. Prima data trebuie sa avem un grup pentru utilizatorii din servicedesk (intotdeauna delegati folosind grupuri nu user accounts).

Vom efectua exercitiul folosind consola AD Users & Computers cu toate ca exista si alte metode ceva mai simple, insa nu pentru adminul incepator. Activam Advanced Features:

Ne ducem pe containerul peste care vrem sa delegam permisiunile:

Click pe Add:

Si de aici incepe delegarea permisiunilor:

Iar acum dam drepturi peste atributul lockoutTime:

Din acest moment membrii grupului Servicedesk vor avea dreptul sa faca unlock pe conturile aflate in OU-ul peste care am efectuat delegarea.

Simplu, nu? O sa revin si cu alte taskuri din categoria delegari.

Ce e interesant aici fata de publicarea unui task via script distribuit prin GPO, e ca GPP se ocupa automat de operatiunea de cleanup. Task-ul va rula, dupa care va fi sters de pe sistem. In cazul cu simplu GPO era nevoie de mai multi pasi, inlcusiv de un GPO pentru cleanup.

Exemple in care ar merge folosita aceasta optiune ar fi: vrei sa rulezi comenzi gen ipconfig /flushdns pe toate sistemele din retea, vrei sa restartezi un serviciu, sa stergi fisiere temporare, etc

http://support.microsoft.com/kb/944043

KB-ul descrie problemele care pot aparea atunci cand ai un RODC in retea si contine update-uri care trebuie instalate pe Windows 2003, XP si Vista.

Deci, de retinut: daca folosesti RODC e obligatoriu sa instalezi updateurile de mai sus pe clienti si chiar si pe domain controllerele care mai ruleaza Windows 2003 in domeniu.

Ca sa fiu clar acum: adaugarea rolului din consola roles nu este necesara. Nici pe 2008 si nici pe 2008R2. Comanda DCPROMO adauga rolul automat (din cauza asta o sa stea si putin mai mult pana sa prezinte wizardul).

Daca in acest moment dau Cancel, primesc urmatorul mesaj:

Cititi cu atentie ce scrie acolo. Rolul a fost instalat de DCPROMO (mai exact, au fost copiate binarele, si atat, configurarea se face mai departe cu dcpromo).

A fost doar un post explicativ ca sa elimin anumite semne de intrebare.

Sa vedem cum procedam. Deschidem ADAC ( Active Directory Administrative Center) din Administrative Tools :

Mergem la Global Search si, in partea dreapta, expandam Add criteria. Bifam “Users with enabled accounts who have not logged on for more than a given numbers of days” si dam click pe Add :

Acum putem selecta numar de zile :

Sa zicem 60 de zile. Dupa care dam un click pe Search si avem rezultatul. Acum, ii putem selecta si, cu click dreapta sau din partea dreapta a consolei ( Tasks ), ii putem dezactiva sau sterge din Active Directory :

Traducerea in LDAP a acestei cautari arata cam asa : cautam obiecte de tip user – persoana, enabled (vezi atributul UserAccountControl) inactive in perioada data curenta minus 60 zile, folosindu-ne de atributul lastLogonTimestamp. Valoarea acestuia din urma este updatata implicit la interval de 14 zile asa ca sfatul meu e sa nu folositi intervalul de 15 sau chiar 30 de zile pentru clean up, ca sa nu riscati sa stergeti conturi active. Convertirea valorii in format standard de timp este descrisa aici .

Cum putem cauta computerele inactive timp de 60 de zile? Editam query-ul, inlocuind valoarea “person” a atributului objectCategory cu “computer”. Click pe Apply si gasim si computerele inactive pe care, de asemenea, le putem dezactiva sau sterge:

Spuneam ca ADAC a aparut de la Windows Server 2008 R2. Consola poate fi folosita totusi si cu Active Directory 2003 si 2008. Vedeti aici conditiile. Sunt valabile si pentru ADAC.