Daim

Aloha, ja, dir bleibt leider nichts anderes übrig. Mit der Sicherung des System States, sichert man: - Active Directory (NTDS.dit) - SYSVOL - Systemstart Dateien - Registry - COM+ Falls eine CA installiert wäre, dann auch diese. Das System State ist das mindeste, was an einem DC gesichert werden sollte (ideal mit NTBACKUP und dann wegsichern), denn somit kann man z.B. bei einem Festplatten-Crash den Server reparieren und danach den DC rücksichern. Mit der Rücksicherung des System States wird der DC in den Zustand gebracht, den er zum Zeitpunkt der System State Sicherung hatte. Yusuf`s Directory - Blog - Einen Server mit rücksichern des System State zum DC stufen Aber eine System State Sicherung auf einer anderen Hardware rückzusichern, muss auch nicht immer funktionieren. Denn wie man an den oben aufgelisteten Punkten sieht, wird auch die Registry mitgesichert, in der bekanntlich Hardware sowie Treiber-Informationen gespeichert werden. Genau dieses kann aber beim rücksichern auf anderer Hardware Probleme bereiten. Ideal wäre es natürlich, wenn die Domäne eben zwei DCs hätte.

Hallo, nur damit es nochmals klar ist. Du musst zuerst die Option "Adressen dieser Verbindung im DNS registrieren" in den erweiterten TCP/IP Einstellungen (im Reiter DNS) der zweiten NIC deaktivieren. Im zweiten Schritt muss (wie bereits erwähnt) dem DNS-Server mitgeteilt werden, dass er diese Verbindung nicht "abhören" soll, denn damit trägt er diese IP erneut im DNS ein. How to enable or disable DNS updates in Windows 2000 and in Windows Server 2003

Hallo, darf man fragen, warum du das konfigurieren möchtest?

Servus, du hast ADPREP mit den beiden Schaltern /FORESTPREP sowie /DOMAINPREP ausgeführt. Wenn es ein R2 sein sollte, dann das ADPREP von der zweiten CD benutzt. Ist der 2003er-Server bereits als Memberserver in die Domäne integriert? Falls nicht, versuche dieses mal zuerst und starte dann erneut das DCPROMO. Funktioniert es jetzt? Versuchst du das herauf stufen mit dem Domänen-Administrator Konto? Du kannst auch mal das DCPROMOUI.LOG kontrollieren für weitergehende Informationen: Yusuf`s Directory - Blog - Debug Protokollierung

Buenos dias, na, wer hat sich denn schon alles angemeldet ?

Muuhhaaaaa..... :D Du weißt wer "glaubt" ? Richtig, der Pfarrer :cool:

Sehr gut investiertes Geld ;)

Das ist nach meinem Geschmack das einzigst deutsche Buch, was etwas in die Tiefe geht. Leider geht IMHO die deutsche Literatur mir nicht tief genug. Demzuflge muss man auf die englischen ausweichen. Da muss natürlich das Buch von Joe Richard (dritte Auflage) aus dem O Reilly Verlag genannt werden. Auch wenn man die englische Sprache nicht flüssig und 100% kann, kommt man schnell mit der Sprache und dem Buch klar. Amazon.de: Active Directory.: English Books: Joe Richards,Robbie Allen,Alistair G. Lowe-Norris Auch das AD Cookbook ist sehr zu empfehlen: Amazon.de: Active Directory Cookbook (Cookbooks (O'Reilly)): English Books: Robbie Allen,Laura E. Hunter Neben dem Buch von Joe Richards, muss das Buch von Sakari Kouti (ebenfalls englisch) genannt werden. Amazon.de: Inside Active Directory. A System Administrator's Guide: System Admin Guide (Microsoft Windows Server System Series): English Books: Sakari Kouti,Mika Seitsonen Wer jetzt noch tiefer in LDAP einsteigen möchte, der kauft sich das Buch von John Craddock. Keine 200 Seiten, aber tiefstes LDAP Wissen: Kimberry Associates : Books Wie gesagt, deutsche tiefergehende Bücher sind leider Mangelware :(

Darf man fragen welches ?

Der RID-Master ist hier tatsächlich der größere Brocken von der besagten drei Rollen. Entscheidend dabei ist das Start-Value (Low-Part/High-Part) der RID-Pools nach einem seize und erneutem online schalten des Ursprungs-Trägers.. Description of RID Attributes in Active Directory

Das ganze wird in Longhorn evtl. nochnals interessant. Das AD hat zwar schon ein paar Jahre auf dem Buckel, war aber zu Zeiten von Windows Server 2003 noch nicht erfahren genug und den Entwicklern von Microsoft fehlte womöglich auc hdie Erfahrung um solch ein Szenario (doppelte Rollen) abzufangen. Vielleicht ändert sich etwas im Longhorn (kann ich mir zwar noch nicht vorstellen...). Genauso wie die SMTP-AD Replikation. Warum man die noch nicht abgeschafft hat, ist mir ein Rätsel...

Richtig. Die "Faustformel" herauszugeben "wenn die Rollen (egal welche" geseizet wurden" den DC neu zu installieren halte ich für richtig und daran sollte sich nichts ändern. Zumal der PDC-Emulator wenn dieser von den anderen Rollen getrennt werden sollte, sowieso mit dem RID-Master auf einem DC liegen sollte.

Aloha, ja, aber... genau genommen trifft das neu installieren nur zu, wenn mindestens einer von drei Rollen geseizet wurde. Die betroffenen drei Rollen wären: -Schema-Master -Domänennamen-Master -RID-Master Die Rollen PDC-Emulator sowie Infrastrukturmaster, könnten erneut zurückverschoben werden, ohne das weiterfolgende Probleme entstehen. Microsoft Corporation

Nicht "exportieren", sondern online verschieben. Entweder über die GUI oder mit NTDSUTIL - TRANSFER. Links hast du ja ausreichend erhalten ;)

Salut, in 99% der Fälle, ist es sogar empfehlenswert, dass alle FSMO-Rollen (so wie woiza bereits schrieb) auf einem DC liegen. Somit ist es "leichter" zu administrieren. Es gibt keinen technischen Grund. Manche Rollen arbeiten eben mit anderen Rollen engmaschig zusammen und "sollten" halt zusammenbleiben. Wenn man die Rollen trennt, sollte man einiges dabei beachten. Wie gesagt, dass sind alles Empfehlungen von Microsoft und sind kein muss. Man sollte sich aber an den Empfehlungen halten. Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben FSMO-Platzierung und -Optimierung auf Active Directory-Domänencontrollern

Servus, das DN steht für Distinguished Name und bedeutet den tatsächlichen Pfad/Ort des Objekts. Der DN an dem Beispiel das du auffürst, würde wie folgt lauten: CN=USER,OU=Test1,DC=EKGN,DC=SUPERDUPER,DC=DE Beim DN ist auch der Relative Distinguished Names (RDN) enthalten, also musst du diesen mit angeben. Der RDN ist "USER". Lies das hier: Lightweight Directory Access Protocol - Wikipedia Wenn du danach noch Fragen hast, melde dich.

Ja, dann ist das ein richtiges Verhalten. Du hast eben nur die Objektdelegierung für das Objekt (in diesem Fall OU) PA vergeben und nicht auf dem Objekt (OU) XY. In der neuen OU, musst du erneut die Objektdelegierung ausführen. Oder verstehe ich etwas falsch?

Servus, Achtung mit dem zurücksetzen der Default Policies wenn Exchange existiert. Für Windows 2000 (und 2003) lies das hier: Yusuf`s Directory - Blog - Gruppenrichtlinien zurücksetzen

Servus, wie wurden denn die Rechte für die beiden Administratoren vergeben? Per Objektdelegierung auf der entsprechenden OU? Zur Kontrolle wer alles welche Rechte auf der OU besitzt: Wenn du im Snap-In "Active Directory-Benutzer und -Computer" in der Menü-Leiste unter Ansicht die "Erweiterte Funktionen" aktivierst, tauchen in den Einstellungen der OUs ein weiterer Reiter Sicherheit auf.

Gerade bei dem Thema verschlüsseln von Kennwörtern und das in Bezug auf "kostenlose" Software, wäre ich vorsichtig. Wie wird z.B. welche Verschlüsselung angewendet usw.

Servus, bessere Variante: Installiere dir den Process Monitor von Microsoft und schau in welchen Verzeichnissen inklusive der Registry das Programm versucht zu schreiben. Dann gibst Du dem Benutzer auf diesen Verzeichnissen/Dateien die entsprechenden notwenidigen Rechte. Für die Zukunft würde ich mit dem Software-Hersteller mal sprechen, dass er gefälligst sein Produkt nach den Sicherheitsmaßgaben des Windows Betriebssystems entwickelt.

Ja, du kannst die Replikation selbst steuern. Du kannst quasi festlegen, wer mit wem replizieren soll. Dann bist aber DU für die AD-Replikation zuständig. Das hat den Nachteil, dass bei div. Konfigurationsänderungen oder anderweitigen Änderungen du dafür sorgen musst, dass die Replikation weiterläuft. Wenn ein DC ausfallen sollte, musst du deine gesamte Topologie neu berechnen und ggf. umstellen. Meistens fallen Probleme dem Administrator auch nicht gleich auf. Wenn aber die Replikation vom AD verwaltet wird, versucht es eigenständig und zeitnah immer eine Lösung zu finden. Wird hingegen die Replikation manuell verwaltet , sollte ebenfalls darauf geachtet werden, dass alle DCs in einem Ring miteinander verbunden sind. Jeder GC zusätzliche Verbindungen mit anderen DCs hat usw. Für die Implementierung sowie Planung eine Aufwändige Angelegenheit. Fazit: Es ist besser, wenn die AD-Replikation vom AD gesteuert wird.

Hallo, du hast also Standorte im Snap-In "Active Directory-Standorte und -Dienste" sowie die entsprechenden Subnetze erstellt und mit den Standorten verknüpft. Danach hast du die DC-Icons an ihren neuen/jeweiligen Standort verschoben. Das AD bzw. genauer, der KCC (samt seinem Prozess ISTG) regelt die Replikation ganz automatisch, wenn die Replikation vom AD und nicht vom Administrator gereget wird. Dieses kann auch mal etwas dauern, bis sich die Replikation bei etwaigen Veränderungen eingespielt hat. Wichtig bei diesem verschieben, ist wie so oft das DNS. Denn der DC trägt sich nun mit seinem SRV-Records am neuen Standort ein. Yusuf`s Directory - Blog - Einen Domänencontroller an einen anderen Standort verschieben Yusuf`s Directory - Blog - Domänencontroller am Standort

Servus, lange Anmeldezeiten liegen zu 99% am DNS. Der Server selbst sollte in seinen TCP/IP-Einstellungen mit seiner echten IP-Adresse drin stehen und die Clients sollten den Server als DNS per DHCP oder statisch mitgeteilt bekommen. Im DNS richtest Du eine Weiterleitung (Forwarder) entweder auf Deinen Router bzw. DNS-Server deines ISPs ein.

Servus, dann deaktiviere die Kontingentverwaltung ;)