Daim

Servus, aktiviere zusätzlich, die in diesem Artikel genannte Richtlinie ebenfalls: Computerkonfiguration/Administrative Vorlagen/System/Skripts\Anmeldeskripts gleichzeitig ausführen Yusuf`s Directory - Blog - Asynchrones Startverhalten beim Windows XP

Dachte ich es mir doch ;). Wird dort der gecrashte DC angezeigt? Falls ja, gehe ggf. den Artikel (kb 216498) erneut durch und stelle sicher, dass die Reste der Leiche definitiv entfernt sind. Anstatt NTDSUTIL zu verwenden, kannst du auch ADSIEdit benutzen. - Öffne ADSIEdit und verbinde Dich mit der Domain-Partition - Navigiere zum Contaier "OU=Domain Controllers" und lösche dort die Einträge des nicht mehr existierenden DCs - Ebenfalls in der Domain-Partition, löscht Du alle Einträge des DCs auf folgendem Pfad "CN=Domain System Volume,CN=File Replication Service,CN=System,DC=<DeineDomäne>,DC=<TLD> - Dann verbindest Du Dich mit der Configuration-Partition im ADSIEdit und entfernst alle Einträge des nicht mehr existierenden DCs (z.B. CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=<DeineDomäne>,DC=<TLD>) - Entferne alle Einträge vom DC, die im DNS und WINS existieren Kontrolliere sicherheitshalber auch das DNS. Du kannst auch die DNS-Einträge des gecrashten DCs auf folgende Weise deregistrieren: nltest /dsderegdns:<FQDN-DC-Name> /dom:<DNS-Domänen-Name>

Servus, du hast also Replikationsprobleme mit NTDSUTIL behoben ? Erklärst du mir bitte, wie du das genau gemacht hast ?

OK - Hellsehen kann ich noch nicht. Denn in deinem o.g. Beispiel ist es korrekt:

Dein Grundproblem ist weiterhin das DNS. Der gecrashte DC sollte aus DNS sowie AD definitiv entfernt sein. Weiterhin empfehle ich dir jeden DC zum GC zu machen (mit den bereits oben genannten Bedingungen). Dann kontrolliere das DNS ob die SRV-Records existieren und richtig gesetzt sind. Die Einträge: _gc _kpasswd _kerberos _ldap sind elementar. Lese: Fehlermeldung: Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung hergestellt werden

Genau so ;). Du kannst auch kontrolliere (nach ausführen von ADPREP mit dem Schalter /FORESTPREP) ob dieses Objekt auf ALLEN DCs in der Gesamtstruktur existiert: CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=<RootDomäne> Wenn du aber einen Tag wartest, bist du aber i.d.R. auf der sicheren Seite. Hier etwas zum lesen. Operations that are performed by the Adprep.exe utility when you add a Windows Server 2003 domain controller to a Windows 2000 domain or forest

Ich gebe dir ledglich Anhaltspunkte bzw. ich zeige dir den Weg.Wie du diesen Weg begehst, bleibt dir überlassen ;). Über das Design des AD hängt eben die Firmenstruktur sowie Anforderungen ab. Das ist völlig unnötig, zumal man z.B. GPOs lediglich auf Benutzer sowie Computer anwenden kann, aber nicht auf Gruppen. Deshalb ist diese Unterteilung der Gruppen überflüssig bzw. nicht notwendig (ich betone, dass ist meine Meinung. Wenn du es für notwendig hälst, kannst du es machen, wobei sich aber der Sinn, mir nicht entschließen würde). Fakt ist, du solltest eben im AD die Standorte erstellen. Alles weitere hängt von eurer Firma ab ;).

Ich weiß jetzt zwar nicht was du genau meinst, aber du kannst ADPREP egal mit welchen Schaltern im laufen Betrieb ausführen. Davon merken die User erstmal nichts. Nach dem ausführen von ADPREP solltest du einige Stunden warten bis sich die neuen Informationen repliziert haben. Wenn du den Domänenfunktionsmodus bzw. Gesamtstrukturfunktionsmodus heraus stufen möchtest, kannst du dies ebenfalls im laufenden Berieb erledigen. Davon merken die User ebenfalls nichts.

Servus, was meinst du mit "Standardsicherung" ? Das System State muss explizit ausgewählt werden. Es sei denn, man erstellt eine ASR - dort ist das System State logischerweise inbegriffen.

Servus, dann sind dir bereits diese Artikel bekannt und haben nicht geholfen? The "Send As" right is removed from a user object after you configure the "Send As" right in the Active Directory Users and Computers snap-in in Exchange Server Users cannot send e-mail messages from a mobile device or from a shared mailbox in Exchange 2000 Server and in Exchange Server 2003

Servus, dann ist einiges faul. 25 Minuten braucht ein Server nie um zu starten. Da liegt eine Fehlkonfiguration des DCs vor. Meistens ist es das DNS, gefolgt von GPOs. Kontrolliere das DNS sowie die TCP/IP-Einstellung, welcher DNS dort auf den DCs eingetragen ist. Prinzipiell kann man sagen, dass die ganze Funktion der Domäne an einer sauberen und den Anforderungen des AD entsprechenden DNS-Konfiguration hängt. Wenn es dabei Probleme oder Fehler ergeben, funktioniert das AD nicht. Das DNS sollte idealerweise auf den DCs installiert sein und die Forward Lookup Zone sollte AD-integriert gespeichert werden. Dadurch kann dann die Option "Nur sichere" Updates gewählt werden, was zu beherzigen wäre. Tools die behilflich sind bei der Fehlersuche wären zuerst das DCDIAG sowie NetDIAG, die sich beide in den Windows Support Tools befinden (auf der Windows Server 2003 CD). Das Eventlog sollte ebenfalls kontrolleirt werden.

Servus, du solltest zuerst den gecrashten DC aus dem AD entfernen. Entweder mit NTDSUTIL oder mit ADSIEdit. Gehe dazu diesen Artikel durch: Entfernen von Daten aus Active Directory nach fehlgeschlagener Domänencontroller-Herabstufung Das ist ein weiterer Artikel: Delete Failed DCs from Active Directory Hier kannst Du Dir über NTDSUTIL einen Webcast anschauen: 7WTT TechNet Webcast: Active Directory - Wartung Ihres Verzeichnisdiensts mit NTDSUTIL (Level 200) Du kannst den DC auch mit der ADSIEdit Variante entfernen - Öffne ADSIEdit und verbinde Dich mit der Domain-Partition - Navigiere zum Contaier "OU=Domain Controllers" und lösche dort die Einträge des nicht mehr existierenden DCs - Ebenfalls in der Domain-Partition, löscht Du alle Einträge des DCs auf folgendem Pfad "CN=Domain System Volume,CN=File Replication Service,CN=System,DC=<DeineDomäne>,DC=<TLD> - Dann verbindest Du Dich mit der Configuration-Partition im ADSIEdit und entfernst alle Einträge des nicht mehr existierenden DCs (z.B. CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=<DeineDomäne>,DC=<TLD>) - Entferne alle Einträge vom DC, die im DNS und WINS existieren Sind denn die beiden Rollen "Schema-Master" sowie Domänennamenmaster auch auf dem anderen DC vorhanden? Wie viele GCs existieren denn in deinem Forest? Wenn es die Bandbreite hergibt und nicht zu oft Änderungen im AD vorgenommen werden, würde ich jeden DC zum GC deklarieren.

Gerade DAS, solltest du vermeiden. So einfach und flach wie möglich/nötig sollte das Desgin aussehen. Ich würde für jeden Standort bei deiner genannten Größe, einen Standort im AD erstellen, wie bereits erläutert. Wenn du im Snap-In "Standorte- und Dienste" alles korrekt konfigurierst und die DC-Icons an ihren entsprechenden Standort verschiebst, sollte der Rest automatisch (dank des DNS) funktionieren.

Korrekt. Das hört sich etwas verwirrend an. Genau genommen ist es unter Windows Server 2008 möglich, die Kennwortrichtlinien nur mit Benutzerobjekten, InetOrgPerson-Objekten und globalen Sicherheitsgruppen zu verknüpfen. Nicht auf Domänen-Ebene wie es z.B. die Default Domain Policy darstellt. Mehrere Kennwortrichtlinien in einer Domäne - faq-o-matic.net

Servus, zu Windows 2000 und 2003 Zeiten, heißt es "AD". Mit Windows Server 2008, heißt es dann "AD DS" ;). Sofern man das aus der Ferne beurteilen kann, würde ich ein Einen-Domänen-Modell wählen mit und darin drei Standorte kreieren. Natürlich nur, wenn deine genannten Standorte auch wirklich physikalische Standorte die voneinander getrennt sind ist. In den Standorten "solltest" du nur dann einen DC aufstellen, wenn dieser vor Ort auch gesichert steht (hinter Schloss und Riegel). Mit Windows Server 2008 entschärft sich das ganze, dank RODC. Richte Dir dann im Snap-In "Standorte und Dienste" Standorte und Subnetze ein und verschiebe die jeweiligen DC-Icons an ihren jeweiligen Standort. Ein Standort kann mehr mehrere Domänen enthalten und eine einzige Domäne, kann mehreren Standorten angehören. Durch das erstellen von Standorten kannst Du die Replikation von Active Directory bzw. das SYSVOL Verzeichnis "besser" steuern. Standortintern (Intrasite) werden Änderungen wesentlich häufiger repliziert als zwischen Standorten (Intersite) und vorallem werden die Daten über die Leitung komprimiert repliziert und nicht so wie standortintern - unkomprimiert. Dadurch hast Du nicht nur die Möglichkeit, die effektive Performance im Netzwerk zu optimieren, sondern auch die WAN-Struktur im Hinblick auf Gescwindigkeit und Kosten Rechnung zu tragen. Durch Standorte kannst Du z.B. jeden DC zu einem Standort verschieben und somit klar definieren, welcher DC zu welchem Standort gehört. Damit wissen die Clients schneller, welcher ihr Anmeldeserver ist. Ebenfalls hast Du die Möglichkeit, gezielter mit GPOs zu arbeiten bzw. standortabhängige GPOs anzuwenden. Hier noch etwas zum lesen: Yusuf`s Directory - Blog - Domänencontroller am Standort Microsoft Corporation

Servus, damit die Clients einen lokalen DC nutzen, musst du unter "Active Directory Standorte und Dienste" die entsprechenden Standorte konfigurieren. Diesen Standorten musst Du dann wiederum, dass entsprechende IP-Subnetz zuordnen. Wenn der Client jetzt startet, versucht er über DNS einen Domänencontroller zu finden, der sich an seinem Standort befindet. Wenn man es genau betrachten will, dann erfragt der Client zuerst per DNS, welche DCs es gibt. Die Liste aus der DNS-Antwort geht er dann durch, um einen DC zu finden, der erreichbar ist. Wenn der Client noch keine oder falsche Standortinformationen haben sollte (wie es z.B. bei Laptops sein kann), bekommt er bei dem ersten Kontakt aufgrund seiner Quell-IP die richtigen Information von einem DC übermittelt. Jeder DC trägt sich im DNS mit seinen SRV-Records ein und somit würde der Client "seine" (IP) Informationen bekommen. Dann gibt es noch die Priorität und Gewichtung. Falls es mehrere DCs an einem Standort gibt, kann man anhand der Priorität (umso niedriger die Zahl, umso höher die Priorität) bestimmen, welcher der DCs die "erste Wahl" darstellt. Was imho nicht verändert werden sollte, sofern es keinen trifftigen Grund dazu gibt. Durch erstellen von Standorte kannst du Einfluss auf die AD-Replikation legen. Wann soll wie oft repliziert werden etc. Intra-Site (standortintern) wird in einem Ring repliziert. Standortübergreifend über einen spanning-tree. Hier was zum lesen: Yusuf`s Directory - Blog - Domänencontroller am Standort Yusuf`s Directory - Blog - Einen Domänencontroller an einen anderen Standort verschieben

Servus, die erste Amtshandlung sollte sein, dass SMB-Signing nach dem Best Practise einzustellen. Gruppenrichtlinien - Übersicht, FAQ und Tutorials

Servus, warum nutzt ihr intern offizielle IP-Adressen? Die gleiche Frage, warum offizielle IP-Ranges? Keine (wenn die zweit Installation vernünftig erstellt wird). Das funktioniert (vorsicht auf DHCP). Ich würde aber die beiden Netze trotzdem versuchen zu trennen. Dazu könnten VLANs behilflich sein oder eigene Switche etc.

Nein, muss er nicht. Das ist ja gerade der Witz an der Objektdelegierung. Man vergibt an einen Benutzer gerade nur die benötigten administrativen Rechte, die er für seine tägliche Arbeit braucht. Im Idealfall vergibt man solche Rechte sogar einem zweiten Benutzerkonto. Falls du einen Benutzer in eine bestehende Standard-Gruppe, wie die "Konten-Operatoren" hinzufügst, hat dieser von Haus aus mehrere/weitere Rechte. Das möchte mal aber oftmals nicht. Daher bietet sich die Delegierung an, um lediglich die minimalsten Rechte zu vergeben. Lies selbst, was für Rechte die Konten-Operatoren haben: Microsoft Corporation Auf der Workstation kannst du das Adminpak abgespeckt installieren. Standardmäßig beinhaltet die Installation des Adminpaks viel zu viele administrative Snap-Ins die der Benutzer nicht braucht, sondern evtl. lediglich die AD Snap-Ins. Diese kannst du mit folgendem Befehl installieren (ohne die restlichen Snap-Ins): msiexec /i adminpak.msi ADDLOCAL=FeADTools /qb Fast noch besser wäre die benutzerdefinierte TASKPAD-Installation. Create Taskpads for Active Directory Operations

Eine autoritative Wiederherstellung, brauchst du lediglich in einer Domäne mit mehreren DCs auszuführen. Denn nur wenn weitere DCs existieren, können die wiederhergestellten Objekte von anderen DCs überschrieben werden, falls kein "authoritative restore" ausgeführt wurde. Existiert lediglich nur ein einziger Domänencontroller in der Domäne, kann die wiederhergestellte Sicherung von keinem DC überschrieben werden. Das ausführen von NTDSUTIL ist somit nicht notwendig. Das brauchst du alles nicht. Wie bereits erwähnt, bei nur einem DC kannst Du dir das mit NTDSUTIL sparen. Dann ist (wie du selbst gemerkt hast) die OU TEST nicht mehr vorhanden. Dies ist ein normales Verhalten in dem Szenario mit nur EINEM DC in der Domäne. Du brauchst einen zweiten DC in der Domäne, dann würde die OU Test bestehen bleiben.

Servus, verwende diesen Befehl: authoritative restore: Restore Subtree OU=<DeineOU>,DC=<DOMÄNE>,DC=<TLD>. Da verwechselst du jetzt aber etwas. Das Stichwort lautet: Subtree. Zum lesen empfehle ich: Active Directory - faq-o-matic.net

Servus, genau. Mitlerweile kann man das direkt downloaden und der Link war mir auch noch bekannt. Danke für den Hinweis. @carnivore Ich zitiere meinen Satz: ;)

Upss... hatte den Thread übersehen... Das stimmt so nicht. Die Funktion des SETPWD wurde zwar in Windows Server 2003 integriert (NTDSUTIL), es lässt sich aber trotzdem unter 2003 noch nutzen, z.B. zum Skripten. Wie hast du es denn versuchen können, denn das SETPWD musst du dir vom PSS zuschicken lassen... Siehe: Setpwd.exe Enhancement to Specify a DSRM Password as an Argument

Warum postest du denn in zwei Foren Ich hatte dir bereits hier geantwortet: http://www.mcseboard.de/windows-forum-ms-backoffice-31/systemwiederherstellung-114250.html

Hallo und willkommen auch von meiner Seite. Lass mich raten. Dein Benutzername "TR58" stellt sich folgendermaßen zusammen: TR = steht für Türkei. 58 = für die Stadt aus der du kommst, in diesem Fall Sivas. Stimmts oder habe ich recht ;).