Daim

Meine allererste Antwort, samt dem Artikel.

Dann verschiebe diese beiden Rollen auf den anderen DC, der bereits die anderen drei Rollen trägt. Wie du die Rollen verschieben kannst, erfährst du aus diesem Artikel: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben

Nein, darfst du nicht. Denn ansonsten wird die Domänenpartition gelöscht, worin sich die ganzen Benutzer-, Gruppen-, Computerkontos usw. dieser Domäne befinden.

Na na na... Der Befehl NETDOM QUERY FSMO gibt dir den/die Träger der FSMO-Rollen zurück und nicht nur den Infrastrukturmaster.

Salut, du gehst auf START - AUSFÜHREN und gibst dort DCPROMO ein. Anschließend folgst du dem Assistenten. Auf den anderen beiden DCs sollte das DNS installiert sein und die FLZ sollte AD-integriert gespeichert sein. Weiterhin sollten sich die FSMO-Rollen auf einem anderen DC befinden. Zusätzlich aktiviere auf den beiden anderen DCs den GC. Natürlich müssen alle Daten sowie Dienste falls auf diesem DC installiert, von einem anderen DC übernommen werden. Wenn dieser DC der erste DC war, sichere noch das EFS-Zertifikat. Ansonsten lies dir diesen Artikel durch, was es noch zu beachten gilt: Yusuf`s Directory - Blog - Den einzigen Domänencontroller austauschen Hast du denn auch diese Frage verstanden, die der Assistent dich fragt? Falls ja, dann kennst du auch die Antwort.

Aloha, nein, kannst du nicht. Denn der Windows-Client verschickt per Broadcast eine DHCP-DISCOVER Anfrage im Netz. Der Broadcast richtet sich dabei an die IP-Adresse 255.255.255.255. Dann antwortet der DHCP-Server, der zuerst diese Anfrage erhält. Der schnellere DHCP-Server gewinnt quasi und bietet dem Client mit einer DHCP-OFFER Nachricht eine IP-Adresse an. Warum denn? Der andere DHCP soll faul in der Ecke liegen? Es geht doch nur drum, den Clients eine IP-Adresse zu verteilen. Lass ihn ruhig arbeiten. Grundlagen zu DHCP (Dynamic Host Configuration Protocol)

Servus, das ist mehr als suspekt und passiert auch nicht von alleine. In diesem Fall, hätte man mit einem kühlen Kopf die Eventlogs prüfen sollen und weiterhin sich in Ruhe erstmal einen Überblick verschaffen. Ein Image rücksichern ist zwar keine gute Idee... aber warten wir es mal ab. Yusuf`s Directory - Blog - Images als Sicherung ? Ich vermute, du hast ihm die FSMO-Rollen neu zugewiesen (geseized?). Ist auch auf beiden DCs der globale Katalog aktiviert? Wundert mich nicht. Du musst nun Troubleshooting betreiben. Installiere dir auf dem laufenden DC die Windows Support Tools (von der Windows Server 2003 CD im Ordner Support\Tools) und führe DCDIAG sowie NetDIAG durch. Überall wo ein FAILED protokolliert wird, versuchst du der Meldung mit der Suchmaschine deiens Vertrauen nachzugehen. Überprüfe weiterhin das Eventlog. Dort müsste "Karneval in Rio" sein. Ganz wichtig ist dabei das DNS. Das muss zwingend sauber funktionieren. Auch dabei kannst du gezielt mit DCDIAG DNS-Tests durchführen. Versuche in jedemfall herauszufinden, wie das passieren konnte. Denn ansonsten stehst du morgen erneut vor dem gleichen Problem (wenn du heute überhaupt da raus kommst...). Überprüfe das DNS und das Eventlog. Gehe anschließend den Fehlermeldungen nach. Die Forward Lookup Zone sollt AD-integriert gespeichert - was nur möglich ist, wenn das DNS auf einem DC installiert wurde - und auf allen DCs sollte das DNS installiert sein. Werfe einen Blick in die Dienstesteuerung und kontrolliere, ob alle Dienste die auf automatisch stehen, auch "Gestartet" sind. Stimmt das Datum und die Uhrzeit auf den DCs? Das kann ich mir gut vorstellen. Aber trotzdem, behalte einen kühlen Kopf und reagiere nicht zu voreilig, sonst machst du am Ende noch mehr kaputt. Ich weiß wie schwer das in der Situation ist, aber in der Ruhe liegt die Kraft.

Servus, nein, wird es nicht. Du solltest eher zu einer Abfrage tendieren. Du kannst die Abfrage auch mit ADFIND von welcome to joeware durchführen. Du musst dich schon ein wenig mit der Materie auseinandersetzen.

Servus, damit nun lediglich nur die IP-Adressen im DNS registriert werden die du benötigst, muss im ersten Schritt, im DNS-Reiter der IP-Konfiguration der jeweiligen LAN-Verbindung, die dynamische Registrierung der IP abgeschaltet werden. Das hast du ja bereits getan. Im zweiten Schritt muss in den Eigenschaften des DNS-Servers, das Abhören des Dienstes an der einen IP-Adresse verhindert werden. Denn ein DNS-Server registriert sich auch die IP-Adressen, an denen er abhört.

Moin, die 621+649 reichen aus. Dann brauchst du nur noch die 647.

Dann ist es bei dir/euch nicht tragbar. Ich kenne Unternehmen mit weitaus mehr Clients, die das genauso machen. Und erneut der Spruch: Wenn das Wörtchen wenn nicht wäre... Du musst dich doch nicht lokal anmelden. Du kennst doch das Domänen-Admin Kennwort. Das reicht doch aus. Wie gesagt, es gibt ettliche Varianten. Ihr müsst euch das am praktikabelsten aussuchen. Ich sage immer, wenn ein Admin seinen Benutzern etwas vorschreibt, hat sich der Admin natürlich auch selbst daran zu halten. Er soll schließlich als Vorbild dienen. Das ist die Praxis weitaus anders aussieht, ist uns allen doch klar. Ich habe jetzt zwar keinen Artikel zur Hand, aber ich bin schon über solch eine Empfehlung gestolpert. Falls ich sie finden sollte, reiche ich sie nach.

Moin. Garnicht. Exakto Mundo. Davon war ich ausgegangen. Das es mit mehreren SBS nicht funktionieren würde, wurde bereits erwähnt. Ich habe meine Antworten explizit auf das OP bezogen und dort war nirgends die Rede von mehreren SBS. Weiterhin wollte ich Unklarheiten des OPs klar stellen (das Verständnis bezgl. der Replikation usw.). Falls tatsächlich die Standorte ebenfalls einen SBS betreiben (sollen), dann kann man das Konstrukt vergessen. Siehe auch: Yusuf`s Directory - Blog - Die Besonderheiten eines Small Business Server`s (SBS)

Servus, hier muss ich mal eingreifen. demnach handelt es sich hier um einen Single-Domänen Forest (eine Gesamtstruktur mit nur einer Domäne). Du meinst sicherlich, dass dieser DC der Träger der FSMO-Rollen ist. Einen Hauptdomänencontroller gibt es so seit Windows 2000 nicht mehr (wie zu Zeiten von NT). Da sich das wirklich verquer anhört, formuliere ich das mal anders. Auf einen DC - der egal in welcher Domäne steht - werden die folgenden Verzeichnispartitionen repliziert: - Schemapartition - Konfigurationspartition - Globaler Katalog (falls ein DC ein GC sein sollte) - ForestDNSZones - Eigens erstellte Anwendungsverzeichnispartitionen Die jeweilige Domänenpartition einer Domäne, wird natürlich nur innerhalb der eigenen Domäne repliziert. Ein GC erhält dabei alle Objekte aller Domänen einer Gesamtstruktur, aber mit nur den wichtigsten Attributen der anderen Domänen. Da die Forward Lookup Zone (FLZ) AD-integriert gespeichert und somit auf jedem DC das DNS installiert sein sollte, sind alle DCs dieser Domäne die autoritativen DNS-Server eben dieser Domäne. Das ist nicht weiter tragisch, denn es bestehen doch noch weitere DCs dieser Domäne an den Standorten. Deine Domäne wäre also noch weiterhin vorhanden und voll funktionsfähig. Wenn das AD-Design stimmt, merken sogar die Clients - wenn es um die Authentifizierung geht - kaum etwas davon. Denn wenn der einzige DC im HQ crashen sollte, nimmt sich ein Domänencontroller aus einem anderen Standort, der dem HQ am nächsten ist (anhand der Kosten der Standortverknüpfungen) dessen an und trägt sich im DNS als Domänencontroller für diesen Standort ein. Dieses Verfahren nennt sich "Automatic Site Coverage". Dabei ist eben das Design im Snap-In "Active Directory-Standorte und -Dienste" sowie das DNS elementar. Yusuf`s Directory - Blog - Domänencontroller am Standort Der Hinweis von blub hat trotzdem seine Richtigkeit. Wieso denn das? Falls die FLZ AD-integriert gespeichert ist, wird diese automatisch auf die anderen DCs repliziert. Somit befinden sich die DNS-Informationen auf den anderen DCs und die anderen DCs sind ebenfalls schreibberechtigt (autoritativ berechtigt) im DNS wie der DC im HQ. Wenn der DC im HQ lediglich nur ein DC sein sollte, würde ich bei einem DC-Crash nichts weiter machen, als die FSMO-Rollen mit Gewalt auf einen anderen DC zu verschieben, den gecrashten DC aus dem AD zu entfernen (mit NTDSUTIL oder ADSIEdit) und dann im HQ einen neuen Server installieren und diesen einfach als zusätzlichen DC zur bereits bestehenden Domäne hinzufügen. Dabei haben die anderen DCs in den Standorten keine Probleme. Ausser das dann Replikationsprobleme im Eventlog protokolliert werden, solange die Leiche dann noch im AD existiert.

Moin, nicht unbedingt. Im Service Pack 2 von Windows XP ist der VSS-Client integriert.

Servus, genau so. Du hast doch auch für deine Wohnung, dein Auto und für das Büro jeweils einen Schlüssel. Dabei würdest du auch nicht auf die Idee kommen, mit einem Schlüssel überall rein kommen zu wollen. Warum? Natürlich wegen der Sicherheit. Verlierst du einen Schlüssel, kann der Finder höchstens eine Tür öffnen und nicht alle anderen. Allen voran lautet das Zauberwort (das was kein Admin hören möchte): Dokumentation (auf Zetteln die verschlossen im Schrank sind oder einer Datenbank usw.). Nun kann man sich natürlich für die Kennwortvergabe ein eigenes System ausdenken. Z.B. könnte in dem Kennwort die Inventarnummer der Maschine und die Zimmernummer verwendet werden. Dabei gibt es unzählige Varianten, du musst dir eins ausdenken. Alles Erziehung. ;) Genauso ist es Pflicht, dass der Admin unter seinem Benutzeraccount keine Domänen-Admin Rechte hat. Das wird auch heute noch leider viel zu oft vernachlässigt. Wenn du diese Frage an die Securityleute von Microsoft stellen würdest, würden ihnen die Haare zu Berge stehen ;) . Es wird natürlich nicht alles so heiß gegessen wie es gekocht wird. Es ist gut das du für die Systeme bereits verschiedene Kennwörter vergibst. Um eine größere Sicherheit zu gewinnen, sollte eben jedes System worauf es einen lokalen Administratoraccount gibt, sein eigenes Kennwort besitzen.

Wenn das Wörtchen wenn nicht wäre... trotzdem ist das pfui ;) .

Servus, in dem du bei angeschalteten Clients, dass Tool "Password Pusher" ausführst und einfach das neue Kennwort vergibst. Das Tool erhälst du, in dem du Samuel eine Mail sendest. S@muel-AreA Trotzdem rate ich dir von dieser Vorgehensweise dringend ab. Das lokale Admin-Kennwort auf den Clients sollte nicht überall gleich lauten.

Genau so. Der Assistent prüft am Anfang ob ein Dienst oder Treiber bzw. Hardware installiert ist der nicht Kompatibel sein könnte. Wenn das der Fall sein sollte, meckert dir der Assistent das dann an. Du kannst dann diese Warnung zu Herzen nehmen und der Sache nachgehen oder du überspringst die Warnung (was du in einer produktiven Umgebung natürlich nicht machst) und aktualisierst trotzdem.

Moin, dann sollte dieser Artikel passen: Error message when you try to remove Exchange Server from a mailbox server that no longer hosts mailboxes: "One or more users currently use a mailbox store on this server" Wenn ihr euch an den Artikel gehalten habt, kann kaum mehr etwas schief gehen ;) . Ich kenne den Autor persönlich und er ist ein MVP für Exchange. Zudem kommt noch hinzu, dass er mittlerweile bei Microsoft angestellt ist.

Ach... da fielen ihm... jetzt verstehe ich deine Worte grizzly. Natürlich kann an einem Standort auch mehrere Domänen existieren, also erhöht sich die Anzahl der Bridgeheads an diesem Standort automatisch. Denn, ein Standort kann mehr als eine Domäne enthalten und eine einzige Domäne kann sich über mehrere Standorte erstecken. Jetzt passts wieder. ;)

Ich hatte die Anzahl der Domänen bewußt nicht erwähnt, da die Standorte ohnehin zu den Domänen gehören. Du drückst das ganze mit anderen Worten aus, aber wir schreiben imho das gleiche. Beispiel: Es existieren in einer Gesamtstruktur zwei Domänen, die auf insgesamt 10 Standorte verteilt sind. Dann hat diese Gesamtstruktur (min.) 10 Bridgeheadserver. Dazu wirst du mir doch zustimmen? OK, da muss ich olc zustimmen. Ich bin mitten im Thread eingestiegen und habe das aufgemalte Szenario vom OP nicht gelesen.

Servus, nicht möchte, sondern müssen, wenn es sich um eine Gesamtstruktur handelt. Jeder STANDORT hat einen Bridgeheadserver. Wieviele Bridgeheadserver in einer Gesamtstruktur exiistieren, hängt einzig und alleine, von der Anzahl der Standorte ab. Nein, du benötigst oder hast nicht einen Bridgehead pro Domäne, sondern pro Standort. Du interpretierst das sicher falsch. Und wenn die Domäne aus nur an EINEM Standort existiert? Dann existiert quasi kein Bridgehead, da die standortübergreifende Replikation vom ISTG nicht erstellt werden muss, da es ohnehin nur einen Standort gibt. Daher ist das entscheidende nicht die Domäne, sondern die Anzahl der Standorte, da der Bridgehead eben für den standortübergreifenden Transport der AD-Daten und für das verteilen der AD-Informationen in seinem eigenen Standort zuständig ist. Description of Bridgehead Servers in Windows 2000 Wenn du explizit einen Bridgehead vorgibst, nimmst du dem AD die Möglichkeit bezgl. des Bridgeheads einzugreifen. Denn alles was du im AD händisch erstellst, wird von den AD-Prozessen nicht mehr angefasst. Daher solltest du die Auswahl der Bridgeheadserver dem AD überlassen. Es kommt immer auf die Größe der Umgebung an und wie AD-lastig gearbeitet wird. Im SoHo Bereich kann der GC locker auch der Bridgehead eines Standorts sein. Dann wird eben auf den GC mehr an AD-Informationen, natürlich abhängig um welche Umgebung es sich handelt (Anzahl der Domänen), repliziert.

Off-Topic:Muuuhhhhhhhaaaaaaaaa... :D . Jaja heißt... das du mich ganz doll lieb hast. Off-Topic:Wir sind Brüda ;)

Off-Topic:Das kann schon deshalb unter Windows 2000 nicht funktionieren, da es damals ein Produkt mit dem Namen "Windows 2000 Server --> Enterprise <--" nicht gab. Sondern "Windows 2000 Server", "Windows 2000 Advanced Server" und "Windows 2000 Datacenter Server". ;)

Servus, weil ich das schon immer mal testen wollte und ohnehin ein Freund der Praxis bin, habe ich das soeben durchgeführt. Einwandfrei durchgelaufen. Funktioniert.