Migration von SBS2K3 zu W2K3 Std. + Ex2K3 ohne Transition Pack?

[martins 11]

Was genau spricht gegen das schalten eines A-Records im public DNS und das ausstellen eines Zertifikats auf bspw. den Namen mail.deinedomain.tld? Hat erstmal genau gar nichts mit mx zu tun, oder? ;)

 

Den A-Record habe ich jetzt für eine Domain beim Hoster (1&1) erstellt, die nicht zum mailen genutzt wird (firmenname.eu). Der A-Record verweist auf die fixe IP-Adresse. Die Domain zum mailen ist "firmenname.de".

 

Funktioniert das so? Wenn ja, wie geht es weiter? :confused:

 

Grüße und Danke für euren Support.

 

Martin

[NorbertFe 1.799]

Den A-Record habe ich jetzt für eine Domain beim Hoster (1&1) erstellt, die nicht zum mailen genutzt wird (firmenname.eu). Der A-Record verweist auf die fixe IP-Adresse. Die Domain zum mailen ist "firmenname.de".

 

Funktioniert das so? Wenn ja, wie geht es weiter? :confused:

 

Grüße und Danke für euren Support.

 

Martin

 

Ich meinte damit, dass dein RPC over https nichts mit dem Schalten eines mx Records oder der Verwendung von POP3 zu tun hat. Eventuell erklärst du kurz, wo du Verständnisprobleme hast ;)

 

Bye

Norbert

[martins 11]

Ich meinte damit, dass dein RPC over https nichts mit dem Schalten eines mx Records oder der Verwendung von POP3 zu tun hat. Eventuell erklärst du kurz, wo du Verständnisprobleme hast ;)

 

Also...

Problem beim "RPC over HTTPs" sehe ich darin, dass wenn ich das am Exchange 2007 in der Zentrale konfiguriere das Problem auftritt, dass das in der Zweigstelle nicht funktioniert, da:

 

- der Name des Zertifikats auf den lokalen Exchange in der Zentrale zeigt (srv01.asdf.local), die User in der Zweigstelle aber ihre eigene Domäne haben.

 

Wenn ich aber nun ein Zertifikat ausstelle, welches von der Zweigstelle akzeptiert würde (z.B. mail.firmenname.com), bekommen die User der Zenrale ein Problem. Nämlich das beim starten von Outlook ein Fenster angezeigt wird: "Sicherheitshinweis" mit u.a. einem roten X "Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein"

 

Ich bin ein wenig ratlos! :confused:

 

Martin

[NorbertFe 1.799]

Ich bin ein wenig ratlos! :confused:

 

Martin

 

Das merkt man ;)

 

Also bei diversen Kunden funktioniert es genau so wie ich schrub ;)

 

bye

Norbert

[martins 11]

Das merkt man ;)

 

OK, noch ein Vorschlag?

 

 

Grüße,

 

Martin

[LukasB 10]

martins, ich hab jetzt den Thread mehrmals durchgelesen, und bin mir immer noch nicht sicher was genau dein Problem ist bzw. deine Frage ist.

 

Ich versuch mal zu rekapitulieren:

 

Du hast im Moment einen Forest mit Exchange, ad.firma.de mit E-Mail Domain firma.de - für RPC over HTTPS wird mail.firme.de verwendet.

 

Dann habt ihr eine Firma gekauft, diese hat einen SBS mit ad.gekauft.de - jetzt wollt ihr das ganze 1:1 weiterbetreiben.

 

Wie Dr. Melzer gesagt habt - ihr müsst Lizenztechnisch nichts ändern. Ihr könnt den SBS 1:1 weiterbetreiben, aber nicht integrieren.

 

Was willst du genau erreichen? Was ist das Ziel? Was soll mit dem SBS passieren? Wollt ihr den Auflösen und in eure Infrastruktur konsolidieren (d.h. eine zweite Recipient Policy? und dann Zugriff via RPC over HTTPS?).

 

Vielleicht ists Sinnvoll wenn du mal genau schilderst was:

 

Der Ist-Zustand ist

 

Der Soll-Zustand sein soll

[martins 11]

Hallo Lukas,

 

ich versuche es mal...

 

Der Ist-Zustand:

 

Firma A (Zentrale) mit Maildomäne @firmaA.de mit einer AD-Domäne abc.local

(W2K3 Domäne mit Exchange 2007)

 

Firma B (Niederlassung) mit Maildomäne @firmaA.de mit einer AD-Domäne xyz.local => Die Maildomäne von A und B ist also identisch!

(SBS2K3 Std. mit Exchange)

 

Es gibt eine 2 Mbit SDSL-Leitung

 

 

Ich hoffe das war jetzt nicht zu knapp!? :)

 

 

Soll-Zustand:

 

Der SBS2K3 in der Firma B (Niederlassung) soll aufgelöst werden (in eine stinknormale AD-Domäne, ohne Exchange), weil:

 

- Die Hardware sowieso ersetzt werden muss

- Kein IT-versiertes Personal am Standort B vorhanden ist

- Eine Maildomäne (@FirmaA.de) auch nur an einem Standort betrieben werden soll, bzw. deren Exchange-Server. Ich hätte es gerne zentralisiert, zumindest den Exchange!

 

=> Eigentlich hat das Unternehmen noch einen 3 Standort (um den geht es aber nicht, da wenn die Probleme mit dem Standort B gelöst sind, Standort C unproblematisch umgeswitcht werden kann).

 

Dadurch, dass es drei Standorte und zwei Exchange-Mailserver gibt (Standort A und Standort B jeweils Exchange) und noch einen Standort (an dem sich die Clients die Mails per PoP direkt bei 1&1 ziehen) der ebenfalls die gleiche Maildomäne (@FirmaA.de) nutzt, kommt es ab und an zu Routingproblemen. Auch deswegen will ich weg von dem derzeitigen Zustand.

 

ABER: Die AD-Domänen von Standort A und B sollen möglichst nicht verändert werden, Standort C hat keine Domäne.

 

1 Exchange und die Clients der Standorte B (ca. 10) und C (3 Clients) ziehen sich ihre Mails direkt vom Exchange der Zentrale. Keine Routingprobleme mehr und die Mails werden zentral an einem Standort gesichert.

 

 

Alle Klarheiten beseitigt? :D

 

Gruß,

 

Martin

[LukasB 10]

Firma A (Zentrale) mit Maildomäne @firmaA.de mit einer AD-Domäne abc.local

(W2K3 Domäne mit Exchange 2007)

 

Firma B (Niederlassung) mit Maildomäne @firmaA.de mit einer AD-Domäne xyz.local => Die Maildomäne von A und B ist also identisch!

(SBS2K3 Std. mit Exchange)

 

Wie hast du die Mail-Anbindung realisiert vom Routing der Adressen zwischen den Standorten? Mit einem POP3-Connector?

 

Ich hoffe das war jetzt nicht zu knapp!? :)

 

Schonmal viel besser, ich kann mir jetzt vorstellen um was es geht.

 

Der SBS2K3 in der Firma B (Niederlassung) soll aufgelöst werden (in eine stinknormale AD-Domäne, ohne Exchange), weil:

 

- Die Hardware sowieso ersetzt werden muss

 

Der SBS ist doch ziemlich sicher eine OEM/OSB-Version, oder? Dann brauchst den sowieso neue Lizenzen.

 

Auf der neuen Hardware kannst du dann einen Stinknormalen WS2003 DC deployen, in deiner momentanen Domain. Die User kannst du dann neu erfassen oder mit ADMT migrieren (ich bin nur mit 100% sicher ob das mit SBS geht, aber glaube schon).

 

- Kein IT-versiertes Personal am Standort B vorhanden ist

- Eine Maildomäne (@FirmaA.de) auch nur an einem Standort betrieben werden soll, bzw. deren Exchange-Server. Ich hätte es gerne zentralisiert, zumindest den Exchange!

 

Je nach Grösse ist das absolut Sinnvoll - wir haben Intern bei unserer 10MA Aussenstelle auch keinen separaten Exchange - Outlook 2007 und Cached Exchange machts möglich.

 

Dadurch, dass es drei Standorte und zwei Exchange-Mailserver gibt (Standort A und Standort B jeweils Exchange) und noch einen Standort (an dem sich die Clients die Mails per PoP direkt bei 1&1 ziehen) der ebenfalls die gleiche Maildomäne (@FirmaA.de) nutzt, kommt es ab und an zu Routingproblemen. Auch deswegen will ich weg von dem derzeitigen Zustand.

 

Ah, also verwendest du POP3 um die Mails zu holen. Okay, das ist natürlich ein ziemliches Disaster - aber gut, davon kommt man leicht weg.

 

ABER: Die AD-Domänen von Standort A und B sollen möglichst nicht verändert werden, Standort C hat keine Domäne.

 

Ich frag jetzt natürlich mal doof - wieso? Willst du wirklich für einen zweiten Standort eine eigene Domain betreuen müssen? Vorallem da du wg. der Hardware eh migrieren musst - zügel die User doch gleich in eure richtige Domain. Sieht dann auch vom Branding her schöner aus.

 

Alle Klarheiten beseitigt? :D

 

Die Frage die sich mir jetzt noch stellt ist wieso du auf irgendeine Art und Weise Probleme mit RPC over HTTPS, SSL Zertifikaten etc. siehst.

[martins 11]

Wie hast du die Mail-Anbindung realisiert vom Routing der Adressen zwischen den Standorten? Mit einem POP3-Connector?

 

Korrekt, Standort A und B PoPpen (GFI-MailEssentials), bei Standort C poppt Outlook direkt mit 1&1.:cool:

 

 

 

Der SBS ist doch ziemlich sicher eine OEM/OSB-Version, oder? Dann brauchst den sowieso neue Lizenzen.

 

Auf der neuen Hardware kannst du dann einen Stinknormalen WS2003 DC deployen, in deiner momentanen Domain. Die User kannst du dann neu erfassen oder mit ADMT migrieren (ich bin nur mit 100% sicher ob das mit SBS geht, aber glaube schon).[/Quote]

 

Jupp, der SBS ist OEM. Wenn das migrieren der Benutzerkonten mit ADMT unter SBS funktioniert, Bingo!

 

 

 

Die AD-Domänen von Standort A und B sollen möglichst nicht verändert werden, Standort C hat keine Domäne.[/Quote]

 

Ich frag jetzt natürlich mal doof - wieso? Willst du wirklich für einen zweiten Standort eine eigene Domain betreuen müssen? Vorallem da du wg. der Hardware eh migrieren musst - zügel die User doch gleich in eure richtige Domain. Sieht dann auch vom Branding her schöner aus.[/Quote]

 

Weil ich noch nie eine bestehende Domäne in eine andere bestehende Domäne gepusht habe. :nene: :shock:

 

... Vielleicht sollte ich das mal ändern!? ;)

 

 

Die Frage die sich mir jetzt noch stellt ist wieso du auf irgendeine Art und Weise Probleme mit RPC over HTTPS, SSL Zertifikaten etc. siehst.[/Quote]

 

Ich hab es ja schon ausgetestet...

 

Standort A = Zertifikatsname für OWA/Outlook Anywhere: mailserver.abc.local

Ich brauche aber noch ein zweites Zertifikat, wenn ich von aussen an den Exchange möchte... nämlich z.B.: mail.firmaA.de

 

und genau dann, wenn ich Zertifikat 2 hinzufüge (über Standardwebsite des IIS), erscheint die Fehlermeldung beim öffnen von Outlook: "Sicherheitshinweis" mit u.a. einem roten X "Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein"

 

Und ohne funktionierende Zertifikate kein RPC over HTTPS!?

:confused::suspect::nene:

 

Gruß,

 

Martin

[LukasB 10]

Jupp, der SBS ist OEM. Wenn das migrieren der Benutzerkonten mit ADMT unter SBS funktioniert, Bingo!

 

Muss man halt testen - ich kenn nicht alle SBS Restriktionen auswendig.

 

Weil ich noch nie eine bestehende Domäne in eine andere bestehende Domäne gepusht habe. :nene: :shock:

 

Aber vorher mal testen. So schlimm ist das ganze nicht, zumindest in SBS Dimensionen - man kann ja immer noch hingehen und Zeug von Hand flicken.

 

Standort A = Zertifikatsname für OWA/Outlook Anywhere: mailserver.abc.local

Ich brauche aber noch ein zweites Zertifikat, wenn ich von aussen an den Exchange möchte... nämlich z.B.: mail.firmaA.de

 

Ja, jetzt hast du zwei Möglichkeiten. Eine VPN Verbindung brauchst du eigentlich eh zwischen den Standorten, und dann kann Standort b auch mit mailserver.abc.local etwas anfangen - das kannst du problemlos zum laufen bringen bevor du den SBS migrierst.

 

Die Variante B, und eigentlich die bessere, ist wenn du RPC over HTTPS generell auf mail.firmaA.de umstellst - weil dann kommen die Leute auch Mobil, von draussen an ihre Mail. Dazu musst du die Config in deiner Original-Domain umkonfigurieren. Gibt schlimmeres.

[martins 11]

Ja, jetzt hast du zwei Möglichkeiten. Eine VPN Verbindung brauchst du eigentlich eh zwischen den Standorten, und dann kann Standort b auch mit mailserver.abc.local etwas anfangen - das kannst du problemlos zum laufen bringen bevor du den SBS migrierst.[/Quote]

 

Aber um das VPN möchte ich herumkommen. 24x7 Erreichbarkeit... ich trau dem Braten da nicht.

 

Es muss doch möglich sein, das ganze ohne VPN zu realisieren!? :confused:

 

Die Variante B, und eigentlich die bessere, ist wenn du RPC over HTTPS generell auf mail.firmaA.de umstellst - weil dann kommen die Leute auch Mobil, von draussen an ihre Mail. Dazu musst du die Config in deiner Original-Domain umkonfigurieren. Gibt schlimmeres.

 

Einige Mitarbeiter der Zentrale arbeiten bereits mit OWA... dann erscheint derzeit noch der hässliche "Zertifikatsfehler", wenn die OWA-Seite aufgerufen wird: https://festeip/owa, da das Zertifikat ja auf exchange.abc.local ausgestellt ist.

 

Stell ich das wie gesagt auf die Maildomäne um (mail.firmaA.de), kommt beim starten von Outlook der Sicherheitshinweis. :(

 

Also einen Fehler habe ich immer... entweder meckert Outlook, wenn ich von intern auf das externe Zertifikat zugreifen möchte oder OWA (von extern) meckert, wenn das Zertifikat auf den lokalen Exchange zeigt.

 

Die Lösung kann ja auch nicht sein, dass die User der Zentrale sich ihre lokalen Mails über das Internet am lokalen Exchange abrufen. Das wäre doch dann sicherlich so, wenn ich im Zertifikat "mail.firmaA.de" eintragen würde!?

 

 

 

Gruß,

 

Martin

[LukasB 10]

Aber um das VPN möchte ich herumkommen. 24x7 Erreichbarkeit... ich trau dem Braten da nicht.

Es muss doch möglich sein, das ganze ohne VPN zu realisieren!? :confused:

 

Für Exchange alleine schon, für eine gemeinse Domain nicht. Wo siehst du das Problem? Eine Aussenstelle sauber integrieren - wie wollt ihr Gegenseitig auf Fileshares zugreifen? Sharepoint? Voice over IP? Drucken? ERP? etc. pp.

 

Stell ich das wie gesagt auf die Maildomäne um (mail.firmaA.de), kommt beim starten von Outlook der Sicherheitshinweis. :(

 

Dann konfigurier die Clients um!

 

Die Lösung kann ja auch nicht sein, dass die User der Zentrale sich ihre lokalen Mails über das Internet am lokalen Exchange abrufen. Das wäre doch dann sicherlich so, wenn ich im Zertifikat "mail.firmaA.de" eintragen würde!?

 

Nein, würden sie nicht. Ersten kannst du in Outlook einstellen ob es zuerst RPC oder RPC over HTTPs probieren soll, zweiten kannst du Zugriff auf RPC over HTTPS intern sperren (über IIS IP-Beschränkungen), dann verwenden die Clients automatisch RPC.

[martins 11]

Für Exchange alleine schon, für eine gemeinse Domain nicht. [/Quote]

Ich will ja nur Exchange, nur Exchange!

 

wie wollt ihr Gegenseitig auf Fileshares zugreifen? Sharepoint? Voice over IP? Drucken? ERP? etc. pp.[/Quote]

Das läuft alles über Citrix (natürlich auch per Telekom-VPN). Aber je wichtiger die VPN-Leitung wird, desto größer ist das Geschrei bei einem Ausfall. Wie gesagt... nur Exchange!

 

Dann konfigurier die Clients um![/Quote]

Eine Idee in welche Richtung ich sie konfiguriere? :confused:

 

Nein, würden sie nicht. Ersten kannst du in Outlook einstellen ob es zuerst RPC oder RPC over HTTPs probieren soll, zweiten kannst du Zugriff auf RPC over HTTPS intern sperren (über IIS IP-Beschränkungen), dann verwenden die Clients automatisch RPC.

 

So eine Einstellmöglichkeit ist mir noch nicht begegnet. Schieß los! :D

[LukasB 10]

Ich will ja nur Exchange, nur Exchange!

 

Das läuft alles über Citrix (natürlich auch per Telekom-VPN). Aber je wichtiger die VPN-Leitung wird, desto größer ist das Geschrei bei einem Ausfall. Wie gesagt... nur Exchange!

 

Ja wie jetzt? Ein VPN Tunnel ist genau gleich zuverlässig wie die Internetleitung - wenn Citrix tut, dann tut auch VPN - wenn Citrix ned tut, dann tut auch VPN nicht.

 

Eine Idee in welche Richtung ich sie konfiguriere? :confused:

 

Den RPCoHTTPS Namen auf den externen Namen umstellen.

 

So eine Einstellmöglichkeit ist mir noch nicht begegnet. Schieß los! :D

 

[martins 11]

Morgen mehr... ich muss jetzt zu Frau und Kind! :)

 

VIELEN DANK bis hierher.

 

Grüße in die Schweiz!

 

Martin