15
Exchange Server - Installation und Konfiguration - Anfänger
Hallo Zusammen,
Meine bisherigen Erfahrungen mit Exchange beschränkten sich auf das Administrieren vorhandener Umgebungen.
Ich habe mir einen Server bei Hetzner gemietet, um einmal möglichst praxisnah Erfahrungen damit zu sammeln.
Ich hatte noch eine Domain rumliegen, die unbenutzt ist und ich für dieses fiktive Szenario verwenden konnte.
Technische Gegebenheiten sind nun wie folgt:
Allgemeines
DNS
Was bisher funktioniert:
Was noch nicht funktioniert / unklar ist:
*MAPI over HTTP connectivity schlägt fehl (mindestens, wenn "SSL-Erforderlich" nicht in den IIS-Settings für MAPI "true" ist)
(Dasselbe betrifft alle anderen Sites (autodiscover, ecp, ews, owa,...) auch, sofern ich nicht "SSL Erforderlich" expliziert auf "false" setzte.
Die nächsten Schritte wären: Das zunächst beheben, wobei ich da Dich mich mega über Euren Input freuen würde. Dann würde ich mich an die Konfiguration des hybriden Betriebs mit O365 wagen
Vielen herzlichen Dank schon mal im Vorhinein für jeden Input.
Grüsse
Nils
Meine bisherigen Erfahrungen mit Exchange beschränkten sich auf das Administrieren vorhandener Umgebungen.
Ich habe mir einen Server bei Hetzner gemietet, um einmal möglichst praxisnah Erfahrungen damit zu sammeln.
Ich hatte noch eine Domain rumliegen, die unbenutzt ist und ich für dieses fiktive Szenario verwenden konnte.
Technische Gegebenheiten sind nun wie folgt:
Allgemeines
- Dedizierter Server mit einer physikalischen NIC (Public-IP 162.55.89.47)
- Hyper-V Server installiert, (Der Gleichzeitig als HTTP/S-Proxy durch IIS agiert)
- Der Hyper-V-Server agiert zusätzlich als NAT-Router für die VMs und verfügt neben dem physikalischen NIC noch über eine virtuelle NIC mit der IP 172.16.0.1 /24
- DC (172.16.0.2), EX (172.16.0.3), ein primitiver Web-Server (172.16.0.80 Zum Testen des Proxy) sowie ein App-Server (zum Testen von NAT-Roles) als VM bereitgestellt.
- AD mit der Domain int.nils.gmbh eingerichtet (DC und EX sind Member)
- Internes Netz 172.16.0.0 /24 hinter einem Hyper-V-NATSwitch für die VMs konfiguriert
DNS
- Interne Zone (int.nils.gmbh) existiert nicht im public DNS
- Externe Zone (nils.gmbh)
- A-Record "nils.gmbh", "mail.nils.gmbh" und "*nils.gmbh" verweisen auf die Public IP vom Hyper-V/Proxy-Server
- MX-Record verweist auf mail.nils.gmbh
- SSL-Zertifikat beantragt für mail.nils.gmbh
- Zugewiesen der Site im Proxy
- Zugwiesen und beantragt im Exchange Admin Center (auf dem EX)
- Die Einstellungen der virtuellen Verzeichnisse habe ich insofern vorgenommen, dass ich über das ECP überall den externen Servername "mail.nils.gmbh" ergänz habe:
- Damit die Auflösung und Routing sowie NAT für mail.nils.gmbh -> 162.55.89.47 -> 172.16.0.3/24 funktioniert, habe ich folgende NAT-Regeln gesetzt:
Was bisher funktioniert:
- Zugriff auf OWA und ECP (Zertifikat wird als gültig anzeigt), sofern IIS SSL nicht erfordert (Laut Browser aber immer gesichert und auch gültiges Cert)
- Mail-Versand ein- und ausgehend (Getestet mit Gmail und AddOn IN sowie OUT)
- Hinzufügen Exchange Konto auf Mobiltelefon (Sofern in IIS "SSL nicht erforderlich" gesetzt ist). (Obwohl der Browser gültiges Cert. augibt)
Was noch nicht funktioniert / unklar ist:
- Einbinden in Outlook Client
- Hier bekomme ich trotz eingetragenen externen Adressen in den virtuellen Verzeichnissen eine Fehlermeldung mit internen Servernamen.
- Korrektes Behandeln von ActiveSync / Autodiscover: Da ich kein gültiges Zertifikat für autodiscover.nils.gmbh habe, entschied ich mich für einen SRV-Record:
- Das validieren des Root-Zertifikats schlägt fehl:
*MAPI over HTTP connectivity schlägt fehl (mindestens, wenn "SSL-Erforderlich" nicht in den IIS-Settings für MAPI "true" ist)
(Dasselbe betrifft alle anderen Sites (autodiscover, ecp, ews, owa,...) auch, sofern ich nicht "SSL Erforderlich" expliziert auf "false" setzte.
Die nächsten Schritte wären: Das zunächst beheben, wobei ich da Dich mich mega über Euren Input freuen würde. Dann würde ich mich an die Konfiguration des hybriden Betriebs mit O365 wagen
Vielen herzlichen Dank schon mal im Vorhinein für jeden Input.
Grüsse
Nils
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: 1528955254
Url: https://administrator.de/contentid/1528955254
Printed on: April 25, 2024 at 14:04 o'clock
15 Comments
Latest comment
Die externe URL deines Mailservers ist augenscheinlich falsch. Franky hat hierfür ein schönes Powershell Script erstellt.
https://www.frankysweb.de/exchange-2016-urls-und-hostnamen-per-powershel ...
Wenn du deine externe Url auf die im Zertifikat enthaltene URL setzt, dürfte der Zertifikatfehler weg sein.
Und den Haken bei SSL erforderlich solltest du niemals rausnehmen, ausser du möchtest, das alle möglichen schwarzen Schafe deinen Server für ihre Zwecke missbrauchen. 443 und 25 bzw. 587 für Relay mit Auth sollten nach Möglichkeit die einzigen extern erreichbaren Ports sein.
https://www.frankysweb.de/exchange-2016-urls-und-hostnamen-per-powershel ...
Wenn du deine externe Url auf die im Zertifikat enthaltene URL setzt, dürfte der Zertifikatfehler weg sein.
Und den Haken bei SSL erforderlich solltest du niemals rausnehmen, ausser du möchtest, das alle möglichen schwarzen Schafe deinen Server für ihre Zwecke missbrauchen. 443 und 25 bzw. 587 für Relay mit Auth sollten nach Möglichkeit die einzigen extern erreichbaren Ports sein.
@rzlbrnft Frankysweb.de kenne ich - Ist super die Website!
Die URLs habe ich in dem Fall alle händisch über das Admin-Center gesetzt.
Alle nochmals geprüft - überall korrekt gesetzt. Oder macht das Script von Frankysweb noch mehr, als ich es durch das händische Setzten selbst konfigurieren würde?
Danke und Gruss
Nils
Die URLs habe ich in dem Fall alle händisch über das Admin-Center gesetzt.
Alle nochmals geprüft - überall korrekt gesetzt. Oder macht das Script von Frankysweb noch mehr, als ich es durch das händische Setzten selbst konfigurieren würde?
Danke und Gruss
Nils
Habe mir das Script nochmal genauer angeschaut: Es scheint die Settings genauso zu treffen,
wie ich es händisch auch vorgenommen habe. Daran kann es offenbar nicht liegen....
Was mach ich verkehrt? :D
wie ich es händisch auch vorgenommen habe. Daran kann es offenbar nicht liegen....
Was mach ich verkehrt? :D
Hast du im IIS das importierte Zertifikat ausgewählt unter Bindings sowohl für Frontend als auch für Backend?
Dieser Thread behandelt ein ähnliches Thema, da hab ich einen Screenshot gepostet.
Exchange 2016 Zertifikat aus Verlängerung tauschen
Kannst du prüfen wenn du mit dem Browser auf die Owa Seite zugreifst, das müsste dann ja https://mail.nils.gmbh/owa sein.
//EDIT:
Ok, hast du, hab ich grad gesehen.
Es liegt wohl am Autodiscover, das gibt nicht mail.nils.gmbh als Mailserver zurück, sondern deinen internen Namen. Du brauchst einen DNS Eintrag der an Autodiscover verweist, also z.B. CNAME unter autodiscover.nils.gmbh mit Verweis auf mail.nils.gmbh, wenn autodiscover im Zertifikat als DNS Name enthalten ist, oder einen SRV Eintrag für den Dienst _autodiscover auf Port 443 der den Mailserver als Ziel zurückgibt. mail.nils.gmbh muss dann ein A-Record sein, der auf die IP deines Servers verweist.
https://www.webhod.de/knowledge-base/autodiscover-srv-eintrag/
Dieser Thread behandelt ein ähnliches Thema, da hab ich einen Screenshot gepostet.
Exchange 2016 Zertifikat aus Verlängerung tauschen
Kannst du prüfen wenn du mit dem Browser auf die Owa Seite zugreifst, das müsste dann ja https://mail.nils.gmbh/owa sein.
//EDIT:
Ok, hast du, hab ich grad gesehen.
Es liegt wohl am Autodiscover, das gibt nicht mail.nils.gmbh als Mailserver zurück, sondern deinen internen Namen. Du brauchst einen DNS Eintrag der an Autodiscover verweist, also z.B. CNAME unter autodiscover.nils.gmbh mit Verweis auf mail.nils.gmbh, wenn autodiscover im Zertifikat als DNS Name enthalten ist, oder einen SRV Eintrag für den Dienst _autodiscover auf Port 443 der den Mailserver als Ziel zurückgibt. mail.nils.gmbh muss dann ein A-Record sein, der auf die IP deines Servers verweist.
https://www.webhod.de/knowledge-base/autodiscover-srv-eintrag/
Vergiss es du hast ja alles veröffentlicht an IPs etc. Sollte man nicht tun
und den Firmennamen evtl. auch mal zensieren ...
@clschal @Xaero1982
Es ist ein fiktives Projekt. Die GmbH gibt es nicht einmal
Es wird nicht produktiv genutzt werden.
Es ist ein fiktives Projekt. Die GmbH gibt es nicht einmal
Es wird nicht produktiv genutzt werden.
@rzlbrnft Danke schon mal für deine Zeit und Kommentare.
Wie Du meinem Screenshot entnehmen kannst, habe ich zwar keinen CNAME, jedoch einen SRV-Verweis für autodiscover.nils.gmbh, der auf mail.nils.gmbh verweist -> Für den wiederum habe ich einen A-Record, der auf die Public-IP vom Proxy verweist.
Ich weiss leider immer noch nicht, wo der Fehler liegt...
Wie Du meinem Screenshot entnehmen kannst, habe ich zwar keinen CNAME, jedoch einen SRV-Verweis für autodiscover.nils.gmbh, der auf mail.nils.gmbh verweist -> Für den wiederum habe ich einen A-Record, der auf die Public-IP vom Proxy verweist.
Ich weiss leider immer noch nicht, wo der Fehler liegt...
Das hast du noch nicht beantwortet:
Hast du im IIS das importierte Zertifikat ausgewählt unter Bindings sowohl für Frontend als auch für Backend?
Wobei man das Backend nicht ändern / anfassen sollte.
Du kannst im Outlook mit Shift+Strg+Rechtsklick auf das Tray Icon die Autoconfiguration testen, das sollte Aufschluss darüber geben woran es liegt.
Wenn man nicht weiß was man tut nicht. Dann sollte man aber gar keinen lokalen Exchange betreiben, sondern lieber in die Cloud gehen.
Zitat von @NordicMike:
Das hast du noch nicht beantwortet:
Das hast du noch nicht beantwortet:
Hast du im IIS das importierte Zertifikat ausgewählt unter Bindings sowohl für Frontend als auch für Backend?
Wobei man das Backend nicht ändern / anfassen sollte.Wenn man nicht weiß was man tut nicht. Dann sollte man aber gar keinen lokalen Exchange betreiben, sondern lieber in die Cloud gehen.
Hab ich geprüft. Backend hat auch das korrekte Zertifikat zugewiesen.
UPDATE:
Es funktioniert nun. Der Fehler lag daran, dass Autodiscover mit die Einstellungen für interne Clients ausgeworfen hatte.
Ich hatte *.nils.gmbh eingetragen als A-Record in den DNS-Settings, womit ich die eigentliche interne Zone int.nils.gmbh von aussen aufgelöst hatte.
Somit konnte nicht mehr zwischen intern und extern unterschieden werden. Ich bekam also in dem Fall durch autodiscover den eigentlich internen Servername ex.int.nils.gmbh ausgeliefert.
Es funktioniert nun. Der Fehler lag daran, dass Autodiscover mit die Einstellungen für interne Clients ausgeworfen hatte.
Ich hatte *.nils.gmbh eingetragen als A-Record in den DNS-Settings, womit ich die eigentliche interne Zone int.nils.gmbh von aussen aufgelöst hatte.
Somit konnte nicht mehr zwischen intern und extern unterschieden werden. Ich bekam also in dem Fall durch autodiscover den eigentlich internen Servername ex.int.nils.gmbh ausgeliefert.
Moin,
noch ein Nachtrag von mir.
Wenn man Strg gedrückt hält und mit der rechten Maustaste auf das Outlook-Tray-Icon klicken kann man da "Email-Autokonfiguration testen" auswählen. Da sieht man sehr genau was Outlook von wo als Infos zurückbekommt.
Denn Outlook ist beim Autodiscover eine Bitch und macht komische Sachen in komischer Reihenfolge.
Wichtig ist vor allem, dass man keine Wildcard-DNS-Einträge hat.
Diese verzögern die Abfrage sehr deutlich. Also schön A und AAAA Record für firma.de und www.firma.de anlegen.
Mit dieser Rewrite-Rule kann man es auch beschleunigen weil Outlook das ganz am Anfang prüft.
Siehe auch https://www.skittel.de/autodiscover-bei-hosted-exchange-beschleunigen/
Stefan
noch ein Nachtrag von mir.
Wenn man Strg gedrückt hält und mit der rechten Maustaste auf das Outlook-Tray-Icon klicken kann man da "Email-Autokonfiguration testen" auswählen. Da sieht man sehr genau was Outlook von wo als Infos zurückbekommt.
Denn Outlook ist beim Autodiscover eine Bitch und macht komische Sachen in komischer Reihenfolge.
Wichtig ist vor allem, dass man keine Wildcard-DNS-Einträge hat.
Diese verzögern die Abfrage sehr deutlich. Also schön A und AAAA Record für firma.de und www.firma.de anlegen.
Mit dieser Rewrite-Rule kann man es auch beschleunigen weil Outlook das ganz am Anfang prüft.
Siehe auch https://www.skittel.de/autodiscover-bei-hosted-exchange-beschleunigen/
Stefan
Ja. Der Wildcard-Eintrag war auch in meinem Fall das Übel.
Dadurch, dass ich für *nils.gmbh einen Wildcard-Eintrag hatte, hatte ich auch automatisch einen für die (eigentlich nur interne) Zone int.nils.gmbh. Somit bekam ich auch per Autodiscover mail.int.nils.gmbh anstelle des zu erwarteten Servername mail.nils.gmbh zurück.
Dadurch, dass ich für *nils.gmbh einen Wildcard-Eintrag hatte, hatte ich auch automatisch einen für die (eigentlich nur interne) Zone int.nils.gmbh. Somit bekam ich auch per Autodiscover mail.int.nils.gmbh anstelle des zu erwarteten Servername mail.nils.gmbh zurück.
