Cum modifici default user profile in Windows 7

 

Nu numai in 7 ci si in Vista si 2008. Totul a pornit de la acest KB unde este specificat procesul.

Nota: Pentru cei ce nu stiu, toate profilele noi facute pe un sistem pornesc de la default user profile (e un template).

Pana acum in 2K si XP pur si simplu copiam profilul userului in care faceam modificarile peste default user profile (cred ca si in examenele de certificare aveam astfel de intrebari). Incepand cu Windows Vista lucrurile s-au schimbat si copierea profilului trebuie facuta in procesul de SYSPREP.

KB-ul mentionat mai sus spune ceva, insa exact cum se face, cum arata fisierul ala unattended sau ce mai mai trebuie sa contina, nu exista in articol. Cautarile pe net sunt si ele nefolositoare. Atunci hai sa vedem cum se face.

 

Procedura e urmatoarea: rulezi sysprep cu fisier de unattend in care ii specifici sa copieze profilul userului administrator peste default user profile. Doar ca acel fisier unattend are un format anume, nu merge sa pui doar parametrul, iar exemple clare pe net nu sunt. De ce? Pentru ca trebuie sa-l faci cu WAIK (Windows Automated Installation Kit). E micut, 1.7Gb 🙂 Asta doar ca sa generezi un fisier de raspuns XML. Mai simplu de atat nu cred ca puteau sa faca 🙂

Din WAIK folosim Windows System Image Manager pentru a creea fisierul de raspuns. O sa aveam nevoie de discul cu Windows pentru a putea construi fisierul de raspuns, unde va trebui sa adaugam un pachet in sectiunea Specialize. Asta pentru a creea rubrica Specialize in fisier. Optiunea de CopyProfile nu e disponibila in GUI (de ce nu ma mira). O vom adauga de mana dupa ce avem fisierul facut si o sa arate cam asa:

<?xml version="1.0" encoding="utf-8"?>
<unattend xmlns="urn:schemas-microsoft-com:unattend">
    <settings pass="specialize">
        <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="x86" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
             <CopyProfile>true</CopyProfile>
        </component>
    </settings>
    <cpi:offlineImage cpi:source="catalog:d:/sources/install_windows 7 ultimate.clg" xmlns:cpi="urn:schemas-microsoft-com:cpi" />
</unattend>

 

Dupa ce avem fisierul va trebui sa customizam profilul de la care pornim. Eu am folosit userul Administrator (nu stiu daca merge si cu alt user). Pentru a folosi userul administrator e nevoie sa-l activati din Local Security Policy (gpedit.msc).

Odata logati pe userul Administrator, incepem sa customizam profilul, si ne pregatim sa rulam SYSPREP:

Se poate vedea ca tema e alta decat cea default si am pus si cateva ceva pe desktop. Systemul va rula sysprep, va reboota, si va trece prin etapa de Specialize. La final, dupa minisetup, desktopul o sa arate asa cum am vrut:

 

 

Si cam toate astea doar ca sa inlocuiesti CopyProfile din XP. Ouch!

Group Policy Security Filtering (I)

 

In ciuda numelui, Group Policy nu se aplica grupurilor ci utilizatorilor si calculatoarelor in functie de containerul (OU), domeniul sau site-ul in care se afla. Si totusi cum putem controla aplicarea Group Policy in functie de un grup de securitate? Raspunsul este prin intermediul “security filtering”.

Obiectele de tip Group Policy au, ca orice alt obiect din Active Directory, un set de liste de control al accesului (ACL) care determina permisiunile. Prin intermediul acestor ACLs putem filtra accesul pentru anumite grupuri sau conturi de utilizator/computer. Care sunt ACL-urile implicite ale unui GPO?

Deschideti consola Group Policy Management:

 

Click pe politica dorita in partea stanga a ferestrei de browsing si selectati tab-ul Delegation:

Pentru o afisare mai familiara a permisiunilor click pe butonul Advanced:

Pentru ca un GPO sa se aplice unui cont de utilizator/computer trebuie ca acest cont, sau grupul din care face parte, sa aiba cel putin permisiunea “Allow” pentru “Read” si “Apply group policy”. Aceasta inseamna ca implicit pentru toti membrii grupului “Authenticated Users” se va aplica politica respectiva. Membrii acestui grup sunt toate conturile de utilizator sau computer care au fost autentificate de catre un Domain Controller. Desi membrii “Domain Admins” nu au permisiunea “Allow” “Apply group policy”, politica li se va aplica prin intermediul apartenentei implicite la grupul “Authenticated Users”.

In cazul in care doriti sa aplicati o politica noua pentru toti utilizatorii din domeniu, dar sa nu si pentru administratorii de domeniu (Domain Admins) aveti doua variante la dispozitie:

1. Scoateti grupul “Authenticated Users” din lista si folositi in locul lui un grup specific.

Atentie! In cazul folosirii grupului “Domain Users” contul “Administrator” nu va fi exceptat de la aplicarea politicii pentru ca face parte si din acest grup.

2. Pentru grupul “Domain Admins” activati permisiunea “Deny” “Apply Group Policy”.

 

In partea a doua a articolului va voi prezenta un scenariu mai complex de filtrare a Group Policy.

Cum sa configurezi un Shared Mailbox pentru Exchange Server

Deseori apar situații când intr-o organizație se dorește ca mesajele de poștă electronică trimise pe o adresă de email specifică să fie recepționate de mai multe persoane odată. De exemplu, poate fi cazul echipei de helpdesk, a unui departament sau chiar toate persoanele din organizație. Primul lucru ce-ți vine in gând este configurarea unei liste de distribuție. Întradevăr, o listă de distribuție îți permite să transmiți pentru mai multe persoane deodată un mesaj de e-mail adresându-i pe o singură adresa de poștă electronică. Totul e bine, dar cum facem când dorim un replay sau un new mail message din numele acestei căsuțe de e-mail ? Răspunsul e că nu putem. Listele de distribuție funcționează doar intr-o singura direcție. Putem transmite un e-mail spre o lista de distribuție dar nu si din partea ei. Orice membru din listă poate răspunde doar din numele propriu nu și a grupului, ori această funcție poate fi utilă uneori. Să luăm exemplul echipei de helpdesk ce are un email de grup helpdesk@contoso.com. Orice soluție la tichetele de helpdesk inițiate prin e-mail trebuie însoțite prin-un mesaj de confirmare prin poșta electronică, este normal ca mesajul respectiv să fie transmis din numele serviciului de helpdesk și nu de la un e-mail personal. Pentru aşa cazuri liste de distribuţie nu mai sunt bune. Se pare că cel mai logic ar fi configurarea pe clientul de poştă pentru fiecare membru din grup a câte două căsuţe de e-mail: una personală şi una comună. Aparent, acest lucru pare a fi imposibil – nu putem configura mai mult de un singur cont de Exchange pe clientul de poştă Outlook. Nu şi dacă se foloşte Shared Mailbox. Shared Mailbox îţi oferă posibilitatea să configurezi pe un singur Outlook câte căsuţe de e-mail Exchange doreşti. Ce este interesant, orice modificare (mesaje noi, ştergerea mesajelor, schimbarea statutului sau a categoriei ș.a.m.d.) in conţinutul căsuţei partajate se sincronizează automat peste tot unde este configurată. Dacă in exemplul de mai sus unul din membrii echipei de suport citeşte un mesaj venit de pe adresa de helpdesk@contoso.com şi face un replay la acesta, atunci mişcarea se reflectă automat pentru restul echipei de suport.

Aşadar, să presupunem că avem mai multe căsuţe personale – dintre care una este pentru utilizatorul jdoe@contoso.com şi un mailbox comun helpdesk@contoso.com. Pentru a configura adresa de helpdesk ca mailbox adiţional vom realiza următoarele:

Pe serverul Microsoft Exchange:

1. Deschidem consola Active Directory Users and Computers, în meniul View selectăm Advanced Feathures.
2. Deschidem Properties pentru obiectul legat de mailbox-ul partajat care cazul nostru este user-ul helpdesk@contoso.com
   1. În tab-ul Exchange Advanced, click pe Mailbox Rights … (View and modify permissions to access this mailbox). În fereastrea Permissions adăugăm toţi utilizatorii ce vor partajeze acest mailbox. Pentru fiecare user bifăm Read Permissions şi Full Mailbox Access în coloana Allow.

   

   1. În tab-ul Security adăugăm din nou lista de utlizatori ce vor partaja căsuţa de e-mail. Pentru fiecare user in Permission for bifăm Send As Allow.

Pe clientul de poştă Microsoft Office Oulook:

1. Deschidem Properties pentru mailbox-ul personal. In tab-ul General deschidem Advanced. În fereastra Microsoft Exchange > Advanced facem click pe Add (Open this additional mailboxes) după care formăm numele casuţei poştale partajate: helpdesk@contoso.com. Click Ok pentru a inchide ferestrele.

În momentul următor in Outlook Mail Folders trebuie să apară şi mailboxul comun:

Windows Server Update Services (WSUS) 3.0 SP2 – Configuring. Part 2

După ce am instalat WSUS 3.0 cu SP2, acesta trebuie configurat.

Ca să deschidem wizard-ul de configurare, în consola WSUS selectăm Options și facem click pe ultima opțiune de jos – WSUS Server Configuration Wizard.

În prima fereastră a wizard-ului, alegem Next.

În a doua, fiecare alege ce vrea. Eu personal, într-un mediu de test, aleg Yes la astfel de întrebări.

La Choose Upstream Server, o să aleg Synchronize from Microsoft Update pentru că este primul server de WSUS din organizația mea.

Dacă aș fi avut mai multe servere de WSUS în diferite locații, poate aș fi ales a doua opțiune. Dar și asta depinde. În principiu, am observat că firmele cu mai multe servere de WSUS aleg Upstream Server-ul în funcție de banda pe care o au la internet din acea locație și/sau banda pe care o au cu sediul central.

Mai sunt unele companii care preferă să aibă mai multe servere dar să le facă management dintr-o singură locație. Asta pentru a se evita angajarea/trainingul unui angajat cu cunoștințe de WSUS. Și aici ne vine în ajutor bifa ”This is a replica of the upstream server”.

Dacă ieșirea la internet se face printr-un proxy, atunci se bifează Use a proxy server when synchronizing și se introduce numele sau IP-ul proxy-ului existent. Dacă se folosește și autentificarea la acel proxy, atunci se bifează și Use user credentials to connect to the proxy server și se introduc datele de identificare respective.

Cum eu nu folosesc proxy, o să apăs Next.

În pagina următoare vom face și prima sincronizare cu serverul Microsoft folosind setările făcute până acum. Tot acum se va interoga serverul despre produsele existente, clasificarea și limba în care sunt disponibile acestea. Trebuie reținut faptul că la această sincronizare nu se download-ează nici un update, se afișează doar lista cu update-urile existente pe Microsoft Update sau WSUS-ul celor de la Microsoft 🙂

Deci click Start Connecting.

Am revenit după 15 minute, atât a durat la mine sincronizarea. Am dat Next și am ajuns la pagina în care trebuie să aleg în ce limbă vreau să download-ez update-urile. Este recomandat să debifăm opțiunea ”Download updates in all languages, including new languages”. Această opțiune trebuie lăsată doar dacă aveți o infrastructură foarte-foarte mare, cu sisteme de operare și/sau aplicații în toate limbile enumerate mai jos. Țineți cont și de faptul că cu cât mai multe limbi alegeți, cu atât mai mult spațiu de stocare pe server veți avea nevoie.

Eu o să aleg opțiunea Download updates only in these languages și o să bifez English.

În pagina următoare alegem produsele (aplicații sau sisteme de operare) pentru care vrem să scoatem actualizările. Pentru acest articol, o să selectez doar Windows Server 2008.

Alegem tipul actualizărilor pentru produsele selectate anterior. În funcție de necesitățile fiecărei companii, se pot selecta toate sau doar unele clasificări. Eu o să merg pe setările implicite.

Alegem cum vrem să se facă sincronizarea – să o facem manual, când vrem noi, sau automat de câteva ori pe zi. De notat faptul că dacă alegem de exemplu metoda autmată și specificăm două sincronizări pe zi, prima sincronizare poate începe la maxim 30 minute după ora specificată.

Eu o să selectez Synchronize manually.

Am ajuns aproape la final. Specificăm dacă dorim să facem prima sincronizre în care se vor download-a doar metadata despre produsele și clasificările specificate anterior. Această sincronizare durează în funcție de câte produse și clasificări am selectat. Ultima dată când am configurat WSUS la un client, am selectat aproximativ jumatate din produse și clasificări și sincronizarea a durat 4 ore… 🙂

Pe ultima pagină nu mai selectăm nimic, sunt doar câteva link-uri cu ce ar mai trebui citit despre WSUS în acest moment.

Facem click pe butonul Finish pentru a închide wizard-ul și a începe prima sincronizare (aceasta începe în background, pentru a vedea cum decurge sincronizarea, trebuie selectată opțiunea Synchronizations din meniul din stânga).

Acum, că am ales doar un produs, sincronizarea a durat câteva zeci de minute. Putem vedea mai jos timpul când s-a făcut prima sincronizare (când am configurat upstream serverul și adresa de proxy) și a doua (după ce am terminat de configurat).

Observăm că prima dată nu s-a download-at informație despre nici un update, pe când la al doilea, avem info despre 275 update-uri pentru Windows Server 2008 și clasificările pe care le-am ales.

Cam atât despre configurarea inițială. Următorul articol vreau să-l scriu despre cum se crează foldere cu update-uri specifice unui anumit produs sau clasificări și despre grupuri de computere.

Timp de access prea mare la biblioteci SharePoint din Windows 7

Mi-am pus de ceva timp pe desktopul meu un Windows 7 release canditate. Totul a inceput bine si chiar nu am avut dificultati sa trec pe el, dupa un timp insa, am observat ca sunt unele probleme atunci cind interactionezi cu bibliotecile de documente pe site-uri SharePoint. In primul rand orice operatiune de open/save in biblioteci dureaza neordinar de mult timp (pe XP imi lua citeva clipe sa deschid un document pe cind aici poate sa ajunga si peste 10 sec) si doi, foarte rar reusesti sa deschizi fara erori o fereastra Windows Explorer (WebDav) la un Document Library si chiar daca se primeste oricum operatiunile de copy/paste dureaza prea mult timp. Dupa un googling pe net am gasit o solutie care pe mine ma ajutat, asa ca daca aveti probleme cu viteza da acces la biblioteci pe SharePoint pe Windows 7 puteti incerca umatoarele: In Internet Explorer > Tools > Intenet Options > Connections > LAN Setting scoatem bifa de pe Auttomaticaly Detect Settings.

Sa fiu sincer, nu stiu exact ce rost are acesta optiune, adevarul e ca functioneaza si pana acum nu ma incurcat cu nimic.

Despre WINSXS pe romaneste.

 

Citeam pe ITBoard despre o dilema legata de folderul WINSXS care pare sa ocupe enorm de mult spatiu. Am vazut acolo si un link catre o explicatie a continutului acestui folder si am remarcat ca multa lume nu a inteles mare lucru. Poate si pentru ca adevarul din articol e undeva la mijloc.

Ca sa puteti intelege de ce acest folder “pare” atat de mare e esential sa cautati cate ceva pe net despre hardlinks si eventual diferente intre hardlinks si symbolic links (ca sa puteti intelege principiul).

Am spus ca adevarul e undeva la mijloc pentru ca da, reprezinta un component store si aici gasim toate componentele OS-ului, inclusiv versiunile vechi, insa … le mai gasim si in alta parte in folderul Windows. Uite sa luam cazul unei componente – msasn1.dll. Prima data am putea sa remarcam ca avem mai multe versiuni in funtie de platforma si daca fisierul a primit un update sau nu. Dar gasim aceeasi versiune (ultima de regula) si in WINSXS si in SYSTEM32. Hmm .. deci e duplicat? Dupa ce ca foderul asta ocupa atat de mult spatiu, mai am fisierele astea si in alta parte? Nu chiar. Sunt HARDLINK-uri. Adica datele sunt intr-un singur loc pe disk cu mai multe referinte catre ele.

 

Inca un exemplu ar fi o versiune mai veche a aceleiasi componente, care nu are decat o referinta, cea din WINSXS:

Acum considerand ca o parte din cei ce au ajuns sa citeasca ce scriu aici stiu ce inseamna hardlinks sau au avut curiozitatea sa citeasca (hint: google) ajungem la o alta intrebare: cat ocupa de fapt acest folder? Sau mai interesant ar fi sa intreb cat ocupa folderul Windows, pentru ca multe din fisiere sunt de fapt referinte catre acelasi set de date si nu duplicate. Tricky, nu?

 

Pentru cei care nu au rabdare sa citeasca despre hardlinks uite si poze pentru toate lumea: http://www.wellho.net/mouth/334_Symbolic-links-and-hard-links.html

Setarea mediului de test/dev virtual pentru soluţii Sharepoint

Aşa cum o parte din articolele ce urmează vor fi legate de soluţii şi servere Sharepoint, o să am nevoie de un mediu integru pentru testări. La drept vorbind dispun de unul ca ăsta la serviciu, însă nu aş dori in nici un fel sa compromit cumva securitatea de acolo prin a publica mai stiu eu ce date confidenţiale. Aşa că cea mai bună soluţie ar fi să-mi construiesc un mediu “from scratch”, complet separat de mediul de testare şi producţie de la serviciu. Componentele mediului de testare le voi realiza pe maşini virtuale VMWare găzduite pe un server Dell PowerEdge 2950. Softul de virtualizare utilizat este un produs VMWare distribuit gratuit: VMWare Server 2.

Pentru simplitate am separat articolul pe mai multe parţi după cum urmează:
Part 1. Setarea mediului virtual şi instalarea sistemului de operare.
Part 2. Instalare şi configurare serviciu directoriu Active Directory şi serviciu DNS.
Part 3. Instalare şi configurare server bază de date.
Part 4. Instalare şi configurare Windows Sharepoint Services 3.0

Primele trei părţi pregătesc sistemul de operare, serviciile de reţea şi backend-ul pentru ca in ultima parte să fie instalata platforma Sharepoint propriu zisă. Pentru cei ce au deja configurat un sistem de testare cu servicii directoriu şi bază de date pot sări direct pe ultima parte, integrindule pe acestea cu Sharepoint-ul. In principiu partea a treia ar putea să şi lipsească dacă va decideţi să utilizaţi o baza de date interna (SSEE) pentru backend(printr-o instalare basic standalone). In acest caz veţi obţine o arhitectură sigle tier, in care toate serviciile atât de frontend cât şi de backend vor rula pe un singur server. În cele ce urmează totuşi, voi realiză o instalare cu o bază de date Microsoft SQL full, separată pe un alt server (Domain Controller).

Aşadar, voi construi mediul de testare pe două servere virtuale. Primul va rula servicii de reţea (DNS, AD) şi baza de date iar pe al doilea IIS cu aplicaţia de Sharepoint.

Înainte de a începe procesul de instalare ar fi util să vă descărcaţi din timp softul de evaluare pentru proiect. Puteţi parcurge următoarele referinţe pentru a vă descărca totul de ce aveți nevoie:

1. Microsoft Windows Server 2008 r2 Evaluation (180 days)
2. Microsoft SQL Server 2008 Trial Software Evaluation Edition x64
3. SQL Server 2008 Service Pack 1
4. Windows Sharepoint Services 3.0 with sp2 x64
5. Microsoft Office Sharepoint Designer 2007

În continuare, voi descrie in amănunt fazele de pregătire a serverelor virtuale și instalarea sistemului de operare Windows Server 2008 pe acestea.

Din seria Group Policy Tattooing

 

Tattooing??? What is that?

Termenul e cunoscut pentru cei ce citesc gpoguy.com; eu il stiu tot de acolo ca nu stiam cum sa denumesc “fenomenul”. Sa incep sa explic: ai policy aplicat peste un user sau computer, trebuie sa-l stergi, il stergi, dar setarile raman in continuare.

Cum asa? Pai probabil ca acele registry settings aplicate prin GPO nu se incadreaza in zonele din registry care sunt sterse cand policy-ul se modifica. Ceva detalii despre asta gasiti pe GPOGUY.

Azi m-am intalnit din nou cu fenomenul asta, insa fiind patit de multe ori am testat inainte si bine am facut. Exista setari chiar si in Administrative Templates care sufera de problema asta (in scenariul meu foloseam W2K3 si XP pe client):

Deci, simpla stergere sau dezactivare a policy-ului nu o sa-mi scoata setarile de proxy din IE de pe statii. E nevoie sa las policy-ul aplicat si sa fac Uncheck la optiunea “Enable proxy settings”.

Concluzia: testati de fiecare data setarile aplicate prin GPO; si la add si la remove.

Cum “patch-uiesti” un sistem offline?

 

Updates, WSUS, System center, nu prea sunt domeniul meu si nici nu m-au atras pana acum; de fapt poate asta e si motivul pentru care caut alternative. Nu sunt chiar alternative, ci solutii pentru cazuri mai speciale. Cum ar fi cazul din titlu.

Sa luam cazul unui sistem pus in DMZ care nu are acces la WSUS si nici nu poate iesi in afara retelei pe HTTP. Greu, nu? Pe vremuri MS mai scotea cate un roll-up ca sa le aduci la zi insa acum baza e Windows Update.

Sau alt caz care mi-a venit acuma in minte. Am doua PC-uri acasa, de ce trebuie sa downloadez update-urile de pe amandoua. Nu ar fi mai frumos sa le downloadez de pe unul singur si dupaia sa le copiez si pe celalalt sistem si sa le instalez? Cei care dorm cu icoana lui Bill sub perna probabil ca mi-ar spune sa imi pun Home Server acasa + WSUS sau proxy care sa-mi cache-uiasca updateurile. Nu e cazul.

In ajutorul nostru vine un tool care sta de mult pe net, dar neobservat de multi, C’T Offline Update. Stiu, site-ul e in germana, dar tool-ul are interfata in limba engleza.

 

 

 

Pe scurt: iti downloadeaza update-urile pe local (le poti instala de cate ori vrei), sau mai are optiunea sa iti faca ISO – il pui direct pe CD si te duci la sistemul unde ai nevoie de updateuri. Se poate vedea ca stie pana la Vista/W2K8 si chiar si Office.

 

Pe sistemul destinatie, e suficient sa rulezi un script si patch-urile se instaleaza automat.

Si uite ca mi-a mai venit un scenariu in minte: sistem virusat care a fost deconectat de la retea. Il devirusezi si trebuie sa-l updatezi. Daca il conectezi din nou la retea risti sa il infectezi din nou (daca ii activezi Windows Firewall poate mai ai o sansa).

 

Later edit: Un prieten a avut probleme in a compila ISO-ul. Am descoperit ca e nevoie sa downloadezi tool-urile de aici http://smithii.com/files/cdrtools-2.01-bootcd.ru-w32.zip si sa le pui in folderul BIN (mai exact e nevoie de mkisofs.exe).

Cautand acum pe net am vazut ca mai exista o alternativa, pe care nu am testat-o, numita Autopatcher. Cool …

Protecting AD – Tombstone objects

 

In articolul precedent am vazut cum putem recupera anumite date care au fost sterse accidental din Active Directory, folosind informatiile dintr-un snapshot. Insa ce facem daca trebuie sa recuperam un obiect intreg (user account). Il putem recreea bineinteles, insa dupa cum stim nu o sa fie acelasi obiect deoarece va avea alt SID (Security Identifier).

Manualul spune ca in acest caz ar trebui sa apelam la un backup – insa un restore din backup inseamna ca trebuie sa restartam un domain controller (de 2 ori) plus ca dureaza ceva toata operatiunea.

Hai sa vedem acum la ce se refera termenul din titlu – Tombstoned objects. Pai tine de un anumit mecanism pe baza caruia functioneaza procesul de replicare si stergere a obiectelor in AD. In clipa in care stergem un obiect, sa spunem un user, obiectul nu este sters, ci atributul isDeleted este setat pe True iar obiectul este mutat intr-un container special numit Deleted Objects. In afara de asta, anumite atribute ale obiectului sunt sterse (fara posibilitatea de a fi recuperate). In aceasta clipa obiectul este invizibil pentru administrator, insa nu si pentru mecanismul de replicare, care il va replica si pe restul domain controller-elor pentru a se asigura ca este sters si pe celelalte servere.

Timpul in care obiectul ramane in aceasta stare poate varia – 60 de zile in forest-urile promovate de la Windows 2000 sau 180 de zile pentru cele care au inceput cu Windows 2003 SP1 (bineinteles ca poate fi modificat). Fiecare DC din domeniu scaneaza aceste inregistrari la un interval de 12 ore si le sterge pe cele care sunt mai vechi decat intervalul specificat.

Nota: Informatiile din articol se refera la modul de functionare al forest-urilor Active Directory care ruleaza in modul Windows 2000 pana la Windows 2008. Incepand cu R2 lucrurile se schimba (exista Recycle Bin).

Acum ca am inteles la ce se refera termenul de tombstoned objects, hai sa vedem si cum putem reanima aceste obiecte. In multe cazuri e mai simplu sa le reanimam decat sa le readucem din backup.

O varianta ar fi cu LDP (il gasiti in support tools) – sincer mi se pare cam peste mana; gasiti pe net cum se face.
Alta varianta ar fi sa o faceti programatic din C++, C#, VB – setand atributul isDeleted pe false si mutand obiectul in containerul de unde a fost sters (ne folosim de atributul lastKnownParent). Pe vremea cand nu existau tool-uri GUI pentru asa ceva tin minte ca imi facusem propriul utilitar care imi cauta aceste obiecte si imi dadea posibilitatea sa le recuperez.

Dar acum exista tool-uri suficiente pentru a uita cele doua variante descrise mai sus. Un exemplu foarte bun este ADRestore.Net care mi-a functionat si pe W2K3 si pe W2K8 (inclusiv versiunea x64).

 

 

 

Un alt tool cunoscut dar numai command line ar fi cel de la Sysinternals pe care il gasiti aici.

Si mai sunt multe, inclusiv PowerPack-urile de la PowerGUI insa atentie ca au ceva dependinte in spate (cmdlet-uri third party) si am avut si supriza sa nu imi ruleze pe W2K8 x64; pe 2003 nu am avut nici o problema.

 

Sa revenim putin si sa ne aducem aminte ce am spus la inceputul articolului: anumite atribute ale obiectului sunt sterse (fara posibilitatea de a fi recuperate). Dupa “recuperare” o sa avem acelasi obiect (acelsi SID) insa multe din informatiile asociate cu acest obiect s-au evaporat. Le puteam adauga manual folosind informatii dintr-un snapshot (vezi AD Explorer).

In majoritatea cazurilor folosim aceasta metoda pentru a recupera obiecte de tip user account. In cazul unui user sters si recuperat prin aceasta metoda, problema apare atunci cand observam ca userul nu mai face parte din nici un grup. Asta pentru ca dupa cum am spus mai sus – unele atribute sunt sterse fara posibilitatea de a fi recuperate. La fel, ne folosim de AD Explorer pentru a vedea group membership-ul user-ului ca sa il adaugam in grupurile din care a facut parte inainte.

 

PS: Backup is still Backup. Don’t forget about it.