4
Exchange 2013 - Änderung Domain Mailadressen
Hallo zusammen,
mal gleich mit der Tür ins Haus
:
folgende Konfiguration:
Ein Beispiel für die Konten:
- IMAP: user1@domain.de
- Exchange: user1@domain.de
Der Exchangeserver wird nur für interne Kommunikation, Kalender / Aufgaben, und als Archiv verwendet. Es sind keine Konnektoren fürs Versenden/Empfangen eingerichtet.
Nun möchte ich - in der Hoffnung, dass einige Outlookprobleme damit verschwinden - die Exchangedomäne ändern.
Damit das Ganze nach der Umstellung wie folgt aussieht:
- IMAP: user1@domain.de
- Exchange: user1@domain-exchange.de (gültige; vom Büro registrierte Domain; brauche ich die eigentlich oder könnte/sollte ich ne Phantasiedoamin verwenden?)
Bevor ich diesen Schritt durchführe, möchte ich noch bei Experten (Euch) nachfragen, ob ich mir das zu leicht vorstelle bzw. etwas übersehe.
Ich habe den Exchaneg damals eingerichtet, kenne mich grundlegend aus, bin aber kein Experte, da es nicht mein täglich Brot ist.
Ich würde in der Exchange Konsole einfach unter Nachrichtenfluss-E-Mail-Adressrichtlinien->E-Mail->Adressformat den Standarf von *@domain.de auf *@domain-exchange.de ändern.
Durch diesen Schritt gehe ich davon aus, dass die bestehenden Mailadressen der user (user1@domain.de -> user1@domain-exchange.de) automatisch geändert werden. Wenn nicht, würde ich in den entsprechenden Postfächern die Mailadresse manuell anpassen.
Anschließend werde ich die Outlookprofile neu einrichten müssen (Exchange löschen->neu anlegen) (ist ne kleine Umgebung).
Unsicherheiten sehe ich vorallem darin, dass wir für den Exchange eine eigene Subdomain mit gültigem SSL Zertifikat erstellt haben.
z.B. exchange.domain.de, damit wir ActiveSync (primär Kalender) nutzen können.
Dies und Autodiscover hatten mich damals bei der Einrichtung ziemlich geärgert - lief dann aber bis zuletzt reibunglos (bis der erste Outlook 2016 Client kam, der nun scheinbar wg. identischer Kontonamen/Mailadressen Probleme macht).
Sehr ihr ein Problem darin, wenn ich die Active-Sync bzw. OWA Url bei der alten URL belasse? Autodiscover sollte ja auch weiterhin funktionieren; da ja der _AutoDiscover DNS Eintrag gesucht wird, dieser auf exchange.domain.de verweist und Exchange Anhand des Usernamen die korrekte - neue - Mailadresse (user1@domain-exchange.de) zurückliefern müsste...
Für Tipps/Ratschläge wäre ich sehr dankbar
Viele Grüße,
Malungo
mal gleich mit der Tür ins Haus
:folgende Konfiguration:
- Exchange 2013
- Outlook 2010 / 2016 Clients mit jeweils Exchangekonto und IMAP Konto
- Beide Mailkonten heißen gleich, was wohl in Outlook 2016 vermehrt zu Problemen führt (Microsoft Outlook 2010,2016 - diverse, frustrierende Bugs)
Ein Beispiel für die Konten:
- IMAP: user1@domain.de
- Exchange: user1@domain.de
Der Exchangeserver wird nur für interne Kommunikation, Kalender / Aufgaben, und als Archiv verwendet. Es sind keine Konnektoren fürs Versenden/Empfangen eingerichtet.
Nun möchte ich - in der Hoffnung, dass einige Outlookprobleme damit verschwinden - die Exchangedomäne ändern.
Damit das Ganze nach der Umstellung wie folgt aussieht:
- IMAP: user1@domain.de
- Exchange: user1@domain-exchange.de (gültige; vom Büro registrierte Domain; brauche ich die eigentlich oder könnte/sollte ich ne Phantasiedoamin verwenden?)
Bevor ich diesen Schritt durchführe, möchte ich noch bei Experten (Euch) nachfragen, ob ich mir das zu leicht vorstelle bzw. etwas übersehe.
Ich habe den Exchaneg damals eingerichtet, kenne mich grundlegend aus, bin aber kein Experte, da es nicht mein täglich Brot ist.
Ich würde in der Exchange Konsole einfach unter Nachrichtenfluss-E-Mail-Adressrichtlinien->E-Mail->Adressformat den Standarf von *@domain.de auf *@domain-exchange.de ändern.
Durch diesen Schritt gehe ich davon aus, dass die bestehenden Mailadressen der user (user1@domain.de -> user1@domain-exchange.de) automatisch geändert werden. Wenn nicht, würde ich in den entsprechenden Postfächern die Mailadresse manuell anpassen.
Anschließend werde ich die Outlookprofile neu einrichten müssen (Exchange löschen->neu anlegen) (ist ne kleine Umgebung).
Unsicherheiten sehe ich vorallem darin, dass wir für den Exchange eine eigene Subdomain mit gültigem SSL Zertifikat erstellt haben.
z.B. exchange.domain.de, damit wir ActiveSync (primär Kalender) nutzen können.
Dies und Autodiscover hatten mich damals bei der Einrichtung ziemlich geärgert - lief dann aber bis zuletzt reibunglos (bis der erste Outlook 2016 Client kam, der nun scheinbar wg. identischer Kontonamen/Mailadressen Probleme macht).
Sehr ihr ein Problem darin, wenn ich die Active-Sync bzw. OWA Url bei der alten URL belasse? Autodiscover sollte ja auch weiterhin funktionieren; da ja der _AutoDiscover DNS Eintrag gesucht wird, dieser auf exchange.domain.de verweist und Exchange Anhand des Usernamen die korrekte - neue - Mailadresse (user1@domain-exchange.de) zurückliefern müsste...
Für Tipps/Ratschläge wäre ich sehr dankbar
Viele Grüße,
Malungo
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: 498203
Url: https://administrator.de/contentid/498203
Printed on: April 25, 2024 at 05:04 o'clock
4 Comments
Latest comment
Vor dem Punkt stand ich auch mal, aber ich habe mich nicht getraut so etwas auszuprobieren, irgendwelche Adresslisten, die interne Suche oder gesharete Kalender könnten dann nicht mehr funktionieren. Sauber wäre es für beide Domains eigene Autodiscover Einträge von getrennten Servern bereit zu stellen.
Ich habe mich dafür entschieden ein Shared Namespace aufzubauen, da ich aus Kostengründen nur bei 50 Usern ein Exchange Konto eingerichtet habe (mit Exchange Zugriffslizenzen) und 200 User bei IMAP bleiben sollen. Deswegen habe ich den Linux IMAP Server für den Transport behalten, er leitet aber E-Mails für bestimmte User weiter zum Exchange Server. Er spielt auch den Smarthost für den Exchange Server und nimmt alle ausgehenden E-Mails von ihm entgegen und verteilt sie nach draußen oder zu den anderen Usern. Also ein Exchange hinterm Postfix/Dovecot.
In Deinem Fall wäre es aber gar nicht so kompliziert, da Du ja schon für jeden User Exchange CAL‘s wegen den Archiv benutzt hast. Da gibt es dann wirklich keinen Grund mehr das IMAP Postfäch zu behalten. Damit wären all Deine Probleme mit winmail.dat, leerem Text in E-Mails, falschem Standardkonto, Autoconfig und zweiter Domain gelöst. Du kannst ja trotzdem noch den IMAP Server als Transport behalten und alle E-Mails durch schicken.
Ich habe mich dafür entschieden ein Shared Namespace aufzubauen, da ich aus Kostengründen nur bei 50 Usern ein Exchange Konto eingerichtet habe (mit Exchange Zugriffslizenzen) und 200 User bei IMAP bleiben sollen. Deswegen habe ich den Linux IMAP Server für den Transport behalten, er leitet aber E-Mails für bestimmte User weiter zum Exchange Server. Er spielt auch den Smarthost für den Exchange Server und nimmt alle ausgehenden E-Mails von ihm entgegen und verteilt sie nach draußen oder zu den anderen Usern. Also ein Exchange hinterm Postfix/Dovecot.
In Deinem Fall wäre es aber gar nicht so kompliziert, da Du ja schon für jeden User Exchange CAL‘s wegen den Archiv benutzt hast. Da gibt es dann wirklich keinen Grund mehr das IMAP Postfäch zu behalten. Damit wären all Deine Probleme mit winmail.dat, leerem Text in E-Mails, falschem Standardkonto, Autoconfig und zweiter Domain gelöst. Du kannst ja trotzdem noch den IMAP Server als Transport behalten und alle E-Mails durch schicken.
1
Moin,
Ich gehe ganz stark davon aus, dass der IMAP-Server der des Provider ist und nicht bei euch im Haus läuft.
Dann kann mich @NordicMike nur anschließen und dir empfehlen, den Exchange auch für den Empfang und Versand zu konfigurieren.
Warum muss alles so kompliziert eingerichtet werden?
Der Empfang erfolgt via MX und beim Versenden nutzt du den SMTP des Providers als Relay.
Habe ich vielfach bei KMU so im Einsatz und keine Probleme mit Doppelkonfigurationen.
Das öffentliche Zertifikat kommt von let's encrypt.
PS:
Waren das gruselige Zeiten, als ich noch POP-Connectoren (AVM KEN, SBS-POP-Connector, etc) zusätzlich zum Exchange genutzt hatte.
Deine Variante mit den 2 identischen Postfächern (intern Exchange, extern IMAP) habe ich auch mal bei einer Firma gesehen und schnell umgestellt.
Ich gehe ganz stark davon aus, dass der IMAP-Server der des Provider ist und nicht bei euch im Haus läuft.
Dann kann mich @NordicMike nur anschließen und dir empfehlen, den Exchange auch für den Empfang und Versand zu konfigurieren.
Warum muss alles so kompliziert eingerichtet werden?
Der Empfang erfolgt via MX und beim Versenden nutzt du den SMTP des Providers als Relay.
Habe ich vielfach bei KMU so im Einsatz und keine Probleme mit Doppelkonfigurationen.
Das öffentliche Zertifikat kommt von let's encrypt.
PS:
Waren das gruselige Zeiten, als ich noch POP-Connectoren (AVM KEN, SBS-POP-Connector, etc) zusätzlich zum Exchange genutzt hatte.
Deine Variante mit den 2 identischen Postfächern (intern Exchange, extern IMAP) habe ich auch mal bei einer Firma gesehen und schnell umgestellt.
1
Danke für Eure Antworten - das hilft mir sehr!
Als IMAP Server verwenden wir den des Providers - das ist korrekt.
Bei der Einrichtung hatten wir auch schon mal kurz überlegt, ob wir den Exchange nicht "voll" konfigurieren, hatten dies aber dann doch bleiben lassen, da es 1. einfacher war die bestehende Konfiguration aus Exchange 365 zu übernehmen und ich 2. folgende Bedenken hatte:
- Da es sich um ein kleines Büro handelt (5-10 User) haben wir natürlich keine Hochverfügbarkeitslösung. Was passiert mit eingehenden Mails, wenn der Server mal 1-2 Tage nicht da ist oder gerade Serverupdates gemacht werden? (Downtime von 1h).
- Zudem hatte ich bedenken, dass Mails ggf. nicht sauber zugestellt werden, weil der Mailserver auf einer Blacklist o.ä. landen könnte.
Könnt ihr mir die Angst aus dem 1. Punkt nehmen? Da der Mailverkehr für das Büro absolut zuverlässig funktionieren muss (einhaltung von Fristen usw.) darf es nicht vorkommen, dass Mails "verloren" gehen. Ich gehe davon aus, dass der Sender von Mails in dern Downtime eine Mail erhält, dass die nicht zugestellt werden kann....ggf. aber auch erst nach einer Frist?
Der 2. Punkt ist wahrscheinlich unbegründet, da ich den Provider dann ja als Smarthost verwenden würde...
So gesehen müsste ich nur in der Firewall den Port 25 freischalten, einen neuen Sendeconnector mit Smarthost (Provider) erstellen, den MX Eintrag beim Provider setzen und einen neuen Empfangsconnector einrichten...
@goscho
An Pop Connectoren hatte ich tatsächlich auch schon mal gedacht *schäm*. In derart kleinen Unternehmen hatte das eigentlich auch immer gut funktioniert. Den Vorteil den ich hier sehen würde, wäre mein o.g. 1. Punkt (Provider ist hochverfügbar); zudem wären die Mails (zumindest die neuen würden auf dem Server bleiben) zusätzlich gesichert...
Das mit dem let's encrypt Zertifikat finde ich interessant. Bisher hatten wir ein 5 Jahre gültiges Zertifikat; das nun bald abläuft. Auf frankysweb.de finde ich ein Script für Let's Encrypt. Ich denke das funktioniert auch gut - jedoch habe ich auch nen Reverseproxy im Einsatz der das Zertifikat dann auch braucht. Hast Du auch den Fall, dass das Zertifikat von mehreren Servern benötigt wird und einen zuverlässig funktionierenden Mechanismus für die automatische Aktualisierung geschaffen? Da würde ich mich gerne mit Dir austauschen
Als IMAP Server verwenden wir den des Providers - das ist korrekt.
Bei der Einrichtung hatten wir auch schon mal kurz überlegt, ob wir den Exchange nicht "voll" konfigurieren, hatten dies aber dann doch bleiben lassen, da es 1. einfacher war die bestehende Konfiguration aus Exchange 365 zu übernehmen
und ich 2. folgende Bedenken hatte:- Da es sich um ein kleines Büro handelt (5-10 User) haben wir natürlich keine Hochverfügbarkeitslösung. Was passiert mit eingehenden Mails, wenn der Server mal 1-2 Tage nicht da ist oder gerade Serverupdates gemacht werden? (Downtime von 1h).
- Zudem hatte ich bedenken, dass Mails ggf. nicht sauber zugestellt werden, weil der Mailserver auf einer Blacklist o.ä. landen könnte.
Könnt ihr mir die Angst aus dem 1. Punkt nehmen? Da der Mailverkehr für das Büro absolut zuverlässig funktionieren muss (einhaltung von Fristen usw.) darf es nicht vorkommen, dass Mails "verloren" gehen. Ich gehe davon aus, dass der Sender von Mails in dern Downtime eine Mail erhält, dass die nicht zugestellt werden kann....ggf. aber auch erst nach einer Frist?
Der 2. Punkt ist wahrscheinlich unbegründet, da ich den Provider dann ja als Smarthost verwenden würde...
So gesehen müsste ich nur in der Firewall den Port 25 freischalten, einen neuen Sendeconnector mit Smarthost (Provider) erstellen, den MX Eintrag beim Provider setzen und einen neuen Empfangsconnector einrichten...
@goscho
An Pop Connectoren hatte ich tatsächlich auch schon mal gedacht *schäm*. In derart kleinen Unternehmen hatte das eigentlich auch immer gut funktioniert. Den Vorteil den ich hier sehen würde, wäre mein o.g. 1. Punkt (Provider ist hochverfügbar); zudem wären die Mails (zumindest die neuen würden auf dem Server bleiben) zusätzlich gesichert...
Das mit dem let's encrypt Zertifikat finde ich interessant. Bisher hatten wir ein 5 Jahre gültiges Zertifikat; das nun bald abläuft. Auf frankysweb.de finde ich ein Script für Let's Encrypt. Ich denke das funktioniert auch gut - jedoch habe ich auch nen Reverseproxy im Einsatz der das Zertifikat dann auch braucht. Hast Du auch den Fall, dass das Zertifikat von mehreren Servern benötigt wird und einen zuverlässig funktionierenden Mechanismus für die automatische Aktualisierung geschaffen? Da würde ich mich gerne mit Dir austauschen
Dafür ist ein Forum da.
IdR versuchen absende Mailserver bis zu 48h Mails zuzustellen (abhängig von deren Konfiguration).
Danach erzeugen die Mailserver NDRs, die der Absender bekommt.
Du kannst aber als Backup-MX auch den Mailserver des Providers einstellen und dann kommen die Mails bei diesem an, wenn dein Server mal länger abwesend ist.
Downtime von 1h? Was soll den da passieren?
Es gibt unzählige Gründe, warum Mails "verloren" gehen können.
Wenn du Hochverfügbarkeit und Exchange haben willst, warum bist du nicht bei Exchange 365 geblieben?
Dort nutze ich Certify the web zur Generation der Zertifikate.
- Da es sich um ein kleines Büro handelt (5-10 User) haben wir natürlich keine Hochverfügbarkeitslösung. Was passiert mit eingehenden Mails, wenn der Server mal 1-2 Tage nicht da ist oder gerade Serverupdates gemacht werden? (Downtime von 1h).
Wenn der Mailserver nicht da ist, dann kann er keine Mails entgegennehmen. IdR versuchen absende Mailserver bis zu 48h Mails zuzustellen (abhängig von deren Konfiguration).
Danach erzeugen die Mailserver NDRs, die der Absender bekommt.
Du kannst aber als Backup-MX auch den Mailserver des Providers einstellen und dann kommen die Mails bei diesem an, wenn dein Server mal länger abwesend ist.
Downtime von 1h? Was soll den da passieren?
Könnt ihr mir die Angst aus dem 1. Punkt nehmen? Da der Mailverkehr für das Büro absolut zuverlässig funktionieren muss (einhaltung von Fristen usw.) darf es nicht vorkommen, dass Mails "verloren" gehen.
Sowas kann dir natürlich keiner garantieren. Diese Garantie hast du aber auch nicht bei deinem IMAP-Zugang beim Provider. Der kann genauso gestört sein.Es gibt unzählige Gründe, warum Mails "verloren" gehen können.
- SPAM (fals positive)
- Fehlkonfiguration (Posteingangsregeln)
- Anwenderfehler beim Sender (falsche Mailadressen)
- Anwenderfehler beim Empfänger (Mail gelöscht und nicht weitergeleitet)
- etc
Ich gehe davon aus, dass der Sender von Mails in dern Downtime eine Mail erhält, dass die nicht zugestellt werden kann....ggf. aber auch erst nach einer Frist?
siehe obenDer 2. Punkt ist wahrscheinlich unbegründet, da ich den Provider dann ja als Smarthost verwenden würde...
im Normalfall schon - es gibt aber auch Ausnahmen bei Providern, die selbst auf SPAMlisten gelandet sind.So gesehen müsste ich nur in der Firewall den Port 25 freischalten, einen neuen Sendeconnector mit Smarthost (Provider) erstellen, den MX Eintrag beim Provider setzen und einen neuen Empfangsconnector einrichten...
Der Versand sollte verschlüsselt (zumeist TLS über 587) erfolgen.@goscho
An Pop Connectoren hatte ich tatsächlich auch schon mal gedacht *schäm*. In derart kleinen Unternehmen hatte das eigentlich auch immer gut funktioniert. Den Vorteil den ich hier sehen würde, wäre mein o.g. 1. Punkt (Provider ist hochverfügbar); zudem wären die Mails (zumindest die neuen würden auf dem Server bleiben) zusätzlich gesichert...
POPo-Connectoren bieten keine Vorteile!An Pop Connectoren hatte ich tatsächlich auch schon mal gedacht *schäm*. In derart kleinen Unternehmen hatte das eigentlich auch immer gut funktioniert. Den Vorteil den ich hier sehen würde, wäre mein o.g. 1. Punkt (Provider ist hochverfügbar); zudem wären die Mails (zumindest die neuen würden auf dem Server bleiben) zusätzlich gesichert...
Wenn du Hochverfügbarkeit und Exchange haben willst, warum bist du nicht bei Exchange 365 geblieben?
Das mit dem let's encrypt Zertifikat finde ich interessant. Bisher hatten wir ein 5 Jahre gültiges Zertifikat; das nun bald abläuft. Auf frankysweb.de finde ich ein Script für Let's Encrypt. Ich denke das funktioniert auch gut - jedoch habe ich auch nen Reverseproxy im Einsatz der das Zertifikat dann auch braucht. Hast Du auch den Fall, dass das Zertifikat von mehreren Servern benötigt wird und einen zuverlässig funktionierenden Mechanismus für die automatische Aktualisierung geschaffen? Da würde ich mich gerne mit Dir austauschen
Ich habe Umgebungen, in denen mehrere Server Zertifikate brauchen.Dort nutze ich Certify the web zur Generation der Zertifikate.
1
