Daim

Salut, würde eine Aussage - egal von wem - nicht stimmen, würden die anderen die Aussage schon korrigieren. Wenn du im Internet danach suchen würdest, würdest du viele Seiten dazu finden, dass das umbenennen eines SBS von Microsoft nicht supportet wird. Dann weiß ich ehrlich gesagt nicht wie du suchst... vielleicht solltest du mal deine Suchmaschine wechseln. ;)

Büddee schön. Das freut mich. Genau so wie es jeder ITler macht und du es bereits aufgezählt hast. Natürlich helfen einem dabei auch die Zertifizierungen sein Know-How aufzubauen. In der IT lautet die Devise: Stetig lernen. ;) Danke und dito. :)

Das ist durchaus normal. Wenn du einen neuen Server zum DC stufen würdest, hätte dieser DC eine viel niedrigere USN. Nein, nicht zwangsläufig. Denn auf jedem DC liegt für jede Verzeichnispartition eine eindeutige Update Sequence Number (zu deutsch "Sequenznummer", kurz USN) vor. Diese USN ist ein 64Bit Wert. Die USN gibt an, wie viele Änderungen einer Verzeichnispartition auf einem Domänencontroller stattgefunden haben. Suche im Internet nach "High-Watermark-Vektor" (HWMV). Installiere dir die Windows Support Tools und führe DCDIAG sowie NetDIAG aus. Damit kannst du den Zustand des DCs, samt seiner Netzwerkkonnektivität überprüfen. Das Eventlog verzeichnet ebenfalls bei bestehenden Probleme, Einträge. Nein, keineswegs. Informiere dich über die AD-Replikation (insbesondere über den High-Watermark-Vektor und Up-to-Dataness-Vektor). Demnächst werde ich auch einen eigenen Artikel über die AD-Replikation schreiben. Du wiederholst dich. Diese Frage hatte ich dir bereits in meiner ersten Antwort beantwortet. Nein, es entstehen dadurch keine Probleme. Wenn Probleme bzgl. der AD-Replikation bestehen würden, würdest du das aus dem Eventlog erfahren. Du kannst aber auch REPLMON oder REPADMIN (beide Tools befinden sich ebenfalls in den Windows Support Tools) ausführen, um die Replikation genauer zu untersuchen.

Salut, du hast wohl den Befehl: Repadmin /showutdvec <DC-Name> <DN der Domänenpartition> ausgeführt. Die Update-Sequence Number (kurz USN) ist Domänencontroller spezifisch. Deshalb ist die USN für ein Objekt auf zwei unterschiedlichen DCs nicht identisch. Es ist normal das zwischen den DCs verschiedene USNs angezeigt werden. Denn je nachdem welcher DC wie oft Änderungen an Objekten durchgeführt hat, kommen diese Unterschiede zustande. Probleme entstehen diesbezüglich keine.

Servus, erst Exchange 2007 mit dem Service Pack 1 wird unter Windows Server 2008 unterstützt. Installing Exchange 2007 on Windows Server 2008

Bonjour, seit Windows Server 2003 ist es möglich, den Computernamen eines DCs umzubenennen. Zu Windows 2000 Zeiten musste vorher der DC heruntergestuft werden. Erst danach war es möglich den Computernamen zu ändern. Ich würde dir das umbenennen des Windows Server 2003 DCs mit NETDOM (aus den Windows Support Tools) ans Herz legen. Es ist der sanftere und sicherste Weg als über die GUI. Siehe dazu: faq-o-matic.net Wie kann man einen Domänencontroller unter Windows Server 2003 umbenennen? Und nein, dass umbenennen ruft keine weiteren Probleme hervor. Du solltest nach der Umbenennung die Dienste DNS sowie WINS kontrollieren. Natürlich muss der neue Computername überall angepasst werden, wo er jeweils hinterlegt wurde (z.B. in Netzwerkapplikationen etc.).

Oki doki. Nächste Stufe. Dann halten wir als Termn den 25.10.2008 und als Ort "Mainz" fest. Puhh... was eine Geburt... Eisgrub wäre zwar lustig, aber wie du schon sagst, ziemlich laut, was ITler doch nicht gebrauchen können. Wie wäre es mit dem "Heiliggeist"? Ich war zwar noch nie da, soll aber ganz ok sein und sieht auch sehr vielversprechend aus. Kloster-Style, da können wir uns bekehren lassen (wenn das bei ITlern überhaupt möglich ist). http://www.heiliggeist-mainz.de/

Wenn die Kunden auf mich hören würden, schon ettliche Male. :cool: Die Unternehmen denken nur ans Geld verdienen und nicht an die Technik. Wenn auf Windows Server 2008 aktualisiert wird, können viel mehr und schneller die Kundenwünsche erfüllt werden. So, jetzt ist es raus (oder so ähnlich). :p

Servus, ich kann es einfach nicht lassen, aber eines der coolsten neuen Features für mich ist der Read-Only Domänencontroller. Im Zusammenhang mit dem Server Core und Bitlocker ist es eine geniale Serverumgebung für Aussenstandorte. Der RODC auf einem Server Core und dann noch Bitlocker aktivieren. Ferdisch. ;) Gerade was das Thema Sicherheit betrifft, wurde im Windows Server 2008 einiges verbessert bzw. eingeführt.

Servus, ich kann mich IT-Home nur anschließen. Wenn ein produktiver Rechner virenverseucht ist bzw. war, ist dieser trotzdem nicht mehr vertrauenswürdig. Du weißt nicht was bereits "kaputt" gegangen ist. Wenn es ein Heimrechner wäre, dann könnetst du weiter experimentieren. Davon würde ich aber im Firmenumfeld Abstand nehmen.

Salut, genau, du musst lediglich das ADPREP /FORESTPREP von der zweiten R2-CD auf deinem Schemamaster durchführen. Yusufs Directory Blog - Schemaupdate beim Windows Server 2003 R2 Das stimmt nicht. Wenn du einen R2 als Memberserver zur Domäne hinzufügst, musst du dazu noch kein Schemaupdate durchführen. Wenn du aber die R2-Features nutzen wolltest (z.B. DFS-R), trotz das kein R2 existiert, müsstest du auch dann ein Schemaupdate bzgl. der R2-Features durchführen. Es werden wegen der Schemaaktualisierung diesbezüglich keine Probleme entstehen. Ja, nach dem Schemaupdate kannst (und solltest) du die DFS-Replikation nutzen. Erst dann werden bei den Dateien lediglich die Deltas repliziert und nicht die gesamte Datei. Voraussetzung wäre, dass alle beteiligten Server unter R2 laufen. Das geht auch nicht. Wenn du DFS-R nutzen möchtest, müssen die involvierten Server auf R2 sein. Ob diese Server dann DCs sind oder Fileserver, spielt keine Rolle. Doch, die FRS-Replikation kannst du jederzeit nutzen. Sie ist eben nur nicht so effizient, wie die DFS-Replikation.

Na... also sowas. Lesen bildet doch. ;) Das wird am zielführendsten sein. Acht eben in der Zukunft, dass der DC sich einmal während der Tombstone Lifetime sich mit dem Replikationspartner repliziert und führe regelmäßig eine Systemstatussicherung durch.

Salut. da die Root-Domäne bereits aus Windows Server 2003 DCs besteht, ist ein ADPREP /FORESTPREP nicht mehr notwendig. Du musst lediglich das ADPREP /DOMAINPREP /GPPREP auf dem Infrastrukturmaster der Sub-Domäne ausführen. Dazu reichen Domänen-Adminrechte. Wenn es sich bei dem Inplace-Update um einen Windows Server 2003 --> R2 <-- handelt, musst du das ADPREP von der zweiten R2-CD ausführen und nicht von der ersten. Nicht notwendig, siehe oben. Yusufs Directory Blog - Migration von Windows Server 2000 auf Windows Server 2003 (Inplace-Update)

Aujaa... das steht auch in dem letzten verlinkten Artikel drin. Die erzwungene Herabstufung im Modus "Verzeichnisdienste wiederherstellen" ist nur unter Windows Server 2008 möglich und nicht unter Windows 2000 sowie Windows Server 2003. Ich vergaß, dass du dich nur im DSRM anmelden kannst. Bringt überhaupt nichts, denn auf einem DC gibt es ausser dem DSRM-Admin keine weiteren lokalen Konten. Jetzt fürchte ich, hilft nur eine Neuinstallation. :(

Na klar, gewaltsam entfernen kann man das AD lokal vom DC. Dazu musst du unter Start-Ausführen den Befehl DCPROMO /FORCEREMOVAL ausführen. Damit werden die AD-Daten lokal vom DC entfernt, aber NICHT aus dem AD. Das bedeutet, auf dem anderen DC in der Domäne (der online ist), musst du die Metadaten des AD noch bereinigen. Quasi die "Leiche" aus dem AD entfernen. Wie das funktioniert, erfährst du von hier: Yusufs Directory Blog - Die Metadaten des Active Directory unter Windows Server 2008 bereinigen Nach dieser Aktion, befindet sich der Server dann in einer Arbeitsgruppe.

Ahh.. ok. Aber trotzdem kannst du in diesem Modus auch einen Blick in das Eventlog werfen. Da sollten schon wertvolle Informationen enthalten sein. Dann bringt das Ausführen der Tools auch nichts.

Das sollst/brauchst/musst du doch nicht. Nur so lebt die Community. Wir lernen mit- und voneinander. ;)

Salut, es kommt darauf an, wie lange exakt der DC ausgeschaltet war. Denn standardmäßig beträgt die Tombstone Lifetime (TSL) Bei einer Windows 2000, Windows Server 2003 sowie "Windows Server 2003 R2 mit SP1" 60 Tage. War der DC länger als 60 ausgeschaltet, hat er die TSL überschritten und kann sich erstmal nicht replizieren. Der zweite Schutzmechanismus den ein DC hat, ist die Registry-Einstellung "Strict Replication Consistency". Dazu müsste aber auch das Eventlog Fehler protokollieren. Aber abgesehen davon, kann man auch in solcher Situation die Replikation wieder zum laufen bekommen. Siehe dazu: Yusufs Directory Blog - Lingering Objects (veraltete Objekte) Da hängt auch keine Firewall dazwischen, die evtl. etwas blocken könnte? Du kannst auch die Windows Support Tools installieren und die beiden Kommandozeilentools DCDIAG sowie NetDIAG ausführen. Danach bekommst du eine Übersicht, was genau Probleme bereitet. Mit DCDIAG kannst du das auch nochmal verifizieren. Aber natürlich solltest du auch einen Blick in das Eventlog werfen. Gerade das DNS- sowie Verzeichnisdienstlog sind von Interesse. Klar, warum auch nicht? Du meldest dich zu diesem Zeitpunkt auch lokal an, denn in diesem Modus ist das AD offline.

Servus, na na na... das kommt auf die Umgebung an. Handelt es sich um einen Single-Domänen Forest, kann sich der Benutzer auch ohne GC anmelden.

OK, dann Rollen wir mal das Feld von vorne auf. Zunächst einmal, die Erläuterung der generellen Funktionsweise, wie sich die Zeit in einer Domäne synchronisiert. Den PDC-Emulator der Root-Domäne könnte man gegen eine externe Quelle (entweder aus dem Internet oder Hardware-Uhr) abgleichen lassen. Auf der Firewall müsste der Port 123 offen sein, wenn mit einer Quelle aus dem Internet abgeglichen werden soll. Der PDC-Emulator muss aber nicht seine Zeit mit einer "externen Quelle" abgleichen. Die tatsächliche Zeit ist nicht zwingend notwendig. Sie sollte nur innerhalb einer Gesamtstruktur synchron sein. Alle DCs holen sich ihre Zeit dann vom PDC-Emulator. Die Clients sowie Memberserver synchronisieren sich ihre Zeit mit ihrem Logon-Server, also dem DC, bei dem sich der Client anmeldet/authentifiziert. Wenn Du am w32time nichts gemacht hast, hast Du eine komplette Zeitsynchronisation. Die PDC-Emulatoren der Child-Domänen holen sich wiederum ihre Zeit, vom PDC-Emulator der Root-Domäne. Der PDC-Emulator der Root-Domäne ist die maßgebliche Zeitquelle für die Gesamtstruktur. Auf dem PDC-Emulator der Root-Domäne wäre folgender Befehl auszuführen, wenn mit einer Quelle aus dem Internet abgeglichen werden soll: w32tm /config /update /manualpeerlist:de.pool.ntp.org /syncfromflags:MANUAL /reliable:YES Überprüfe anschließend das Eventlog. Du musst nur darauf achten das an den Clients sich die Zeit nicht mehr als 15 mins abweicht, denn dann verweigert w32time seinen Dienst. Hier müsstest Du dann von Hand erstmal nachstellen. How to configure an authoritative time server in Windows Server 2003 Wenn also am w32tm nichts verändert wurde, funktioniert die Zeitsynchronisierung automatisch. Gib an einem XP-Client mal diesen Befehl händisch ein: "w32tm /config /update /syncfromflags: DOMHIER" (<--ohne Leerzeichen nach dem Doppelpunkt).

Servus, kontrolliere doch mal im ersten Schritt, an welchem DC sich die Clients authentifiziert haben. Benutzen sie den DC vor Ort oder einen entfernten DC? Führe dazu in der Kommandozeile auf dem Client, diesen Befehl aus: set L Denn die Clients beziehen ihre Uhrzeit von ihrem Anmeldeserver.

Servus, wenn ihr die Möglichkeit dazu habt, dann würde ich euch empfehlen direkt auf Windows Server 2008 umzustellen. Fakt ist, es läuft. Du weißt selbst, Probleme können immer und jederzeit in der IT auftauchen. Diese gilt es dann bei erscheinen zu analysieren und zu beheben. Yusufs Directory Blog - Den ersten Windows Server 2008 DC zu einer Windows 2000/2003/R2 Gesamtstruktur hinzufügen

Salut, zunächst einmal, man startet nicht bei zwei existierenden DCs in der Domäne, beide DCs gleichzeitig. Immer zuerst den einen DC und wenn dieser wieder bereit ist, erst den anderen. Bei einem Neustart benötigt das AD seine Zeit, aber keine 30 Minuten. Wichtiger ist eher, welchen DNS-Server der DC in seinen TCP/IP-Einstellungen eingetragen hat. Wenn zwei DCs existieren, könnte man die überkreuz Variante konfigurieren, was soviel bedeutet, du trägst auf DC01 den DC02 als primären DNS-Server und auf dem DC02 trägst du den DC01 als primären DNS-Server ein. Installiere dir die Windows Support Tools und führe ein DCDIAG sowie NetDIAG durch. Mit diesen beiden Kommandozeilentools kann man den Zustand der DCs kontrollieren. Dann poste doch mal ein IPCONFIG -all von beiden DCs. Mit DCDIAG kann man auch gezielte DNS-Tests durchführen. Jedoch sollte schon bei bestehenden Problemen das Ausführen von DCPROMO (ohne Parameter) ausreichen um Fehler zu entdecken. Schau dir zu DCDIAG die Hilfe an (DCPROMO -?). Aber du solltest natürlich zuerst einen Blick in das Eventlog der DCs werfen.

Servus, also im ersten Link meiner ersten Antwort steht der Weg exakt beschrieben. Du bräuchtest dich nur daran zu halten. Eine kürzere Variante findest du unter in dem Link unter diesem Abschnitt: Die einzugebenden Befehle bei der umfangreicheren Variante, wären: Start - Ausführen - NTDSUTIL - Metadata cleanup - Connections - Connect to Server <servername> (ein vorhandener DC) - Quit - Select operation target - List Domains - Select Domain <Domänennummer> - List Sites - Select Site <Standortnummer> - List servers in site - Select server <DC-Nummer> - Quit - Remove selected server - Quit Viele Wege führen nach Rom...äähhmmm... ans Ziel. ;)

Du kannst dir auch noch den Passwort Pusher von Samuel anschauen. Zum ändern des lokalen Admin-Kennworts müssen die Clients aber online sein. S@muel-AreA