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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1528955254
Url: https://administrator.de/forum/exchange-server-installation-und-konfiguration-anfaenger-1528955254.html
Ausgedruckt am: 30.12.2024 um 16:12 Uhr
15 Kommentare
Neuester Kommentar
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.
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/
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.
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