Dies ist der zweite Teil der Artikelserie. Wie schon im ersten Teil angekündigt, befasst sich dieser Artikel mit der Konfiguration.
Wichtig: Vorher unbedingt den ersten Teil lesen, da dieser Artikel direkt darauf aufbaut.
Konfiguration Exchange 2016
Der erste Teil endete mit den Überlegungen für die URLs mit denen auf Exchange zugegriffen werden soll. Der Einfachheit halber hier noch einmal die Tabelle mit den URLs:
| Dienst / Protokoll | DNS-Name |
| OWA (Interne URL) | https://mail.frankysweb.de/owa |
| OWA (externe URL) | https://mail.frankysweb.de/owa |
| OAB (interne URL) | https://mail.frankysweb.de/OAB |
| OAB (externe URL) | https://mail.frankysweb.de/OAB |
| ActiveSync (interne URL) | https://mail.frankysweb.de/Microsoft-Server-ActiveSync |
| ActiveSync (externe URL) | https://mail.frankysweb.de/Microsoft-Server-ActiveSync |
| MAPI (interne URL) | https://mail.frankysweb.de/mapi |
| MAPI (externe URL) | https://mail.frankysweb.de/mapi |
| EWS (interne URL) | https://mail.frankysweb.de/EWS/Exchange.asmx |
| EWS (externe URL) | https://mail.frankysweb.de/EWS/Exchange.asmx |
| ECP (interne URL) | https://mail.frankysweb.de/ecp |
| ECP (externe URL) | https://mail.frankysweb.de/ecp |
| Outlook Anywhere (Intern) | mail.frankysweb.de |
| Outlook Anywhere (extern) | mail.frankysweb.de |
| Autodiscover (Intern) | https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml |
Die Konfiguration der URLs ist für Autodiscover wichtig. Diese URLs werden durch Autodiscover an Outlook verteilt, somit findet Outlook den entsprechenden Exchange Server. Werden die virtuellen Verzeichnisse nicht mit entsprechenden URLs konfiguriert, kommt es später wieder zu Zertifikatsfehlern. Es ist also genau darauf zu achten, dass für jedes virtuelle Verzeichnis eine entsprechende interne und externe URL gesetzt wird. Autodiscover verteilt sonst falsche URLs an die Clients.
Die URLs können per Exchange Administrative Center eingestellt werden, hier für OWA:
hier für ECP:
Auf diese Weise werden alle virtuellen Verzeichnisse konfiguriert, mit Ausnahme von “Powershell” und “Autodiscover”. “PowerShell” und “Autodiscover” werden _NICHT_ verändert und erhalten keine neuen URLs:
Es werden also nur die folgenden virtuellen Verzeichnisse mit den URLs aus der Tabelle gefüllt:
- owa
- OAB
- Microsoft-Server-ActiveSync
- mapi
- EWS
- ecp
Nachdem die virtuellen Verzeichnisse konfiguriert wurden, kann auch der Hostname für Outlook Anywhere vergeben werden, auch dies ist wieder per Exchange Administrative Center möglich:
Eine kleine Ausnahme bildet die Autodiscover URL für den CAS-Dienst, diese kann nur per Exchange Management Shell gesetzt werden. In der Standardeinstellung ist auch hier der interne Servername eingetragen:
Mit dem folgenden Befehl wird die URL entsprechend geändert:
Set-ClientAccessService EX1 -AutoDiscoverServiceInternalUri "https://autodiscover.frankysweb.de/Autodiscover/Autodiscover.xml"
Nachdem diese Schritte durchgeführt wurden, kann der IIS Server mittels “iisreset” neu gestartet werden:
Die Exchange Konfiguration ist soweit fertig, weiter geht es mit den erforderlichen DNS Einträgen.
DNS Konfiguration
Exchange hört nach den oben durchgeführten Schritte nur noch auf mail.frankysweb.de und Autodiscover auf autodiscover.frankysweb.de. Damit diese beiden FQDNs nun auch im internen Netzwerk, sowie auch aus dem Internet (HomeOffice) auflösbar sind, müssen entsprechende DNS Einträge konfiguriert werden.
Noch einmal kurz der Ablauf der Kommunikation (vereinfacht)
Ein interner Rechner hat als DNS Server üblicherweise den Domain Controller konfiguriert. Outlook auf dem internen Rechner wird zunächst autodiscover.frankysweb.de anfragen um den Exchange Server zu finden. Der DNS Server auf dem Domain Controller antwortet auf die Anfrage des Clients mit der internen IP Adresse des Exchange Servers. Der Client ruft die Konfiguration ab und fragt dann wiederum den internen DNS Server nach mail.frankysweb.de. Das Bild stellt die DNS Anfragen und Antworten vereinfacht dar (grüne und roter Pfeile):
Ähnliches gilt für Clients im HomeOffice. Auf den meisten Routern wird ein DNS-Forwarder laufen. Dieser DNS Forwarder auf dem Router reicht die DNS Anfragen des Clients aus dem HomeOffice an entsprechende DNS-Server im Internet weiter. Hier gibt es zwar noch mehrere beteiligte DNS-Server, aber schlussendlich wird der DNS-Server des Hosters auf die Autodiscover reagieren müssen. Die Anfragen zu autodiscover.frankysweb.de und mail.frankysweb.de, sollen nun mit der externen IP-Adresse des Internetanschlusses des Unternehmens beantwortet werden. Die Outlook Verbindung wird also diesen Weg gehen (blaue Pfeile)
Intern wird sich Outlook mit mail.frankysweb.de verbinden welches auf die interne IP-Adresse des Exchange Servers zeigt. Extern wird es ebenso mail.frankysweb.de sein, nur mit dem Unterschied, dass jetzt die externe IP aufgelöst wird.
Dazu müssen die DNS Server entsprechend konfiguriert werden:
Internen DNS Server konfigurieren
Da Autodiscover nach erfolgter Konfiguration nun die URLs wie oben angegeben verteilen wird, müssen die URLs nun auch verfügbar sein. Auf dem Domain Controller werden die DNS-Zonen etwa wie folgt aussehen:
Da das ActiveDirectory in diesem Fall auf den Namen frankysweb.local hört, gibt es dazu zwei entsprechende interne Zonen und normalerweise auch eine Reverse Lookup Zone mit den entsprechenden Subnetzen.
Intern muss Exchange nun aber über den Namen mail.frankysweb.de und autodiscover.frankysweb.de erreichbar sein, denn diese Namen wurden entsprechend konfiguriert. Daher wird zunächst eine neue DNS Zone erstellt:
Als Zonentyp wird “Primäre Zone” belassen:
Auch die Zonenreplikation kann so belassen werden:
Als Zonenname wird “mail.frankysweb.de” eingetragen:
Dynamische Updates können abgeschaltet werden:
Innerhalb der neuen Zone wird nun ein neuer HOST-A Eintrag angelegt:
Für den HOST-A Eintrag wird _KEIN_ Name konfiguriert. Im Feld IP-Adresse wird die interne IP des Exchange Servers angegeben und das Häkchen bei “Verknüpften PTR-Eintrag erstellen” entfernt:
Somit sollte es nun wie folgt aussehen:
Die Schritte werden entsprechend für Autodiscover wiederholt. Eine weitere Neue Zone mit dem Namen “Autodiscover.frankysweb.de” wird angelegt:
Und auch in der Zone autodiscover.frankysweb.de wird ein HOST-A Eintrag mit der internen IP des Exchange Servers angelegt:
Mittels nslookup können nun die beiden Zonen überprüft werden.
Autodiscover.frankysweb.de und mail.frankysweb.de müssen von einem internen Client/Rechner/Server auf die interne IP des Exchange Servers verweisen:
Konfiguration externer DNS (Hoster)
Damit der Exchange Server nun auch aus dem Internet (HomeOffice) unter dem Namen mail.frankysweb.de erreichbar ist, müssen entsprechende DNS Einträge beim Hoster der Domain gesetzt werden. Je nach Hoster (Strato, 1und1, HostEurope etc.) verläuft die Konfiguration hier etwas unterschiedlich. In diesem Beispiel ist es Strato:
Zuerst werden zwei neue Subdomains angelegt:
Einmal die Subdomain mit dem Namen “mail”, woraus sich “mail.frankysweb.de” ergibt:
Gleiches für die Subdomain mit dem Namen “autodiscover”, woraus sich autodiscover.frankysweb.de ergibt.
Für beide Subdomains wird jetzt ein A-Record definiert:
Als IP-Adresse wird die externe IP-Adresse des Internetanschlusses des Unternehmens angegeben:
Hinweis: Hier handelt es sich um die WAN-IP des Routers / Firewalls des Unternehmens.
Die WAN-IP wird für autodiscover und mail eingegeben. Die Übersicht der Domain sollte nun in etwa so aus sehen:
Autodiscover.frankysweb.de und mail.frankysweb.de verfügen über je einen A-Record mit der externen IP Adresse des Unternehmens.
Die DNS Auflösung mittels nslookup sollte jetzt die externe IP für autodiscover.frankysweb.de und mail.frankysweb.de zurückliefern:
Es fehlt jetzt noch die Portweiterleitung am Router des Unternehmens damit der Exchange Server auch unter Port 443 erreichbar ist.
Konfiguration Portweiterleitung am Router / Firewall
Die END-Einträge wurden nun konfiguriert, allerdings fehlt noch eine Portweiterleitung am Router des Unternehmens, damit der Exchange Server auch via Port 443 aus dem Internet erreichbar ist. Auch hier ist die Einrichtung wieder abhängig vom eingesetzten Router oder Firewall. Auch der Name variiert hier von Hersteller zu Hersteller, NAT-Regel, Portforward, DNAT, Portweiterleitung oder Portfreigaben sind hier gängige Begriffe.
Die Logik dahinter ist folgende:
Eine Verbindung, die an der externen IP Adresse des Routers auf einem bestimmten Port ankommt, wird weitergeleitet an eine interne IP-Adresse und Port.
Hinweis: Die Einrichtung einer Portweiterleitung macht den Exchange Server aus dem Internet via Port 443 erreichbar. Besser wäre der Einsatz einer entsprechenden Firewall bzw. Proxys (hier ein Beispiel) zwischen Internet und Exchange Server. Die Einrichtung ist aber nicht Gegenstand dieses Artikels.
Falls das Unternehmen über eine Fritzbox verfügt, funktioniert die Einrichtung einer Portfreigabe wie folgt:
Wie im Screenshot zu erkennen ist, wird nur der Port 443 (TCP) an die interne IP des Exchange Servers auf Port 443 weitergeleitet.
Das rote Tuch (Exchange Zertifikat)
Zum Schluss ist das “rote Tuch” besser bekannt als Zertifikat an der Reihe. Wenn die Vorbereitungen allerdings alle abgeschlossen wurden, ist es jetzt kein Problem mehr.
Noch einmal kurz zum Hintergrund:
In der voran gegangene Konfiguration wurden die virtuellen Verzeichnisse und die Outlook Anywhere Konfiguration soweit angepasst, das diese auf mail.frankysweb.de hören, aus diesem FQDN ergeben sich dann die entsprechenden URLs mit denen die Verzeichnisse (interne und externe URLs) entsprechend konfiguriert wurden. Internes und Externes DNS wurden ebenfalls so konfiguriert, dass der Exchange Server unter diesen URLs erreichbar ist. Somit sind für das Zertifikat nur die folgenden FQDNs von Bedeutung:
- mail.frankysweb.de
- autodiscover.frankysweb.de
Mehr muss nicht auf dem Zertifikat stehen. Nur diese beiden Namen. Falls sich jetzt schon jemand fragen sollte: Was ist denn wenn ich mehrere Domains habe und auch E-Mail Adressen mit beispielsweise “@frankysweb.com”? Weiterlesen, kommt noch…
Um die Zertifikatsanforderung zu speichern, sollte vorab ein Ordner angelegt werden. Am besten auf dem Exchange Server selbst unter C:\. In diesem Fall ist es C:\Zertifikat:
Jetzt kann die Zertifikatsanforderung erstellt werden.
Zertifikatsanforderung erstellen
Damit eine Zertifizierungsstelle ein Zertifikat ausstellen kann, wird eine Zertifikatsanforderung benötigt. Die Zertifikatsanforderung teilt der Zertifizierungsstelle die Eigenschaften für das Zertifikat mit. Um bei den Ausweisbeispiel zu bleiben: Die Zertifikatsanforderung ist der Antrag auf einen Ausweis, wobei der Antrag den Namen, Adresse usw. enthält. Der Antrag (Zertifikatsanforderung) muss jetzt von von einer Behörde/Land (Zertifizierungsstelle) ausgestellt werden.
Eine Zertifikatsanforderung kann via Exchange Admin Center erstellt werden:
Als Anzeigename wird “mail.frankysweb.de” eingetragen:
Der nächste Dialog kann so belassen werden, hier muss nichts ausgewählt werden:
Gespeichert wird das Zertifikat auf EX1 dem Exchange Server:
Im darauf folgenden Dialog werden alle URLs noch einmal angezeigt:
Wer die Liste durchscrollt, wird feststellen, das hier noch interne Servernamen und URLs angezeigt werden. Auch diese können so belassen werden:
Im nächsten Dialog lassen sich die Einträge für das Zertifikat bearbeiten, hier wird jetzt alles gelöscht, sodass nur noch “mail.frankysweb.de” und “autodiscover.frankysweb.de” überbleibt.
Vorher:
Nachher:
Jetzt müssen noch ein paar Angaben vervollständigt werden. Organisationsname entspricht dabei den Firmenname, der Abteilungsname kann frei gewählt werden, Ort, Bundesland und Land sollte klar sein:
Zum Schluss wird der Speicherort für die Zertifikatsanforderung angegeben. Im Vorfeld wurde dazu der Ordner c:\Zertifikat auf dem Exchange Server angelegt. Dieser Ordner kann nun per Administrativer Freigabe angesprochen werden:
Die Anforderung wurde erstellt im Admin Center ist nun eine ausstehende Anforderung zu sehen:
Ausstehende Anforderung bedeutet in diesem Fall soviel wie: Antrag ausgefüllt, aber noch kein Ausweis ausgestellt.
Unter C:\Zertifikat findet sich nun eine Datei mit dem Namen “Anforderung.txt”. Diese Datei enthält den Antrag für die Zertifizierungsstelle, auch “Certificate Signing Request” (CSR) genannt:
Der Antrag (CSR) muss nun bei einer Zertifizierungsstelle eingereicht werden.
Zertifikat von einer offiziellen Zertifizierungsstelle anfordern
Die zuvor generierte Anforderung muss nun bei einer Zertifizierungsstelle eingereicht werden. Die Zertifizierungsstelle stellt dann ein entsprechendes Zertifikat aus.
Wie schon mehrfach erwähnt müssen zwei Namen auf dem Zertifikat (SAN Zertifikat) vorhanden sein (autodiscover.frankysweb.de und mail.frankysweb.de). So steht es auch in der generierten Anforderung. Bei dem Reseller PSW gibt es recht günstig ein entsprechendes Zertifikat:
https://www.psw-group.de/ssl-zertifikate/detail/c44-geotrust-quickssl-premium/
3 Jahre Gültigkeit kosten 99 EUR. Verschiedene andere CAs bieten Zertifikate auch kostenlos an, wobei als wohl bekanntester Vertreter StartSSL Probleme mit Mozilla bekommen hat (StartSSL und auch WooSign haben es nicht ganz so genau mit der eigenen Sicherheit genommen).
Der Prozess wie eine Anforderung eingereicht werden muss, ist aber bei den meisten Zertifizierungsstellen ähnlich:
- Anmelden
- Zertifikatsanforderung einreichen
- Valdierung durchlaufen (das Verfahren kann unterschiedlich sein, meistens eine Mail an webmaster@domain.tld oder hostmaster@domain.tld)
- Zertifikat erhalten
- Bezahlen (ggf. auch kostenlos)
Trotz der Probleme bei StartSSL lassen sich weiterhin Zertifikate beantragen, da wie schon der Prozess bei den meisten Zertifizierungsstellen relativ ähnlich ist, folgt hier das Beispiel mit StartSSL. Die Anmeldung wurde bereits abgeschlossen:
Bei StartSSL müssen dann die beiden DNS-Namen angegeben und der Inhalt der Datei Anforderung.txt hochgeladen werden:
Nach entsprechender Validierung durch die Zertifizierungsstelle erhält man das Zertifikat. Für Testumgebungen lässt sich StartSSL weiterhin wunderbar verwenden, ich nehme an das die Probleme mit Mozilla in absehbarer Zeit geklärt werden.
Für produktive Umgebung würde ich empfehlen ein Zertifikat zu kaufen, der Preis aus dem oben genannten Beispiel ist sicherlich nicht zu hoch und bei 3 Jahren Laufzeit durchaus erschwinglich.
Sobald man das Zertifikat von der Zertifizierungsstelle erhalten hat (meistens per Download oder per Mail), kann es auf dem Exchange Server unter C:\Zertifikat abgespeichert werden.
Die meisten Zertifizierungsstellen stellen das Zertifikat in verschiedenen Formaten aus. Exchange Server kann mit .CER und .CRT Dateien umgehen. In diesem Beispiel ist es eine .CRT Datei:
Zertifikatsanforderung abschließen und Dienste zuweisen
Sobald das Zertifikat im Ordner C:\Zertifikat abgespeichert wurde, kann die Austehende Anforderung abgeschlossen werden. Dieser Vorgang kann wieder mittels Exchange Admin Center erfolgen:
Im Dialog wird dann wieder die Administrative Freigabe und der Name des Zertifikats angegeben:
Sobald die Anforderung abgeschlossen wurde, wird das Zertifikat mit “Gültig” gekennzeichnet:
Jetzt ist zwar ein gültiges Zertifikat vorhanden, aber dieses Zertifikat wurde noch nicht den Exchange Diensten zugeordnet.
Damit Exchange dieses Zertifikat auch künftig verwendet, muss es an die relevanten Dienste gebunden werden, dazu werden die Eigenschaften des Zertifikats per Doppelklick geöffnet und die folgenden Dienste zugewiesen:
- SMTP
- IMAP
- POP
- IIS
Die Warnung muss bestätigt werden, dann wird das Zertifikat ausgetauscht:
Ab jetzt benutzt Exchange das neue Zertifikat.
Überprüfung
Zur Überprüfung können nun mehrere Tests durchgeführt werden.
Zunächst kann die DNS Auflösung von internen sowie externen Rechnern getestet werden:
Intern muss die interne IP des Exchange Servers aufgelöst werden, extern die entsprechende IP des Routers mit der Portweiterleitung.
Dann kann Outlook Web Access von internen sowie externen Rechnern aufgerufen werden, jeweils unter den Namen mail.frankysweb.de. Beim Aufruf darf nun keine Zertifikatswarnung mehr auftreten:
In den Details des Zertifikat unter dem Punkt “Alternativer Antragsstellername” müssen beide Namen hinterlegt sein:
Outlook zeigt im Verbindungsstatus nur mail.frankysweb.de als Servernamen an, interne Namen dürfen hier nicht mehr vorkommen:
Der Outlook Modus “E-Mail Autokonfiguration testen” liefert nur noch URLs mit https://mail.frankysweb.de/… zurück
Exchange Remote Connectivity Analyzer lässt für den Autodiscover Test sauber durch:
Bei der URL “https://frankysweb.de:443/Autodiscover” darf es zu einem Fehler kommen, da Exchange nicht unter dieser URL erreichbar ist, für die URL https://autodiscover.frankysweb.de:443/autodisover” muss es sauber durchlaufen (Ohne Zertifikatswarnung)
Nachtrag
Dies war die grundlegende Konfiguration mit einer E-Mail Domain und einem offiziellen Zertifikat. Nun gibt es natürlich noch weitere Fälle mit einer internen Zertifizierungsstelle oder mehreren E-Mail Domänen. Das wird dann ein Fall für Teil 3 (bereits in Arbeit, wird verlinkt wenn fertig).
Super Artikel, vielen Dank.
Eine Frage hätte ich noch:
Für was sind die anderen Zertifikate, die laufen jetzt nach einigen Jahren ab. Werden diese benötigt und wie erneuert?
Microsoft Exchange
Microsoft Exchange Auth Zertifikat
WMSVC
Hallo Franky,
super Anleitung, vielen Dank dafür.
Ändern hier gerade die Einstellung an einem Exchange 2013 um danach auf 2019 zu migrieren. Soweit so gut. Nach Umstellung der virtuellen Verzeichnisse und improtieren des öffentlichen gekauften Zertifikats funktioniert dies auch wunderbar auf danach neu installierten Outlook-Clients, sofortige Verbindung ohne Fehler. Die bestehenden Clients (70 Stück an der Zahl) melden jedoch Proxy-Fehler und fragen in EndlosSchleife Benutzer und Passwort ab. Kein Beikommen. Legt man auf den alten bestehenden Clients ein neues Profil an, geht dass mit dem neuen Profil sofort fehlerfrei. Ist jedoch bei 70 Outlook-Clients ein riesen Akt. Mit vormals virtuellen Verzeichnissen exchange2013.domäne.local keinerlei Probleme. Irgendwas scheint in den Profilen bei autodiscover falsch integriert zu sein. Oder im DNS fehlt noch etwas.
Hast doch noch eine Idee?
Viele Grüße René
Ich danke erstmal für deine sehr guten Anleitungen und Hilfestellungen, durch die habe ich viel gelernt, muss aber wohl noch viel lernen. Denn ich habe den Punkt nicht mit dem Zertifkat. Habe dort nur den Auswahlpunkt Selbstsigniertes Zertifkat. Die andere Option steht mir nicht zur Verfügung.
Seitdem ich mein Zertifikat erneuert habe bekomme ich bei Outlook immer:
„Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein.“
angegeben wird der name vom internen Server, es sollte aber der Name von der registierten Domain remote.domain.de benutzt werden.
Vor der Neuausstellung gab es dieses Problem nicht. Jetzt muss der Vorgang fortgesetzt werden mit bestätigung auf ja.
Das nervt mit der Zeit. Ich habe nur das Zertifikat neu ausgestellt (nicht erneuert weil eine SAN-Domain mit hinzugekommen ist die aber nicht mit dem Exchange-Server zu tun habt.
Ich habe hier gesehen, dass auch andere Leute hier dieses Problem haben, vielleicht gibt es hier ja jemand der Tips hat damit man dieses Verhalten abstellen kann. Ansonsten funktioniert die Mail-Zustellung ohne fehlermeldung von intern und extern über meine Split-DNS-Konfiguration.
Dann passt der Name im Zertifikat tatsächlich nicht mit der angesprochenen Adresse überein.
und wo und wie ändere ich das?
Ich habe mal wieder Probleme mit:
Ich bekomme den wieder den obigenSicherheitshinweis
Es ging lange Zeit gut aber seit ein paar Wochen taucht es beim Start von Outlook immer wieder auf, sowohl auf meinem PC
wie auch bei einem neu eingerichteten Notebook.
Geändert wurde nicht ausser das mal Updates für den Exchangeserver kamen.
Aktuell exchange 2016 Build 15.1.2507.21
Da es früher mal ging gehe ich nicht davon aus das es mit dem Zertifikat und den Einstellungen (wie Split DNS, virtuelle Verzeichnisse zu tun hat, Auch der Exchange Verbindungsstatus zeigt auf remote.domain.de
die von lokal ausgeführt auf die interne IP vom Exchange-server zeigt und von extern auf die externe IP zeigt.
Hat da jemand hier noch Tips wie man der Sache auf den Grund gehen kann?
Hallo Frank,
Super Anleitung! Ich warte sehnsüchtig auf Teil3, denn ich habe einige Domänen und lebe gerade damit das alle Domänen auf eine einzige zeigen und bin mir unsicher ob das so gut ist.
Weiterhin habe ich zur Zeit Probleme mit meinem Android und dem ActiveSync. Es will anscheinend nicht syncen :(. Naja ich warte noch mal ne Nacht ab und hoffe das es die mystische IT-ler Nacht beheben wird.
Ansonsten hilfst du mir immer enorm weiter
Danke du MVP (kann man das sagen, denn ich habe das noch nirgends gelesen)
Grüße
Michael
Super Artikel und ich denke, dass ich das meiste auch verstanden habe ;-)
Was mir noch nicht ganz klar ist: was muss bzw. darf nicht als CN (Common Name) eingetragen werden und was muss als SAN eingetragen werden?
Der Hintergrund ist, dass ich schon verschiedene Artikel gelesen habe, in denen immer wieder von Client-Problemen bzgl. SAN-Zertifikaten geschrieben wird, wenn z.B. ein Host-FQDN nur im CN steht aber nicht als SAN eingetragen ist.
Zudem muss seit iOS 13 der Hostname als SAN angegeben werden, da der CN als nicht mehr vertrauenswürdig gilt (https://support.apple.com/de-de/HT210176).
Im o.a. Beispiel-Zertifikat wird ja als CN der Host mail.frankysweb.de verwendet. Das würde dann ja nicht mehr mit iOS funktionieren. Und laut DigiCert (https://www.digicert.com/faq/subject-alternative-name-compatibility.htm) sollen SSL Clients ja den CN ignorieren, wenn es ein SAN-Zertifikat ist.
Oder wird der CN automatisch beim Erstellen des Zertifikats immer auch als SAN eingetragen? Und heißt das dann, dass der CN bei SAN-Zertifikaten mehr oder weniger nur noch als Name dient und ansonsten von heute üblichen Clients (Outlook, Browser, Smartphone Mail-Apps) ignoriert wird (oder hat der CN doch noch eine wichtige Bedeutung?
Und würde dann im o.a. Beispiel auch ein Zertifikat mit dem CN=AndererServer.frankysweb.de und den beiden SANs mail.frakysweb.de und autodiscover.frankysweb.de auch funktionieren, also einem CN, der nicht mit dem Exchange zu tun hat?
Vielen Dank schon Mal
Gruß, Frank
Hallo Frank,
als CN wird in der Regel immer der DNS-Name eingesetzt, welcher auch durch die Benutzer aufgerufen wird. So ist es leichter für Benutzer erkennbar. Wichtig ist, dass alle entsprechenden DNS Namen als SAN angegeben werden. Wenn der CN beispielsweise auf mail.frankysweb.de lautet, dann muss mail.frankysweb.de auch als SAN eingetragen werden. Wichtig ist in jedem Fall das die SANs richtig sind, nur der CN reicht nicht aus. Bei der Ausstellung tragen viele CAs den CN auch gleich als SAN ein, das ist aber abhängig von der CA. Zu deiner Frage mit bei Beispiel: wenn der CN andererserver.frankysweb.de lautet, dann muss dieser auch als SAN eingetragen werden: andererserver.frankysweb.de mail.fr…, autodiscover… Das Zertifikat wäre damit auch gültig.
Gruß,
Frank
Hallo Frank,
somit ist letztlich also nur wichtig, dass alle tatäschlich verwendeten DNS-Namen als SAN eingetragen sind. Für die obige Exchange Konfiguration wäre es also ausreichend, wenn die SANs mail…. und autodiscover…. im Zertifikat enthalten sind. An welcher Stelle der SAN-Liste diese Einträge dann stehen, wieviel und welche weiteren SANs noch enthalten sind und was im CN steht, wäre für Exchange dann egal. Habe ich das so richtig verstanden?
Gruß, Frank
P.S.: es wurde in der Artikelserie ja schon auf das Geotrust Multi-SAN Zertifikat (bei PSW) hingewiesen. Trägt die CA von Geotrust den CN automatisch als SAN ein und man muss nur noch die weiteren SAN ergänzen oder muss man beim Erstellen des CSR den CN nochmal manuell als SAN eintragen?
Hallo Frank,
exakt. Du solltest in jedem Fall alle SANs beim Erstellen des CSRs korrekt mit angeben. Also auch den CN.
Gruß,
Frank
Hallo Frank,
ich habe ein Riesenproblem beim Kunden. Er wollte seinen Exchange eigentlich ab 1.1. nicht mehr nutzen daher habe ich das recht teure Wildcard-Zertifikat nicht verlängert. Jetzt arbeitet er trotzdem weiter. Ok, bestelle ich einfach ein neues Zertifikat…
Dachte ich aber leider zeigt der ECP erst eine Datumswarnung und beim Ignorieren nur eine leere weisse Oberfläche, noch nicht mal die Benutzerabfrage. Weder der Ersatz des Backend-Zertifikats noch irgend etwas anderes klappte bislang.
Auch der Weg über die Konsole klappt nicht, schon der Aufruf von Get-ExchangeCertificate scheitert:
[PS] C:\Windows\system32>Get-ExchangeCertificate
Fehler beim Exchange-Zertifikatvorgang mit Ausnahme auf Server SERVER2016. Die Fehlermeldung lautet: Unknown error
(0xe0434352)
+ CategoryInfo : InvalidOperation: (:) [Get-ExchangeCertificate], LocalizedException
+ FullyQualifiedErrorId : [Server=SERVER2016,RequestId=8da4ea95-0a4d-4b24-8293-fd7cfe964c7e,TimeStamp=06.01.2021 1
1:58:29] [FailureCategory=Cmdlet-LocalizedException] FFE12269,Microsoft.Exchange.Management.SystemConfigurationTas
ks.GetExchangeCertificate
+ PSComputerName : server2016.xxx.local
Grund ist eventuell dass ich testweise einmal das Datum zurückgestellt hatte um zu versuchen ob ich mit dem gestrigen Datum noch rankomme….
Irgend eine Idee was ich noch machen kann ausser ein komplettes Restore und Verlust der Mails seit gestern?
Hallo Franky,
immer noch ne Tolle Anleitung und habe Sie mir immer auf gemacht wo ich das bei mir in der Firma sowie beim Kunden umgesetzt habe!
Jetzt habe ich Gestern das nochmal bei einen anderer Kunden versucht und kommen dort auf Folgende Fehler:
ExchangeServer2013 (Server2012), 2 Domain Controller (Server2012 & Server2019)
Ich bekommen jetzt bei den Client Intern die Sicherheitshinweis, das der „Der Name auf dem Sicherheits Zert. nicht mit den Namen überein“ Sehe auch das dort oben die Interne Name steht mit der .local Endung , und nicht der Externe.
Mir ist aufgefallen, das ich erst vergessen hatte die Zone für „autodiscove“ anzulegen, das hab ich aber nachgeholt.
Hab aber leider immer noch die Fehlermeldung .-.
Habe alles nochmal überprüft und die Einstellungen sind so, wie Sie in der Anleitung sind :/
Extern Klappt auch alles Super!
Grüße Alex
Hallo Franky,
ich habe ein Zertifikat eines öffentlichen Zertifikats-Anbieters, das bald abläuft. SMTP Dienst ist drauf gebunden.
In der Zwischenzeit haben wir den Anbieter gewechselt. Ich habe ein neues Zertifikat erstellt und ebenfalls SMTP drauf gebunden.
Benutzt Exchange 2016 jetzt automatisch das neue Zertifikat, wenn das alte abläuft? Oder muss ich da noch etwas tun?
Moin,
hat alles auf Anhieb geklappt.
Ich komme immer gerne wieder auf Frankys Anleitungen zurück!
Das System ist ein Server2016 (DC) mit Exchange 2016, für 5 Mitarbeiter im Office.
Grüße
Michael
Hallo Franky!
Ich greife immer wieder auf deine Anleitungen als Stütze zurück und bin mehr als froh das es diese Seite gibt. Man erhält immer Zuverlässige Informationen für Konfigurationen und Problembehebungen die mich weiter bringen. Danke für diese nunglaubliche Mühen!
Nun habe ich jedoch zwei Problem, Ich habe eine DC (Server 2016 Standad) und einen Exchange 2016 Cu16 in je einer virtuellen Maschine am laufen und wollte ein Zertifikat erwerben und Einbinden. Zuvor habe ich deine Anleitungen durchforstet um alle srichtig zu machen. Habe hier nochmals die Exchange-URL Konfigurationen für autodiscover.xxx.de und mail.xxx.de geprüft. Alles gut. Dann habe ich im DC im DNS die Forward Zonen autodisvocer.xxx.de und mail.xxx.de eingerichtet laut deiner Anleitung. Nun werden die DNS Anfragen korrekt auf die interne IP des Exchange verwiesen. Aber nur für nicht Domänen Computer. Ich stehe grad völlig auf den Schlauch. Habe schon experimentiert und natürlich auch einige Berichte mit umgekehrter Situation gefunden. Das aber alles nicht geholfen. Das meiste bezog sich davon auf Dynamische Updates Aktualisierung für „nicht sichere und sichere“ Zonen. Es ist aktuell kein Beinbruch, aber die Domänenrechner verbinden sich aktuell immer über extern.
Mein zweites Problem. Trotz aller Einstellungen in Exchange das ich 100 MB eingehend und ausgehend in allen Postfächer empfangen und senden kann, funktioniert trotzdem immer nur 10 MB. Auch hie bin ich ratlos. Sowohl bei MX Empfang und Senden als auch bei sendenb per SMT-Relay. Ich wäre ein Tipp ebenfalls hilreich,
Vielen Dank im Vorab!
du hast aber keine Sonderzeichen wie (!@#$%^&*(). im Datenbanknamen? Da hab ich was bei Dell unter Artikel sln167469 gelesen
Hallo, Peter,
Nein, keine Sonderzeichen in den DB-Namen…
Ich habe meine Konfiguration nach obiger Anleitung durchgeführt.
„Dann kann Outlook Web Access von internen sowie externen Rechnern aufgerufen werden, jeweils unter den Namen mail.frankysweb.de. Beim Aufruf darf nun keine Zertifikatswarnung mehr auftreten:“
Leider kommt es bei mir intern weiterhin zu Zertifikatswarungen. Auch Outlook meldet, dass der Server nicht mit dem Zertifikat übereinstimmt. Von extern funktioniert es. Woran kann das liegen?
Nach Auskunft des Zertifikatslieferanten (SSLMarket) funktioniert ein offizielles Zertifikat im lokalen Netzwerk nicht…
Hallo Wolfgang,
hast du denn intern auch Split-DNS eingerichtet?
Also praktisch das für interne Namensauflösung auch der externe Name auf die lokale IP zeigt….
So geht es bei mir auch mit offiziellem Zertifikat.
VG
Peter
Hallo, Peter,
danke für die schnelle Antwort – ich habe (stressbedingt ;-) ) etwas länger gebraucht, um wieder hierher zu kommen…
Ja, ich denke, die beiden Zonen (mail.meinedomain.de und autodiscover.meinedomain.de) habe ich – wie in der Anleitung – mit den entsprechenden A-records für die Exchange-IP – richtig angelegt.
Mittlerweile hat sich noch ein weiteres Problem (vermutlich aus der gleichen Ursache resultierend) gezeigt:
Beim Versuch, eine Abwesenheitsnotiz einzurichten, kommt die Meldung:
„Ihre Einstellungen für automatische Antworten können nicht angezeigt werden, da der Server zur Zeit nicht verfügbar ist. Versuchen Sie es später erneut.“
Ich sollte vielleicht hinzufügen, dass das Implementieren des Zertifikats im Rahmen der Migration von 2010 nach 2016 geschah. Da es für mich nach einem Zertifikat-Problem aussah, habe ich die Frage hier gepostet.
Zwischenzeitlich zeigen sich – wie bereits angeführt – auch noch andere Probleme.
So weist die Suche in Outlook folgende Meldung aus:
„Wir haben Probleme beim Abrufen von Ergebnissen vom Server. Manche Elemente sind in Ihren Suchergebnissen vielleicht nicht enthalten.“
Bei der Überprüfung stellte sich heraus, dass der Suchindex beschädigt war. Dieser wurde zwischenzeitlich repariert und zeigt nun „Healthy“. Die Fehlermeldung in der Suche bleibt aber… :-(
Mittlerweile habe ich herausbekommen, dass Autodiscover funktioniert (Email Autokonfigurationstest von Outlook).
Die Suche funktioniert merkwürdigerweise ohne Fehler, wenn ich die Cache-Funktion abschalte. Mit eingeschaltetem Cache bekomme ich die Fehler.
Die Zertifikatmeldungen sind nach Löschen und Neuanlage des Profils weg (bisher getestet bei 2 Benutzern).
Bleibt das Problem der Abwesenheitsnotiz…
Ein super Anleitung die mir schon öfter geholfen hat. Vielen Dank dafür!
Jetzt stehe ich aktuell vor dem Problem dass, trotz gewissenhaft durchgearbeiteter Anleitung, bei den Clients
eine Fehlermeldung bezüglich Zertifikat auftaucht:
„Der Name auf dem Sicherheitszertifikat ist ungültig oder…“
Als Servername wird der interne FQDN (server02.domain.local) angezeigt der natürlich nicht auf dem Zertifikat vorhanden ist.
Ich habe beim besten willen keine Idee mehr wo dieser interne Servername herkommt.
DNS überprüft, sämtliche URLs auf dem Exchange überprüft.
Nslookup intern + extern alles ok, etc…
Jeder Hinweis ist willkommen.
Client: Win 10 + Office 365 Business
Server: 2012R2 + Exchange 2016
Nachtrag: nachdem ich mich noch einmal mit dem Artikel über Autodiscover beschäftigt habe, konnte ich durch Löschen der autodiscover-Cache-Dateien erreichen daß die Meldung bzgl. des internen Namens / Zertifikat nicht mehr erscheint.
Der Startfehler mit den alten Profilen blieb dadurch leider bestehen, das stört jetzt aber nicht so…
Grüsse Ansgar
Hallo Frank,
danke für die Superanleitung. Habe einen Exchange 2016 damit nach der Migration von einem SBS2011 über eine weitere sehr gute Anleitung von Dir mit einem offiziellen Zertifikat versehen weil Zugriff über Handys sonst nicht mehr vernünftig möglich. Verwende dazu ein Wildcard-Zertifikat. An dem Server arbeiten ca. 15 Clients alle mit Outlook 2013.
Habe jetzt das gleiche Problem was schon etliche andere Kommentare beschreiben, ohne daß ich eine passende Lösung gesehen hätte: auf einigen PCs erscheint der interne Exchange-Name auf einer Zertifikatswarnung „Der Name auf dem Sicherheitszertifikat ist ungültig…“ Als Zertifikat wird das Wildcard angezeigt. Auf mehr als der Hälfte der Rechner klappt es ohne den Hinweis. DNS ist bei allen gleich konfiguriert, nslookup zum autodiscover ist korrekt. Arbeite ich bei diesen Rechnern mit dem ursprünglichen migrierten Profil, lässt sich Outlook gar nicht öffnen (Informationsspeicher steht nicht zur Verfügung), mit einem neu angelegten kommt dann die Zertifikatswarnung. Bin ich dann einmal im Outlook, sehe ich sowohl im Verbindungstest als auch beim Autodiscover-Test über Strg-Outlook die gleichen Einträge wie bei den funktionierenden Clients.Alle virtuellen Verzeichnisse sind mehrfach geprüft ausschliesslich auf die externe URL eingestellt. Der Exchange setzt seit heute CU15 ein.
Hast Du eine Idee? Grüsse, Ansgar
Hallo miteinander,
ist es möglich, statt mail.domain.de und autodiscover.domain.de ausschließlich autodiscover.domain.de zu verwenden? Man würde also alle virtuellen Verzeichnisse auf autodiscover.domain.de statt mail.domain.de legen. Dann könnte man statt eines teureren Wildcard Zertifikates ein günstigeres Einzelzertifikat verwenden.
Vielen Dank schon einmal im voraus für die Antwort!
Hallo Udo,
da wird eher anders herum ein Schuh draus, verwende nur mail.domain.de und konfiguriere Autodiscover auf diese Domain. Im DNS werden dann anstatt Host-A Records, SRV-Records angelegt. Ein Beispiel für die Konfiguration findest du im Autodiscover Whitepaper:
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-autodiscover/
Gruß,
Frank
Hallo Frank,
die Anleitung ist genial und funktioniert bei uns schon 10 Monate fehlerfrei.
Das bedeutet aber auch dass in 2 Monaten das Zertifikat abläuft.
Kannst du mir Tipps geben wie ich das Zertifikat bei der PSW-Group verlängere?
Danke
Jens
Da suche ich auch gerade nach einer Lösung, wenn ich einfach das vorhandene nehme und sage verlängern bzw. Anforderung neu erstellen, bekomme ich zwar die cert aber beim einreichen bei PSW meckert PSW und sagt:
kein LändercodeC= angegeben. Was muss ich Tun ?
Hallo zusammen, in Verbindung mit den Zertifikatseinstellungen bin ich auf ein für micht seltsames Problem gestossen.
Wir haben einen Exchange 2016 Server auf einem 2012 R2 Std am laufen. Zertifikate usw. ist alles eingerichtet, die Bindungen des Zertifikat passen etc. Unsere Outlook 2013/2016 Clients wurden auch ohne Probleme angebunden.
Auf unserem DC läuft die Zertifizierungsstelle für unseren Terminalserver der über RDP mit Zertifkat und RSA Anbindung
angesprochen wird. Ab und an erhalten Outlook Clients eine Zertifikatswarnung mit Hinweis auf unsere Subdomains
mail.“unseredomäne“.de und autodiscover.“unseredomäne“.de . Schaut man sich das Zertifikat an wird das selbst ausgestellte des DC für den Terminalserverbetrieb „unseredomain.dyndns.org“ angezeigt. Unsere DNS Forwardzonen für die mail und autodiscover werden auch per A Eintrag auf die IP des Exchangeservers verwiesen. Alle Einstellungen passen auch auf der Powershell überprüft am Exchangeserver. Wie kommt es zu diesem Problem ? Jedesmal disconected sich dann Outlook und der entsprechende Client muss erst einen neustart machen bevor Outlook sich wieder verbinden kann.
Hallo Frank,
ich habe ein Problem, nachdem ein abgelaufenes Wildcard Zertifikat beim Exchange 2016 gewechselt wurde.
Es lässt sich jetzt nicht mehr der SMTP Dienst mit dem Zertifikat verbinden.
Woran kann das liegen oder wie bekommt man den Dienst dort wieder hinzugefügt?
Funktionieren tut es aber trotzdem
Hallo Frank und alle,
eigentlich ist alles nach Anleitung bestens durchgelaufen. Das wichtigste kann ich aber nicht ändern den MAPI namen da mir den Punkt unter Virtuelle Adapter fehlt.
MAPI läuft aber bestens, da die Outlooks funktionieren bis auf das jetzt der Servername nicht zum Zertifikat passt…
Würde es langen das in der Shell auszuführen:
Get-MapiVirtualDirectory -Server $servername | Set-MapiVirtualDirectory -externalurl $mapiexturl -internalurl $mapiinturl
(mit den richtigen Variablen ;)
Danke /Lars
Hallo Frank,
erstmal vielen Dank für diese super Anleitung.
Bei mir fehlt unter den virtuellen Verzeichnissen der Punkt „mapi“ . Im IIS ist der allerdings zu sehen.
Wie kann das sein das der EX die Schnittstelle nicht einbindet?
Danke & Grüße
/Lars
hei Frank, deine Komentarfunktion hat grad aus meinen www . irgendwas vom Post von eben ein http davorgehauen. So wars nicht gemeint. Also alles ohne http:// bitte
Gruß Jörg
Hallo Frank,
besten Dank für Deine Antwort. Ich hatte kurz zuvor auch die Lösung schon gefunden. Google ist Dein Freund. :-) War vorher nur nicht auf die Idee gekommen das man das konvertieren können kann. Nun bin ich schlauer. Im übrigen kann man auch gleich das Intermediate Zertifikate mit aufnehmen und hat dann alles gleich in einer Datei drin.
Für alle die hier mitlesen und das auch machen müssen kurz der openssl befehl dazu:
openssl pkcs12 -export -in ev_intermediate.crt -in http://www.xyz.crt -inkey http://www.yxz.key -out http://www.xyz.de.pfx
Die pfx Datei fliegt dann in den Exchange
(ich bennene meine Zertifikatdateien immer nach der Hauptdomain, dann isses etwas übersichtlicher)
viele liebe Grüße an Dich Frank Du hast mir die ganze Zeit extrem geholfen mit deinem Blog.
Jörg
hallo joersch
Danke für dein feedback, immer schön wenn eine Lösung kommt. Ich habe auch mal mit OpenSSL rummachen müssen um ein gültiges Zertifikat zusammenzusetzen, bequem ist anders ;-)
Hallo Frank,
besten Dank für Deine Tutorials. Ich habe meine Exchanges von 2003 über 2010 zu 2016 dank Deiner Hilfe erfolgreich migriert. Wenn man im Web sucht, kommt man praktisch an Deinen Tutorial nicht vorbei. Das hat mir alles ausgesprochen gut geholfen. Klasse!
Auch ich habe eine Zertifikatsfrage. Wir setzten ein GeoTrust EV Zertifikat ein (websites), in dem ich jetzt im Zuge eines reissue noch die autodiscover.xyz.de und outlook.xyz.de per SAN mit aufgenommen habe. Das csr ist nicht mit exchange erstellt, sondern ganz klassisch in einer linux kiste. Von GeoTrust habe ich nun das Zertifikat nebst intermediate Zertifikate bekommen. Hier habe ich zusätzlich noch das csr und natürlich den private Key als separtes File.
Importiere ich nun das offizielle Zertifikat per:
Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path C:\Zertifikat\www.xyz.de.crt -Encoding byte -ReadCount 0))
Wird es importiert und auch mit seinem Thumbprint angezeigt. Soweit alles gut.
Möchte ich es nun aktivieren, kommt ein Fehler das der PrivateKey nicht enthalten ist.
[PS] C:\Windows\system32>Enable-ExchangeCertificate -Thumbprint „……..“ -Services POP,IMAP,SMTP,IIS
Ein spezieller RPC-Fehler ist auf Server EXCHANGE aufgetreten: Das Zertifikat mit dem Fingerabdruck
‚….‘ wurde gefunden, ist jedoch für die Verwendung mit Exchange Server nicht
gültig (Begründung: PrivateKeyMissing).
Logisch, mein crt was ich von der offiziellen CA erhalten hab, hat natürlich keinen PrivateKey enthalten. Den hab ja auch ich und geb den selbstverständlich nicht einer CA. Das würde ja den ganzen Prozess sonst völlig nutzlos machen.
Blos wie bekomme ich jetzt das Zertifikat nebst meinem PrivateKey in den Exchange rein? Die Dokus zu Import-ExchangeCertificate und Enable-ExchangeCertificate schweigen sich dazu aus.
Wo ist denn nur mein Fehler? Kannst Du mir einen Tipp geben was ich hier falsch mache?
besten Dank
Jörg
Hallo Joersch,
du kannst Private Key und Public Key mittels OpenSSL in das PKCS12 Format konvertieren. In diesem Format kannst du es auf dem Exchange Server importieren und den Exchange Diensten zuweisen. Der private Key liegt jetzt auf deinem Linux Server, da du den CSR dort erzeugt hast. Exchange benötigt natürlich den Private Key mit Zertifikat.
Gruß,
Frank
PS: Hoffe das war so verständlich ausgedrückt.
Hallo Frank,
seit einiger Zeit kämpfe ich mit der Medlung von Outlook und der Zertifikatswarnung mit der Url des lokalen Exchange. Ich habe alles so konfigueriert wie in den Anleitungen beschrieben. NsLookup liefert auch korrekte Ergebnisse.
Zusätzlich zum Test habe ich eine neue Testdomäne mit Ex-2016 installiert. Auch hier das gleiche Problem.
Aufgefallen ist mir, das beim Abruf von Get-ClientAccessService |fl unter Fqdn der lokale Name steht. Kann / muss ich den auch auf die externe verbiegen und falls ja, wie?
Beim Get-WebServicesVirtualDirectory|fl ist noch zu sehen, dass die InternalNLBBypassUrl leer ist, sonst steht alles auf dem externen FQDN (außer bei MetabasePath).
Hallo Klaus,
kontrolliere noch einmal deine URLs, im Artikel stehen alle relevanten URLs.
Gruß,
Frank
Hallo nochmals,
hast du wegen der SMTP Zustellung einen Tipp für mich – siehe meine obige Frage: Danke und Gruß
Hallo Frank,
erst einmal auch von mir Danke. Hast mir mit der ausführlichen Anleitung sehr weitergeholfen und alles funktioniert wie vorgesehen.
Jetzt habe ich mal, wie von Dir beschrieben den MS Remote Connectitvity Analyzer durchlaufen lassen und bekam als Ergebnis: „Connectivity Test Successful with Warnings“
Dies ist die Warnung:
„The Microsoft Connectivity Analyzer can only validate the certificate chain using the Root Certificate Update functionality from Windows Update. Your certificate may not be trusted on Windows if the „Update Root Certificates“ feature isn’t enabled.“
Weiß jemand was dies bedeutet bzw. wie man dies korrigieren kann?
Danke und Gruß Michael
Hallo Michael,
Ich nehme an, dass dir entsprechende Zwischenzertifikate fehlen. Handelt es sich um ein Zertifikat von GoDaddy?
Gruß,
Frank
Hallo Frank,
danke dass Du gleich antwortest: nein, wie von Dir empfohlen, ist das Zertifikate von der PSW-Group.
Gruß Michael
Guten Morgen,
basierend auf diesem Artikel und deinem Autodiscovery Whitepaper hab ich noch die ein oder andere Frage:
Umgebung:
Domäne A: firma.de mit Wildcardzertifikat,
Domäne B: firma.com bislang ohne Zertifikat.
Feste IP und Exchange über mail.firma.de autodiscovery.firma.de erreichbar.
Ich habe in der Vergangenheit sonst mit dem PopCon von Servolution oder dem Pullution Connector gearbeitet. Jetzt steht im Raum das ganze auf SMTP Empfang umzustellen.
D.h. MX auf mail.firma.de umsetzen, Firewall und Connector konfigurieren, das wars. Richtig?
Jetzt kommts.
Was mach ich mit der .com Domäne? Da ich dafür kein eigenes Zertifikat habe. Brauch ich eins?
Oder kann ich den MX auch auf die DE Domäne stellen? Und zusätzlich einen SVR Record?
Noch eine Frage:
Ich habe ja beide Domänen als akzeptierte Domänen im Exchange. Mit Popconnector sage ich expliziet schiebe PopEingang in Postfach XY. Wie ist das bei zwei Domänen bei SMTP Empfang? Wird das Ziel anhand des E-mailadressenpools im Postfach angesteuert (1x de und 1x com Adresse/Postfach)? Oder anhand der Standardadresse? Würde aber bedeuten dass ich für jede Standardadresse ein eigenes Postfach brauch, oder?
Sorry für die ggf. amateurhaften Fragen, aber MX/SMTP Zustellung ist für mich neuland.
Danke und Gruß
Jochen
Hallo Frank,
danke für den Verweis. Habe ich das falsch verstanden oder darf man bei Exchange 2010, im Falle eines CAS Arrays, den MAPI Verkehr sowieso nur auf die interne domain verweisen?
Danke und Grüße!
Hallo Frank,
danke für deine Rückmeldung!
Ich muss noch sagen, dass es sich bei uns um einen Exchange 2010 handelt. FOlgende URLS konnte ich anpassen: OWA, ECP, ActiveSync, OAB, Autodiscover
MAPI konnte ich nicht finden! Die Verzeichnisse stimmen aber soweit. Trotzdem greift er auf den fqdn des Exchange Servers bei Verbindungsstatus zu.
Vielen Dank nochmal für deine Hilfe!
MFG Kilian
Hallo Kilian,
für Exchange 2010 musst du ein CAS-Array einrichten. Der Artikel hier bezieht sich auf Exchange 2016. Hier im Blog findet sich aber auch ein entsprechender Artikel für Exchange 2010.
Gruß,
Frank
Hallo Frank,
vielen Dank für deinen super Beitrag!
Leider habe ich das Problem, dass Outlook beim Verbindungsstatus noch die interne Serveradresse stehen hat.
Wenn ich dich recht verstanden habe sollte da ja jetzt mail.domaine.tld stehen!
Beim autokonfigurationstest steht verbunden mit interner Server aber alle anderen Dinge laufen sauber auf die mail.domain.tld.
Kannst du mir weiterhelfen?
Hallo Kilian,
prüfe noch einmal die Einstellungen der virtuellen Verzeichnisse und von Outlook Anywhere, da wird noch irgendwo der Servername stehen.
Gruß,
Frank
Moin Frank,
saubere Arbeit und bestens dokumentiert.
Ich hätte da noch zwei Fragen:
1. In einem weiteren Artikel erklärst du die Notwendigkeit dass AD´s zukünftig z.B. ad.testdomain.de
die offizielle Domain wäre http://www.testdomain.de
Im internen DNS gehe ich dennoch mit den Zonen so um wie du es beschrieben hast und lege für die mail. und autodiscovery die zwei Zonen an?
2. Wie verhält sich das ganze wenn ich bereits ein Wildcard Zertifikat habe?
Vielen Dank vorab.
Hi,
zu 1) Ja, du kannst die Zonen wie beschrieben erstellen.
zu 2) Wenn du die URLs entsprechend konfiguriert autodiscover.testdomain.de, kannst du das Wildcard Zertifikat nutzen
Gruß,
Frank
Hi nochmal,
hast du ein workaround bzw einen fahrplan wie ich dann das selbsterstellte Exchange Zertifikat durch das vorhandene Wildcard Zertifikat austausche? Über Anfordern und Abschließen gehts ja nicht, das das Wildcard Zertifikat ja bereits besteht.
Danke vorab
Beste Grüße
Jochen
Hi,
wenn du das Zertifikat bereits hast, musst du es nur importieren und die Dienste zuweisen. Beides funktioniert via EAC (Server -> Zertifikate). Alternativ auch via Shell.
Gruß,
Frank
Sry sehe grade das Marcus H. scheinbar die selben Probleme hat/hatte. Ich werde mal nachher alle betroffenen Server neu starten, ich denke aber nicht das das einen Unterschied macht.
Ein Dankeschön vorab auch von mir.
Ich hatte zunächst eine laufende Umgebung mit (vereinfacht):
intern.firma.de als interne Domain
firma.de als externe Domain (für VPN, ActiveSync, etc.)
firma_erweitert.de als externe Domain (für Webseite, Haupt-E-Mail-Domain)
Der exchange.intern.firma.de lief mit einem selfsigned certificate das ich über die AD verteilt habe. Outlook hat dann über autodiscover.intern.firma.de den Exchange gefunden und war mit dem Zertifikat glücklich da es ja im Zertifikatsspeicher liegt.
Nun habe ich mir ein SAN Zertifikat besorgt (mail und autodiscover.firma.de) und meinen Exchange wie hier beschrieben auf mail.firma.de umgestellt. Meinen internen DNS habe ich wie folgt angepasst:
autodiscover.intern.firma.de CNAME zeigt auf autodiscover.firma.de
mail.intern.firma.de CNAME zeigt auf mail.firma.de
autodiscover.firma.de ist als Zone eigentragen und hat einen A Record ohne Namen der auf die IP des Exchange zeigt, selbes gibt für mail.firma.de
Jetzt verbindet sich mein Outlook allerdings immernoch zu exchange.intern.firma.de (wie vor der Umstellung) und bekommt entsprechend eine Zertifikatswarnung weil der Hostname nicht zum Zertifikat passt. Ich bin etwas ratlos warum Outlook weiterhin mit exchange.intern.firma.de redet, auch wenn ich das Profil in Windows lösche und automatisch neu einrichte.
Zunächst mal eine Grundsatzfrage: Spielt firma_erweitert.de als E-Mai Domain eine Rolle für Autodiscover? Muss ich hier auch noch im DNS aktiv werden?
Und dann die Frage schlecht hin, wo kann das Problem noch bestehen? Im Exchange habe ich (nachträglich) die virtuellen Verzeichnisse auf mail.firma.de angepasst und auch den IIS neu gestartet. Outlook bleibt sturr auf exchange.intern.firma.de
Vielen Dank. Reicht es das alte im Exchange dann zu löschen oder zu deaktivieren und die Prozedur neu zu machen oder muss ich noch zusätzlich etwas beachten?
Beste Grüße Bernd
Hallo Bernd, wenn du das neue Zertifikat hast, kann das alte gelöscht werden. Es wird eh für ungültig erklärt.
Gruß, Frank
Hallo Frank,
vielen Dank für die tolle Anleitung. Ich habe bei PSW Group ein Zertifikat bestellt und eingebunden. Es funktioniert soweit alles. Ich habe nur den Fehler gemacht, dass ich bei deren Bestellformular autodiscover nicht als SAN dazugeschrieben habe. Ich dachte, das steht automatisch im Zertifikat – zumal es bei der CSR drin stand. (Mit Encoder geprüft.)
Kann ich einfach nochmal ein zweite Anforderung nur mit autodiscover erstellen und ein zweites bei PSW ordern?
Vielen Dank für eine Info. Beste Grüße Bernd
Hallo Bernd,
beide DNS-Namen müssen auf ein Zertifikat. Du kannst das Zertifikat bei PSW zurückziehen lassen und ein Neues ausstellen lassen (Mit neuem CSR).
Gruß, Frank
Hallo Frank,
vielen, vielen Dank für Deine Mühe. Leider komme ich bei StartSSL nicht weiter. Wenn ich den Inhalt der TXT Datei einspiele kommt die Meldung „CSR format content parse error,please generate a new one.“
Habe ich jetzt mehrfach probiert und bekomme immer wieder den selben Fehler.
Was mache ich falsch?
Gruß
Christoph
Hallo Christoph,
StartSSL ist nicht mehr vertrauenswürdig und wird auch demnächst geschlossen. Verwende stattdessen Let’s Encrypt. Hier findest du auch ein Script, welches dir das Zertifikat besorgt:
https://www.frankysweb.de/neue-version-des-exchange-zertifikatsassistent-fuer-lets-encrypt/
Gruß,
Frank
Fehler gefunden, DNS Einträge wurden nicht aufs zweite AD repliziert…
*neuebaustelleaufmach
Ich hab es jetzt für Exchange 2013 umgesetzt, mit GeoTrust Zertifikat und es scheint soweit alles in Ordnung zu sein, abgesehen von den Internen Outlook Clients.
Diese geben einen Zertifikatfehler aus und sagen die lokale Domain passt nicht zum Zertifikat. (Was ja verständlich ist)
„Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Webseite überein“
Ich hab ledigilich die Powershell beim alten Namen gelassen, der Rest hat den neuen. Ich habs jetzt diversemal geprüft, habt ihr da eine Idee? :/
Hallo Frank,
Deine Anleitungen sind immer eine gute Hilfe. Nun stehe ich aber vor einem Problem beim erstellen eines Tertifikates bei StartSSL/StartCOM. Nach dem reinkopieren der Anforderung erscheint rechts neben dem Feld nicht wie bei Dir „Algorythm: RSA Key Length: 2048“ sondern „CSR format content parse error, please generate a new one“. Was mache ich falsch?
VG Mike
Hallo Mike,
StartSSL / STartCOM ist keine vertrauenswürde CA mehr. Schau dir lieber die Let’s Encrypt Zertifikate an. Du findest entsprechende Artikel hier auf der Seite.
Gruß, Frank
Hi.
Leider kommt bei mir der Fehler „CSR format content parse error, please generate a new one“ wenn ich die ANforderung in das Feld kopiere. Habe es auch schon mehrmals neu erstellt.
Was mache ich denn dort falsch?
Danke dir.
VG,
Jens
Hi Frank, danke für den Hinweis und den Link. Das hat mir geholfen.
Habe aber leider noch ein Problem Lokal im Outlook. Trotz der Konfiguration deiner Anleitung kommt jetzt
noch der Fehler „Der name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein“, obwohl der korrekte Name im Zertifikat steht. Er syncronisiert die Mails auch, alles scheint zu funktionieren, aber die Meldung kommt nach ca. 1 Minute nach öffnen des Outlooks. Man muss mit Ja bestätigen und dann kommt diese erst wieder, wenn der Outlook geschlossen wird und neu geöffnet wird.
Hast du mir Hier einen Tipp, an was das noch liegen kann? Ich habe ein Zertifikat von GeoTrust.
Danke
Gruß Markus
Hallo Zusammen,
erst mal großes Lob an die super Klasse Anleitung von Frank. Habe mit dieser Anleitung entsprechend alles konfiguriert auf meinem Exchange 2016. Es läuft auch alles soweit ordentlich. Habe nur das Problem, dass ich mit dem Firefox nicht auf das OWA zugreifen kann. Es kommt immer die Fehlermeldung NS_ERROR_NET_INADEQUATE_SECURITY. Wo muss noch eine Einstellung gemacht werden, dass OWA auch unter Firefox und nicht nur unter IE und Edge funktioniert?
Vielleicht weiß jemand Rat. Danke!
Gruß
Markus
Hi Markus,
ich denke dies hier sollte helfen:
https://www.frankysweb.de/chrome-und-windows-server-2016-err_spdy_inadequate_transport_security/
Gruß, Frank
Mach mal ein neues Zertifikat selbst. Auch mit neuer Vorlage. Hatte ich mal bei einem Kunden, dass das Zertifikat nach Installation immer ein paar Stunden ging, dann blank nach Anmeldung. Habe nie rausgefunden, was das Problem war, aber lag an der Vorlage in der Zertifizierungsstelle.
nochmals Update und Gute Nacht,
bis auf den Zertifikatsfehler geht jetzt wieder alles :) also ich stehe wieder am Anfang.
Wenn es gar nicht anders geht kommt halt ein Wildcard Zertifikat, kostet zwar wieder etwas mehr aber ist wahrscheinlich Stressfreier
Update Echange Konsole geht wieder, Im ISS dem Port 444 ein SSL Zertifikat zugewiesen dann kommt man wieder rein :) leider versnedet der Exchange im Moment keine Mails an extern, da muss ich jetzt mal nachsehen
Sorry wenn ich euch hier so zuspamme, aber Problem ist immer noch nicht gelöst, ganz im Gegenteil.
Ich habe etwas an den Zertifikaten im Manager geändert. Seitdem verbindet sich auch intern kein Outlook mehr. normalerweise kein Problem hatte ja alle Zertifikate gesichert und die Einstellungen dokumentiert. Nun aber das Problem ich kann mich zwar in OWA und auch im ECP anmelden, bekomme dann aber nur eine blanke Seite angezeigt.
Wäre Super wenn mir jemand einen Tip geben könnte wo der Fehler liegt.
Ansonsten werde ich morgen dann wohl alles neu installieren müssen
so Exchange und DC neu gestartet. Leider keine Veränderung.
Was aber auch total seltsam ist, bei einigen Benutztern klappt die Anmeldung über die Outlook App für IOS bei anderen nicht ?? Gibt es eine Beschränkung der Postfachgröße Bei der App ? Die beiden Benutzer, die es zur Zeit nicht könne waren vorher in der Gruppe Domänenadmin, da habe ich Sie rausgenommen, da ich glaube irgendwo mal gelesen zu haben, das es deshalb nicht geht, aber auch das brachte bisher keine Veränderung.
Jemand ein Paar Ideen für mich ? Danke
es ist nicht unbedingt ein Zertifikatsfehler aber irgendwo ist noch ein Wurm drin.
Ich bekomme den sicherheitshinweis
Zertifikat gültig, Dauer gültig aber dann –
Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Webseite überein.
Dann erscheint oben der „falsche FQDN“ des Servers und zwar mit seinem internen Servernamen und nicht mit exchange.intern.domäne.de auf dem zertifikat habe ich aber stehen outlook.domäne.de bzw. autodiscover.domäne.de
Wie bekomme ich das korrigiert ? Bis ich das neue Zertifikat installiert hatte war ja alles OK :) Nun ist es halt ein echtes.
Hi Marcus,
leider kann ich dir nicht genau sagen wo der Fehler bei mir lag, aber ich nehme an das der IIS was damit zutun hat. Schlussendlich habe ich ein IIS-Reset auf dem Server gemacht und Ruhe war.
Heute habe ich keine Zertifikatswahrungen mehr. Vorher habe ich viele Möglichkeiten ausprobiert, welche manchmal auch zum Erfolge geführt haben.
Lokalen Outlook Cache löschen und Outlook Neuinstallation haben meist die Warnungen verschwinden lassen. Komischerweise nicht bei allen Usern.
Bei Usern mit zwei oder mehr Postfächer hat es meist nicht geholfen.
Aber seit dem IIS Reset (Cache leeren) ist alles wieder in Ordnung.
Viele Grüße
Maik
@ Heiner @Maik, @Frank, Hallo,
habe jetzt das gleiche Problem wie ihr:
Schritt für Schritt nach Anleitung von Frank umgesetzt (auf Exchange2016 aktuelle CU mit Outlook2016 u.2013-Clients),
alles funktioniert wie erwartet,außer Outlook -> Zertifikatsfehler! Outlook bekommt immer noch den
alten internen Servernamen „ex1.meinedomäne.de“ präsentiert wo hingegen das neue Zertifikat auf „mail.meinedomäne.de“ lautet. Alle URLs intern+extern(owa,OAB,Microsoft-Server ActiveSync, mapi, EWS, ec, Outlook Anywhere) auf „mail.meinedomäne.de“ sowie autodiscover intern auf „autodiscover.meinedomäne.de“ angepasst. Habe alle Einstellungen dokumentiert und mehrfach kontrolliert, finde aber keinen Fehler. Wer kann helfen? Wie kann Outlook sich auf den neuen Servernamen verbinden?
Viele Grüße
Marcus
Hallo Frank,
ich möchte auch einmal ein herzliches Dankeschön hier lassen! Deine Tutorials usw. helfen mir sehr, bzw. haben mir auch sehr geholfen einen Windows Server 2016 mit Exchange einzurichten. Gerade die Zertifikate waren etwas schwieriger, mit deiner guten Erklärung jedoch ganz einfach und man hat es auch verstanden für Folgeprojekte.
Ich hoffe du machst noch weiter! Einiges gibt es sicher noch zu lernen :-)
Danke und schöne Grüße!
Vielen Dank für das Lob, schön zu hören das es weitergeholfen hat. Ich betreibe diese Seite ja nun schon ein paar Jahre und möchte das auch noch ein paar weitere Jahre machen :-)
Ich lerne ja auch jeden Tag etwas dazu :)
Hallo Frank,
Danke für deine Hilfe und das HowTo, läuft einwandfrei jetzt endlich auch ohne externen Zertifikat Fehler :)
gruß Mike
Hallo Franky,
wirklich tolle Anleitung. :-)
Ich hab hier Exchange 2010 laufen und bin aktuell dabei deine Anleitung durchzuarbeiten, da ich nun auch ein externes Zertifikat einsetzen möchte.
Was mir allerdings fehlt sind in Exchange 2010 die MAPI & die EWS ìntern/extern URL, wo finde ich diese?
Danke.
Hi Mike,
MAPIoverHTTP wird nicht von Exchange 2010 unterstützt. EWS lässt sich per Shell konfigurieren: get/set-webservicesvirtualdirectory
Gruß, Frank
Hallo @ll, gestern hatte ich Besuch: Der Fehler: NS_ERROR_NET_INADEQUATE_SECURITY zeigte sich im Firefox, wenn ich auf meinem frisch installierten Exchange 2016 CU5 mit eigenen AD-Zertifiakten per OWA zugreifen wollte.
OK – Firefox mag kein SHA1 – macht ja Sinn..
Also Zertifizierungsstelle auf SHA-256 umgestellt: certutil -setreg ca\csp\CNGHashAlgorithm SHA256 – neues Zertifikat gleiches Problem
Hier https://www.nartac.com/Products/IISCrypto habe ich „best practice“ ausgeführt – nun waren die Zertifikate schön – Firefox zufrieden – aber nach der Anmeldung gab es eine weiße Seite mit dem auth.owa – Problem.
Der Dienst: Microsoft Exchange-Benachrichtigungsbroker war es nicht – der ist immer nach einigen Sekunden down. Nach gefühlt unendlich langer Fehlersuche, habe ich ein Backup der System-Partition zurück gespielt. VHDX-Datei getauscht. Der Stand vom Vormittag war wieder da, dann die gleichen Schritte noch mal ausgeführt und schont konnten alle Browser (die das passende CA hatten) auf das OWA zugreifen… Es ist immer wieder schön auch während der Installation ein Backup zu haben :-) Viele Grüße aus Berlin Jens
Hallo Frank
Ich habe die Anleitung https://www.frankysweb.de/exchange-2016-die-basiskonfiguration/ und danach diese Anleitung durch gearbeitet bis zu DNS. Bei dieser Anleitung beim Thema DNS (Provider) steh ich nun jedoch etwas auf dem Schlauch. Zuerst habe ich keine Fixe IP somit habe ich beim Provider jeweils CNAMES eintragen lassen, anstelle der A Records, welche auf meinen DYNDNS Namen verweisen, ich hoffe dies ist auch korrekt. Aber ich habe bei der bestehenden Konfiguration gesehen, dass es noch MX Einträge gibt, welche momentan zum Provider verweisen. Müsste ich hier nun nicht auch noch einen MX Eintrag erstellen? Würde dieser auf mail.xyz.de verweisen?
Grüsse & Dank
Simon
Hallo Simon,
wenn du keine feste IP hast und den cname gesetzt hast kannst den mx auf den cname zeigen lassen.
Zum versenden verwende aber bitte unbedingt einen Smarthost. Thema Spam und dynamischer adresspool beim Provider.
Viele Grüße
Olli
Hallo
ja wirklich tolle Anleitung. Für MAPI over HTTP musste ich aber noch einen weiteren Befehl hinzufügen
Set-MapiVirtualDirectory -Identity „ContosoMail\mapi (Default Web Site)“ -ExternalUrl https://contoso.com/mapi -IISAuthenticationMethods NTLM,Negotiate
Hallo Frank,
sollte in der Anleitung nicht noch TLS für SMTP erwähnt werden. Es wird hier (vermutlich) davon ausgegangen, dass der MX auch auf mail.frankysweb.de lautet.
Trotzdem würde STARTTLS für Port 587 (Client-Connector) nicht funktionieren (Zwertifikatwarnung), weil das neue Zertifikat dem Client-Connector noch explizit per set-receiveconnector -tlscertificatename zugewiesen werden muss.
@Frank, @Maik
Hallo,
der unsäglichen MAPI Virtual Directory Bug war auch bei mir Ursache allem Übels. Frank sollte vielleicht im Beitrag eine deutliche Warnung setzen, dass nach dem Anpassen der URLs über EAC die Authentifizierung zu kontrollieren ist oder besser gleich die EMS einsetzen. Danke an alle.
Viele Grüße
Heiner
Hallo Heiner,
das Problem wurde mit Exchange 2016 CU4 behoben.
Gruß, Frank
Hi erstmal! „Eigentlich“ genau was ich gesucht habe, jedoch habe ich nach der Konfiguration ein Problem…
Owa / Activesync funktioniert, jedoch können sich clients mit Outlook 2010 nach Änderung der virtuellen Verzeichnisse nicht mehr anmelden! (Alle Schritte nochmal kontrolliert, keine Änderung)
Eckdaten: DC: Server2016 (DNS/AD), Exch: Server2016 / 2016 (Exchange, IIS)
Bereits eingerichtete Profile zeigen einige Minuten den Verbindungsversuch, dann verabschiedet sich Outlook. Mein Hintergedanke war also: Alte Verbidungsinfos stecken noch im Profil. Neues Profil angelegt: Zum Schluss erscheinen die 3 Positionen zum Abschluss und bei „Am Exchange anmelden“ bleibt die Konfig stehen und hängt sich auf.
Nach dem Reset der Virtuellen Verzeichnisse ging es jetzt zum Glück wieder, aber durch bin ich mit dem Thema noch nicht…
Hi,
schau dir mal die Authentifizierungseinstellungen des MAPI vDirs an. Hier werden wahrscheinlich keine Authentifizierungsmethoden angeboten. Dies könnte bei dir das Problem sein:
https://www.frankysweb.de/neuer-exchange-2016-server-outlook-fragt-nach-anmeldeinformationen/
Gruß, Frank
Hallo Frank, Peter und Heiner,
da ich jetzt endlich mal Zeit hatte mich mit dem Problem des Zertifikatsfehler auseinander zusetzen, ist mir folgendes aufgefallen. Bei Neuinstallation von Outlook 2016 gibt es keine Warnung. Bei einigen Clients hat es auch ausgereicht die ost Datei zu löschen und diese neu erstellen zulassen. Leider funktioniert das nicht bei jedem Client.
Der Fehler scheint von den Exchange-Empfangsconnectoren zu stammen. Dort steht der FQDN für alle Empfangsconnectoren immer noch auf dem internen Namen (z.B. Exchange.domain.local).
Vielleicht habt ihr ja eine Idee.
Viele Grüße
Maik
Meine Fragen dazu:
Kann ich diese einfach auf mail.domain.de ändern? Wird dadurch die Funktionalität des Exchange Servers in irgendeiner Weise beeinflusst? Oder sollte ich ein selbst erstelltes Zertifikat für die Empfangsconnectoren erstellen?
Hi Maik,
kannst du mir einmal die Autodiscover.xml zuschicken? Du kannst dafür die Exchange Toolbox verwenden:
https://www.frankysweb.de/exchange-toolbox-fr-exchange-server-2016-beta-1/
Wenn alle URLs korrekt konfiguriert sind und auch das Zertifikat passt, dann sind meistens Outlook PlugIns Schuld.
Gruß, Frank
Hallo Frank,
ich habe vor ein paar Tagen einen SBS 2011 auf Exchange 2013 migriert. Wir haben allerdings ein Wildcard Zertifikat was ich dann in den Exchange eingebunden habe. Es funktioniert auch soweit alles bis auf Passwortabfragen die hin und wieder im Outlook auftauchen (auch von extern). DNS Einträge stehen alle. Bei einem Kollegen taucht dann beim Start von Outlook 2013 die Meldung auf das der Name auf dem Zertifikat nicht übereinstimmen würde. Klickt man auf das Zertifikat zeigt er „Domain.de“ an anstatt „*.Domain.de“. Bei einem anderen der Outlook 2016 benutzt kann das Konto gar nicht angebunden werden. Es erscheint immer eine Kennwortabfrage aber keine Zertifikatsfehlermeldung.
Die Testexchangeconnectivity im Autodiscover sowie im Outlook Modus laufen beide ohne jeglichen Fehler durch.
Im moment haben wir mehr Probleme mit der Anbindung intern als von Extern.
Vielleicht hast du ja den Masterplan :-) Bin zu allen Schandtaten bereit.
Gruß,
Olli
Hi Olli,
wurden die internen URLs entsprechend gleich mit den externen URLs konfiguriert und sind diese auch intern via DNS auflösbar?
Gruß,
Frank
Hi Frank,
ja alles vorhanden und auflösbar. Ich bin jetzt schon hingegangen und habe im Outlook Anywhere mal auf NTLM umgestellt. Bei manchen brachte das eine Verbesserung bei anderen wiederum nicht.
autodiscover.domain.de als Zone vorhanden zeigt auf den Exchange und ist intern sowie extern wunderbar auflösbar.
remote.domain.de Zone vorhanden zeigt auf den Exchange und ist ebenfalls auflösbar.
Egal von welchem Server DNS funktioniert einwandfrei.
Viele Grüße
Olli
Hallo Frank.
Super Erklärung danke dafür.
Ich hab eine Frage,
bei dem zertifikat WMSVC welcher Dienst muss da zugewiesen sein?
Bei mir steht nach einem update da nichts mehr ausgewählt drinn.
Ich denke das ist so nicht richtig.
Vielen Dank für deine Antwort
Hi Chris,
der WMSVC ist ein IIS Dienst (Web Management Service) und gehört nicht zu Exchange, daher wird diesem Zertifikat auch kein Exchange Dienst zugewiesen. Das Zertifikat wird nur vom Web Management Service benutzt.
Gruß, Frank
@Meik, @Heiner, @Frank
Ich hatte das gleiche Bild nachdem ich meinen Exchange 2010 mit einem neuen Zertifikat versorgt hatte. Da ich gleichzeitig am Verteilen von Office 2016 war kam sehr schnell die Idee die Frank schon vorschlug – Outlook Profil löschen und neu anlegen. Denn bei mir hatten alle Office 2016 User die ich vor dem Zertifikatswechsel installiert hatte das Problem – alle Installationen nach dem Zertifikatwechsel liefen fehlerfrei und Outlook meckerte nicht …
Gruß
Peter
Hallo beisammen,
Ich hatte kürzlich mein Zertifikat über StartSSL bezogen und war eigentlich recht glücklich damit. Alle Systeme (Outlook, IOS, …) funktionierten wunderbar. Heute morgen habe ich meine Apple-Devices auf das neue IOS 10.2 aktualisiert und die Synchronisation funktionierte nicht mehr. Es sieht wohl so aus, als ob Apple die Root-CA, die von StartSSL genutzt wird nicht mehr implementiert hat. Ich habe dann auf dem iPhone versucht, die Zertifikate manuell zu installieren – leider ohne Erfolg. Schade…
Grüße Andi
Hi Andi,
Apple hat STartSSL aus der Liste der vertrauenswürdigen CAs genommen (Es gab Sicherheitsprobleme mit der CA).
Gruß, Frank
@Maik, @Frank, Hallo,
habe jetzt das gleiche Problem wie Maik:
Schritt für Schritt nach Anleitung von Frank umgesetzt (auf Exchange2016 CU3 mit Outlook2016-Clients),
alles funktioniert wie erwartet,außer Outlook2016 -> Zertifikatsfehler! Outlook bekommt immer noch den
alten internen Servernamen „ex1.meinedomäne.de“ präsentiert wo hingegen das neue Zertifikat auf „mail.meinedomäne.de“ lautet. Alle URLs intern+extern(owa,OAB,Microsoft-Server ActiveSync, mapi, EWS, ec, Outlook Anywhere) auf „mail.meinedomäne.de“ sowie autodiscover intern auf „autodiscover.meinedomäne.de“ angepasst. Habe alle Einstellungen dokumentiert und mehrfach kontrolliert, finde aber keinen Fehler. Wer kann helfen? Wie kann Outlook2016 sich auf den neuen Servernamen verbinden?
Viele Grüße
Heiner
Hi,
du könntest dir mal mit der Exchange Toolbox (oder direkt mit Outlook) die Autodiscover XML anzeigen lassen und mir ggf. zuschicken. Dann lässt sich heraus finden welcher Eintrag Schuld ist.
https://www.frankysweb.de/exchange-toolbox-fr-exchange-server-2016-beta-1/
Übrigens: Outlook Profil mal testhalber neu eingerichtet? Outlook Plugins verursachen gerne mal solche Probleme.
Gruß, Frank
Hallo Frank, danke für die Hilfe! Kann ich Dir die autodiscover XML über dieses Formular zuschicken, oder besser per E-Mail?
Viele Grüße
Heiner
Hi,
Per Mail bitte.
Gruß, Frank
Hallo Frank,
ich habe eine Frage zur Anpassung des internen DNS: In Deinem Beispiel wird eine neu Zone „mail.frankysweb.de“ angelegt. Warum nicht eine Zone „frankysweb.de“ und in dieser einen Host-A Eintrag „mail“? Wie würde man verfahren wenn Deine interne (AD) Domäne split-brain wäre, also anstatt „frankysweb.local“ ebenfalls „frankysweb.de“?
Danke für Deine super Anleitungen!
Hi,
du kannst auch die Zone anlegen und in der Zone die entsprechenden Einträge, dann musst du aber auch daran denken die öffentlichen Einträge entsprechend zu pflegen (WWW).
Gruß, Frank
Hallo Frank und alle Anderen,
erst mal Danke für die detaillierte Anleitung!
Hat soweit alles einwandfrei funktioniert – allerdings nur mit dem IE und Edge.
Kann es sein, dass der Chrome und der Firefox ein Problem mit dem Split DNS haben?
Sowohl intern als auf beim externen Zugriff erhalte ich im Chrom diese Fehlermeldung:
ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY
und im Firefox diese: Fehlercode: NS_ERROR_NET_INADEQUATE_SECURITY
Wie gesagt mit dem IE und dem Edge sowohl intern und extern kein Problem. Mit den anderen Browser nicht möglich :-(
Kann mir da event. jemand weiterhelfen?
Gruss
Alex
Hallo,
vielen Dank für die Anleitung. Anhand dieser habe ich einen Exchange 2013 Server mit einen SAN Zertifikat installiert.
Leider bekomme ich immer den Fehler auf den Clients:
„Es liegt ein Problem mit dem Sicherheitszertifikat des Proxyservers vor.
Der Name des Sicherheitszertifikats ist ungültig oder entspricht nicht dem Namen der Zielwebsite ‚mail.domäne.de‘.
Von Outlook kann keine Verbindung mit dem Proxyserver hergestellt werden (Fehlercode: 10).“
oder eine Zertifikatsverwarnung das der Name nicht über einstimmt, obwohl die Namen im Zertifikat mail.domäne.de
und autodiscover.domäne.de angeben sind und auch im Exchange eingerichtet sind.
Hallo Maik,
ich nehme an dass nicht alle Virtuellen Verzeichnisse entsprechend der URL (intern sowie extern) konfiguriert wurden. (Outlook Anywhere nicht vergessen)
Gruß, Frank
Hallo Frank,
danke für deine schnelle Antwort, aber alle Virtuellen Verzeichnisse sind umgestellt auch Outlook Anywhere.
Beim manchen Client bekomme ich eine Fehlermelder, bei anderen funktioniert es ohne.
Virtuelle Verzeichnisse: WebservicesVirtualDirectory, OWAVirtualDirectory, ECPVirtualDirectory,
ActiveSyncVirtualDirectory, OABVirtualDirectory,
Internal: mail.domäne.de
External: mail.domäne.de
Outlook Anywhere: ClientAccessServer
autodiscover.domäne.de
Ich habe schon überall nach gesehen, finde aber nicht den Punkt, wo der lokal Servername noch verwendet wird.
Hallo Maik,
konntest du das Problem lösen?
Mich würde gern die Lösung interessieren?
Gruß
Denis
Hallo Maik,
ich habe auch die gleiche nur sporadisch auftretende Fehlermeldung.
Alle virtuellen Verzeichnisse sind angepasst.
Hast du eine Lösung für dein Problem gefunden?
Gruß
Christian
Hallo Frank,
ich musste bei meinem Server Exchange 2013 CU11 bei „Autodiscover URL für den CAS-Dienst“ anstatt Set-ClientAccessService den Befehl Set-ClientAccessServer eintragen. Den anderen hat er nicht akzeptiert, obwohl es in deiner Shell ok aussah.
Aber es läuft top mit deiner Anleitung. Vielen Dank!
Gruß Herta
Hallo
richtig, bei einem Exchange 2013 Server heißt es noch „Set-ClientAccessServer“ anstatt „Set-ClientAccessService“. Ich ergänze den Artikel mit einem entsprechenden Hinweis.
Gruß, Frank
Hallo Frank,
Danke für die gute und detaillierte Anleitung zu Zertifikaten. Wir hatten auch immer Probleme mit Meldungen und Warnungen zum Zertifikat auf unseren Exchange. Nun habe ich mich letzte Woche ran gemacht und deine Anleitung abgearbeitet. Sieht jetzt sehr gut aus. Bis heute keine Zertifikatswarnung an irgendeinem Rechner. Eine Meldung wirft Outlook jetzt noch aus. „Konfigurieren von Nutzer@firma.de-Servereinstellungen für diese Website zulassen? https://autoconfigure.strato.de/autodiscover/autodiscover.xml …“ Geh ich richtig der Annahme, dass das der Autodiscover-Dienst von Strato ist? Soll ich das zulassen oder soll ich den Dienst in Strato deaktivieren?
Hallo Michael,
richtig, das ist der Autodiscover Dienst von Strato, dieser muss deaktiviert werden und „der eigene“ wie beschrieben konfiguriert werden.
Gruß, Frank
Hallo Frank – das hilft ungemein weiter. Ich habe lange mit verschiedenen teueren Einzelzertifikaten gearbeitet, und kann das endlich vernünftig gestalten.
Aber wenn man von Zertifikate zu wenig Ahnung hat wird einem eben alles angedreht ;-)
Nochmals Danke für die Klarstellung
Peter
Hi Peter,
wenn du das gleiche Zertifikat auf mehreren Systemen einsetzt, solltest du dokumentieren auf welchen Systemen dieses Zertifikat zum Einsatz kommt. Wenn du zum Beispiel das gleiche Zertifikat für Exchange und einen anderen Dienst verwendest, musst du es auch bei beiden Systemen aktualisieren wenn es aufläuft.
Bei einer größerem Anzahl von DNS-Namen auf dem Zertifikat lohnt sich auch ggf. ein Wildcard Zertifikat. Ein Wildcard Zertifikat enthält dann den Eintrag *.Domain.de, somit sind alle Namen unterhalb von Domain.de (owa.domain.de, Firewall.domain.de, abc.domain.de) adressierbar. Gerade in diesem Fall wird eine saubere Dokumentation wichtig. Wildcard Zertifikate gibt es schon ab ca. 100. EUR pro Jahr.
Gruß, Frank
Vielen Dank für diesen Artikel – ich habe schon ewig nach einer verständliche Erklärung für die Zertifikatseinrichtung gesucht.
Kleine Fragen hätte ich da noch:
1. darf ein SAN-Zertifikat auf mehreren Maschinen laufen? Beispielsweise haben wir ja eine SPAM-Appliance die Mails von außen zuerst annimmt und sich als unser Mailserver ausgibt.
2. Ich muss ja vermutlich von jeder Maschine die das Zertifikat erhält eine eigene csr erstellen, müssen die Angaben da identisch sein, also auch autodiscover etc. enthalten, oder sagt man in der csr dann nur mail.domain.de?
3. Da man ja im SAN-Zertifikat auch noch weitere Namen angeben kann, ist es OK auch noch weitere Server zu adressieren wie gate.domain.de und das Zertifikat an den Stellen ebenfalls zu nutzen? Dann könnte man ja alle externen Zugänge wie Citrix-Gateways oder ähnliches mit nur einem Zertifikat versorgen, und das wäre prima..
Viele Grüße
Peter
Hi,
zu 1: Ja, du kannst das Zertifikat auf mehreren Systemen einsetzen, solange der private Schlüssel exportierbar ist.
zu 2: Du kannst das vorhandene Zertifikat nutzen und exportieren und dann auf dem Zielsystem importieren.
zu 3: siehe 1 und 2. Ja, das kann man machen.
Gruß, Frank
Wie müsste ich das Ganze anpassen, wenn ich statt einer festen IP dyndns nutzen würde?
Also Exchange 2016 -> Holt per POP3 die Mails von einem Postfach bei Strato ab und verschickt sie über den Smarthost bei Strato. (Mail: username@xyz.de )
Der Zugriff über Outlook, OWA, etc. erfolgt allerdings über zxy.dyndns.org.
Muss ich jetzt mail.zxy.dyndns.org und autodiscover.zxy.dyndns.org einrichten?
Also stelle ich das Zertifikat genau so aus, wie du mit frankysweb.de nur mit zxy.dyndns.org?
Oder benötige ich dafür irgendwas bestimmtes?
Hi,
bitte:
https://www.frankysweb.de/aufbau-einer-kleinen-exchange-2016-organisation-teil-1/
Gruß, Frank
Scheint jetzt alles zu laufen! Vielen lieben Dank noch einmal für deinen Beitrag!!!
Evtl. doch noch eine Frage… was für ZERTIFIKATE müssen im Exchange da sein.
Ich hab insgesamt 3 Stück: 1. mein Zertifikat was (vorerst) von StartSSL kommt (mail.meinedomain.de) 2. ein Zertifikat das „keinen Namen“ hat (Aussteller: cn=exchange.domain.local) Dienste: IIS 3. Zertifikat ist Microsoft Exchange Server Auth Certificate Dienste: SMTP…
Hat mir jemand noch einen Tipp, was für welche benötigt werden!? bzw. kann ich das OHNE NAMEN entfernen?!
Danke
Gruß Swen
Du musst keine Zertifikate löschen.
Gruß, Frank
Moin Moin,
super und nochmals vielen Dank. So könnte ich jetzt unsere Probleme angehen und das endlich mal VERNÜNFTIG konfigurieren.
Bei zwei Schritten hänge ich…
1. meine Cmdlets nimmt er nicht – (in früheren Schulungen hab ich das wohl mal gelernt – muß ich in der Console erst mal was laden, dass er mir die nimmt?!) -Get-ClientAccessService xxxxx usw.
2. beim Speichern der Anforderung (nach der Anleitung) bringt er mir einen Fehler „Verwenden Sie einen gültigen Dateinamen, wenn Sie das Cmdlet „New-ExchangeCertificate“ auf dem Server xxx-xxx mit dem Parameter RequestFile ausführen. Die Datei darf nicht im Zielordner vorhanden sein. Parametername: RequestFile“
Vielleicht kann mir hier jemand helfen -> Danke
Gruß Swen
Ist jetzt 3 Jahre her aber wie hast Du die Fehlermeldung unter Punkt 2 wegbekommen?
Hi Sven.
Ich wollte das nachspeilen auf meinem Exchange und hatte das selbe Problem.
wenn man googlet findet man zb sowas:
„But to answer your question on the settings, the commandlet is called get-clientaccesserver instead of service, you can hit tab to complete partial names so you don’t have to remember the full name.“
Anscheinend heisst das jetzt get-clientaccessserver und nicht ClientAccessService. Mit „server“ konnte ich dann den gesetzten Wert auf meinem Server erfolgreich abfrage.
Was wäre ich, ohne die Hilfe von Spezialisten wie Franky :-)
Vielen Dank