Blog Home  Home Feed your aggregator (RSS 2.0)  
LDAP://Yusufs.Directory.Blog/ - Thursday, September 21, 2006
Wieviele Sprachen sprechen Sie? Ich spreche bloß eine: LDAP!
 
 Thursday, September 21, 2006

Das man mit dem Active Directory-Assistenten DCPROMO einen Server zum Domänencontroller promoten (Heraufstufen)
sowie demoten (Herabstufen) kann, dürfte allen bekannt sein.

Was aber, wenn während dem Herabstufen eines DCs ein Fehler auftaucht bzw. der DC keine Verbindung zur Domäne hat?

Dann könnte man dennoch das Herunterstufen des DCs über Dcpromo /Forceremoval erzwingen.
Mit diesem Befehl werden die AD-Daten lokal vom DC entfernt. Die Einträge im AD bleiben aber weiterhin bestehen.
Siehe auch: Die Metadaten des Active Directory unter Windows Server 2008 bereinigen



Klappt es damit auch nicht, gibt es noch einen anderen Weg wie man das Active Directory lokal von einem DC entfernen kann.

Man navigiert in der Registry des DCs (Start - Ausführen - Regedit) zu dem folgendem Pfad und ändert den Wert im Schlüssel ProductType:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions\"ProductType"="LanmanNT" zu "ServerNT"

Danach muss der Server neu gestartet werden. Alles weitere wird in diesem Artikel erläutert:
Domain controllers do not demote gracefully when you use the Active Directory Installation Wizard to force demotion in Windows Server 2003 and in Windows 2000 Server


Egal auf welcher diesen beiden Wege der DC heruntergestuft wird, als letzten Punkt gilt es
die DC-Informationen händisch mit NTDSUTIL oder ADSIEdit aus dem Active Directory zu entfernen:

Die Metadaten des Active Directory unter Windows Server 2008 bereinigen

Falls dieser DC der FSMO-Rolleninhaber war, müssen diese auf einen anderen DC übertragen werden:
Die FSMO-Rollen verschieben

Des Weiteren muss sichergestellt sein, dass die Funktion des globalen Katalogs sowie die Namensauflösung (DNS) weiterhin
in der Domäne bzw. Gesamtstruktur verfügbar ist.

Eins sei noch angemerkt: Wenn DCPROMO /Forceremoval nicht ordnungsgemäß funktioniert,
dann ist einiges mehr im argen und ich würde den Server neu installieren.

Thursday, September 21, 2006 8:09:31 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory  | 
 Tuesday, September 19, 2006

Möchte man die Protokollierung auf einem DC was das Active Directory (AD) betrifft erhöhen, so kann man dies in der Registrierung (Registry) des DCs einstellen.
Denn standardmäßig werden kritische Ereignisse und Fehlerereignisse im Verzeichnisdienstprotokoll des DCs protokolliert.
Durch die entsprechende Bearbeitung der Registry auf dem DC kann die Protokollierungsstufe des AD erhöht werden, um auch andere Ereignisse zu protokollieren.

Der Registry-Schlüssel mit dem man das Protokollverhalten beeinflussen kann ist:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

 

Hier können für einzelne Bereiche die Protokollierung angepasst (erhöht) werden, über die detaillierter protokolliert werden soll.
Die Protokollierung wird aber nur auf dem DC erhöht, auf dem die entsprechende Registryänderung durchgeführt wurde!
Diese Einstellung wird auch nicht auf andere DCs repliziert.

 

Es stehen folgende Ereignistypen ab Windows 2000 zur Verfügung:

 

1 Knowledge Consistency Checker (KCC)

2 Security Events

3 ExDS Interface Events

4 MAPI Interface Events

5 Replication Events

6 Garbage Collection

7 Internal Configuration

8 Directory Access

9 Internal Processing

10 Performance Counters

11 Initialization/Termination

12 Service Control

13 Name Resolution

14 Backup

15 Field Engineering

16 LDAP Interface Events

17 Setup

18 Global Catalog

19 Inter-site Messaging

 

Ab Windows Server 2003 stehen zusätzlich noch diese Ereignistypen zur Verfügung:

 

20 Group Caching

21 Linked-Value Replication

22 DS RPC Client

23 DS RPC Server

24 DS Schema

 

Jeder dieser Ereignistypen, stellt ein REG_DWORD-Wert dar und haben alle als eingestellten Wert „0“ eingetragen.

Durch die Erhöhung dieses Wertes, kann die Protokollierung detaillierter stattfinden, aber Vorsicht, zu viele Einstellungen (z.B. man aktiviert auf allen Typen den höchsten Wert), kann den DC Performancetechnisch in die Knie zwingen. Daher sollte die vorgenommene Einstellung auch wieder rückgängig gemacht werden, wenn es nicht mehr benötigt wird.

 

Es stehen sechs Stufen (0-5) zur Verfügung:

 

0 (None) = In dieser Stufe werden ausschließliche kritische Fehler protokolliert. Dies ist die Standardeinstellung für alle Ereignistypen, die nur geändert werden sollte wenn Probleme bestehen.

 

1 (Minimal) = Bei dieser minimalen Einstellung werden auch die etwas weniger kritischen Ereignisse protokolliert. Wenn man nicht weiß wo genau das Problem besteht, sollte mit dieser Einstellung das Troubleshooting begonnen werden.

Alleine in dieser Stufe werden bereits deutlich mehr Ereignisse in der Ereignisanzeige verzeichnet, daher sollte genauestens überprüft werden, ob diese Stufe für die Problemsuche ausreicht bevor man „erhöht“.

 

2 (Basic) = Diese Stufe erhöht die Protokollierung noch etwas. Falls Stufe 1 nicht ausreicht, sollte - ganz nach dem Motto „Schritt für Schritt“ - diese Stufe angewendet werden.

 

3 (Extensive) = In dieser Stufe werden alle Schritte der einzelnen Aufgaben im Active Directory detailliert protokolliert. Hier wird schon sehr viel protokolliert, im Gegensatz zu den Stufen 0 bis 2. Ab der Stufe 3 wird auch der Server durch die starke Protokollierung extrem belastet, daher sollten leistungsfähige Maschinen zur Verfügung stehen. Die Stufen 0-2 reichen für die Fehlerbehebung im Active Directory normalerweise aus.

 

4 (Verbose) = Bei dieser Stufe wird der Protokollierungsgrad noch weiter erhöht als die Stufe 3. Allerdings ist die Steigerung der Protokollierung nicht so hoch, als bei der Erhöhung von der Stufe 2 zu 3.

 

5 (Internal) = Das ist die höchste Stufe die man einstellen kann. In dieser Stufe werden alle Informationen in das Ereignisprotokoll geschrieben, die das Active Directory protokollieren kann. Diese Stufe sollte nur für wenige Ereignistypen gleichzeitig eingestellt werden, denn ansonsten wird es sehr schnell unübersichtlich in der Ereignisanzeige. 

 

 

Es können noch bei weiteren Diensten eine höhere Protokollierung aktiviert werden, z.B. für:

NTFRS Diagnostic Logging

HKLM\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters

Mit dieser Einstellung, wird ein  Debug Log im Verzeichnis: „%windir%\debug\NtFrs_0000n.log“ erstellt (ebenfalls mit den Stufen 0-5).

Debug Maximum Log Messages

Debug Log Files

 

Falls es Probleme mit Benutzerkonten bzw. Anmeldungen kommen sollte, so kann man die Netlogon Protokollierung aktivieren:
How to enable user environment debug logging in retail builds of Windows 

Enabling debug logging for the Net Logon service


Mit dem Tool NLPARSE kann man sich die Auswertung der Netlogon-Protokolldatei erleichtern:

Account Lockout and Management Tools

 

 

Die beiden Tools DCDIAG und NetDIAG aus den Windows Support Tools (die sich auf der Windows Server 2003 CD im Ordner Support befindet),
sind bei der Fehlersuche ebenfalls behilflich.

 

„DCDIAG /v“ und „NetDIAG /v“ sollten zur Diagnose herangezogen werden.

Für die Auswertung des DCDIAGs, hatte ich hier einen Artikel geschrieben:

Domänencontroller mit DCDIAG prüfen

 

 

 

 

Für weitere Log-Möglichkeiten siehe diese Links:
How to configure Active Directory diagnostic event logging in Windows Server 2003 and in Windows 2000 Server

How to enable folder redirection logging to gather verbose troubleshooting information in Windows 2000

Troubleshooting SCECLI 1202 Events

How to configure Active Directory diagnostic event logging in Windows Server 2003 and in Windows 2000 Server

Fixing Group Policy problems by using log files

Enable Logging for Group Policy Management Console

Enabling Logging for Group Policy Editor

Enable Logging for Group Policy Editor Client Side Extensions

 

Tuesday, September 19, 2006 7:26:00 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory | Administration  | 
 Sunday, September 17, 2006

Oft möchte man wissen, an welchem Client ein bestimmter User angemeldet ist.

 

 

 

Sunday, September 17, 2006 8:10:50 PM (W. Europe Standard Time, UTC+01:00)  #      Windows Server  | 

Auf NT/2000/2003 Mitgliedsservern/Standaloneserver sowie NT/2000/XP Clients ist es möglich, den Systemen mehrere NetBIOS-Namen zu vergeben.

 

Das funktioniert nicht auf Domänencontrollern sowie auf NT-Printservern !

 


Durch folgenden Registry-Key, kann man einem Server mehrere Alias-Namen vergeben.
Dazu trägt man jeden zusätzlichen NetBIOS-Namen in einer eigenen Zeile in den „MULTI_SZ-Variable“-Wert ein:


Key: HKEY_Local_Machine\System\CurrentControlSet\Services\LanmanServer\Parameters

Name: "OptionalNames"

Typ: REG_MULTI_SZ

 

 

Desweiteren sollte das „StrictNameChecking“ deaktiviert werden. Das funktioniert aber erst mit Windows 2000 ab Service Pack 3 sowie mit Windows Server 2003.
Mit diesem (gesetzten) Schlüssel wird dem Serverdienst (SMB) ermöglicht, dass er eine Verbindung, die nicht mit seinem echten Computernamen versucht wird, zulässt:

 

Key: HKEY_Local_Machine\System\CurrentControlSet\Services\LanmanServer\Parameters

Name: "DisableStrictNameChecking"

Typ: REG_DWORD

Wert: 1

 

Normalerweise wird das nicht unterstützt:

http://support.microsoft.com/kb/254210/en-us

Damit der Serverdienst dieses unterstützt, setzt man den „DisableStrictNameChecking“-Schlüssel: http://support.microsoft.com/kb/281308/en-us

 

Nach der Registry-Änderung muss der Serverdienst beendet und neu gestartet werden, mit (in der Kommandozeile des Server`s) „net stop server && net start server“.

Danach (oder nach einem Reboot) werden die eingetragenen Alias-Namen „auch“ dynamisch in der WINS-Datenbank als „03h [Nachrichtendienst]“ eingetragen.
Die beiden fehlenden Einträge 00h [Arbeitsstationsnamen] und 20h [Serverdienst] sind noch statisch hinzuzufügen.

 

Ab Windows Server 2003 ist es auch möglich, einem Server mehrere DNS-Namen per Registry-Schlüssel zu geben.
Diese werden als A-Resource Records (A-RR) im DNS registriert. Dadurch bleiben einem die CNAME-Einträge im DNS erspart
(wer die CNAME-Einträge bevorzugt, kann diese natürlich setzen).

 

Die DNS-Alias-Namen werden in einer REG_MULTI_SZ-Variable mit dem Namen "AlternateComputerNames" gespeichert:

 

Key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Dnscache\Parameters

Name: "AlternateComputerNames"

Typ: REG_MULTI_SZ

 

Dazu muss der jeweilige DNS-Name als FQDN <Clientname.DNS-Domänenname> in einer Zeile eingegeben werden.
Die Änderung wird mit einem „ipconfig /registerdns“ (oder Serverneustart) wirksam.

 

 

Möchte man lokal auf dem Server selbst auch auf eine Freigabe per UNC zugreifen, erhält man nach Eingabe von \\AlterComputername\Freigabe eine Anmeldeaufforderung.
Das liegt am Authentifizierungsprotokoll "Kerberos". Damit das nicht passiert, müssen noch zwei SPNs (Service Principal Name) erstellt werden.
Dazu müssen zuerst unter Windows 2000 und Windows Server 2003 die "Windows Support Tools" installiert werden. Ab Windows Server 2008 ist das Tool SETSPN bereits "on Bord".

Wenn der Computername des Dateiservers "Fileserver01.Domäne.DE" und der CNAME "Alias.Domäne.de" lautet, gilt es die folgenden beiden Befehle in der Kommandozeile einzugeben:

 

Setspn -a HOST/CNAME Fileserver01

 

und

 

Setspn -a HOST/CNAME.Domäne.de Fileserver01



Wenn anschließend der Ticketcache geleert oder der Server neu gestartet wird, erscheint danach keine Anmeldeaufforderung mehr.

 

Sunday, September 17, 2006 12:28:16 PM (W. Europe Standard Time, UTC+01:00)  #      Networking  | 
 Saturday, September 16, 2006

Wenn ein AD-Standort umbenannt wird, passiert im Hintergrund folgendes:

  1. Die Standortnamensänderung wird in der Gesamtstruktur repliziert
  2. Wenn die Standortnamensänderung auf einen lokalen Domänencontroller repliziert wurde, kontrolliert der Anmeldedienst (Netlogon) seine "subnet-to-site" - Zuordnungstabelle. Anschließend informiert der Anmeldedient "Netlogon" die Clients über den neuen Standortnamen.
  3. Der DNS-Server schreibt die neuen Domänencontroller-Records in die Zone (mit geändertem Site-Namen). Diese Informationen werden dann auch auf die DNS-Server repliziert, basierend auf der DNS oder AD Replikation.
  4. Der Netlogon-Dienst auf den Domänencontrollern, registriert die neuen Standort-spezifischen Domänencontroller "SRV-Records" auf ihrem autoritativen DNS-Servern, sprich die SRV Records werden neu gesetzt.
  5. Die Clients bekommen diesen neuen Standortnamen vom Domänencontroller mitgeteilt. Der Client bzw. Resolver, nutzt dann diesen neuen Standortnamen um DNS Abfragen nach einem Domänencontroller zu stellen.
  6. Davon betroffen ist auch das DFS, dass seinen Cache alle 12 Std. aktualisiert, dieser aber erst zuverlässig nach 24 Std. funktioniert.

Wichtig ist, dass nach dem umbenennen eines Standortes der Anmeldedienst "Netlogon" neu gestartet werden muss (net stop netlogon && net start netlogon). Man kann natürlich auch den DC neu starten.

 

 

Weitere Informationen:
Gründe für das Einrichten eines Einzelstandortes oder separater Standorte

You may experience problems when you rename sites in the Active Directory forest

Saturday, September 16, 2006 12:18:44 PM (W. Europe Standard Time, UTC+01:00)  #      Active Directory  | 
Copyright © 2012 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme: