im Zuge einer AD-Aktualisierung auf 2008 R2 möchte ich alle alten DCs (vor W2K8R2) an allen Standorten entfernen...
Ich möchte jedoch die Abhängigkeiten vorab klären zu diesen alten DCs... also dass keine Drucker, Switche etc - statisch konfiguriert - noch auf diese DC angewiesen sind.
Per DNS Debug kann ich DNS Anfragen loggen.
Welche Methode habe ich aber, um Anfragen ans Active Directory auf einem bestimmten DC festzustellen?
Gibts andere Methoden außer Wireshark etc? Da durch die Replikation bedingt sehr viel LDAP Traffic vorhanden ist.
das wird dir nicht viel bringen. Da Anfragen an AD automatisch verteilt werden, wirst du mit größter Sicherheit viele Anfragen feststellen - bei denen fragt der Client halt "irgendeinen" DC der Domäne. Du kannst daran aber nicht unterscheiden, ob der Client "statisch" konfiguriert ist oder einfach einen anderen DC fragen könnte. Dasselbe gilt übrigens auch für DNS.
Die Gerätschaften, die du nennst, werden übrigens kaum einen DC fragen wollen (wozu sollte ein Switch oder ein Drucker das tun?). Der sinnvollste Weg ist, die IP-Konfiguration der Clients zu überprüfen (und bei der Gelegenheit zu dokumentieren). Ja, das ist Arbeit.
Na, wir haben ja Drucker und Switche mit AD-Integration und können AD-User darauf berechten... bzw. Drucker aus dem Verzeichnis heraus installieren.
Dass da eine Unterscheidung auf IP-Ebene kaum möglich ist habe mir schon gedacht...
Die Anmeldungen kommen ja in der Regel vom jeweiligen Subnet. Das is ja schon mal klar... DNS habe ich schon vor einigen Wochen per DHCP umgestellt. Es wird nur noch der neue DC/DNS verwendet - natürlich leitet der auch an den alten DC (RoundRobin)... das ist alles schon klar
drum frage ich auch in die Runde: in der Hoffnung, dass doch jemand ne Idee hat :-)
selbst wenn du User berechtigst, heißt das noch lange nicht, dass das betreffende Gerät den DC fragt. Aber das wäre jetzt Haarspalterei.
Du wirst schlicht nicht drumrumkommen, deine kritischen Dienste zu prüfen, ob sie Abhängigkeiten haben. Für alles, was nicht in die Kategorie "kritisch" fällt, musst du eben nach der Umstellung bei Problemen Nacharbeit einplanen.
Unter
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\NTDS\Diagnostics
kannst du für verschiedene Bereiche Werte zwischen 0 (kein Logging) und 5 (extrem Logging) setzen.
Du kannst ja mal
"8 Directory Access" und "16 LDAP Interface Events" probieren, ob was für dich Brauchbares gelogged wird.
Du kannst dem DC die LDAP-Priority etwas hochsetzen, dann ist er aus der normalen DNS-Verteilung draußen http://technet.microsoft.com/en-us/l.../cc957290.aspx
Was dann noch an LDAP-Queries reinkommt, kommt nicht per DNS
selbst wenn du User berechtigst, heißt das noch lange nicht, dass das betreffende Gerät den DC fragt. Aber das wäre jetzt Haarspalterei.
Du wirst schlicht nicht drumrumkommen, deine kritischen Dienste zu prüfen, ob sie Abhängigkeiten haben. Für alles, was nicht in die Kategorie "kritisch" fällt, musst du eben nach der Umstellung bei Problemen Nacharbeit einplanen.
Gruß, Nils
Hi Nils,
das kann es leider durchaus heißen. Viele Systeme finden den DC nicht automatisch sondern wollen statisch einen eingetragen bekommen. Dazu gehören oft auch Softwaresysteme (Bsp. OTRS) die dies auch benötigen.
Das Problem hatten wir hier auch, wir haben dann für den Übergang einen DNS Eintrag mit dem Namen des alten DC erstellt der auf den neuen DC zeigte.
Das ist aber nur eine Übergangslösung.
Wirklich nur eine Idee!
DCs bieten die Möglichkeit an, das Logging hoch zu drehen
und dann? Man erzeugt damit eine Unmenge Daten. Die Energie, die man zur Auswertung benötigt, sollte man dann doch lieber in eine Überprüfung und Dokumentation der Konfig stecken ... zumal fraglich ist, ob einem die Daten überhaupt was bringen.
Du kannst dem DC die LDAP-Priority etwas hochsetzen, dann ist er aus der normalen DNS-Verteilung draußen
Ich rate entschieden davon ab, in der genannten Situation irgendwas am AD oder den vorgelagerten Diensten zu verändern. Erfahrungsgemäß führt sowas hinterher nur zu Problemen.
Viele glauben z.B., ein Windows-Dateiserver würde bei jedem Zugriff den DC fragen, um zu prüfen, ob der User denn zugreifen darf. Tut er aber nicht, denn genau um das zu vermeiden, wurde das Prinzip der SIDs und der Zugriffstoken entwickelt.
Dass es Dienste gibt, die das anders machen, steht außer Frage. Das wird aber oft stark überschätzt.
die Datenmenge hängt von der Feinheit des Loggings ab.
Wenn der TO Glück hat, sind bereits bei Level 1 oder 2 die gewünschten Daten dabei.
"Überprüfung und Dokumentation" will ich dem To keinesfalls ausreden.
Vorsicht ist gut, Kontrolle ist aber besser.
Der genannte LDAP-Key ist ein offiziell supporteter Key, der nach meiner persönlichen Erfahrung problemlos arbeitet. Gerade für die genannte Situation "Alter DC soll abgedreht werden" eignet der sich sogar hervorragend, um mögliche Probleme im Vorfeld zu erkennen. Sollten Probs auftreten stellt man ihn halt wieder zurück auf 0.
generell stimme ich Nils zu, wenn es um die Dokumentation geht. Und ich stimme blub auch zu, wenn es um die Möglichkeit geht, bei nicht vorhandener Dokumentation (was häufig das zugrundeliegende Problem ist), dennoch die AD-Konsumenten zu bestimmen.
Ein Weg, den ich persönlich sauberer als den der Prioritäten empfinde, ist der folgende (den ich übrigens genau anders herum für Migrationen zu neuen Betriebssystemen auf DCs häufig empfehle):
Erzeuge eine neue AD-Site ohne (oder mit nicht verwendetem) IP-Subnetzbereich.
Verschiebe den DC in diese neue Site. Dort sollten (automatisch) keine Clients zugewiesen werden, d.h. das Subnetz sollte wirklich nicht verwendet werden.
Prüfe die korrekte DNS Registrierung, d.h. SRV-Einträge in der neuen Site des DCs als auch das Entfernen der alten Einträge aus den alten Sites bzw. der globalen _tcp-Zone.
Nun dürften keine "regelkonformen" Anfragen mehr per DCLocator an den DC gehen, ausschließlich hart-verdrahtete Systeme "finden" den DC noch.
Logging kann entweder mit den von den Kollegen genannten Möglichkeiten erfolgen oder aber schlichtweg mittels Netzwerk Monitor, der den "inbound" Verkehr überwacht. Wichtig ist hier ein längerer Zeitraum der Überwachung, was aber zu Problemen bei der Datenauswertung führen kann.
Zuguterletzt schaltest Du den DC testweise aus, ohne ihn zu demoten. Hier zeigt sich dann am deutlichsten und schnellsten, ob es Probleme gibt. Das ist allerdings die letzte Maßnahme.
