Aktualizace komponent adresářových služeb

Autor: Justin Turner, starší inženýr eskalace podpory ve skupině Windows

Note

Tento obsah napsal technik zákaznické podpory Microsoftu a je určený zkušeným správcům a architektům systémů, kteří hledají hlubší technické vysvětlení funkcí a řešení ve Windows Serveru 2012 R2 než témata na TechNetu obvykle poskytují. Neprošel však stejnými úpravami, takže jazyk může působit méně propracovaně než to, co se běžně nachází na TechNetu.

Tato lekce vysvětluje aktualizace součástí adresářové služby ve Windows Serveru 2012 R2.

Co se naučíte

Vysvětlete následující aktualizace součástí adresářové služby:

• Vysvětlete následující aktualizace součástí adresářové služby:

  • Úrovně funkčnosti domény a lesů

  • Vyřazení NTFRS

  • Změny optimalizátoru dotazů LDAP

  • Vylepšení událostí 1644

  • Vylepšení propustnosti replikace služby Active Directory

Úrovně funkčnosti domény a adresářové struktury

Overview

Tato část obsahuje stručné představení změn na úrovni funkčnosti domény a úrovni funkčnosti lesa.

Nový DFL a FFL

S vydáním jsou nové úrovně funkčnosti domény a lesu.

• Úroveň funkčnosti doménové struktury: Windows Server 2012 R2

• Úroveň funkčnosti domény: Windows Server 2012 R2

Úroveň funkčnosti domény windows Serveru 2012 R2 umožňuje podporu následujících možností:

1. Ochrana na straně stejnosměrného proudu pro chráněné uživatele

   Chránění uživatelé se už nemohou ověřovat v doméně Windows Serveru 2012 R2:

   • Ověřte se pomocí NTLM autentizace

   • Použití šifrovacích sad DES nebo RC4 v předběžném ověření protokolu Kerberos

   • Delegujte s neomezeným nebo omezeným delegováním

   • Prodloužení platnosti lístků uživatelů (TGT) nad rámec počáteční 4hodinové životnosti

2. Zásady ověřování

   Nové zásady služby Active Directory založené na doménové struktuře, které se dají použít u účtů v doménách Windows Serveru 2012 R2 k řízení, ze kterých hostitelů se účet může přihlásit, a použít podmínky řízení přístupu pro ověřování u služeb spuštěných jako účet

3. Sila zásad ověřování

   Nový objekt Active Directory založený na lesní struktuře, který může vytvořit vztah mezi uživatelskými účty, spravovanými službami a účty počítače, které lze použít ke klasifikaci účtů pro zásady ověřování nebo k izolaci ověřování.

Další informace najdete v tématu Konfigurace chráněných účtů.

Kromě výše uvedených funkcí zajišťuje úroveň funkčnosti domény Windows Serveru 2012 R2, že na jakémkoli řadiči domény běží Windows Server 2012 R2. Úroveň funkčnosti doménové struktury Windows Server 2012 R2 neposkytuje žádné nové funkce, ale zajišťuje, že každá nová doména vytvořená v doménové struktuře bude automaticky fungovat na úrovni funkčnosti domény Windows Server 2012 R2.

Povinné nastavení minimální úrovně DFL při vytváření nové domény

Windows Server 2008 DFL je minimální funkční úroveň podporovaná při vytváření nové domény.

Note

Vyřazení služby FRS se provádí odebráním možnosti instalace nové domény s nižší úrovní funkčnosti domény než Windows Server 2008 se Správcem serveru nebo Windows PowerShellem.

Snížení funkční úrovně lesa a domény

Úrovně funkčnosti lesů a domén jsou ve výchozím nastavení nastaveny na Windows Server 2012 R2 při vytváření nové domény a nové doménové struktury, ale lze je snížit pomocí Windows PowerShellu.

Pokud chcete zvýšit nebo snížit úroveň funkčnosti lesa pomocí Windows PowerShell, použijte rutinu Set-ADForestMode.

Nastavení contoso.com FFL na režim Windows Server 2008:

Set-ADForestMode -ForestMode Windows2008Forest -Identity contoso.com

Pokud chcete zvýšit nebo snížit úroveň funkčnosti domény pomocí Windows PowerShellu, použijte rutinu Set-ADDomainMode.

Nastavení contoso.com DFL na režim Windows Server 2008:

Set-ADDomainMode -DomainMode Windows2008Domain -Identity contoso.com

Povýšení řadiče domény se systémem Windows Server 2012 R2 jako další repliky do stávající domény se systémem 2003 DFL funguje.

Vytvoření nové domény v existujícím lesu

ADPREP

V této verzi nejsou žádné nové operace lesních nebo doménových struktur.

Tyto soubory .ldf obsahují změny schématu pro službu registrace zařízení.

1. Sch59

2. Sch61

3. Sch62

4. Sch63

5. Sch64

6. Sch65

7. Sch67

Pracovní složky:

1. Sch66

MSODS:

1. Sch60

Zásady ověřování a izolované systémy

1. Sch68

2. Sch69

Zastaralost NTFRS

Overview

Služba FRS je ve Windows Serveru 2012 R2 zastaralá. Vyřazení služby FRS se provádí vynucením minimální úrovně funkčnosti domény (DFL) systému Windows Server 2008. Toto vynucování je k dispozici pouze v případě, že se nová doména vytvoří pomocí Správce serveru nebo Windows PowerShellu.

K určení úrovně funkčnosti domény použijete parametr -DomainMode s rutinami Install-ADDSForest nebo Install-ADDSDomain. Podporované hodnoty pro tento parametr mohou být platné celé číslo nebo odpovídající hodnota výčtu řetězce. Pokud chcete například nastavit úroveň režimu domény na Windows Server 2008 R2, můžete zadat hodnotu 4 nebo Win2008R2. Při provádění těchto cmdletů ze serveru 2012 R2 zahrnují platné hodnoty tyto pro Windows Server 2008 (3, Win2008), Windows Server 2008 R2 (4, Win2008R2), Windows Server 2012 (5, Win2012) a Windows Server 2012 R2 (6, Win2012R2). Úroveň funkčnosti domény nemůže být nižší než úroveň funkčnosti doménové struktury, ale může být vyšší. Vzhledem k tomu, že služba FRS je v této verzi zastaralá, windows Server 2003 (2, Win2003) není rozpoznaným parametrem s těmito rutinami při spuštění z Windows Serveru 2012 R2.

Změny optimalizátoru dotazů LDAP

Overview

Algoritmus optimalizátoru dotazů LDAP byl znovu vyhodnocen a dále optimalizován. Výsledkem je zlepšení výkonu při efektivitě vyhledávání LDAP a čase hledání LDAP složitých dotazů.

Note

Od vývojáře:vylepšení výkonu hledání prostřednictvím vylepšení mapování z dotazu LDAP na dotaz ESE. Filtry LDAP nad rámec určité úrovně složitosti brání optimalizovanýmu výběru indexu, což vede k výrazně nižšímu výkonu (1000x nebo více). Tato změna mění způsob, jakým vybíráme indexy pro dotazy LDAP, aby se zabránilo tomuto problému.

Note

Kompletní opravy algoritmu optimalizátoru dotazů LDAP, což vede k:

• Rychlejší hledání
• Zvýšení efektivity umožňuje řadičům domény dělat více
• Méně volání podpory týkající se problémů s výkonem AD
• Zpětně portováno do Windows Server 2008 R2 (KB 2862304)

Background

Schopnost hledat ve službě Active Directory je základní služba poskytovaná řadiči domény. Další služby a obchodní aplikace spoléhají na vyhledávání ve službě Active Directory. Obchodní operace se můžou přestat zastavit, pokud tato funkce není dostupná. Jako klíčová a intenzivně využívaná služba je nezbytné, aby řadiče domény efektivně zpracovávaly vyhledávací provoz LDAP. Algoritmus optimalizátoru dotazů LDAP se snaží co nejefektivněji vyhledávat pomocí mapování vyhledávacích filtrů LDAP na sadu výsledků, která může být splněna prostřednictvím záznamů, které jsou již indexovány v databázi. Tento algoritmus byl znovu vyhodnocen a dále optimalizován. Výsledkem je zlepšení výkonu při efektivitě vyhledávání LDAP a čase hledání LDAP složitých dotazů.

Podrobnosti o změně

Vyhledávání LDAP obsahuje:

• Umístění (hlava NC, organizační jednotka, objekt) v hierarchii pro zahájení hledání

• Filtr hledání

• Seznam atributů, které se mají vrátit

Proces hledání lze shrnout takto:

1. Pokud je to možné, zjednodušte vyhledávací filtr.

2. Vyberte sadu indexových klíčů, která vrátí nejmenší pokrytou sadu.

3. Proveďte jeden nebo více průniků indexových klíčů, abyste snížili rozsah pokrytí množiny.

4. Pro každý záznam v pokryté sadě vyhodnoťte výraz filtru a také bezpečnostní opatření. Pokud se filtr vyhodnotí jako PRAVDA a je udělen přístup, vraťte tento záznam klientovi.

Optimalizace dotazů LDAP upraví kroky 2 a 3, aby se snížila velikost zahrnuté sady. Konkrétně aktuální implementace vybere duplicitní indexové klíče a provádí zbytečné průniky.

Porovnání starých a nových algoritmů

Cílem neefektivního vyhledávání LDAP v tomto příkladu je řadič domény s Windows Serverem 2012. Hledání se dokončí přibližně za 44 sekund, protože se nepodaří najít efektivnější index.

adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=justintu@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfind.txt

Using server: WINSRV-DC1.blue.contoso.com:389

<removed search results>

Statistics
=====
Elapsed Time: 44640 (ms)
Returned 324 entries of 553896 visited - (0.06%)

Used Filter:
 ( |  ( &  ( |  (cn=justintu)  (postalCode=80304)  (userPrincipalName=justintu@blue.contoso.com) )  ( |  (objectClass=person)  (cn=justintu) ) )  ( &  (cn=justintu)  (objectClass=person) ) )

Used Indices:
 DNT_index:516615:N

Pages Referenced          : 4619650
Pages Read From Disk      : 973
Pages Pre-read From Disk  : 180898
Pages Dirtied             : 0
Pages Re-Dirtied          : 0
Log Records Generated     : 0
Log Record Bytes Generated: 0

Ukázkové výsledky pomocí nového algoritmu

Tento příklad opakuje přesně stejné vyhledávání jako výše, ale cílí na řadič domény s Windows Serverem 2012 R2. Stejné vyhledávání se dokončí za méně než sekundu z důvodu vylepšení algoritmu optimalizace dotazů LDAP.

adfind -b dc=blue,dc=contoso,dc=com -f "(| (& (|(cn=justintu) (postalcode=80304) (userprincipalname=dhunt@blue.contoso.com)) (|(objectclass=person) (cn=justintu)) ) (&(cn=justintu)(objectclass=person)))" -stats >>adfindBLUE.txt

Using server: winblueDC1.blue.contoso.com:389

.<removed search results>

Statistics
=====
Elapsed Time: 672 (ms)
Returned 324 entries of 648 visited - (50.00%)

Used Filter:
 ( |  ( &  ( |  (cn=justintu)  (postalCode=80304)  (userPrincipalName=justintu@blue.contoso.com) )  ( |  (objectClass=person)  (cn=justintu) ) )  ( &  (cn=justintu)  (objectClass=person) ) )

Used Indices:
 idx_userPrincipalName:648:N
 idx_postalCode:323:N
 idx_cn:1:N

Pages Referenced          : 15350
Pages Read From Disk      : 176
Pages Pre-read From Disk  : 2
Pages Dirtied             : 0
Pages Re-Dirtied          : 0
Log Records Generated     : 0
Log Record Bytes Generated: 0

• Pokud strom nejde optimalizovat:

  • Příklad: Výraz ve stromu byl nad sloupcem, který není indexován.

  • Záznam seznamu indexů, které brání optimalizaci

  • Exponováno prostřednictvím ETW trasování a ID události 1644

    

Povolit ovládání statistik v protokolu LDP

1. Otevřete LDP.exe, připojte se a synchronizujte se s řadičem domény.

2. V nabídce Možnosti vyberte Ovládací prvky.

3. V dialogovém okně Ovládací prvky rozbalte Načtení předdefinovaných, vyberte Hledat statistiky a pak zvolte OK.

   

4. V nabídce Procházet vyberte Hledat.

5. V dialogovém okně Hledat vyberte tlačítko Možnosti .

6. Ujistěte se, že je v dialogovém okně Možnosti hledání zaškrtnuté políčko Rozšířené a zaškrtněte políčko OK.

   

Zkuste toto: Použití protokolu LDP k vrácení statistik dotazů

Na řadiči domény nebo z klienta nebo serveru připojeného k doméně, který má nainstalované nástroje služby AD DS, proveďte následující akce. Opakujte následující kroky cílené na DC s Windows Serverem 2012 a Windows Serverem 2012 R2.

1. Projděte si článek "Vytváření efektivnějších aplikací s podporou Microsoft AD" a podle potřeby se k němu vraťte.

2. Pomocí protokolu LDP povolte statistiky vyhledávání (viz Povolení ovládacího prvku Statistiky v protokolu LDP)

3. Proveďte několik vyhledávání protokolu LDAP a sledujte statistické informace v horní části výsledků. Stejné hledání zopakujete i v jiných aktivitách, abyste je zdokumentovali v textovém souboru poznámkového bloku.

4. Proveďte vyhledávání PROTOKOLU LDAP, které by optimalizátor dotazů měl být schopen optimalizovat z důvodu indexů atributů.

5. Pokuste se vytvořit vyhledávání, které trvá dlouhou dobu k dokončení (můžete zvážit zvýšení možnosti časového limitu, aby se vyhledávání nezastavilo předčasně).

Další zdroje

Co jsou vyhledávání ve službě Active Directory?

Jak funguje vyhledávání ve službě Active Directory

Vytváření efektivnějších aplikací Microsoft Active Directory-Enabled

951581 dotazy LDAP se v adresářové službě AD nebo LDS/ADAM spouští pomaleji, než se čekalo, a id události 1644 se může protokolovat.

Vylepšení událostí z roku 1644

Overview

Tato aktualizace přidá do ID události 1644 další statistiky výsledků hledání LDAP, které vám pomůžou při řešení potíží. Kromě toho existuje nová hodnota registru, kterou lze použít ke spuštění protokolování na základě časového prahu. Tato vylepšení byla zpřístupněna v systémech Windows Server 2012 a Windows Server 2008 R2 SP1 prostřednictvím KB 2800945 a budou zpřístupněna pro Windows Server 2008 SP2.

Note

• Do ID události 1644 se přidají další statistiky vyhledávání LDAP, které pomáhají řešit neefektivní nebo nákladné vyhledávání LDAP.
• Nyní můžete zadat prahovou hodnotu času vyhledávání (např. událost protokolu 1644 pro vyhledávání trvající déle než 100 ms) místo zadání hodnot prahu nákladných a neefektivních výsledků vyhledávání.

Background

Při řešení potíží s výkonem služby Active Directory se zjeví, že aktivita vyhledávání LDAP může k problému přispívat. Rozhodnete se povolit protokolování, abyste viděli nákladné nebo neefektivní dotazy LDAP zpracovávané řadičem domény. Pokud chcete protokolování povolit, musíte nastavit hodnotu diagnostiky polního inženýrství a volitelně můžete zadat prahové hodnoty výsledků hledání pro nákladné nebo neefektivní scénáře. Po povolení úrovně protokolování Field Engineering na hodnotu 5 se všechna vyhledávání splňující tato kritéria protokolují do protokolu událostí adresářových služeb s ID události 1644.

Událost obsahuje:

• IP adresa a port klienta

• Počáteční uzel

• Filter

• Obor hledání

• Výběr atributu

• Ovládací prvky serveru

• Navštívené položky

• Vrácené položky

V události chybí klíčová data, jako je například délka času stráveného hledáním a jaký (pokud se nějaký použil) index.

Další statistiky vyhledávání přidané do události 1644

• Použité indexy

• Odkazované stránky

• Čtení stránek z disku

• Předběžné přečtené stránky z disku

• Vyčištění upravených stránek

• Změněné špinavé stránky

• Doba hledání

• Atributy bránící optimalizaci

Nová prahová hodnota registru založená na čase pro protokolování události 1644

Místo zadání hodnot prahových hodnot nákladných a neefektivních výsledků hledání můžete zadat prahovou hodnotu času hledání. Pokud chcete protokolovat všechny výsledky hledání, které trvaly 50 ms nebo déle, zadáte 50 v desetinném / 32 v šestnáctkovém formátu (kromě nastavení hodnoty Field Engineering).

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"Search Time Threshold (msecs)"=dword:00000032

Porovnání staré a nové události s ID 1644

OLD

NEW

Zkuste toto: Použití protokolu událostí k vrácení statistik dotazů

1. Opakujte následující kroky cílené na DC s Windows Serverem 2012 a Windows Serverem 2012 R2. Po každém hledání sledujte ID události 1644 na obou řadičích domény.

2. Pomocí regedit povolte protokolování s ID události 1644 pomocí prahové hodnoty založené na čase na řadiči domény s Windows Serverem 2012 R2 a starou metodou na řadiči domény s Windows Serverem 2012.

3. Proveďte několik hledání LDAP, která překračují prahovou hodnotu, a sledujte statistické informace v horní části výsledků. Použijte dotazy LDAP, které jste zdokumentovali dříve, a opakujte stejné vyhledávání.

4. Proveďte vyhledávání LDAP, které optimalizátor dotazů nedokáže optimalizovat, protože jeden nebo více atributů není indexováno.

Vylepšení propustnosti replikace služby Active Directory

Overview

Replikace AD používá pro přenos replikace RPC. Ve výchozím nastavení RPC používá vyrovnávací paměť 8K a velikost paketu 5K. To má čistý účinek, kdy odesílající instance bude přenášet tři pakety (přibližně 15 tisíc dat) a pak musí počkat na odezvu sítě před odesláním více. Za předpokladu 3ms doby odezvy by nejvyšší propustnost byla přibližně 40 Mb/s, a to i při využití sítí o kapacitě 1 Gb/s nebo 10 Gb/s.

Note

• Tato aktualizace upraví maximální propustnost replikace AD z 40 Mb/s na přibližně 600 Mb/s.

  • Zvyšuje velikost vyrovnávací paměti pro odesílání RPC, což snižuje počet síťových cyklů.

• Účinek bude nejvýraznější na vysokorychlostní síti s vysokou latencí.

Tyto aktualizace zvyšují maximální propustnost na přibližně 600 Mb/s změnou velikosti vyrovnávací paměti rpc pro odesílání z 8 KB na 256 kB. Tato změna umožňuje zvětšit velikost okna TCP nad rámec 8 tisíc a snížit počet síťových odezv.

Note

K úpravě tohoto chování neexistují žádná konfigurovatelná nastavení.

Další zdroje

Jak funguje model replikace služby Active Directory