Hallo zusammen,
Wir möchten in unserem Lab einen Versuch starten einen "Hosted Exchange Server" aufzusetzen.
Wir betreiben unseren eigenen Exchange 2019 und noch 12 weitere (2016 und 2019) bei Kunden.
Wir hatten uns nun überlegt, dass wir für unsere Kunden eben einen "Hosted Exchange Server" in unserem Rechenzentrum in Betrieb nehmen könnten.
Fragen:
- Ist es überhaupt möglich mehrere Domains auf einem Server zu betreiben?
- Wie geht man beim Zertifikat vor? Es könnte ja theoretisch täglich neue Kunden / neue Domains geben oder eben auch Kunden die den Dienst kündigen. Muss da jedesmal ein neues Zertifikat ausgestellt werden?
- Wäre es möglich nur mit einem Zertifikat zu arbeiten z. Bsp.: "meinexchange.de"?
- Wie verhaltet sich das autodiscover?
Vielen Dank bereits im Voraus für eure Hilfe.
Ist es überhaupt möglich mehrere Domains auf einem Server zu betreiben?
Falls du smtp Domains meinst: ja natürlich.
Wie geht man beim Zertifikat vor? Es könnte ja theoretisch täglich neue Kunden / neue Domains geben oder eben auch Kunden die den Dienst kündigen. Muss da jedesmal ein neues Zertifikat ausgestellt werden?
Entweder das, oder men löst das wie auch ms das mit o365 gelöst hat. ;)
ich möchte noch ein paar Dinge anmerken:
1. das ist lizenztechnisch nicht ganz preiswert, weil du auf mpla lizenzieren musst.
2. Gibts von ms dazu entsprechende whitepaper.
3. Gibts viele die sich dachten, mach ich einfach mal. Die meisten stellen dann fest, es wird aufwändig und teuer.
Hallo und Danke Norbert.
Könnte man betr. den Domains nicht auch CNAME-Einträge nutzen?
Ja, aber das ändert weder was an der Notwendigkeit der Namen im Zertifikat (zumindest die autodiscover domains) oder der Verwendung von http Redirects (siehe O365).
- Ist es überhaupt möglich mehrere Domains auf einem Server zu betreiben?
Wie bereits Norbert geschrieben hat, ist das über die "Akzeptierten Domains" im Exchange und entsprechende DNS-Records möglich.
- Wie geht man beim Zertifikat vor? Es könnte ja theoretisch täglich neue Kunden / neue Domains geben oder eben auch Kunden die den Dienst kündigen. Muss da jedesmal ein neues Zertifikat ausgestellt werden?
- Wäre es möglich nur mit einem Zertifikat zu arbeiten z. Bsp.: "meinexchange.de"?
Du kannst das ganze auch geschickt über ein "globales" (mit "global" meine ich Kundenunabhängig) Zertifikat und eine globale URL regeln (weiter unter ein paar Details)
- Wie verhaltet sich das autodiscover?
Mal angenommen, du konfigurierst den Server für eine globale Domain "meinexchange.de", die keinem Kunden gehört und auch bestehenden beleibt, wenn ein Kunde X den Dienst kündigt.
Du konfigurierst nun die URLs wie folgt:
Eine URL für den internen und externen Zugriff auf bspw. OWA und andere Dienste: "mail.meinexchange.de"
und die Autodiscover URL: "autodiscover.meinexchange.de"
(Natürlich beides mit "https://" usw..)
Nun musst du nur noch bei deinen Kunden einen SRV-Eintrag mit folgenden Werten setzen:
Type=SRV
Service=_autodiscover
Protocol=_tcp
Name=@
Target=autodiscover.meinexchange.de.
Priority=10
Weight=10
Port=443
TTL=3600
Achtung: Du solltest nur den SRV-Record innerhalb der Kunden-Domains konfigurieren, keine anderen Records (bspw. A oder CNAME)!
Beim Einrichten von Outlook werden die User einen Hinweis bekommen, das sie zum Konfigurieren von Outlook auf die URL "autodiscover.meinexchange.de" weitergeleitet werden. Der Warnhinweis kann aber mit einem Klick auf "Diesen Hinweis nicht erneut anzeigen" (oder so ähnlich) in Zukunft vermieden werden. Ich denke mal, dass ist verkraftbar.
Den Zugriff auf OWA (OAB, usw...) würde ich so belassen, dass Benutzer auf die URL "mail.meinexchange.de" (also die Kundenunabhängige URL / Domain) zugreifen.
Somit lässt sich alles über ein Zertifikat abwickeln, welches nur die Namen "autodiscover.meinexchange.de" und "mail.meinexchange.de" beinhaltet.
Zusatz:
Ein paar Sachen musst du noch beachten.
1. Die Benutzer aus den verschiedenen Domains können andere Benutzer, Ressourcen, (Verteiler-)Gruppen und Kontakte in den Adressbüchern sehen.
Um dieses Problem zu umgehen, solltest du für alle Kundendomain eigene Adressbücher (Globales Adressbuch, Offline-Adressbuch, usw...) anlegen. Mit einem entsprechendem RecipientFilter lassen sich die Adressbücher auf bestimmte Domain beschränken.
Ebenfalls benötigst du hierzu den "ABP Routing Agent" von Microsoft, dieser "routet" praktisch die verschiedenen Adressbücher, sodass jeder Nutzer nur die Adressbücher sieht, die für ihn bestimmt sind.
Eine Anleitung von Microsoft findest du hier: https://docs.microsoft.com/de-de/exchange/address-books/address-book-policies/turn-on-address-book-policy-routing
Im Prinzip genügt es aber, folgende PowerShell-Befehle auszuführen:
Install-TransportAgent -Name “ABP Routing Agent” -TransportAgentFactory “Microsoft.Exchange.Transport.Agent.AddressBookPolicyRoutingAgent.AddressBookPolicyRoutingAgentFactory” -AssemblyPath $env:ExchangeInstallPath\TransportRoles\agents\AddressBookPolicyRoutingAgent\Microsoft.Exchange.Transport.Agent.AddressBookPolicyRoutingAgent.dll Enable-TransportAgent “ABP Routing Agent” Restart-Service MSExchangeTransport Get-TransportAgent Set-TransportConfig -AddressBookPolicyRoutingEnabled $true
2. Eigene Adressbuchrichtlinien und Emailadressrichtlinien
Per Default hast du nur eine Emailadressrichtlinie im Exchange. Diese sieht wahrscheinlich so aus, dass deine "erste" konfigurierte Domain (bspw. "meinexchange.de") für neue E-Mail-Adressen verwendet wird. Um nicht immer die Adressen nach dem Anlegen eines neuen Benutzer ändern zu müssen, würde ich dir empfehlen auch gleich eigene Emailadressrichtlinie für jede einzelne Domain anzulegen.
Zudem solltest eine eigene Adressbuchrichtlinie pro Domain konfigurieren, welche dann schlussendlich alle Adressbücher für die jeweilige Domain beinhaltet.
3. Downloaddomain
Aufgrund einer Sicherheitslücke würde ich dir empfehlen, eine "Download-Domain" zu konfigurieren. Diese kann ebenfalls mit der "globalen" Domain konfiguriert werden (bspw. "download.meinexchange.de"). Natürlich muss dein Zertifikat diesen Namen ebenfalls beinhalten. Mehr Details zur Sicherheitslücke und die Konfiguration findest du hier: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1730
4. Aufbau und Konfiguration AD
Ich würde dir empfehlen, eine "übergeordnete" OU für alle Kunden-Domains in der AD zu erstellen, bspw. "Hosted Customers". Unter dieser OU wiederum, erstellst du dann wieder für jede Domain eine OU (bspw. eine OU "kundeabc.de"). Wie du dann diese OU weiter aufbaust, ist völlig egal (bspw. wenn du noch eine eigene OU für Benutzer und eine für Kontakte erstellen willst --> Ist völlig dir überlassen)
Damit sich nun ein einzelner Kunde nicht mit "name@meinexchange.de" ("meinexchange.de" steht in diesem Fall für deine AD-Domain) an deinem Server anmelden muss, solltest du für jede weitere Domain einen eigenen UPNSuffixes erstellen. Bspw. für die Domain "kundeabc.de", damit sich Endbenutzer dieses Kunden mit "name@kundeabc.de" anmelden können.
Dies geht ganz einfach per PowerShell mit
Set-ADForest -Identity “meinexchange.de” -UPNSuffixes @{add=”kundeabc.de”}
Danach musst du nur noch in den AD-Benutzer den entsprechenden UPNSuffix auswählen, da dort per Default deine AD-Domain ("meinexchange.de") gewählt wird (ich glaube auch bei der Erstellung eines Benutzers ist dies bereits möglich)
Durch den UPNSuffix ist es dir nun auch möglich, AD-Benutzer mit gleichen Namen zu erstellen, solang sich der Suffix und der Prä-Windows2000 Anmeldename unterscheiden.
Bspw. kann es so einen Max Mustermann bei dem Kunden "Kunde ABC" und einen beim Kunden "Kunde 123" geben, beide können sogar als Anmeldenamen "max.mustermann" verwenden.
(Vorraussetzung ist, der Prä-Windows2000 Anmeldename ist eindeutig, hier kann aber bspw. einfach "kundenkürzel.vorname.nachname" verwendet werden)
Wie du siehst, gibt es für einen solchen Server einen deutlich höheren Konfigurationsaufwand, als für einen "normalen" Server.
Das ganze lässt sich aber ziemlich leicht Skripten, sodass alle nötigen Konfigurationen leicht und schnell vorgenommen werden können.
Hier findest du noch Hinweise und ein Guide von Microsoft (ist zwar für einen Exchange 2013, sollte aber auch für Exchange 2019 gelten):
https://docs.microsoft.com/en-us/exchange/multi-tenancy-in-exchange-2013-exchange-2013-help
https://www.microsoft.com/en-us/download/details.aspx?id=36790
Nun musst du nur noch bei deinen Kunden einen SRV-Eintrag mit folgenden Werten setzen:
Ich empfehle nicht mit SRV Records zu hantieren. Denn damit erwischt man maximal die WIndows Outlooks. Alle anderen Clients ignorieren sowas einfach.
Der Warnhinweis kann aber mit einem Klick auf "Diesen Hinweis nicht erneut anzeigen" (oder so ähnlich) in Zukunft vermieden werden.
Oder per Policy, wenns verwaltete Maschinen sein sollten.
@hellhunter Vielen Dank! Aa hast du dir wirklich Zeit genommen und in meinen Augen eine exakte, umfangreiche und saubere Antwort geliefert! - Einfach nur WOW - Man lernt nie aus :)
Nun musst du nur noch bei deinen Kunden einen SRV-Eintrag mit folgenden Werten setzen:
Ich empfehle nicht mit SRV Records zu hantieren. Denn damit erwischt man maximal die WIndows Outlooks. Alle anderen Clients ignorieren sowas einfach.
Hi Norbert, hättest du hier in diesem Fall eine andere Empfehlung?
Wir hatten uns nun überlegt, dass wir für unsere Kunden eben einen "Hosted Exchange Server" in unserem Rechenzentrum in Betrieb nehmen könnten.
Ihr seid also nach 2 Jahren immer noch in der Findungsphase, oder wie soll ich diese später Rückfrage deuten? ;)