Zweiter Server im AD, Umzug Exchange 2003

[blueintheface 10]

Hallo @alle!

 

Stehe vor der Aufgabe, einen neuen W2K3-Server (64bit) in ein Netz zu integrieren, der vom

bisherigen Server (32bit, lahm und überlastet) zwar nicht alle, aber doch einige Aufgaben

übernehmen soll, vor allem soll Exchange 2003 auf die neue Maschine umziehen.

Das ist natürlich nichts was hier mit einem Satz beantwortet werden kann, ich habe auch schon

etliches gelesen zu dem Thema, aber ich würde lügen wenn ich behaupten würde dass ich nun schlauer

bin als zuvor, eher verwirrter. Vielleicht kann mir hier jemand einen Tipp geben wo es eine brauchbare

Anleitung für so ein Szenario gibt (wenn es sie denn gibt).

 

Das Netz ist so aufgebaut, dass es zwei Standorte gibt, die über eine Gateway-to-Gateway-VPN permanent

verbunden sind. Am Standort A befindet sich das W2K3-Netz (eigene AD-Domain), am Standort B bislang

ein W2K-Netz (ebenfalls eigene Domain), zwischen beiden Domains besteht eine halbwegs funktionierende

Vertrauensstellung.

Mein Ziel ist es nun EINE W2K3-Domain zu schaffen, eben mit zwei 2003er-Servern. Der bisherige

W2K3-Server ersetzt den 2000er am Standort B (diese Domain fällt dann weg, die Windows-User müssen

in die 2003er umziehen), am Standort A ersetzt der neue Server den nach B wechselnden und übernimmt

(u.a.) den Exchange-Server. Mit einem AD würde es entfallen immer zwei ADs pflegen zu müssen.

 

Hört sich eigentlich einfach an, aber ich bin mir nicht mal sicher ob das so überhaupt machbar ist.

Darum wäre ich dankbar für brauchbare Tipps, auch wenn es nur in der Form "guckst du da" ist.

 

Thanks,

Blue

[NorbertFe 2.032]

Hallo @alle!

 

Stehe vor der Aufgabe, einen neuen W2K3-Server (64bit) in ein Netz zu integrieren, der vom

bisherigen Server (32bit, lahm und überlastet) zwar nicht alle, aber doch einige Aufgaben

übernehmen soll, vor allem soll Exchange 2003 auf die neue Maschine umziehen.

 

Das ist natürlich nichts was hier mit einem Satz beantwortet werden kann,

 

Doch. Es geht nicht.

Du kannst Exchange 2003 nicht auf 64bit installieren.

 

Bye

Norbert

[blueintheface 10]

Doch. Es geht nicht.

Du kannst Exchange 2003 nicht auf 64bit installieren.

 

Hoppla.. an die wichtigsten Sachen denkt man zuletzt.. oder eben überhaupt nicht. :rolleyes:

Dann bleibt Exchange eben erst mal auf dem bisherigen Server und auf den neuen kommt dann später Exchange 2007.

Hoffe dass wenigstens die Erweiterung der Domäne um einen weiteren Server

klappt wie gedacht.

 

Danke Norbert für die schnelle Antwort.

 

Grüsse,

Blue

[dippas 10]

Hallo Blue,

 

willst du den 64-Bit-Server einsetzen, weil es "State of the Art" zu sein scheint, oder weil Du den tatsächlich benötigst? Der Einsatz von 64-Bit-Servern (2003) will wohl überlegt sein. Auftretende Probleme mit der Anwendungssoftware (z.B. E2k3 nicht auf 64-Bit) oder mit Treibern können auftreten.

 

64-Bit machen Sinn, wenn man 64-Bit-Applikationen laufen hat und/oder > 4 GB RAM einbaut und dies auch ausnutzt (z.B. Datenbanken, aber nicht jede nutzt das dann auch tatsächlich!)

 

Vorweg: Es ist KEINE wirklich gute Idee, einen Exchange auf einem DC laufen zu lassen! Das hat nicht nur Sicherheitsgründe, sondern auch mit den Eigenheiten der Unumkehrbarkeit der Serverrolle (DC oder nicht) nach der Installation von Exchange zu tun.

 

Ein Effekt ist auch, dass ein Exchange-Server auf einem DC sehr lange zum herunterfahren benötigt. Das Herunterfahren dauert deshalb so lange, weil MS das AD für schnelles Herunterfahren "optimiert" hat. Exchange prüft aber das AD ebenfalls beim herunterfahren. Da es dann aber bereits "weg" ist, wartet Exchange auf einen Time-Out. Der kommt aber erst nach (ich glaube) 10 min. per default.

 

Wie Du selbst festgestellt hast, ist das nicht "mal eben" verstanden und umgesetzt. Daher hier nur ganz ganz grob in Eckdaten die Vorgehensweise:

 

1. W2k3 (neu) in Standort A installieren, Mitglied zur Domäne machen, Schemaerweiterung auf dem alten Server durchführen, neuen Server zum DC machen, Serverrollen (auch Schemamaster!!) und Globalen Katalog übertragen, Dateien rüberkopieren, Exchange installieren und integrieren, Postfächer verschieben, öffentliche Ordner replizieren, RUS konfigurieren. Connectoren umkonfigurieren usw. WINS nicht vergessen. Zeitaufwand ca. 2 - 3 Tage, je nach Datenmenge und Gesundheitszustand der Domain.

2. Warten und Ereignisanzeige sowie allgemeine Funktionalität (z.B. AD-Replikation) beobachten.

3. W2k3 (alt): Exchange deinstallieren, DC herunterstufen, aus der Domain entfernen, Format c: (um etwaige Altlasten loszuweden). Dabei immer auch den neuen DC beobachten (Ereignisanzeige)

4. W2k3 (alt) im Standort A installieren, zum Mitglied der Domäne machen, IP-Einstellungen können auf DHCP bleiben. (Noch) NICHT zum DC machen.

5. Den Standort B im AD von Standort A einrichten (DNS-Reverse-Zone mit IP-Kreis "B", Standortverknüpfungen usw.)

 

Wenn das alles fehlerfrei geklappt hat, dann den alten Knecht einpacken und zu Standort B schleppen.

 

Standort B:

1. Server aufbauen, feste IP aus Standort B geben, DNS- und WINS(!)-Konfiguration einrichten und diese auf den neuen Server in Standort A zeigen lassen.

2. dcpromo auf altem Rechner ausführen

3. das AD wird nun vom Standort A auf den neuen (alten) Server in Standort B repliziert (überprüfen!)

4. Globalen katalog auf diesen Server für den Standort B einschalten

5. WINS-replikation konfigurieren, DNS konfigurieren usw.

6. Daten W2k (B) auf W2k3 (B - alter Rechner) migrieren, Berechtigungen beachten

7. PCs rüber in die neue Domain

8. W2k abschalten

9. fertig

 

Klingt einfach, ist es aber nicht. Schon gar nicht geht es "mal eben" und braucht auch seine Zeit, biss alles wirklich rund und fehlerfrei läuft. Ich schätze, dass man vom Einlegen der CD in den neuen Server, bis zum Abschalten des alten W2k-Servers (Domain B) bis zu 2 Wochen braucht (Installation, Updates, Datenmigration, Replikation, Fehlersuche und -bereinigung, Transport usw.).

 

Viel Spaß :)

 

grüße

 

dippas

[NorbertFe 2.032]

Vorweg: Es ist KEINE wirklich gute Idee, einen Exchange auf einem DC laufen zu lassen! Das hat nicht nur Sicherheitsgründe, sondern auch mit den Eigenheiten der Unumkehrbarkeit der Serverrolle (DC oder nicht) nach der Installation von Exchange zu tun.

[/Quote]

 

Neben diesen Gründen ist für mich der Hauptgrund, dass im Desasterfall ein deutlich komplexeres Vorgehen zur Wiederherstellung notwendig wird.

 

Ein Effekt ist auch, dass ein Exchange-Server auf einem DC sehr lange zum herunterfahren benötigt.

 

Naja, dass ist nicht immer so, und kann zur Not ja auch beeinflußt werden. Aber trotzdem ist die Installation eines Exchange auf einem DC nicht empfohlen.

 

 

 

3. W2k3 (alt): Exchange deinstallieren, DC herunterstufen,

 

Und in dem Moment ist das EFS Recovery Agent Zertifikat den Bach runtergegangen. ;)

 

6. Daten W2k (B) auf W2k3 (B - alter Rechner) migrieren, Berechtigungen beachten

 

Genau hier wo es interessant wird, hast du nur zwei Punkte? ;) Stichwort admt für den TO.

 

7. PCs rüber in die neue Domain[/Quote]

 

Ja admt für PCs und USer. Ansonsten gibts Mecker mit den Usern wenn die Desktops anders aussehen. ;)

 

8. W2k abschalten

 

EFS nicht vergessen.

 

Klingt einfach, ist es aber nicht.

 

Naja, kommt drauf an, wie oft man es schon durch hat. ;)

 

Schon gar nicht geht es "mal eben" und braucht auch seine Zeit, biss alles wirklich rund und fehlerfrei läuft. Ich schätze, dass man vom Einlegen der CD in den neuen Server, bis zum Abschalten des alten W2k-Servers (Domain B) bis zu 2 Wochen braucht (Installation, Updates, Datenmigration, Replikation, Fehlersuche und -bereinigung, Transport usw.).

 

Über welche Größenordnung spricht der OP eigentlich? Abgesehen davon, holt man sich für sowas normalerweise sein komplettes Know How weder aus Büchern oder Foren, sondern kauft sich das zumindest anteilig ein. :)

 

Bye

Norbert

[dippas 10]

hallo Norbert,

 

Du hast mit Deinen Ergänzungen natürlich recht. Vielleicht hätte ich auch erwähnen sollen, dass meine Liste keinen Anspuch auf Vollständigkeit erhebt ;)

 

Aber immerhin habe ich es geschafft in < 4000 Zeichen eine Richtung aufzuzeigen, bei der Du (glücklicherweise) nur wenige Ergänzungen hast. :D Unvollständig zwar, aber nicht grundsätzlich falsch.

 

Letztlich zeigt es aber, dass es doch nicht soooo einfach ist, auch wenn man es schon häufig gemacht hat. dazu ist es dann doch zu "komplex". Ich gehe davon aus, das der Kollege blue es bislang noch nie gemacht hat. Insofern ....

 

Abgesehen davon, holt man sich für sowas normalerweise sein komplettes Know How weder aus Büchern oder Foren, sondern kauft sich das zumindest anteilig ein.

 

Dem kann ich nichts hinzufügen.

 

grüße

 

dippas

[blueintheface 10]

Erst mal vielen Dank für eure ausführlichen und kompetenten Antworten, dippas und Norbert!

 

Bzgl. 64 bit-OS: über Nutzen und Risiken lässt sich natürlich vortrefflich streiten.

Da auf dem Server aber auch eine Oracle 10-DB plus Application-Server läuft (64-Bit tauglich

wie es sich heutzutage gehört) und schon allein 3GB der 8GB für sich beansprucht, und HP für die

Maschine (ProLiant DL 320 G5p) komplette und stabile 64-bit-Treiber liefert ist das Thema

eigentlich schon durch. Bleibt nur noch Microsoft mit seiner immer noch nicht durchgängigen

Unterstützung für 64-Bit unter W2K3, aber mit der R2 hat sich doch schon vieles verbessert

denke ich.

 

Es gibt sicher gute Gründe Exchange nicht auf einem DC zu betreiben, da fehlen mir die Kenntnisse

um das zu beurteilen, muss ich zugeben. Andererseits: Was ist mit dem SBS? Ist das kein DC? Und ist

Exchange nicht Bestandteil davon? Aber naja, der SBS ist wieder ein Speziallfall.

 

Jedenfalls hab ich den neuen Server erst mal als einfachen Member-Server in die Domäne integriert,

da die Oracle-Applikation laufen muss. Mir reicht auch der bisherige Server (dann am Standort B)

als alleiniger DC, ob die 15 User am Standort A für die Anmeldung an der Domäne durch den S-DSL

VPN-Tunnel müssen ist eigentlich Wurscht, zumindest was die Datenmenge anbetrifft. Es sei

denn es gibt andere, AD-spezifische Gründe die dagegen sprechen (z.B. der DC an Standort B ist

in einem anderen IP-Netz als die Clients an Standort A). Da könnt Ihr sicherlich was dazu sagen.

 

Grösster Knackpunkt ist aus meiner beschränkten Sicht dann der Exchange-Server, den ich schon gern

auf der neuen Maschine hätte (Exchange 2007 dann). Übrigens auch noch den WSUS 3, der Server soll

schliesslich was zu tun haben. :)

 

Ich gebe zu ich habe mich noch gar nicht damit befasst da ich grad anderes zu tun habe, aber wenn

schon davon abgeraten wird Exchange auf einem DC zu installieren, auf einem einfachen Member-Server

gehts sicher auch nicht, oder ???

 

 

Grüsse,

Blue

[phoenixcp 10]

Andererseits: Was ist mit dem SBS? Ist das kein DC? Und ist

Exchange nicht Bestandteil davon? Aber naja, der SBS ist wieder ein Speziallfall.

Gut erkannt ;) Der SBS ist ein sehr spezieller Spezialfall.

[NorbertFe 2.032]

Da auf dem Server aber auch eine Oracle 10-DB plus Application-Server läuft (64-Bit tauglich

 

Du willst Oracle 10g, Exchange 2007 und DC auf einer Kiste fahren? Viel Spaß im Fehlerfall.

 

Bye

Norbert

[Monarch 10]

Du hast offenbar zu viele Anwendungen mit unterschiedlichen Anforderungen für zu wenige Server ;)

 

So langsam aber sicher könnte man da einmal über Virtualisierung nachdenken...

 

mfg

Monarch

[blueintheface 10]

Du willst Oracle 10g, Exchange 2007 und DC auf einer Kiste fahren? Viel Spaß im Fehlerfall.

 

Nee, will ich nicht ganz.. DC darf gerne weg bleiben da.. wenns denn geht :)

Und wir reden hier über grade mal 15 User je Standort, von denen nur 5 mit der DB arbeiten, und das Mailaufkommen ist entsprechend gering.

 

Tja, Fehlerfall ist immer problematisch, und ob ich Exchange auf einer eigenen Maschine habe oder mit Oracle zusammen wäre weniger das Problem.. die Oracle-Anwendung/DB hab ich in 2 Stunden auf einer Ersatzmaschine wieder laufen, auf den Clients muss nur die IP-Nummer des Application-Servers angepasst werden. Den Exchange hätte ich in der Zeit so oder so nicht neu aufgebaut, jedenfalls ich nicht.

 

 

 

Du hast offenbar zu viele Anwendungen mit unterschiedlichen Anforderungen für zu wenige Server ;)

 

So langsam aber sicher könnte man da einmal über Virtualisierung nachdenken...

 

So viele Anwendungen sinds nun auch wieder nicht.. und über Virtualisierung hab ich in der Tat schon nachgedacht, bringt aber m.E. nichts in diesem Szenario.

 

 

 

Klar, man kann für jede Serveranwendung eine eigene Maschine hinstellen, vorrausgesetzt man hat das nötige Kleingeld, grade auch für die Folgekosten (zusätzliche Lizenzen für OS, Backup-Software etc., die Klimaanlage darf dann schon 'n bisschen dicker sein, die Energieversorger freuen sich das x Maschinen mit 2% CPU-Last XXX Watt verbrauchen usw.).

 

Aber da begeben wir uns in Grundsatzdiskussionen die hier Fehl am Platze sind, meiner Meinung nach jedenfalls :)

 

Grüße,

Blue

[phoenixcp 10]

Nee, will ich nicht ganz.. DC darf gerne weg bleiben da.. wenns denn geht

Aber da begeben wir uns in Grundsatzdiskussionen die hier Fehl am Platze sind, meiner Meinung nach jedenfalls

 

Ich seh das weniger als Grundsatzdiskussion. Wir versuchen hier immer wieder den TO's Best Practice Ansätze zu liefern und können diese nur durch eigene Erfahrungen und offizielle Dokumente / Dokumentationen seitens der jeweiligen SW-Hersteller untermauern. Ob du dich dann an den BP-Ansatz hälst, oder deine Schiene durchziehst, ist am Ende deine Sache.

 

Tja, Fehlerfall ist immer problematisch, und ob ich Exchange auf einer eigenen Maschine habe oder mit Oracle zusammen wäre weniger das Problem.. die Oracle-Anwendung/DB hab ich in 2 Stunden auf einer Ersatzmaschine wieder laufen, auf den Clients muss nur die IP-Nummer des Application-Servers angepasst werden. Den Exchange hätte ich in der Zeit so oder so nicht neu aufgebaut, jedenfalls ich nicht.

Und selbst da seh ich noch nicht, das du nach 2 Stunden Arbeit an der Oracle DB wieder online bist. Dann solltest du dir lieber Gedanken machen, ob du ein DB-Mirroring unter Oracle in Betracht ziehst und zwei Server hinstellst. Aus Erfahrung ist immer dann kein funktionierendes Backup da, wenn man denn mal eins braucht.

 

So viele Anwendungen sinds nun auch wieder nicht.. und über Virtualisierung hab ich in der Tat schon nachgedacht, bringt aber m.E. nichts in diesem Szenario.

Klar sind es nicht so viele Anwendungen, aber die Art und Weise der Anwendungen tut ihr übriges. Von daher finde ich den Einwand mit der Virtualisierung nicht so daneben, eher im Gegenteil.