dmetzger

Was willst Du genau erreichen?

Aha, Du hast Ned Pyle also ebenfalls abonniert. ;) Tolle Lektüre, gut geschrieben und stets lehrreich. Ich unterscheide spitzfindig zwischen "not recommended" und "not supported". Ned lässt mit sich auch darüber diskutieren: "If you know what you're doing then do it." Er weist bei seiner Nicht-Empfehlung ausdrücklich darauf hin, dass Kunden vergessen könnten, die Replikation zu reaktivieren und dann irgendwann ein Problem mit der Tombstone Lifetime bekommen. Wenn man weiss, was man tut, vergisst man NIE, die Replikation wieder zu aktivieren. (Erinnerungsstütze: Immer das Kommandozeilenfenster offen lassen, bis die ganze Arbeit erledigt und dokumentiert ist.) Zum Testen einer Schemaerweiterung reicht ja auch eine AD LDS-Instanz mit importiertem, produktivem AD-Schema. Das war kürzlich schon mal ein Diskussionsthema im Board. http://www.mcseboard.de/active-directory-forum-79/rodc-dmz-171509.html#post1055102

Off-Topic: Alles klar, fürchtete schon, unverständliches Gemurmel von mir gegeben zu haben. :shock: Meistens antworte ich nicht nur dem TO, sondern allen, die das heute und in Zukunft je lesen könnten. Der eien oder andere könnte es ja verstehen. Einen haben wir ja schon...:D

@Norbert: Meinst Du mich? Verstehst Du sie?

Du wirst nicht darum herumkommen, das irgendwann doch zu tun. Du willst am Ende ja den Exchange Server 2010 in der produktiven Umgebung einsetzen. Falls Du wirklich so furchtbar Angst vor der Schemaerweiterung hast, kannst Du 1.) temporär einen zusätzlichen virtuellen DC in die produktive Umgebung aufnehmen; 2.) diesem die notwendigen FSMO-Rollen übertragen; 3.) die ausgehende Replikation auf diesem DC mit repadmin deaktivieren; 4.) die Schemaerweiterung gegen diesen DC ausführen; 5.) die ausgehende Replikation auf diesem DC wieder aktivieren, wenn alles gut gegangen ist. Wenn nicht (was kaum passieren wird), schaltest Du den DC aus, erzwingst die Übertragung der zuvor übertragenen FSMO-Rollen auf einem anderen DC und führst eine Bereinigung der Metadaten durch. Soweit wird es aber bestimmt nicht kommen.

Die Fehlermeldungen sollten Dir ja helfen, die Ursachen zu bereinigen. Ich schliesse mich Norbert an. Es war bisher immer möglich, Replikationsfehler in den Griff zu bekommen. Man lernt daraus auch mehr fürs nächste Mal, als wenn man einfach neu installiert. Das hier kann Dir vielleicht helfen: Debunking Myths About Additional Domain Controllers In SBS Domains - The Official SBS Blog - Site Home - TechNet Blogs

Falls Du die Komponente "Microsoft-Windows-International-Core-WinPE\SetupUILanguage" ansprichst: Ja, hier geht es um die Sprache für die Benutzeroberfläche während des Setups (-> Setup User Interface Language). Bei deutschsprachigen Systemen ist das de-DE, auch für uns Schweizer. Du darfst selbstverständlich "Österreichisch" reinschreiben, aber dann greift ggf. die Einstellung "<WillShowUI>OnError</WillShowUI>", und aus der automatischen wird eine teils manuelle Installation. :D Dieser Link hilft vielleicht weiter: Windows Vista Deployment Step-by-Step Guide Ich habe zudem kürzlich Beispiel-Antwortdateien für eine Verteilung per WDS publiziert. Vielleicht sind auch diese von Nutzen für Dich: http://www.mcseboard.de/windows-server-forum-78/vollautomatische-installation-wds-funktioniert-173169.html#post1066088

Du brauchst dazu keinen Virtual PC. Die Datenträgerverwaltung von Windows 7 und/oder Windows Server 2008 R2 genügt: The Lazy Admin : Mount a VHD Within Windows 7 / Server 2008 R2 Ja, so lange es nur darum geht, den Inhalt der VHD anzusehen. Dein Sicherungskonzept hat sich allgemein nie durchgesetzt. Mache ordentliche Sicherungen von den VMs, aber keine Images. Du darfst sonst sehr bald in diesem Forum nach Begriffen wie "USN Rollback" suchen. Necron hat Dir viel Lektüre mit grundsätzlichem Inhalt angeboten. Nimm sein Angebot an und lies Dich durch.

Der DC denkt sich aber bestimmt auch keine Vorlage aus, die es nie gegeben hat, und benennt sie darüber hinaus mit dem Zusatz "angepasst". Das klingt glaubhaft. Wäre interessant zu wissen, was nach einem nächsten Neustart passiert. Das wüssten wir ebenfalls gerne. Im Gegensatz zu Dir haben wir aber keinen direkten Zugriff auf den Server. Das macht es schwer zu bestimmen, weshalb die Fehlereinträge zuerst geschrieben wurden und jetzt nicht mehr. Siehe oben. Da könnte ich ein paar Geschichten erzählen von Admins, die "überhaupt nichts gemacht" haben - wenn man lokal auf Server zugreifen kann, finden sich oft unglaubliche Spuren... Ja, da wäre ich auch sehr misstrauisch und würde unbedingt wissen wollen, was vorgegangen ist.

Exchange Server 2000 kann mit Exchange Server 2003 und Exchange Server 2007 koexistieren, nicht aber mit Exchange Server 2010. Von daher hättest Du nichts zu befürchten. Coexisting with Exchange Server 2003 and Exchange 2000 Server: Exchange 2007 Help

Er repariert womöglich noch immer das Hinterrad. :) Es gibt so viel zu tun, und doch habe ich das Gefühl, nirgendwo hinzukommen. War über den Mittag eine Stunde mit dem Hund über gefrorene Schneefelder unterwegs, blauer Himmel, es wird wärmer und heller, zum ersten Mal eine leichte Ahnung von Frühling gespürt. Man ist ja Optimist. :cool: Wünsche Euch allen einen schönen Abend. Daniel

Ein Windows Server 2003 (R2) reicht technisch selbstverständlich aus. Mir wäre W2K3 auch tatsächlich lieber als ein W2K8, denn Exchange Server 2000 kann schlecht mit globalen Katalogen auf Domänencontrollern mit W2K8/W2K8R2 umgehen. Der "Dummy"-Server soll ja als Domänencontroller mit DNS und GC für die Zwischenphase installiert werden. Diese Zwischenphase kann auch einige Tage dauern, während denen der Exchange Server 2000 bis zu seiner Entfernung weiter in Betrieb bleibt. Denk in jedem Fall an die notwendige zusätzliche Serverlizenz für den zusätzlichen Domänencontroller. Als Variante des von Microsoft beschriebenen Migrationsverfahrens könnte man sich die Installation eines Exchange Servers 2007 auf dem zusätzlichen Domänencontroller überlegen und die Postfächer vor der Entfernung des Exchange Server 2000 von diesem umziehen und auf dem E2K7 parken, bis der SBS 2008 in der Domäne ist. So bleibt neben der Gesamtstruktur auch die Exchange-Organisation erhalten. Exchange Server 2007 - Evaluation Software Zu letzterem Punkt kann Dr.Melzer bestimmt ergänzend ausführen, ob dies lizenzrechtlich zulässig ist. Wenn Du die Migration übers Wochenende durchziehst und niemand produktiv auf die zwischengelagerten Postfächer zugreift, entstehen möglicherweise keine lizenzrechtlichen Probleme.

Das hast Du eingangs nicht erwähnt, sondern den Eindruck erweckt, einen einzelnen Exchange Server 2007 virtualisieren und den bestehenden physischen ersetzen zu wollen. (Du hast auch das Klonen als Option genannt.) Mit 100 Benutzern musst Du bestimmt keine Rollentrennung vornehmen. Das wäre zu viel des Guten. Da genügt eine virtuelle Instanz mit 8 GB RAM und ausreichend Speicherplatz für die Postfächer bei weitem, auch wenn die Leute gleichzeitig mit Outlook, Outlook Web Access und Dutzenden von iPhones auf ihre Mail zugreifen.

Meine Empfehlung.

Existiert in der DNS-Verwaltung eine AD-integrierte Forward-Lookupzone "_msdcs.XXXXX.local"?

In allen Migrationsszenarien von Microsoft für den SBS 2000 wird die Koexistenz mit SBS 2003/2008 in der selben Domäne nie erwähnt. Ich gehe deshalb davon aus, dass eine solche Migration nicht vorgesehen ist und möglicherweise auch nicht funktioniert. Im Internet lassen sich Beiträge finden, deren Autoren theoretische Überlegungen anstellen, in welchen Schritten eine Migration innerhalb der gleichen Domäne von SBS 2000 zu SBS 2003 zu erfolgen hat, z.B.: Blog article: Upgrading SBS 2000 to SBS 2003 and Exchange 2000 to 2003 Diese Szenarien gehen davon aus, einen Windows Server 2003 mit Exchange Server 2003 in die bestehende SBS 2000-Domäne einzubinden, den SBS 2000 dann zu entfernen und anschliessend einen SBS 2003 in diese Domäne zu installieren. Keiner der Autoren hat dieses Szenario aber anscheinend tatsächlich erfolgreich durchgespielt. Wäre es unterstützt, würde Microsoft dieses Szenario wahrscheinlich ebenfalls beschreiben. How to upgrade Small Business Server Domain Environment to regular Windows 2003 Domain Die In PlaceAktualisierung von SBS 2000 zu SBS 2003 hat den grossen Nachteil, dass es keinen Weg zurück gibt, falls sie fehlschlägt. Ich habe bisher niemanden gefunden, der eine solche Aktualisierung problemlos durchführen konnte. Small Business Server 2003 Upgrade from Hell You cannot complete an in-place upgrade of SBS 2000 after you run adprep Je nach Grösse der SBS-Umgebung (es sind ja meistens nur wenige Benutzer) ist es möglicherweise doch das Einfachste, mit einem SBS 2008/2011 parallel und ohne physische/logische Verbindung zur bestehenden SBS 2000-Domäne eine neue Gesamtstruktur mit gleichem FQDN aufzubauen und die Daten von Hand zu migrieren. Variante 2 ist eine zweifache Migration mit ADMT, um über eine Zwischenschritt-Gesamtstruktur mit anderem FQDN/Netbios-Namen eine definitive mit ursprünglichem FQDN/Netbios-Namen zu erreichen. Mir scheint Variante 1 allerdings in diesem Fall die einfachere zu sein. Dies im Gegensatz zu meiner ersten Aussage in Beitrag 2 dieses Threads.

Es gibt ja auch noch die administrative Delegation. Idealerweise ist eine Testumgebung vollständig von der produktiven getrennt. Sonst ist es absehbar, dass irgendwann jemand doch in der produktiven Umgebung herumfummelt. Wir reden hier von einer zweiten Gesamtstruktur, nicht von einer Subdomäne? Du musst zwei Gesamtstrukturen verwalten. Das lässt sich je nach Automatisierungs- und Standardisierungsgrad durchaus bewerkstelligen.

Herzliche Gratulation und willkommen im Club! :)

Das ist ja das Problem. Würde es sie geben, liesse sie sich öffnen. :rolleyes: Andererseits erfindet der überlebende DC mit Bestimmtheit nicht eine "inetres_angepasst_poledit.adm". Hier muss in der Vergangenheit eine selbst gebaute Vorlage mit diesem Dateinamen existiert haben, möglicherweise aber nur lokal auf dem nicht mehr funktionsfähigen DC. Falls Du wirklich zu dcgpofix.exe greifen möchtest, dann lies vorab noch dies: The Dcgpofix tool does not restore security settings in the Default Domain Controller Policy to their original state

Ok., verstanden. Das ist ein SBS 2000 im Grunde, oder nicht? Und warum nicht auch in diesem Fall? Ja, natürlich: Download details: Migrating from Small Business Server 2000 or Windows 2000 Server to Windows Small Business Server 2003 Auch wenn es möglicherweise mehr Zeit benötigt, würde ich die zweifache Migration an Stelle von In Place-Aktualisierungen oder dem direkten Weg von SBS 2000 auf SBS 2008 vorziehen. Zum einen bleiben AD-Gesamtstruktur und Exchange-Organisation enthalten, zum anderen müssen die ACLs nicht neu geschrieben und keine Postfächer per PST ex- und importiert werden.

Davon ausgehend, dass Dein heutiges produktives Netz das Subnetz 192.168.1.0/24 umfasst und es Dir vorrangig um zusätzliche IP-Adressen geht, könntest Du einfach die Subnetzmaske auf 255.255.254.0 ändern und so ein Subnetz 192.168.0.0/23 erreichen. Du würdest somit alle IP-Adressen von 192.168.0.1 bis 192.168.1.0 hinzugewinnen, d.h. 255 zusätzliche.

Hast Du eine ADM-Vorlage angepasst und über "Administrative Vorlagen" dem fraglichen Gruppenrichtlinienobjekt zugefügt? Du müsstst in diesem Fall diese Vorlage entfernen und beobachten, ob sich das GPO nun ohne Fehlermeldung öffnen und bearbeiten lässt.

Kannst Du von anderen Stationen auf die Sysvol- und Netlogon-Freigaben des betreffenden DCs zugreifen? Kannst Du die GPMC mit Fokus auf den betreffenden DC öffnen?

Gut, dass Du uns das sagst. Das können wir aus der Ferne ja nicht sehen. Selbstverständlich. Nur gibts haufenweise Leute im akademischen Umfeld, die MSDNAA-Lizenzen für den produktiven Einsatz nutzen und dann behaupten, niemand habe ihnen gesagt, dass sie das nicht dürfen. Du weisst es jetzt oder hast es schon gewusst. Ein produktiver Einsatz wäre somit sogar vorsätzliche Missachtung der Lizenzbestimmungen. (Und hast Du nicht eine feste IP-Adresse zum Hosten von Anwendungen erwähnt? Der Gedankengang von Nils ist absolut nachvollziehbar.) War das nicht Deine ganz ursprüngliche Frage? So klar scheint mir nicht, was Dir völlig klar ist und was nicht. Aber selbstverständlich. Meine Vorredner haben Dich auf die E-Mail-Adressrichtlinien hingewiesen. Genau so tun wir das im produktiven Umfeld täglich bei Kunden. Understanding E-Mail Address Policies: Exchange 2010 SP1 Help Aber Du kriegst es noch immer nicht hin, eine Adressrichtlinie zu erstellen? Kann man daraus was lernen? Und er hat Euch auch schon beigebracht, was der Unterschied zwischen Präfixen und Suffixen ist?

Trage an Stelle des Localhost die IP-Adresse des DC2 ein.