aba

Willst du diese Lösung wirklich für nur einen User einsetzen, bei dem das PW nach 40 Tagen ändern soll? Wann müssen die andern User ihr Kennwort ändern? Nie? ....

Sicher, die von Dir zuletzt genannte Lösung funktioniert zwar technisch. Aber vom Sicherheitskonzept finde ich es recht fragwürdig ..... imho

XCOPY /? (beim mir unter Win XP wird dann die Hilfe und die Optionen angezeigt)

da erscheint gleich als erste Option "/A":

/A Kopiert nur Dateien mit gesetztem Archivattribut, ändert das Attribut nicht.

Das ist doch "inkrementell" kopieren ;)

--------

Wenn Du "diffrentiell" möchtest, genau eine Option drunter "/M":

/M Kopiert nur Dateien mit gesetztem Archivattribut, setzt das Attribut nach dem Kopieren zurück.

Ich würde den/die Clientrechner einmal aus der Domäne entfernen und wieder hinzufügen ...... Dann schauen, ob es "besser" ist.

Das Problem klingt irgendwie sehr merkwürdig, aber auch interessant ;)

An den Berechtigungen innerhalb der AD (an den OUs und den Objekten) hast Du nicht vorgenommen?

Das ist von Prüfung zu Prüfung unterschiedlich. Mal stehen die Punkte drauf, manchmal nicht ... bei den W2k-Examen war es eine ganze Zeit ohne Punktangabe, da stand dann nur bestanden/nicht bestanden .... bei den W2k3-Examen sind wieder Punkte angegeben.

Bis Anfang des Jahres bezogen sich die Punkte immer auf die Gesamtpunktzahl 1000 bezogen (z.B. 820 Pkt. von 1000 -> 82%) .... Das hat imho MS jetzt umgestellt .... man muß immer 700 mindestens haben zum bestehen ... und die maximal erreichbare Punktzahl ist variabel.

Auf dem FTP-Server als Basisverzeichnis einfach das wwwroot-Verzeichnis des Webservers angeben ... ;)

Für mich hören sich die Fehlermeldungen irgendwie nach einem DNS-Problem an ... Die Clients scheinen die Serverdienste LDAP und Kerberos für die Domäne im Netz nicht zufinden ... Auf dem DNS ist alles klar (SRV-Einträge für die Domäne)? Die Clients befragen den "richtigen" DNS-Server?

Eine bestehende W2k-Domäne, die in diesem Fall eine eigene Gesamtstruktur darstellt, bekommst Du nicht in eine W2k3 Gesamtstruktur "gehängt".

Wo machst Du denn die Änderung? In der Benutzerkonfiguration oder in der Computerkonfiguration? ....

Welches Betriebsystem?

Bei W2k: "secedit /refreshpolicy machine_policy /enforce" oder "secedit /refreshpolicy user_policy /enforce" ohne Abmelden/Neustart.

Bei W2k3 lautet der Befehl "gpupdate /force /target:Computer|user".

Ist die Forward-Lookup-Zone eine Active-Directory-integrierte Zone? Dann bekommen nur die DNS-Server die Zone übertragen, die auch DC in der Domäne sind (Zonentransfer wird über die AD-Replikation durchgeführt). Es hört sich für mich so an, dass der "neue w2k3 Server" nur ein Member-Server der Domäne ist. Der hat dann leider Pech und bekommt die Zone nicht übertragen (weil er eben kein DC ist und deswegen auch nicht an der Replikation der DCs teilnimmt).

Beide Prüfungen habe ich als sehr "knackig" empfunden. Die 70-296 sogar als noch knackiger.

Gefragt wird alles was neu ist beim W2k3 ...

Ohne dcpromo wird das imho nix.

Aus der AD wurde durch den vorherigen DCPROMO ja der Server1 entfernt. Wenn du das Backup des Systemstatus auf dem ersten Server ohne dcpromo wieder einspielst, taucht er deswegen noch lange nicht wieder als DC in der Domäne auf, denn die Änderung, dass Server1 als DC "aus dem Rennen ist", ist aktueller als das Backup des Systemstate von Server1.

Wenn der Ping auf localhost (127.0.0.1) funktioniert, dann ist's nicht das Protokoll. Dann funktioniert die Bindung vom Protokoll auf die NIC anscheinend nicht. Da sollte auch was im Eventlog auftauchen. Dann kann es eigentlich nur der Treiber sein.

Oder hast Du die IP fest für die NIC vergeben und diese vergebene IP-Adresse hast Du erfolgreich angepingt?

Läuft auf dem DC, den Du neu installieren willst, noch irgendwas an Software/Diensten?

Falls nein, einfach mit dcpromo DC entfernen .... (nachdem Du den 2. DC installiert und die Betriebsmaster verschoben hast) .... Server neu installieren und wieder zum DC heraufstufen (Betriebsmaster anschließend wieder zurückschieben).

So übernimmst Du wenigstens keinerlei "Altlasten" aus der vorherigen Installation.

Und den 2. DC würde ich auf Dauer als Redundanz im Netz lassen. Diese "Sparnetze" mit nur einem DC sind für mich irgendwie unverständlich.

Das hört sich schwer nach 'nem Problem mit dem NIC-Treiber an (wenn ipconfig wirklich nix von sich gibt unter NT). Evtl. mal einen anderen Treiber (älter/neuer) versuchen.

Evtl. hilft es ja auch, das aktuelle NT-Servicepack noch mal drüber zu installieren.

Evtl. ist im Microsoft Technet Script Center ja was zu finden.

Ohne nähere Infos kann man nur sagen: "Im Prinzip ist ein Update von Win98 auf Windows 2000 Prof. kein Problem, aber ....." ;)

Mit Boardmitteln vom Betriebssystem: Systemmonitor und dann eine Warnung konfigurieren.

Zu beachten ist eigentlich nur, das DNS fehlerfrei in den Netzwerkeinstellungen auf beiden Servern konfiguriert ist und der DNS-Server funktioniert.

Ich glaube, da brauchst Du das Schema-Snap-In. Das Snap-In muß allerdings vorher noch mit "regsvr32 schmmgmt.dll" installiert werden. Mit dem Snap-In kannst Du auch den "Schreibschutz" vom Schema "entfernen".

Irgendwelche Einträge in den Ereignisprotokollen vorhanden, die vielleicht beim Fehler-/Lösungsuchen behilflich sein können?

Man kann von einem IMAP-Client auf den Exchange zugreifen ....

Aber imho mit dem Exchange-Server per IMAP nicht in ein IMAP-Postfach auf einem anderen Server "schauen". Und genau so habe ich die Frage von ITSN verstanden.

Ich habe beide Prüfungen abgelegt. Als Vorbereitung habe ich die beiden MOC-Ordner durchgearbeitet und konnte auf längere praktische Erfahrung mit XP, MS Office, Outlook Express, IE, .... zurückgreifen.

Nur das Wissen aus den beiden MOC-Ordnern reicht mit Sicherheit nicht. Man braucht zusätzlich noch einiges an Erfahrung! Die wollen z.B. in der 70-272 Sachen im Word oder Excel wissen, da wußte ich ja selbst nicht mal, dass es so was gibt (geschweige denn, wie es funktioniert ;) ). Aber mit ein bisschen praktischer Erfahrung (auch mit den MS-Prüfungen) hat es doch auf Anhieb geklappt.

Beim Backup wird im Transaktionsprotokoll eine "Marke" (LSN, Logical Sequenz Number) gesetzt. Alle Transaktionen, die während des Backups durchgeführt werden und im Protokoll landen, werden zum Ende des Backups mit in die Sicherung geschrieben.

D.h. bis zum Ende des Backups gehen keinerlei Transaktionen verloren. Die DB inkl. des Transaktionsprotokolls ist absolut konsistent am Ende der Sicherung.

Die einzigen beiden Möglichkeiten, die ich sehe (habe ich aber selber noch nicht getestet!):

Erweiterte Startoption -> Verzeichnisdienstwiederherstellung

Anmelden als Administrator (müßte das Kennwort sein, dass zur Verzeichnisdienstwiederherstellung bei der Installation der Domäne verwendet wurde.

In den Sysvol-Ordner wechseln, und den Ordner der GPO verschieben ... Das dürfte zwar Fehlermeldungen beim nächsten Neustart/Anmeldung hageln, aber vielleicht ist es zumindest so möglich, wieder an den Domänencontroller "heranzukommen".

Eine andere Möglichkeit wäre, den Systemstatus aus dem letzten Backup zurückzusichern SYSVOL und AD-DB. Alle Änderungen in der AD seit dem letzten Backup wären dann allerdings futsch. Aber vielleicht immer noch besser als Neuinstallation.

Es wäre evtl. interessant zu wissen, wofür der Snapshot der DB gebraucht wird.