Wydajność zapytań do katalogu Active Directory

W zasadzie trudno jest napisać dokładny przewodnik jak tworzyć wydajne zapytania do Active Directory, na wydajność takiego zapytania składa się wiele czynników. Można jednak pokusić się o zebranie kilku uwag na ten temat co i właśnie czynię.

fActive Directory jest oparte na katalogu LDAP, który to został stworzony w celu szybkiego i łatwego dostępu do zasobów usług katalogowych. Wszelkie operacje wyszukiwania, tworzenia, usuwania obiektów w katalogu sprowadzają się do wykonania odpowiednich operacji na katalogu. Z tych wszystkich operacji nawięcej wykonywanych jest różnego rodzaju operacji wyszukujących dane w katalogu. Operacje te przy źle zoptymalizowanych zapytaniach mogą stanowić duże obciążenie dla serwera katalogu Active Directory.

Jak możemy zdefiniować optymalne zapytanie?  Przyjmijmy że jest to takie zapytanie, w którym przetwarzana jest minimalna liczba wymaganych obiektów, a im więcej z nich odpowiada warunkom zapytania tym lepszej jakości jest nasz filtr. Oczywiście to nie zawsze jest idealne kryterium, ale zbliża nas do optymalnej wydajności, tworząc sytuację w której nie wykonujemy zapytań na wszytkich obiektach w domenie, tylko po to żeby znaleźć pojedynczy obiekt.

Zbudowanie optymalnych zapytań dla naszych potrzeb w aplikacjach lub skryptach może wymagać kilku prób z różnego rodzajami filtrów ale istnieje kilka podstawowych zasad których warto sie trzymać.

1. Wybór miejsca rozpoczęcia zapytania 

Każde z zapytań kierowanych do serwera LDAP ma zdefiniowane (w sposób jawny lub niejawny) trzy elementy:

  • search root: czyli miejsce poczÄ…tku wyszukiwania,
  • scope: czyli zakres w jakim zostanie przeprowadzona operacja wyszukiwania,
  • filtr: czyli kryteria wedÅ‚ug których zostanÄ… wybrane okreÅ›lone obiekty.

Dodatkowo dla zapytania określona może być również lista atrybutów obiektów, które zostaną zwrócone.

Często spotykanym przypadkiem w wielu aplikacjach korzystających z Active Directory jest rozpoczynanie zapytania w ścieżce głównej domeny, czyli ustawienie search root na DC=Domena,DC=PL. Efektem tego, przy odpowiednio ustawionym zakresie zapytania jest przeważnie przeszukanie wszystkich obiektów w ramach domeny. Na pierwszy rzut oka wydaje się to już nie być szczęśliwym rozwiązaniem, szczególnie w przypadku zapytań mających zwrócic niezbyt duża liczbę obiektów.

Tip: Starajmy się więc jeżeli jest to tylko możliwe doprecyzować miejsce rozpoczęcia wykonywania zapytania do określonych jednostek organizacyjnych lub framgentów katalogu, tak aby unikać przeszukiwania całości drzewa domeny, tylko po to aby znaleźć kilku użytkowników w jednym z OU.

2. Jak głęboko w katalogu będzie wykonane zapytanie 

Dla każdego zapytania LDAP możemy określić jeden z trzech zakresów:

  1. subtree: zapytanie zostanie wykonane rozpoczynając od miejsca określonego przez search base dla wszystkich obiektów znajdujących sie w tym miejscu katalogu i wszystkich obiektów potomnych w strukturze katalogu. W przypadku ustalenia miejsca rozpoczęcia wyszukiwania na określony kontener, przeszukane zostaną obiekty w tym kontenerze oraz we wszytskich kontenerach znajdujących się poniżej tego kontenera.
  2. one level: zapytanie zostanie wykonane dla obiektów tylko w tym miejscu struktury katalogu, które zostało określone. Jeżeli jako podstawa zapytania określone zostanie pojedyncze OU to operacja wykonana zostanie tylko na obiektach znajdujących się w tym OU.
  3. base: oznacza ze zapytanie wykonane zostanie tylko dla obiektu który został wskazany jako podstawa zapytania. Do czego jest to przydatne? W szczególności do tego aby uzyskać z katalogu dla wskazanego obiektu wartości atrybutów konstruowanych i w kilku podobnych przypadkach.

Jak widać określenie zakresu zapytania może mieć znaczący wpływ na liczbę przetwarzanych w zapytaniu obiektów, dlatego warto czasami pomysleć czy zamiast wskazania zakresu jako subtree nie warto w tym wypadku użyć chociażby one level.

Tip:  W przypadku zapytań z użyciem zakresu subtree zawsze starajmy się jak najbardziej przybliżyć podstawę wyszukiwania do lokalizacji obiektów, których poszukujemy. Jeżeli wiemy że w naszym katalogu obiekty użytkowników tworzone są w określonym OU to rozpocznijmy wyszukiwanie właśnie od tego OU, nie zaś od podstawy domeny. W przypadku zapytań kierowanych do obiektów w konkretnym kontenerze użyjmy zakresu one level zamiast subtree. Efekt będzie ten sam a unikniemy przeszukiwania struktury OU.

3. Używanie optymalnych, lub zbliżonych do optymalnych filtrów w zapytaniach 

Chyba najcześciej w naszych zapytaniach szukamy danych dotyczących kont użytkowników. Większość osób piszących skrypty w tym celu posługuję się filtrem LDAP:

(objectClass=user)

Filtr ten jest niezbyt poprawny z conajmniej dwóch powodów:

  • objectClass nie jest atrybutem indeksowanym, co znaczÄ…co pogarsza czas wyszukiwania obiektów.
  • w przypadku użycia atrybutu objectClass jako parametru wyszukiwaniw uwzglÄ™dniane sÄ… również wszystkie obiekty potomne tej klasy, czyli na przykÅ‚ad dla klasy user zwrócone zostanÄ… również obiekty komputerów (klasa computer jest klasÄ… potomnÄ… user).

O wiele lepszy w tym przypadku wydaje się być atrybut objectCategory który jest atrybutem indeksowanym, jednak wiele obiektów różnych klas może posiadać tą samą wartość objectCategory. Chociażby obiekty klasy user oraz contact są oba obiektami kategorii Person.

idealnym połączeniem w tym przypadku jest więc użycie połączenia atrybutów objectClass i objectCategory w ramach pojedynczego filtru:

(&(objectClass=user)(objectCategory=Person)).

Innym przykÅ‚adem filtru LDAP mocno obciążajÄ…cego katalog jest zapytanie z użyciem znaku maski ‘*’ znajdujÄ…cego siÄ™ na poczÄ…tku wyszukiwanego ciÄ…gu, czyli na przykÅ‚ad:

(&(objectClass=user)(objectCategory=Person)(samAccountName=*nowak)).

Wynika to z tego że serwer Active Directory nie jest w stanie korzystać ze standardowego mechanizmu indeksów w przypadku gdy znak maski znajduje się na początku wyszukiwanego ciągu znaków. W Windows 2003 wprowadzony został specjalny rodzaj indeksu (tuple) wspomagający tego rodzaju wyszukiwanie, ale nie wszystkie atrybuty z niego korzystają.

Kolejnym przykÅ‚adem zapytania, które może znaczÄ…co wpÅ‚ynąć na wydajność jest zapytanie z użyciem znaku negacji ‘!’. Powód jak powyżej – nie zawsze uda siÄ™ w przypadku tego typu zapytaÅ„ skorzystać z indeksów atrybutów, co wymusza drogie przeszukiwanie katalogu.

Temat konstruowania efektywnych filtrów LDAP możnaby ciągnąć dłużej i może uda mi się napisać osobny kawałek tesktu na blogu temu poświęcony. Te trzy elementy które wymieniłem są najczęściej spotykanymi błędami wpływającymi na wydajność zapytań, które udało mi się zauważyć wiele razy w różnego rodzaju skryptach i oprogramowaniu.

——————–

W zasadzie te trzy punkty pozwalają nam na kontrolowanie podstawowych elementów zapytania. W przypadku optymalizacji zapytań dodatkową rolę mogą odgrywać też takie elementy jak lista zwracanych atrybutów, typ atrybutów użytych w zapytaniach itp.

Active Directory posiada mechanizm pozwalający nam na łatwy dostęp do danych statystycznych dotyczących wykonywanych zapytań. W przypadku gdy chcemy testować dokładność i wydajność naszych zapytań warto się tymi mechanizmami posłużyć. Dostęp do nich możemy uzyskać na różne sposoby, na przykład testując nasze zapytania z użyciem narzędzia adfind i używając przełącznika -stat (i pokrewnych, polecam adfind -??? ).

Inny sposób pozwalający na przetestowanie naszych zapytań kierowanych do DC bezpośrednio ze skrytpu czy aplikacji to użycie klucza rejestru 15 Field Engineering utworzonego w gałęzi HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics. Klucz ten pozwala na logowanie w dzienniku zdarzeń dokładnych statystyk dotyczących zapytań LDAP kierowanych do kontrolera domeny. Klucz ten działa również dla instancji ADAM. Dokładny opis logowania i diagnozowania zapytań LDAP z użyciem tej metody można znaleźć na stronach ActiveDir.org. Jedną z użytecznych możliwości dostępnych w ramach tego mechanizmy jest możliwość zdefiniowania parametrów, przy których zapytanie uznawane jest za nieefektywne i zostanie zalogowane w dzienniku zdarzeń.

Jeżeli zainteresował Was ten klucz rejestru, to chociaż nie jest to bezpośrednio związane z tematem tego postu może warto zajrzeć do jednego z postów na blogu Jorge, w którym zebrał on wpisy rejestru związanie z diagnostyką i logowaniem.

Err.exe – przydaty przy bÅ‚Ä™dach

Jedno z bardziej użytecznych a mniej (chyba) znanych narzędzi diagnostycznych dla systemów Windows to Err.exe. Mam nadzieję że większość czytających ten post zna to narzędzie, jednak na wszelki wypadek gdyby ktoś do tej porty je przeoczył postanowiłem je tutaj opisać.

Opis narzÄ™dzia jest prost “error lookup tool”, i to oddaje dokÅ‚adnie istotÄ™ jego dziaÅ‚ania. NarzÄ™dzie to pozwala na wyszukanie w ramach nagłówków i tablic programów odpowiedniego opisu do podanego kodu bÅ‚Ä™dy.

Przykład:

C:\>err -1073741730
# for decimal -1073741730 / hex 0xc000005e
STATUS_NO_LOGON_SERVERS ntstatus.h
# There are currently no logon servers available to service
# the logon request.
# 1 matches found for “-1073741730”

Proste? A mówi wszystko o błędzie numer -1073741730.

O Err przypomniałem sobie dzisiaj diagnozując błąd w jednej z aplikacji, gdybym użył go od razu zaoszczędziłoby to trochę czasu. Postanowiłem więc zamieścić tę informacje na wypadek gdyby ktoś jeszcze nie zaprzyjaźnił sie z Err.exe.

LDP, LDAPEditor i inni …

Przy pracy z usÅ‚ugami katalogowymi czÄ™sto zachodzi potrzeba wyszukiwania, przeglÄ…dania i modyfikowania obiektów w katalogu. SÅ‚uży do tego wiele narzÄ™dzi – czasami te dostarczone z systemem nie sÄ… wystarczajÄ…co elastyczne i trzeba siÄ™gnąć po coÅ› dodatkowego. Do napisania tego posta w zasadzie skÅ‚oniÅ‚o mnie wskazanie przez kogoÅ› na grupie dyskusyjnej nie znanego mi wczeÅ›niej narzÄ™dzia (LDAPEditor) ale postanowiÅ‚em napisać nie tylko o nim ale ogólnie o kilku dostÄ™pnych rozwiÄ…zaniach.

Jeżeli operacja którą chcemy wykonać jest trudna do wykonania (lub też niemożliwa) w narzędziach typu AD Users & Computers to pozostaje nam sięgnięcie do narzędzi zewnętrznych.

Dla tych którzy nie boją sie linii poleceń zdecydowanie polecane są ADFIND i ADMOD napisane przez joe, jednego z lepiej orientujących się w dziedzinie katalogów Active Directory\ADAM człowieka udzielającego się na znanych mi forach i grupach. Funkcjonalność tych dwóch narzędzi pozwala w zasadzie na wykonanie dowolnej operacji w katalogu Active Directory\ADAM.

W ramach narzÄ™dzi graficznych dostÄ™pnych w systemie (Support Tools) mamy do dyspozycji ADSIEdit i LDP.EXE. ADSIEdit jest to konsola MMC pozwalajÄ…ca na przeglÄ…danie i edycjÄ™ obiektów katalogu. Niestety jest ona dosyć ograniczona w swoich możliwoÅ›ciach oraz posiada jednÄ… duża wadÄ™ – korzysta z wÅ‚asneg cache przez co niektóre zmiany (na przykÅ‚ad w schemacie) widoczne sÄ… z opóźnieniem.

Dla odmiany drugie z tych narzędzi LDP.EXE, o którym wieść gminna niesie że zostało stworzone trochę przez przypadek, to najbardziej uniwersalne narzędzie dostępne do zarządzania katalogiem AD w ramach systemu. LDP jest to po prostu graficzny klient LDAP dzięki czemu możemy przy jego pomocy wykonać dowolną operację jaką umożliwia katalog. Niestety korzystanie z niego wymaga pewnej znajomości katalogu i ogólnie LDAP i dla wielu osób prostota graficzna i sposób korzystania z LDP.EXE jest zbutynim utrudnieniem. Tych którzy korzystają z LDP.EXE zachęcam do korzystania z jego wersji zawartej w ADAM SP1 i Windows 2003 R2. Jest ona znacznie rozbudowana w stosunku do poprzedniej wersji, pozwala między innymi na edycję list ACL i SACL na obiektach katalogu oraz na przegląd metadanych replikacji obiektu.

PoÅ›rednim rozwiÄ…zaniem może być wiÄ™c LDAPEditor, o którym informacje znalazÅ‚em w ramach jednego z wÄ…tków na grupie dyskusyjnej. LDAPEditor jest również klientem LDAP tak jak LDP.EXE, ale jego autorzy zbudowali go bardziej jako edytor “wizualny” gdzie użytkownik widzi graficznÄ… reprezentacjÄ™ katalogu i obiektów, ma dostÄ™p do ich wÅ‚aÅ›ciwoÅ›ci i edycji atrybutów. NarzÄ™dzie to może być bardzo przydatne dla wszystkich dla których LDP.EXE jest za trudne, a używanie narzÄ™dzi linii poleceÅ„ jest maÅ‚o wygodne. W szczególnoÅ›ci może być on przydatny dla wszystkich administratorów serwerów opartych na ADAM, który to jeszcze nie dorobiÅ‚ siÄ™ wÅ‚asnego zestawu narzÄ™dzi innych niż ADSIEdit i LDP.EXE.

Warto tutaj zaznaczyć że zarówno LDP.EXE jak i LDAPEditor będą działać nie tylko przy współpracy z Active Directory ale również w przypadku połączenia do innych katalogów LDAP takich jak chociażby OpenLDAP czy eDirectory.

Z innych narzędzi graficznych służących do edycji danych w katalogu Active Directory warto również zaznaczyć istnienie ADModify .NET, które to narzędzie pozwala w prosty sposób dokonać modyfikacji zawartości atrybutów na wielu obiektach katalogu.

Jeżeli ktoś z czytelników posiada własne ulubione narzędzia do współpracy z katalogiem Active Directory lub ogólnie z usługami katalogowymi zachęcam do podzielenia się informacją o nich poprzez komentarze :).

Problemy z RSS

W chwili obecnej na W2K.PL mam małe problemy związane z działaniem feed RSS wynikające z zawirowań przy przejści na nowy engine blogu. Mam nadzieję że uda mi się z nimi szybko uporać i udostępnić RSS czytelnikom.

Do tego czasu pozostaje prosić mi Was o cierpliwość i nie uciekanie :). RSS bÄ™dzie 🙂

Prezentacje z MTS 2005

Jako że od czasu konferencji mineÅ‚o już kilka chwil (co prawda nie porozumiewszy siÄ™ z organizatorem 🙂 ) zamieszczam tutaj prezentacje Power Point z moich prezentacji z konferencji MTS 2005, która odbyÅ‚a siÄ™ we wrzeÅ›niu 2005. Sesje byÅ‚y dwie, to i prezentacje sÄ… dostÄ™pne w liczbie sztuk dwóch:

  • ADFS, w zaÅ‚ożniu ma wyjaÅ›nić podstawy technologii Active Directory Federation Services wprowadzonej w Windows 2003 R2. Jako że temat ten nie należy do najbardziej popularnych 🙂 (a szkoda), i najczęściej budzi wiele pytaÅ„ to z chÄ™cia odpowiem na takowe jeżeli zostanÄ… mi przesÅ‚ane poprzez e-mail (a może w koÅ„cu uruchomie komentarze),
  • RozwiÄ…zywanie problemów z Active Directory przedstawia kilka podstawowych problemów zwiÄ…zanych z usÅ‚ugami katalogowymi Active Directory i sposoby ich unikniecia\rozwiÄ…zania. Przedstawione sÄ… podstawowe problemy z usÅ‚ugÄ… DNS, replikacjÄ…, wystÄ…pieniem USN roll-back oraz odtworzeniem usÅ‚ug katalogowych.

Mam nadzieję, że informacje te będą przydatne, przykłady praktyczne w wersji nagranej niestety nie sa dostępne. A wszystkich zapraszam na MTS 2006, który zapewne się odbędzie. Nie wiem czy pojawię się tam w roli prelegenta\słuchacza ale i tak zachęcam żeby się na ta konferencję wybrać. Napewno będzie tam przynajmniej kilka ciekawych i dobrze poprowadzonych sesji.

Uaktualniona poprawka MS06-042 dla IE

Microsoft opublikował poprawioną poprawkę związaną z biuletynem bezpieczeństwa MS06-042. Oryginalna poprawka po zainstalowaniu w systemie powodowała problemy związane z dostępem do stron w przypadku przeglądarki IE 6 oraz potencjalne problemy związane z bezpieczeństwem w przypadku przeglądarki IE6 SP1.

Szczegółowe informacje oraz link do poprawki można znaleźć w artykue KB 918899:

Internet Explorer 6 Service Pack 1 unexpectedly exits after you install the 918899 update

Zmiany na blogu

Zmiany, zmiany, zmiany … miejmy nadziejÄ™ że na lepsze. Od jakiegoÅ› czasu nosiÅ‚em sie z tym zamiarem i w koÅ„cu nadszedÅ‚ czas na zmianÄ™ oprogramowania blogu. Zobaczymy czy WordPress okaże siÄ™ wygodniejszy niż nanobloger. W chwili obecnej wiÄ™kszość zasobów poprzedniego blogu zostaÅ‚a już przeniesiona do WordPress, niestety poprzednie linki bezpoÅ›rednie sÄ… już nieaktualne. Jeżeli ktoÅ› miaÅ‚ zakÅ‚adki do tych artykułów to niestety trzeba bÄ™dzie je uaktualnić.

Dzięki tej zmianie możliwe będzie zamieszczanie komentarzy do wiadomości co mam nadzieję będzie zmianą pozytywną jak tylko zainstaluje mechanizmy utrudniające umieszczanie w komentarzach spamu.

Zmianą mniej przyjemną jest zmiana adresu dla feed RSS z wiadomościami. Wszystkich czytelników którzy nadal chcieliby subskrybować wiadomości z W2K.PL poprzez RSS prosiłbym o zmianę adresu feed na http://www.w2k.pl/feed/ w konfiguracji czytników.

Cóż, pozostaje tylko z mojej strony zadbać o atrakcyjność zawartości :).

Inspekcja zdarzeń zmian zasad (Policy changes auditing)

Dzisiaj na WSS.pl pojawił się krótki w zasadzie wątek dotyczący inspekcji zmian zasad (audit policy changes) dostępnej w ramach zasad inspekcji systemów Windows 2000/XP/2003/Vista. Temat w zasadzie prosty a pytanie wzięło się tylko i wyłącznie z faktu, że autor tego wątku został zmylony przez nazwę ustawienia i próbował osiągnąć cel inny niż to ustawienie realizuje.

Pomimo tego że nazwa opcji sugerować może, że pozwala ona na śledzenie zmian w obiektach GPO opcja ta realizuje śledzenie zmian w zasadach zaaplikowanych w systemie w wyniku edycji któregoś z obiektów zasad obejmujących system.
Nie zostanie więc zarejestrowany fakt zmiany ustawień GPO a fakt zastosowania tych ustawień w ramach lokalnych ustawień systemu, objawiając się odpowiednim wpisem o powodzeniu lub porażce wprowadzenia tego ustawienia.
Domyślnie zasada dotycząca inspekcji zmian zasad włączona jest dla kontrolerów domeny w Windows 2003.

Jak więc można poddać inspekcji zmiany w ustawieniach GPO? Niestety odpowiedź na chwilę obecną jest taka że możliwość inspekcji zmian w GPO przy pomocy mechanizmów systemu jest cokolwiek ograniczona. Jedyny fakt o jakim możemy uzyskać informację zapisaną w Event log to fakty zmiany ustawień GPO przez użytkownika (zakończony powodzeniem lub porażką, w zależności którą kategorie zdarzeń poddajemy inspekcji). Wbrew temu co można by oczekiwać zdarzenie to zostanie zapisane pod kategorią Directory object Access, jako że zanotowany zostanie fakt dostępu do obiektu skojarzonego w GPO w katalogu Active Directory. I tak w przypadku powodzenia wykonania takiej zmiany, przy domyślnych ustawieniach systemu Windows 2003 w event log zapisane zostanie zdarzenie ID 566 zawierające następujące informacje:

Event Type:	Success Audit
Event Source:	Security
Event Category:	Directory Service Access
Event ID:	566
Date:		8/17/2006
Time:		9:12:19 PM
User:		W2K\Administrator
Computer:	ROOTDC
Description:
Object Operation:
Object Server:	DS
Operation Type:	Object Access
Object Type:	groupPolicyContainer
Object Name:
CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=w2k,DC=pl
Handle ID:	-
Primary User Name:	ROOTDC$
Primary Domain:	W2K
Primary Logon ID:	(0x0,0x3E7)
Client User Name:	Administrator
Client Domain:	W2K
Client Logon ID:	(0x0,0xBF136)
Accesses:	Write Property

Properties:
Write Property
Default property set
versionNumber
groupPolicyContainer

Additional Info:
Additional Info2:
Access Mask:	0x20

Zdarzenie to niesie ze sobą informację o tym, że określony użytkownik dokonał zmiany jednego z atrybutów tego obiektu . w tym przypadku zmiany informacji o numerze wersji GPO. Zmiana ta w zasadzie oznacza że GPO zostało poddane edycji przez określonego użytkownika. Niestety nie znajdziemy tutaj informacji, które z ustawień GPO zostały zmienione. Ponieważ, to co wszyscy określamy jako GPO składa się tak naprawdę z dwóch elementów:

  • obiektu w katalogu Active Directory
  • definicji ustawieÅ„ GPO zapisanych w pliku, w ramach wolumenu SYSVOL

inspekcji można poddać też pliki dotyczące odpowiednich GPO. W ten sposób możliwe będzie uzyskanie informacji o próbach edycji danych znajdujących się w tych plikach w inny sposób niż przez narzędzia dostarczane wraz z systemem. Inspekcja zdarzeń związanych z dostępem do tych plików nie różni się w żaden sposób od inspekcji zdarzeń na dwojonym innym pliku . wymaga uaktywnienia opcji inspekcji dostępu do obiektów i skonfigurowania ustawień inspekcji (SACL) na odpowiednich folderach.
W ten sposób jednak również nie uzyskamy informacji o tym co zostało zmienione w odpowiednich plikach. Pozostaje porównanie tych plików, w ich aktualnych wersjach z wersjami znajdującymi się w ramach kopii zapasowej lub z dokumentacją papierową. Przygotowanie tej ostatniej znacznie ułatwia zastosowanie GPMC, które to narzędzie pozwala na wygenerowanie raportu z ustawień GPO w formacie HTML. Rozwiązanie dalekie od ideału ale pozwala, przy zachowaniu pewnych procedur na udokumentowanie i śledzenie zmian wprowadzonych w GPO w kolejnych ich edycjach.

Inspekcję zmian w GPO taką jaką wszyscy chyba byśmy chcieli posiadać zapewniają na chwilę obecną tylko rozwiązania firm trzecich, takich jak chociażby (bezpłatna kryptoreklama) NetPro.

tombstoneLifetime a Windows 2003 R2

Obiekty usuwane w katalogu Active Directory przechowywane sa przez okreslony czas jako obiekty typu tombstone. Obiekt taki zawiera ograniczony zestaw atrybutow obiekt usunietego (zestaw ten moze byc rozszerzany w razie potrzeby poprzez ustawienieodpowiedniej wartosci atrybutu searchFlags). Ulatwia to znacznie ewentualne odtworzenia takiego, oraz pozwala mechanizmom katalogu Active Directory na usuniecie z katalogu ewentualnych odwolan do usunietego obiektu, przed jego fizycznym usunieciem z bazy katalogu. Przechowywanie usunietego obiektu w tej formie pozwala rowniezn na zrelikowanie infomracji o jego usunieciu do wszystkich kontrolerow domeny w rama domeny \ lasu. Czaszycia tych obiektow wyznacza rowniez praktyczny czas waznosci danych w kopii zapasowej katalogu Active Directory.

Obiekty typu tombstone przechowywane sa w katalogu przez czas okreslony wartoscia atrybutu tombstoneLifetime obiektu CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=,DC=. W przypadku gdy wartosc tego atrybutu nie jest podana, przyjmowany jest domyslny czas 60 dni. Jako ze domyslny czas 60 dni wprowadozny w Windows 2003 byl niewystarczajcy zostal on podniesiony do 180 dni w Windows 2003 SP1.

Wszystko wydaje sie byc wiec w porzdku, jednak w ramach dyskusji prowadzonej na grupach dyskusyjnych okazalo sie ze istenieje problem z Windows 2003 R2, ktory w okreslonym przypadku powoduje ze dla nowo tworzonego lasu Active Directory w oparciu o nosnik Windows 2003 R2 czas zycia obiektow tombstone wynosi 60 zamiast 180 dni. Problem ten wystepuje wtedy gdy promocja lasu odbywa sie na kontorlerze opartym o Windows 2003 SP1 z zainstalowanymi plikami z drugiego CD dystrybucji WIndows 2003 R2. Na skutek bledu w pliku inicjalizujacym schamat AD,wartosc atrybutu tombstoneLifetime nie jest ustawiana, co sprowadza sie do domyslnej wartosci 60 dni.

Rozwiazanie problemu jest proste, dowolnym narzedziem pozwalajacym na modyfikacje katalogu AD (ldp.exe, adsiedit.msc, admod.exe) nalezy wprowadzic odpowiednia wartosc atrybutu do katalogu.

Informacje o problemie podsumowujace dyskusje z grup dyskusyjnych mozna znalezc w blogu Joe i jorge. PS. Przepraszam za chwilowy brak PL znakow w tresci. Jak tylko rozwiaze sie maly problem z konfiguracja postaram sie je uzupelnic.