8
Nach Serverwechsel (Exchange 03) unter Verbindungsstatus Outlook immer noch alter Server bei Verzeichnis
Weiterhin Zugriff auf Verzeichnis des alten Exchange 03 bei Outlook
Hallo Community!
leider beschäftigt mich immer noch das Übersiedeln des Exchange 03 auf eine neue Hardware. Nach erfolgreichen Übersiedeln der Mailboxes, Öffentlichen Ordners, OAB, etc. und anpassen der Master-Rolle versuchen die Outlook-Clients immer noch (ersichtlich unter Verbindungsstatus) auf die Verzeichnisse des alten Exchange 03 zuzugreifen. Der "alte" Exchange wurde noch nicht vom Netz genommen aus Sicherheitsgründen, jedoch wurden alle Ordner bereits repliziert und der Mailverkehr rennt einwandfrei schon über den neuen Server.
Nun meine Frage: Um welche Verzeichnisse handelt es sich, auf die Outlook (unter Verbinungsstatus) zugreift? Und wie bringe ich den Clients bei diese nun auf den neuen Server (Servername) abzugreifen? Bei Mail wird bereits auf den neuen Server zugegriffen. Einzig die Verzeichnisse können bspw. bei Zugriff über RPC/Https nicht erreicht werden!
Vielen lieben Dank für Euren Support und noch ein schönes WE!!!
leider beschäftigt mich immer noch das Übersiedeln des Exchange 03 auf eine neue Hardware. Nach erfolgreichen Übersiedeln der Mailboxes, Öffentlichen Ordners, OAB, etc. und anpassen der Master-Rolle versuchen die Outlook-Clients immer noch (ersichtlich unter Verbindungsstatus) auf die Verzeichnisse des alten Exchange 03 zuzugreifen. Der "alte" Exchange wurde noch nicht vom Netz genommen aus Sicherheitsgründen, jedoch wurden alle Ordner bereits repliziert und der Mailverkehr rennt einwandfrei schon über den neuen Server.
Nun meine Frage: Um welche Verzeichnisse handelt es sich, auf die Outlook (unter Verbinungsstatus) zugreift? Und wie bringe ich den Clients bei diese nun auf den neuen Server (Servername) abzugreifen? Bei Mail wird bereits auf den neuen Server zugegriffen. Einzig die Verzeichnisse können bspw. bei Zugriff über RPC/Https nicht erreicht werden!
Vielen lieben Dank für Euren Support und noch ein schönes WE!!!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 131009
Url: https://administrator.de/contentid/131009
Printed on: April 25, 2024 at 23:04 o'clock
8 Comments
Latest comment
Hallo,
das "Verzeichnis" im Outlook-Verbindungsmonitor meint die Globale Adressliste (nicht etwa Public Folder).
Beim direkten Zugriff (RPC, innerhalb des gleichen Netzes) wird die "Verzeichnis" Verbindung i.A. direkt zum DC aufgebaut. Bei RPC-over-HTTPS kennt Outlook den DC nicht und verbindet deswegen erstmal zu Exchange. Bis SP1 wird es von da an den DC weitergeleitet, ab SP1 fungiert Exchange für den Client als Proxy (DsProxy).
Frage also erstmal: Diese "Verzeichnis"-Einträge mit dem alten Exchange als Server hast du nur beim HTTP-Zugriff, oder?
Wenn ja: woher ist wohl die Frage. Bei der Aktivierung als RPC-over-HTTP-Zugriff müssen auf Front- und Backend ein par Registry-Keys gesetzt werden. Vielleicht ging dabei der für DsProxy unter. Schaue dir mal http://www.msxfaq.de/clients/rpchttp.htm an. Wir hatten auch mal einen Fall, dass ein Port von einer anderen Software blockiert wurde, daher ist auch das in dem Artikel beschriebene netstat wichtig.
Gruß
Filipp
das "Verzeichnis" im Outlook-Verbindungsmonitor meint die Globale Adressliste (nicht etwa Public Folder).
Beim direkten Zugriff (RPC, innerhalb des gleichen Netzes) wird die "Verzeichnis" Verbindung i.A. direkt zum DC aufgebaut. Bei RPC-over-HTTPS kennt Outlook den DC nicht und verbindet deswegen erstmal zu Exchange. Bis SP1 wird es von da an den DC weitergeleitet, ab SP1 fungiert Exchange für den Client als Proxy (DsProxy).
Frage also erstmal: Diese "Verzeichnis"-Einträge mit dem alten Exchange als Server hast du nur beim HTTP-Zugriff, oder?
Wenn ja: woher ist wohl die Frage. Bei der Aktivierung als RPC-over-HTTP-Zugriff müssen auf Front- und Backend ein par Registry-Keys gesetzt werden. Vielleicht ging dabei der für DsProxy unter. Schaue dir mal http://www.msxfaq.de/clients/rpchttp.htm an. Wir hatten auch mal einen Fall, dass ein Port von einer anderen Software blockiert wurde, daher ist auch das in dem Artikel beschriebene netstat wichtig.
Gruß
Filipp
Danke für die rasche Antwort!
Also zur Architektur verwenden wir nur einen Exchange-Server (also keine Front-/Backend Lösung).
Innerhalb des Firmennetzes verbindet sich Outlook ebenfalls zu 7 "Verzeichnisse" am DomainController, welcher ursprünglich den Exchange03 zur Verfügung stellte. Zwei Verbindungen zu "E-Mail" und eine zu "Öffentliche-Ordner" wird lt. Verbindungsstatus erfolgreich zum neuen Exchange03 verbunden.
Die externen Clients können sich aufgrund Portforwarding zum neuen Exchange03 nicht zu die "Verzeichnisse" verbinden (via RPC/Https), was meiner Meinung nach auch mein aktuelles Problem mit dem Verbindungsfehler zu Exchange Server begründet.
Die notwendigen Reg-Einträge (Ports, etc.) wurden lt. Msxfaq.de zuvor gesetzt und auch Netstat liefert das gewünscht Ergebnis. Irgendwie befürchte ich dass dann die Globale Adressliste immer noch am alten und nicht am neuen Exchange Server liegt?!?!
Also zur Architektur verwenden wir nur einen Exchange-Server (also keine Front-/Backend Lösung).
Innerhalb des Firmennetzes verbindet sich Outlook ebenfalls zu 7 "Verzeichnisse" am DomainController, welcher ursprünglich den Exchange03 zur Verfügung stellte. Zwei Verbindungen zu "E-Mail" und eine zu "Öffentliche-Ordner" wird lt. Verbindungsstatus erfolgreich zum neuen Exchange03 verbunden.
Die externen Clients können sich aufgrund Portforwarding zum neuen Exchange03 nicht zu die "Verzeichnisse" verbinden (via RPC/Https), was meiner Meinung nach auch mein aktuelles Problem mit dem Verbindungsfehler zu Exchange Server begründet.
Die notwendigen Reg-Einträge (Ports, etc.) wurden lt. Msxfaq.de zuvor gesetzt und auch Netstat liefert das gewünscht Ergebnis. Irgendwie befürchte ich dass dann die Globale Adressliste immer noch am alten und nicht am neuen Exchange Server liegt?!?!
Hallo,
Wenn der neue Exchange kein GC ist muss der Zugriff weiterhin auf den alten stattfinden. Dazu sollte der DsProxy auf dem neuen Exchange ein porxying durchführen. Wenn er das nicht tut wird's schwierig...
Gruß
Filipp
Also zur Architektur verwenden wir nur einen Exchange-Server (also keine Front-/Backend Lösung).
Okay, dann muss das manuell konfiguriert werden, steht in dem Artikel, hasst du also überprüft(?).Die externen Clients können sich aufgrund Portforwarding zum neuen Exchange03 nicht zu die "Verzeichnisse"
verbinden (via RPC/Https), was meiner Meinung nach auch mein aktuelles Problem mit dem Verbindungsfehler zu Exchange Server
begründet.
Was für ein Portforwarding? Von einer globalen IP (die extern anliegt) auf Firewall/Router Port 443 auf den neuen Exchange? Das sollte schon passen. Der gesamte Verkehr geht in HTTPS getunnelt zum Exchange (normalerweise Frontend) und wird dort durch den RCP-Proxy ausgepackt und an die einzelnen Dienste (Store, DSProxy) verteilt. Letzteres sind dann interne Netzzugriffe, im internen Netz sollte es kein Portforwarding geben.verbinden (via RPC/Https), was meiner Meinung nach auch mein aktuelles Problem mit dem Verbindungsfehler zu Exchange Server
begründet.
Die notwendigen Reg-Einträge (Ports, etc.) wurden lt. Msxfaq.de zuvor gesetzt und auch Netstat liefert das gewünscht
Irgendwie befürchte ich dass dann die Globale Adressliste immer noch am alten und nicht am neuen Exchange Server
liegt?!?!
Die GAL liegt gar nicht am Exchange-Server. Sie liegt auf einem DC, oder genauer gesagt GC. Der alte Server war Exchange + DC(+GC), richtig? Ist denn der neue auch ein GC? Wenn der Exchange-Backend gleichzeitig GC ist, ist das noch etwas anders zu konfigurieren, siehe http://technet.microsoft.com/en-us/library/bb125001(EXCHG.65).aspxIrgendwie befürchte ich dass dann die Globale Adressliste immer noch am alten und nicht am neuen Exchange Server
liegt?!?!
Wenn der neue Exchange kein GC ist muss der Zugriff weiterhin auf den alten stattfinden. Dazu sollte der DsProxy auf dem neuen Exchange ein porxying durchführen. Wenn er das nicht tut wird's schwierig...
Gruß
Filipp
Also die Konfiguration abhängig meiner Architektur habe ich lt. Anleitung durchgeführt, hat genauso früher auch am "alten" Exchange 03 funktioniert!
Portforwarding für die öffentliche IP mit folgenden Ports an den neuen Exchange geleitet: 443 (SSL), 593 (RPC) und natürlich 25 und 110 für Empfangen und Senden, das klappt aber eh! Zugriff auf den alten Exchange03 gibt es keinen durch Portweiterleitung!
Der neue Exchange-Server wurde als weitere DC installiert, jedoch liegt tatsächlich der GC noch am ersten DC! (lt. NTDS Setting). Sollte nun ein einfaches Entfernen des GC am alten und ein Hinzufügen des GC am neuen mein Problem lösen!???
Vielen Dank für dein Bemühen!
Portforwarding für die öffentliche IP mit folgenden Ports an den neuen Exchange geleitet: 443 (SSL), 593 (RPC) und natürlich 25 und 110 für Empfangen und Senden, das klappt aber eh! Zugriff auf den alten Exchange03 gibt es keinen durch Portweiterleitung!
Der neue Exchange-Server wurde als weitere DC installiert, jedoch liegt tatsächlich der GC noch am ersten DC! (lt. NTDS Setting). Sollte nun ein einfaches Entfernen des GC am alten und ein Hinzufügen des GC am neuen mein Problem lösen!???
Vielen Dank für dein Bemühen!
Hallo,
Frage ist noch, was du mittelfristig mit dem alten Server vorhast. Oben schreibst du "Der "alte" Exchange wurde noch nicht vom Netz genommen aus Sicherheitsgründen". Nimm ihn auf keinen Fall einfach "vom Netz", sondern deinstallier ihn auf jeden Fall sauber (sowohl Exchange, als auch DC)!
Gruß
Filipp
Also die Konfiguration abhängig meiner Architektur habe ich lt. Anleitung durchgeführt, hat genauso früher auch am
"alten" Exchange 03 funktioniert!
Naja... irgendwo scheint ja ein Fehler zu sein, oder auch ein Unterschied zu dem alten Exchange. Und die Forenteilnehmer sollten schon auch etwas über die Architektur erfahren, sonst wird das mit der Hilfe schwierig. Aber ich glaube, so langsam verdeutlicht sich dieser Punkt..."alten" Exchange 03 funktioniert!
Portforwarding für die öffentliche IP mit folgenden Ports an den neuen Exchange geleitet: 443 (SSL), 593 (RPC) und
natürlich 25 und 110 für Empfangen und Senden, das klappt aber eh!
Port 593 brauchst du nicht. 110 nur, wenn externe Nutzer auch POP3 machen sollen (aber ich dachte, die machen RPC-over-HTTPs. Und wenn sie POP3 machen solltest du dir POP3 TLS und SSL nochmal anschauen). Port 25 brauchst du nur, wenn die Mails per MX an dich zugestellt werden, nicht wenn du sie per POP3-Connector abholst.natürlich 25 und 110 für Empfangen und Senden, das klappt aber eh!
Der neue Exchange-Server wurde als weitere DC installiert, jedoch liegt tatsächlich der GC noch am ersten DC! (lt. NTDS
Setting). Sollte nun ein einfaches Entfernen des GC am alten und ein Hinzufügen des GC am neuen mein Problem lösen!???
Kann gut sein, dass das hinzufügen der GC-Rolle das Problem löst (die auf dem alten solltest du trotzdem erst später entfernen, GCs kannst du beliebig viele haben), wäre wohl einen Versuch wert. Auch wenn damit die eigentliche Ursache dann nicht gefunden ist (sollte auch funktionieren, wenn der GC auf einem anderen Server ist als der Exchange, bzw. das ist ja eigentlich sogar der Normalfall). Beachte den von mir geposteten Technet Artikel zu Ex + GC auf gleichem Server.Setting). Sollte nun ein einfaches Entfernen des GC am alten und ein Hinzufügen des GC am neuen mein Problem lösen!???
Frage ist noch, was du mittelfristig mit dem alten Server vorhast. Oben schreibst du "Der "alte" Exchange wurde noch nicht vom Netz genommen aus Sicherheitsgründen". Nimm ihn auf keinen Fall einfach "vom Netz", sondern deinstallier ihn auf jeden Fall sauber (sowohl Exchange, als auch DC)!
Gruß
Filipp
Danke für den Hinweis!!
Grundsätzlich nochmal zu meiner Architektur: Bis dato hatten wir nur einen Server als DC, Exchange03 (Standard SP2) Server, etc.! Aus Gründen der Performance wurde nun ein weiterer Domaincontroller (Memberserver) im Netzwerk installiert, auf welchen nun Exchange03 läuft. Es wurden also sämtliche Postfächer und Ordner auf den neuen Server verschoben bzw. repliziert. Das alte Exchange bleibt jedoch noch so lange am ersten Server installiert, bis ich sicher bin dass keine Dienste mehr auf den alten Exchange zugreifen. Danach wird das alte Exchange sauber entfernt und der erste Server wird weiterhin als DC genutzt. Es wird also keine Front-/Backend Architektur angestrebt!
Der Mailempfang erfolgt über MX-Record auf unsere öffentliche IP, also vielen Dank für den Hinweis über die (unnötigen) Ports. Die externen Nutzer greifen wie richtig erwähnt via RPC-over-HTTPS auf den Server zu! D.h. es müssen nur Port 25 (Empfang) und 443 (SSL) geöffnet sein. Diese Ports werden Netzintern nun auf den "neuen" Exchange-Server geleitet. (Zuvor wurden diese logischerweise auf den ersten Server umgeleitet)
Da nun der erste respektive alte Exchange-Server von "außen" nicht mehr erreichbar ist, ist auch der GC für die externen Nutzer nicht mehr erreichbar. Deshalb meine Vermutung auch dass die externen Nutzer die Fehlermeldung im Outlook erhalten der Exchange Server sei nicht erreichbar bzw. nicht online. Ich werde nun auch den GC auf den neuen Exchange zur Verfügung stellen (lt. Technet Artikel) und hoffe dass damit die externen Clients auch automatisch bei Verbindungsaufbau die "Verzeichnisse" am neuen Exchange suchen und finden!?!
Danke nochmals, ich werde morgen berichten ob diese Änderung zum gewünschten Ergebnis geführt hat!
Grundsätzlich nochmal zu meiner Architektur: Bis dato hatten wir nur einen Server als DC, Exchange03 (Standard SP2) Server, etc.! Aus Gründen der Performance wurde nun ein weiterer Domaincontroller (Memberserver) im Netzwerk installiert, auf welchen nun Exchange03 läuft. Es wurden also sämtliche Postfächer und Ordner auf den neuen Server verschoben bzw. repliziert. Das alte Exchange bleibt jedoch noch so lange am ersten Server installiert, bis ich sicher bin dass keine Dienste mehr auf den alten Exchange zugreifen. Danach wird das alte Exchange sauber entfernt und der erste Server wird weiterhin als DC genutzt. Es wird also keine Front-/Backend Architektur angestrebt!
Der Mailempfang erfolgt über MX-Record auf unsere öffentliche IP, also vielen Dank für den Hinweis über die (unnötigen) Ports. Die externen Nutzer greifen wie richtig erwähnt via RPC-over-HTTPS auf den Server zu! D.h. es müssen nur Port 25 (Empfang) und 443 (SSL) geöffnet sein. Diese Ports werden Netzintern nun auf den "neuen" Exchange-Server geleitet. (Zuvor wurden diese logischerweise auf den ersten Server umgeleitet)
Da nun der erste respektive alte Exchange-Server von "außen" nicht mehr erreichbar ist, ist auch der GC für die externen Nutzer nicht mehr erreichbar. Deshalb meine Vermutung auch dass die externen Nutzer die Fehlermeldung im Outlook erhalten der Exchange Server sei nicht erreichbar bzw. nicht online. Ich werde nun auch den GC auf den neuen Exchange zur Verfügung stellen (lt. Technet Artikel) und hoffe dass damit die externen Clients auch automatisch bei Verbindungsaufbau die "Verzeichnisse" am neuen Exchange suchen und finden!?!
Danke nochmals, ich werde morgen berichten ob diese Änderung zum gewünschten Ergebnis geführt hat!
Guten Morgen!
Nachdem ich nun den GC auch auf den neuen Exchange03 zur Verfügung gestellt habe, versuchen sich die externen Clients zumindest gänzlich mit dem neuen Exchange-Server zu verbinden (lt. outlook.exe /rpcdiag). Verbindungsaufbau funktioniert jedoch leider trotzdem noch nicht!
Im LAN funktioniert der Test mit rpcdiag problemlos und eine Verbindung via HTTPS wird zum neuen Exchange aufgebaut!
Der NETSTAT Test liefert folgendes Ergebnis: Server horcht u.a. auf 6001, 6002 & 6004
Da ich ein Zertifikat von StartCom verwende und diese auch am Server sowie Client installiert habe (OWA über https funktioniert fehlerfrei), weiß ich leider nicht mehr weiter wo das RPC over HTTPS Problem nun liegen kann!
Bin für jeden Hinweis sehr sehr dankbar!!!
Nachdem ich nun den GC auch auf den neuen Exchange03 zur Verfügung gestellt habe, versuchen sich die externen Clients zumindest gänzlich mit dem neuen Exchange-Server zu verbinden (lt. outlook.exe /rpcdiag). Verbindungsaufbau funktioniert jedoch leider trotzdem noch nicht!
Im LAN funktioniert der Test mit rpcdiag problemlos und eine Verbindung via HTTPS wird zum neuen Exchange aufgebaut!
Der NETSTAT Test liefert folgendes Ergebnis: Server horcht u.a. auf 6001, 6002 & 6004
Da ich ein Zertifikat von StartCom verwende und diese auch am Server sowie Client installiert habe (OWA über https funktioniert fehlerfrei), weiß ich leider nicht mehr weiter wo das RPC over HTTPS Problem nun liegen kann!
Bin für jeden Hinweis sehr sehr dankbar!!!
Ich war wohl etwas zu ungeduldig um das Replizieren des GC abzuwarten!
Es funktioniert nun auch der Zugriff via RPC over HTTPS!
Danke nochmals!!
Es funktioniert nun auch der Zugriff via RPC over HTTPS!
Danke nochmals!!
