Anfragen an DC feststellen vor Entfernen

[Malzwei 10]

Hallo Kollegen,

 

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.

 

Wie würdet Ihr vorgehen?

 

Danke & Grüße

[NilsK 2.930]

Moin,

 

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.

 

Gruß, Nils

[Malzwei 10]

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 :-)

[NilsK 2.930]

Moin,

 

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

[blub 115]

 

drum frage ich auch in die Runde: in der Hoffnung, dass doch jemand ne Idee hat :-)

 

Hi,

Wirklich nur eine Idee!

DCs bieten die Möglichkeit an, das Logging hoch zu drehen

 

Directory Services Debug Logging Primer - Ask the Directory Services Team - Site Home - TechNet Blogs

 

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/library/cc957290.aspx

Was dann noch an LDAP-Queries reinkommt, kommt nicht per DNS

 

blub

[Avaatar 28]

Moin,

 

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.

[NilsK 2.930]

Moin,

 

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.

 

Gruß, Nils

[NilsK 2.930]

Moin,

 

das kann es leider durchaus heißen.

 

natürlich kann es das, es muss aber nicht.

 

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.

 

Gruß, Nils

[blub 115]

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.

[olc 18]

Hi,

 

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):

 

1. Erzeuge eine neue AD-Site ohne (oder mit nicht verwendetem) IP-Subnetzbereich.
   
2. Verschiebe den DC in diese neue Site. Dort sollten (automatisch) keine Clients zugewiesen werden, d.h. das Subnetz sollte wirklich nicht verwendet werden.
   
3. Entferne den DC aus der globalen / generischen AD-DNS _tcp-Zone mittels SRV-mnemonics: How to optimize the location of a domain controller or global catalog that resides outside of a client's site
   
4. 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.
   
5. Nun dürften keine "regelkonformen" Anfragen mehr per DCLocator an den DC gehen, ausschließlich hart-verdrahtete Systeme "finden" den DC noch.
   
6. 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.
   
7. 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.
   

 

Viele Grüße

olc

[NilsK 2.930]

Moin,

 

guter Trick und gute Anleitung. Muss ich mir mal merken!

 

(Es bleibt aber meine Skepsis gegenüber dem Grundansatz. Man sollte gut überlegen, ob man den gewaltigen Overhead dieser Methode wirklich braucht - wenn es einen Sinn ergeben soll, sprechen wir hier von mehreren Tagen, wahrscheinlich sogar mehreren Wochen Verzug bei der Migration ... und ich erlaube mir die Anmerkung, dass der Network Monitor (NMCap), Ethereal et al. bei der Langzeitaufzeichnung durchaus zwischendurch mal abbrechen.)

 

Gruß, Nils

[olc 18]

Hi Nils,

 

wie gesagt, ich stimme Dir da vollkommen zu. :)

 

Ich wollte zusätzlich jedoch eine Alternative geben, da nicht immer alles so gut läuft, wie man es sich z.B. in Bezug auf die Dokumentation vorstellt... Insbesondere auch, da der Weg anders herum dazu dienen kann, neue Betriebssysteme auf den DCs einzubringen, ohne sie jedoch allen Clients sogleich verfügbar zu machen. Und das schwingt ja auch bei dem Thread mit, ohne daß es vom TO genannt wurde. :)

 

Bezüglich des Netzwerk Monitors: Vollkommen richtig, obwohl man das auch "abfangen" kann. Alternativ dazu geht auch ganz simpel ein PerfMon oder SPA-Mitschnitt. Der zeigt auch die Top-Konsumenten (bzw. ggf. auch alle).

 

Viele Grüße

olc