Daim

Ahaa... einer von uns beiden unterliegt (wie so oft) dem "Begrifflichkeits-Problem" ;) . Das ist alles richtig. Der Assistent fragt dich, wo die Active Directory-Datenbank (NTDS.dit) sowie die Protokoll-Dateien gespeichert werden sollen. Er fragt dich aber nirgends, welche Verzeichnispartitionen repliziert werden sollen. Denn es werden automatisch alle Verzeichnispartitionen die der andere DC hält, auf den neuen repliziert. Der neue DC erhält automatisch die folgenden Verzeichnispartitionen: - Schema-Partition - Konfigurations-Partition - Domänen-Partition - Anwendungsverzeichnispartition (wie z.B. die DomainDNSZone sowie die ForestDNSZone) Du wirfst die Begrifflichkeiten durch die Gegend ;) . Überprüfe dein Vorgehen mit dem o.g. Artikel, evtl. fällt dir ein Fehler auf.

Hola, trotzdem gibt es die Bezeichnungen PDC und BDC so nicht mehr. Es sind alles DCs. Nein, musst du nicht. Normalerweise fügst du den Server als zusätzlichen DC deiner bestehenden Domäne hinzu und wartest lediglich die AD-Replikation ab. An keinem Punkt musst du angeben, welche Verzeichnispartitionen repliziert werden sollen. Siehe: Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen Schildere deine Vorgehensweise genauer.

Servus, ja, ist es. Denn das Access-Token in dem die sämtlichen SIDs der einzelnen Gruppenzugehörigkeiten enthalten sind, wird nur einmal bei der Anmeldung erstellt und wird nicht dynamisch, während einer Benutzer-Sitzung aktualisiert. Daher muss sich beim ändern der Gruppenzugehörigkeiten der betroffene Benutzer ab- und wieder anmelden, damit er ein neues/aktualisiertes Access-Token erhält.

Servus, starte im normalen Modus und gehe in die Kommandozeile. Dort gibst du SETPWD ein.

Dann hast du beim Hinzufügen zur Domäne lediglich: Benutzername: "Administrator" - anstatt - "domäne.de\administrator" angegeben ;) .

Das eine sind die Domänen-Konten, worauf die Kennwortrichtlinie wirkt und das andere ist das lokale Administrator-Konto. Ein leeres Kennwort des lokalen Admins ist natürlich nicht ideal, aber eben ein Kennwort das auf allen Client gleich lautet, ist auch nicht viel besser. Das kannst du auch im übrigen mit diesem Skript/Tool erledigen: Microsoft Certified Professional Magazine Online | Column: Automating Local Admin Password Changes -- Readers Weigh In Avian Waves : Tech : Tools : XS BAP S@muel-AreA

Erstelle dann mal zuerst das Computerkonto-Objekt im AD und versuche dann den Client in die Domäne hinzuzufügen. Wenn das funktioniert, nimm den Client erneut aus der Domäne, lösche das Computerkonto-Objekt, benenne den Client um und versuche ihn erneut in die Domäne hinzuzufügen und zwar mit dem Domänen-Admin Account.

Servus, genau so soll es ja auch im Idealfall aussehen. Du willst doch nicht mutwillig die Sicherheit des Netzwerks herunterschrauben ?

Servus, mit welchen Rechten bzw. Benutzerkonto fügst du den Client in die Domäne hinzufügen ? Denn standardmäßig können seit Windows NT, authentifizierte Benutzer standardmäßig 10 Clients in die Domäne aufnehmen. Yusuf`s Directory - Blog - Clients in die Domäne hinzufügen Der RID-Master verteilt jedem DC standardmäßig 500 RIDs, damit die DCs Objekte erstellen können. Wenn die DCs 250 RIDs verbraucht haben, versuchen sie in regelmäßigen Abständen vom RID-Master neue RIDs zu bekommen. Dieses trifft aber nicht auf deinen Fall hier zu.

Huhuu, nicht ganz richtig. Es wird auch auf den Microsoft-Seiten nicht korrekt dargestellt. Dort liest man des öfteren etwas von 14 Tagen. Die Wahrheit liegt wie so oft dazwischen ;) . Liest selbst: Yusuf`s Directory - Blog - Die letzte Benutzeranmeldung herausfinden

Servus, du meinst so etwas in der Art: Yusuf`s Directory - Blog - Wie stellt man sicher, dass ein Benutzer sich nur an einem Client anmelden kann? Ich bin ein Freund von der einfachen Variante.

OKi doki. Ich hatte es aus dem Kopf anders vermutet und konnte es nicht nachprüfen.

Servus, da hast du etwas missverstanden. Er möchte es genau umgekehrt wissen ;) . Zitat: dsquery user -d ad.local -limit 0 | dsget user -disabled -dn > c:\users.txt Damit werden die DEaktivierten Benutzer ausgegeben. Das gleiche in grün. Das UserAccountControl mit dem Wert "1.2.840.113556.1.4.803:=2" gibt lediglich die DEaktivierten Benutzer-Objekte zurück.

Servus, jetzt habe ich mehr Zeit und kann ausführlicher antworten. Das ist genau ein DC zu wenig. D2D2T findet in der Regel in größeren Umgebungen bei höherwertigen Sicherungslaufwerken statt. Denn der Tot eines jeden Sicherungslaufwerks ist der ständige Start-Stop Betrieb durch den nicht Konsistenten Datenfluss. Daher sichert man in größeren Umgebungen zuerst auf Disk und schreibt dann die Sicherung auf Tape. Das halte ich für dein Szenario nicht für nötig, obwohl du dies aber trotzdem machen könntest. Da du lediglich zwei Server hast und jeder Server auch noch ein Sicherungslaufwerk hält, solltest du die Sicherung spät Abends planen und direkt auf Band schreiben lassen. Danach kannst du die Protokolle überprüfen wie die Sicherung verlaufen ist. Wenn erhöhte Start-Stop Betriebe stattgefunden haben, kannst du immer noch umstellen (sofern das die eingesetzte Backup-Software unterstützt). Als Backup-Software würde ich zuerst das NTBACKUP, dass im OS enthalten prüfen. Wenn das deinen Ansprüchen genügt, ist alles in Butter.

Salve, Anmeldungen sowie Abmeldungen lassen sich auch per Logonskript und Logoffskript protokollieren. Dazu gilt es eine Batch-Datei zu erstellen, eine für die Anmeldung (wenn gewünscht) und eine andere für die Abmeldung: Logon.cmd: echo logon %username% %computername% %date% %time% >> \\Server\Freigabe\Logon.txt Logoff.cmd: echo logoff %username% %computername% %date% %time% >> \\Server\Freigabe\Logoff.txt Anschließend gilt es die erstellen Batch-Dateien in eine entsprechende Richtlinie zu verknüpfen: Benutzerkonfiguration - Windows-Einstellungen - Skripts (Anmelden/Abmelden).

Korrekt.

Servus, achte in diesem Artikel auf die rote Schrift: Yusuf`s Directory - Blog - Dateizugriff überwachen

Servus, Zu allererst sollte ein /aktuelles/ sowie natürlich funktionierendes Backup vom System State existieren. Da bei dir das Exchange 2000 Schema in der Gesamtstruktur vorhanden ist, musst du zuerst die Exchange Schema-Erweiterung „korrigieren“. Dazu wird die Datei InetOrgPersonfix.ldf benötigt, die sich in der Archiv-Datei Support.cab im Verzeichnis „Support\Tools\" auf der Windows Server 2003 CD befindet. Diese Archiv-Datei gilt es zu entpacken und anschließend mit LDIFDE ins Schema zu importieren. Alles weitere erfährst du von diesem Link: Yusuf`s Directory - Blog - Das Active Directory Preparation Tool - ADPREP Dann musst du im zweiten Schritt das Active Directory-Schema aktualisieren bzw. auf Windows Server 2003 vorbereiten. Dazu führst du das Tool ADPREP von der Windows Server 2003 CD aus. Falls die neue Maschine ein Windows Server 2003 --> R2 <-- sein sollte, beachte bitte, dass du das ADPREP von der zweiten R2 CD verwendest. Denn das ADPREP bei R2 befindet sich auf beiden CDs. Yusuf`s Directory - Blog - Schemaupdate beim Windows Server 2003 R2 Du führst das ADPREP mit dem Schalter /FORESTPREP auf deinem 2000er Schema-Master aus. Anschließend führst du ADPREP mit dem Schalter /DOMAINPREP auf dem Infrastruktur-Master in der Domäne aus, in der du den neuen Server hinzufügen möchtest. Danach füge den neuen Server als "zusätzlichen Domänencontroller einer bereits existierenden Domäne" hinzu. Deine Forward Lookup Zone (FLZ) im DNS sollte auf deinem 2000er DC idealerweise AD-integriert gespeichert sein und "Nur sichere" Updates zulassen". Wenn die FLZ im AD gespeichert ist, erleichtert dir die Replikation das Leben ein wenig. Yusuf`s Directory - Blog - Einen zusätzlichen DC in die Domäne hinzufügen In den TCP/IP Einstellungen des neuen Servers trägst Du als ersten und einzigsten DNS den bestehenden 2000er DC ein. Erst wenn die Replikation stattgefunden hat, kannst du die DNS-Server Einstellung verändern. Siehe: Yusuf`s Directory - Blog - Welcher DNS-Server sollte eingetragen werden ? Somit hast Du das AD und DNS auf Deinen neuen DC "gesichert". Dann solltest Du die 5 FSMO-Rollen auf den neuen DC noch verschieben: Yusuf`s Directory - Blog - Die FSMO-Rollen verschieben Zusätzlich solltest Du den neuen DC zum GC deklarieren. Dieses kannst Du in dem Snap-In "Standorte- und Dienste" in dem jeweiligen Standort, auf Deinem Server - in den Eigenschaften der NTDS-Settings den Haken bei "Globaler Katalog" setzen. Yusuf`s Directory - Blog - Globaler Katalog (Global Catalog - GC) Achtung: Exchange 2000 funktioniert nicht auf Windows Server 2003!

D2D2T = Disk to Disk to Tape ;) .

Na sowas aber auch, dann sollten wir die Wochenenden abschaffen :p . Richtig gelernt. Aber genau genommen, würde das AD auch ohne DNS funktionieren, man könnte es dann aber sehr schwer ansprechen. Aber ist eine andere Nummer. Die Devise, dsas das AD ohne DNS nicht läuft, kann man stehen lassen (obwohl es technisch aber möglich ist). Das geht natürlich nicht. Als Faustregel gilt, auf jedem DC sollte immer das DNS mit installiert werden und die FLZ sollte eben AD-integriert gespeichert sein. Ergo, installiere auf dem DC2 noch das DNS und warte die Replikation ab. Wie gesagt, jeder DC sollte ohnehin zwecks Redundanz auch das DNS installiert bekommen. Da deine Struktur am Ende eine Single-Domänen Forest darstellt, existiert in deinem DNS lediglich eine Forward Lookup Zone die eben auf allen DCs/DNS-Server repliziert wird. Jeder Client versucht sich an einem DC, der in seinem Standort steht anzumelden. Daher ist es wichtig, im AD "Standorte" zu erstellen und die jeweiligen DC-Icons dann auch an ihre entsprechenden Standorte zu verschieben. Denn dann tragen sich die DCs mit ihren SRV-Records im DNS für den entsprechenden Standort ein. Dadurch findet der Client im DNS - seinen - DC. Yusuf`s Directory - Blog - Domänencontroller am Standort Selbstverständlich. Der Client macht zuerst einen DNS-Lookup an seinem Standort der so aussieht: _ldap._tcp.<Standort>._sites.dc._msdcs.<Domäne>.<TLD>. Bekommt er darauf keine Antwort, sendet er dem nächsten Lookup diesmal nicht explizit an seinen Standort, sondern diesmal an die Domäne. Die Abfrage würde folgendermaßen lauten: _ldap._tcp.dc._msdcs.<Domäne>.<TLD>. Ich denke, wir sollten doch die Wochenenden abschaffen, dann kommst du nicht so sehr in Verlegenheit, so viel nachdenken zu müssen :D .

Servus, die Tombstone Lifetime (TSL) beträgt bis Windows Server 2003 standardmäßig 60 Tage. Erst bei einer neu erstellten Gesamtstruktur mit Windows Server 2003 --> SP1 <-- beträgt die TSL 180 Tage. Natürlich lässt sich die Tombstone Lifetime jederzeit händisch verändern. Das kannst du mit ADSIEdit erledigen. Der Pfad lautet: CN=Directory Service,CN=WindowsNT,CN=Services,CN=Configuration,DC=Domäne,DC=TLD Diese Einstellung würde dann alle Domänen im der Gesamtstruktur betreffen. Dabei sollte aber trotzdem Vorsicht geboten sein, denn dadurch kann sich abhängig von der Anzahl der gelöschten Objekte, das AD aufblähen. Wenn nun also ein DC für eine gewisse Zeit ausgeschaltet werden soll, könnte man VORHER die TSL "vergrößern". Oder der DC wird vorher heruntergestuft. Zurück zu deiner Frage: Nein, die DCs würden sich nicht synchronisieren. Im AD spielen weit mehr Faktoren, als die Benutzerkonten mit eine Rolle. Der andere DC würde sich technologisch weiterentwickeln und der ausgeschaltete DC bekommt davon nichts mit.

Dann solltest du z.B. noch zwei weitere Zahlen ans Ende stellen. Da du das Kennwort lediglich für den speziellen Modus benötigst, ist es nicht soo gravierend wenn dort ein schwieriges Kennwort vergeben wird. Achte lediglich darauf, dass du es auch dokumentierst ;) .

Servus, du kannst - wie bereits von ducke erwähnt - die Konsistenz der AD-Datenbank überprüfen. Werden dabei Fehler gemeldet, kannst du ein FIXUP drüber laufen lassen. Yusuf`s Directory - Blog - Die Active Directory-Datenbank reparieren Lässt sich der Fehler damit auch nicht beheben, solltest du wenn möglich den DC herunter- und erneut wieder hochstufen. Lässt sich der DC nicht mit DCPROMO herunterstufen, so musst du ihn mit Gewalt runterstufen. Anschließend musst du aber noch das AD von der Leiche entfernen. Yusuf`s Directory - Blog - Das Active Directory gewaltsam vom DC entfernen

Servus, was Sicherheitstechnisch ohnehin ein Fehler ist. Verwende dieses Kennwort, dann geht es mit Sicherheit: Pa$$w0rd# Ich würde dir nicht empfehlen, die Komplexität herunter zuschrauben. Denn zu Windows Server 2008 Zeiten, kann man sich (bei gesetzten Reg.-Key) damit jederzeit anmelden.

Servus, als allgemeine Faustregel gilt, an einem DC gehört mindestens das System State gesichert. Mit sichern des System States sichert man: - Active Directory (NTDS.dit) - SYSVOL - Systemstart Dateien - Registry - COM+ Falls eine CA installiert wäre, dann auch diese. Wenn nun eine Teilstruktur gelöscht wird, führt man eine autoritative Rücksicherung (bei mehreren DCs) des System States durch. Das AD und SQL haben eins genmeinsam, es handelt sich bei beiden um Datenbanken. Der Aufbau einer AD-Datenbank unterscheidet sich aber wesentlich von einer SQL-DB. Die Datenbank-Engine einer Active Directory Datenbank ist die "Extensible Storage Engine (ESE)". Alles weitere erfährst du aus dem Internet. Dann solletst du dir trotzdem die ASR-Sicherung, die im Betriebssystem enthalten ist, anschauen. Das System State sowie die ASR-Sicherung führt man über das NTBACKUP durch.