34
Zertifikats-Fehlermeldung bei Outlook in Verbindung mit Exchange 2016
Hallo Zusammen,
erstmal noch ein gesundes neues Jahr
Ich bin gerade dabei von einem Exchange 2010 auf Exchange 2016 zu migrieren (ein erstes Testpostfach konnte ich auch bereits erfolgreich umziehen).
Der Zugriff über OWA (externe URL) im internen Netz (https://outlook.ads-xx.de/owa) funktioniert auch (entsprechender DNS-Eintrag, der auf die lokale IP 172.22.16.105 vom Exchange verweist ist vorhanden, funktioniert auch.)
Für die externe-URL (die ja auch intern erreichbar ist), habe ich ein entsprechendes DV-SSL-Zertifikat gekauft und eingebunden, das funktioniert auch.
Leider habe ich trotzdem das nervige Zertifikats-Problem:
Wenn ich auf "Zertifikat anzeigen.." klicke, bekomme ich das SSL-Zertifikat für meine externe URL angezeigt, was aber trotzdem als "nicht Vertrauenswürdig" erscheint, weil Outlook den Server unter dem lokalen Namen "fo1vmsrm05.ads.local" anspricht.
Die Frage an Euch wäre jetzt, kann ich den Namen mit dem Outlook den Exchange anspricht irgendwo ändern oder habt ihr vielleicht eine andere Lösungsmöglichkeit für mich?
Diesen Fehler hatte ich bereits mit Exchange 2010 (und Outlook 2010), aber wenn wir jetzt schon auf Windows 10 und Office 2016 migrieren, wäre es schön, wenn ich den Fehler nicht "mit-migriere"
Danke vorab!
erstmal noch ein gesundes neues Jahr
Ich bin gerade dabei von einem Exchange 2010 auf Exchange 2016 zu migrieren (ein erstes Testpostfach konnte ich auch bereits erfolgreich umziehen).
Der Zugriff über OWA (externe URL) im internen Netz (https://outlook.ads-xx.de/owa) funktioniert auch (entsprechender DNS-Eintrag, der auf die lokale IP 172.22.16.105 vom Exchange verweist ist vorhanden, funktioniert auch.)
Für die externe-URL (die ja auch intern erreichbar ist), habe ich ein entsprechendes DV-SSL-Zertifikat gekauft und eingebunden, das funktioniert auch.
Leider habe ich trotzdem das nervige Zertifikats-Problem:
Wenn ich auf "Zertifikat anzeigen.." klicke, bekomme ich das SSL-Zertifikat für meine externe URL angezeigt, was aber trotzdem als "nicht Vertrauenswürdig" erscheint, weil Outlook den Server unter dem lokalen Namen "fo1vmsrm05.ads.local" anspricht.
Die Frage an Euch wäre jetzt, kann ich den Namen mit dem Outlook den Exchange anspricht irgendwo ändern oder habt ihr vielleicht eine andere Lösungsmöglichkeit für mich?
Diesen Fehler hatte ich bereits mit Exchange 2010 (und Outlook 2010), aber wenn wir jetzt schon auf Windows 10 und Office 2016 migrieren, wäre es schön, wenn ich den Fehler nicht "mit-migriere"
Danke vorab!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 530637
Url: https://administrator.de/contentid/530637
Ausgedruckt am: 23.11.2024 um 11:11 Uhr
34 Kommentare
Neuester Kommentar
Hallo,
dann stelle doch die internen URIs auf die externen Adressen ein und passe das Autodiscover entsprechend an?!?
Gruß,
Jörg
dann stelle doch die internen URIs auf die externen Adressen ein und passe das Autodiscover entsprechend an?!?
Gruß,
Jörg
Hallo Jörg,
ja das war auch meine Idee - nur ist mir noch nicht ganz klar, welche URL ich ändern muss.
Also welche der URL's für den internen Zugriff von Outlook auf Exchange zuständig ist.
Und muss ich das Autodiscovery zwingend ändern?
Das nutzen wir eigentlich nicht. Die Remote-Nutzer (die Outlook haben) nutzen ausschließlich VPN, noch ein paar iPhones (die nutzen ja soweit ich weiß die OWA-Url, das geht ja).
Danke vorab!
VG
Frank
ja das war auch meine Idee - nur ist mir noch nicht ganz klar, welche URL ich ändern muss.
Also welche der URL's für den internen Zugriff von Outlook auf Exchange zuständig ist.
Und muss ich das Autodiscovery zwingend ändern?
Das nutzen wir eigentlich nicht. Die Remote-Nutzer (die Outlook haben) nutzen ausschließlich VPN, noch ein paar iPhones (die nutzen ja soweit ich weiß die OWA-Url, das geht ja).
Danke vorab!
VG
Frank
Moin,
nutzte split DNS.
also z.B. mail.firma.de sowohl für extern als auch intern.
Für Intern die DNS-Server anpassen.
Dabei erledigt sich auch das Problem wen mobile Geräte sich in unterschiedlichen Netzwerken befinden bis zu extern ohne VPN.
Stefan
nutzte split DNS.
also z.B. mail.firma.de sowohl für extern als auch intern.
Für Intern die DNS-Server anpassen.
Dabei erledigt sich auch das Problem wen mobile Geräte sich in unterschiedlichen Netzwerken befinden bis zu extern ohne VPN.
Stefan
Moin Stefan,
Danke für den Tipp - das ist auch bereits so umgesetzt.
Also es wird eine URL für intern und extern genutzt.
Der interne DNS übersetzt die (eigentlich externe Adresse) zu dem internen Exchange-Server 172.22.16.105.
Was ich mir aber nicht erklären kann, woher er immer noch den lokalen Namen fo1vmsrm05.ads.local zum Verbinden mit dem Exchange hernimmt.
VG
Frank
Danke für den Tipp - das ist auch bereits so umgesetzt.
Also es wird eine URL für intern und extern genutzt.
Der interne DNS übersetzt die (eigentlich externe Adresse) zu dem internen Exchange-Server 172.22.16.105.
Was ich mir aber nicht erklären kann, woher er immer noch den lokalen Namen fo1vmsrm05.ads.local zum Verbinden mit dem Exchange hernimmt.
VG
Frank
Hi,
was heißt bei dir, es ist so umgesetzt?
- Sind die Zonen im AD mit dem Host Eintrag erstellt?
- Sind alle dazugehörigen Dienste im Exchange auf die URL angepasst?
Autodiscover getestet?
Oben im Screenshot ist zu sehen, dass noch beide Server in der ECP Konsole vorhanden sind.
Die Migration ist also noch nicht abgeschlossen. Du verbindest dich auf den korrekten Server?
Die URLs sind überall angepasst?
Lasse dir doch mal die URLs per Powershell ausgeben, ob dort alles passt.
Grüße Phil
was heißt bei dir, es ist so umgesetzt?
- Sind die Zonen im AD mit dem Host Eintrag erstellt?
- Sind alle dazugehörigen Dienste im Exchange auf die URL angepasst?
Autodiscover getestet?
Oben im Screenshot ist zu sehen, dass noch beide Server in der ECP Konsole vorhanden sind.
Die Migration ist also noch nicht abgeschlossen. Du verbindest dich auf den korrekten Server?
Die URLs sind überall angepasst?
Lasse dir doch mal die URLs per Powershell ausgeben, ob dort alles passt.
Grüße Phil
Hallo,
ja - das Autodiscover musst Du zwingend ändern. Afaik geht das auch gar nicht mehr ohne.
Gruß,
Jörg
ja - das Autodiscover musst Du zwingend ändern. Afaik geht das auch gar nicht mehr ohne.
Gruß,
Jörg
Hi Phil,
Danke für die Antwort - ja die Zonen sind im DNS mit dem entsprechenden Host-Eintrag angelegt:
Die Auflösung funktioniert soweit auch:
Die Migration ist noch nicht abgeschlossen - bisher habe ich nur ein Testpostfach migriert. Der alte Server (Exchange 2010) hat die .104 am Ende - der neue die .105 (Exchange 2016).
Die URL's passen soweit auch würde ich sagen.. nirgendwo steht mehr noch der lokale Name fo1vmsrm05.ads.local drinnen. Aber leider kommt immer noch die Fehlermeldung mit genau diesem Namen. Daher frage ich mich, woher er diesen Namen wohl nimmt..
Danke für die Antwort - ja die Zonen sind im DNS mit dem entsprechenden Host-Eintrag angelegt:
Die Auflösung funktioniert soweit auch:
Die Migration ist noch nicht abgeschlossen - bisher habe ich nur ein Testpostfach migriert. Der alte Server (Exchange 2010) hat die .104 am Ende - der neue die .105 (Exchange 2016).
Die URL's passen soweit auch würde ich sagen.. nirgendwo steht mehr noch der lokale Name fo1vmsrm05.ads.local drinnen. Aber leider kommt immer noch die Fehlermeldung mit genau diesem Namen. Daher frage ich mich, woher er diesen Namen wohl nimmt..
Hallo Jörg,
Danke für die Info - habe ich mittlerweile auch so eingerichtet im DNS.
Leider kommt immer noch die Fehlermeldung mit dem lokalen Hostnamen (auf den das Zertifikat dann natürlich nicht passt).
Mir ist es echt rätselhaft, woher er diesen lokalen Namen nimmt..
VG
Frank
Danke für die Info - habe ich mittlerweile auch so eingerichtet im DNS.
Leider kommt immer noch die Fehlermeldung mit dem lokalen Hostnamen (auf den das Zertifikat dann natürlich nicht passt).
Mir ist es echt rätselhaft, woher er diesen lokalen Namen nimmt..
VG
Frank
Moin Frank,
hast du dir mal dir URLs per Powershell ausgeben lassen?
Hast du dir urls per Weboberfläche oder per Powershell angepasst?
Blöde Frage, aber die Exchange Server mal durchgestartet?
Kannst du mal ein zweites Postfach migrieren oder ein Testpostfach anlegen und migrieren?
Der servername welcher im Zertifikat angemeckert wird ist der Exchange 2016 oder der alte?
Nicht das er eine Verbindunf zu z. B. Public Folder Database auf dem 2010 herstellen will, aber nicht kann?
Grüße Phil
hast du dir mal dir URLs per Powershell ausgeben lassen?
Hast du dir urls per Weboberfläche oder per Powershell angepasst?
Blöde Frage, aber die Exchange Server mal durchgestartet?
Kannst du mal ein zweites Postfach migrieren oder ein Testpostfach anlegen und migrieren?
Der servername welcher im Zertifikat angemeckert wird ist der Exchange 2016 oder der alte?
Nicht das er eine Verbindunf zu z. B. Public Folder Database auf dem 2010 herstellen will, aber nicht kann?
Grüße Phil
Hallo,
den bekommt der Client via AutoDiscover.
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-auto ...
Gruß,
Jörg
den bekommt der Client via AutoDiscover.
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-auto ...
Gruß,
Jörg
1
Moin Phil,
-> die URL's habe ich mir mit der Exchange-PowerShell ausgeben lassen:
Das obere ist der alte Server fo1vmsrm04 (mit der .104 am Ende), das untere der fo1vmsrm05 (mit der .105 am Ende). Ich würde sagen, dass passt soweit oder?
-> Ich habe die URL's mit einem Script angepasst, und eben auf der WebGUI nachgesehen, ob er sie wirklich übernommen hat
https://www.frankysweb.de/exchange-2016-urls-und-hostnamen-per-powershel ...
-> Ja schon mehrfach :D
-> Ja, das werde ich später mal testen
-> Der Name der angemeckert wird, ist der neue (fo1vmsrm05)
-> PublicFolders habe ich in der Umgebung gar nicht
Danke schon mal!
VG
Frank
-> die URL's habe ich mir mit der Exchange-PowerShell ausgeben lassen:
Das obere ist der alte Server fo1vmsrm04 (mit der .104 am Ende), das untere der fo1vmsrm05 (mit der .105 am Ende). Ich würde sagen, dass passt soweit oder?
-> Ich habe die URL's mit einem Script angepasst, und eben auf der WebGUI nachgesehen, ob er sie wirklich übernommen hat
https://www.frankysweb.de/exchange-2016-urls-und-hostnamen-per-powershel ...
-> Ja schon mehrfach :D
-> Ja, das werde ich später mal testen
-> Der Name der angemeckert wird, ist der neue (fo1vmsrm05)
-> PublicFolders habe ich in der Umgebung gar nicht
Danke schon mal!
VG
Frank
Hallo Jörg,
nein, das kann ich relativ sicher ausschließen. Hier das XML-File (zensiert) welches ich über den Outlook-AutoDiscover-Test bekommen habe:
In der Config steht nirgendwo mehr der lokale Servername fo1vmsrm05.ads.local.
Auch im Autodiscovery-Check steht nirgendwo mehr der lokale Hostname (wird wahrschienlich von der XML-Datei abgeleitet vermute ich):
Noch irgend eine Idee vielleicht?
VG
Frank
nein, das kann ich relativ sicher ausschließen. Hier das XML-File (zensiert) welches ich über den Outlook-AutoDiscover-Test bekommen habe:
<?xml version="1.0" encoding="utf-8"?>
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006">
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a">
<User>
<DisplayName>Test User</DisplayName>
<LegacyDN>/o=ADS/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Test User</LegacyDN>
<AutoDiscoverSMTPAddress>xxx@t-online.de</AutoDiscoverSMTPAddress>
<DeploymentId>cd304ad8-61b9-4b57-b3a5-ce324d3ac938</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<MicrosoftOnline>False</MicrosoftOnline>
<ConsumerMailbox>False</ConsumerMailbox>
<Protocol Type="mapiHttp" Version="1">
<MailStore>
<InternalUrl>https://outlook.ads-xxx.de/mapi/emsmdb/?MailboxId=98500932-1865-474b-80a8-95d175ecad89@t-online.de</InternalUrl>
<ExternalUrl>https://outlook.ads-xxx.de/mapi/emsmdb/?MailboxId=98500932-1865-474b-80a8-95d175ecad89@t-online.de</ExternalUrl>
</MailStore>
<AddressBook>
<InternalUrl>https://outlook.ads-xxx.de/mapi/nspi/?MailboxId=98500932-1865-474b-80a8-95d175ecad89@t-online.de</InternalUrl>
<ExternalUrl>https://outlook.ads-xxx.de/mapi/nspi/?MailboxId=98500932-1865-474b-80a8-95d175ecad89@t-online.de</ExternalUrl>
</AddressBook>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Fba">https://outlook.ads-xxx.de/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://outlook.ads-xxx.de/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
<External>
<OWAUrl AuthenticationMethod="Fba">https://outlook.ads-xxx.de/owa/</OWAUrl>
<Protocol>
<Type>EXPR</Type>
<ASUrl>https://outlook.ads-xxx.de/EWS/Exchange.asmx</ASUrl>
</Protocol>
</External>
</Protocol>
<Protocol>
<Type>EXHTTP</Type>
<Server>outlook.ads-xxx.de</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
<ASUrl>https://outlook.ads-xxx.de/EWS/Exchange.asmx</ASUrl>
<EwsUrl>https://outlook.ads-xxx.de/EWS/Exchange.asmx</EwsUrl>
<EmwsUrl>https://outlook.ads-xxx.de/EWS/Exchange.asmx</EmwsUrl>
<EcpUrl>https://outlook.ads-xxx.de/owa/</EcpUrl>
<EcpUrl-um>?path=/options/callanswering</EcpUrl-um>
<EcpUrl-aggr>?path=/options/connectedaccounts</EcpUrl-aggr>
<EcpUrl-mt>options/ecp/PersonalSettings/DeliveryReport.aspx?rfr=olk&exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx>&realm=ads.local</EcpUrl-mt>
<EcpUrl-ret>?path=/options/retentionpolicies</EcpUrl-ret>
<EcpUrl-sms>?path=/options/textmessaging</EcpUrl-sms>
<EcpUrl-photo>?path=/options/myaccount/action/photo</EcpUrl-photo>
<EcpUrl-tm>options/ecp/?rfr=olk&ftr=TeamMailbox&exsvurl=1&realm=ads.local</EcpUrl-tm>
<EcpUrl-tmCreating>options/ecp/?rfr=olk&ftr=TeamMailboxCreating&SPUrl=<SPUrl>&Title=<Title>&SPTMAppUrl=<SPTMAppUrl>&exsvurl=1&realm=ads.local</EcpUrl-tmCreating>
<EcpUrl-tmEditing>options/ecp/?rfr=olk&ftr=TeamMailboxEditing&Id=<Id>&exsvurl=1&realm=ads.local</EcpUrl-tmEditing>
<EcpUrl-extinstall>?path=/options/manageapps</EcpUrl-extinstall>
<OOFUrl>https://outlook.ads-xxx.de/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://outlook.ads-xxx.de/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl>https://outlook.ads-xxx.de/OAB/c9b7b31b-afd2-403c-92dc-4673bdecc530/</OABUrl>
<ServerExclusiveConnect>On</ServerExclusiveConnect>
</Protocol>
<Protocol>
<Type>EXHTTP</Type>
<Server>outlook.ads-xxx.de</Server>
<SSL>On</SSL>
<AuthPackage>Basic</AuthPackage>
<ASUrl>https://outlook.ads-xxx.de/EWS/Exchange.asmx</ASUrl>
<EwsUrl>https://outlook.ads-xxx.de/EWS/Exchange.asmx</EwsUrl>
<EmwsUrl>https://outlook.ads-xxx.de/EWS/Exchange.asmx</EmwsUrl>
<EcpUrl>https://outlook.ads-xxx.de/owa/</EcpUrl>
<EcpUrl-um>?path=/options/callanswering</EcpUrl-um>
<EcpUrl-aggr>?path=/options/connectedaccounts</EcpUrl-aggr>
<EcpUrl-mt>options/ecp/PersonalSettings/DeliveryReport.aspx?rfr=olk&exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx>&realm=ads.local</EcpUrl-mt>
<EcpUrl-ret>?path=/options/retentionpolicies</EcpUrl-ret>
<EcpUrl-sms>?path=/options/textmessaging</EcpUrl-sms>
<EcpUrl-photo>?path=/options/myaccount/action/photo</EcpUrl-photo>
<EcpUrl-tm>options/ecp/?rfr=olk&ftr=TeamMailbox&exsvurl=1&realm=ads.local</EcpUrl-tm>
<EcpUrl-tmCreating>options/ecp/?rfr=olk&ftr=TeamMailboxCreating&SPUrl=<SPUrl>&Title=<Title>&SPTMAppUrl=<SPTMAppUrl>&exsvurl=1&realm=ads.local</EcpUrl-tmCreating>
<EcpUrl-tmEditing>options/ecp/?rfr=olk&ftr=TeamMailboxEditing&Id=<Id>&exsvurl=1&realm=ads.local</EcpUrl-tmEditing>
<EcpUrl-extinstall>?path=/options/manageapps</EcpUrl-extinstall>
<OOFUrl>https://outlook.ads-xxx.de/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://outlook.ads-xxx.de/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl>https://outlook.ads-xxx.de/OAB/c9b7b31b-afd2-403c-92dc-4673bdecc530/</OABUrl>
<ServerExclusiveConnect>On</ServerExclusiveConnect>
</Protocol>
</Account>
</Response>
</Autodiscover>In der Config steht nirgendwo mehr der lokale Servername fo1vmsrm05.ads.local.
Auch im Autodiscovery-Check steht nirgendwo mehr der lokale Hostname (wird wahrschienlich von der XML-Datei abgeleitet vermute ich):
Noch irgend eine Idee vielleicht?
VG
Frank
Die Migration ist noch nicht abgeschlossen - bisher habe ich nur ein Testpostfach migriert. Der alte Server (Exchange 2010) hat die .104 am Ende - der neue die .105 (Exchange 2016).
Genau deswegen solltest du dir mal folgenden Artikel zu Gemüte führenClient Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2010
Btw. "@t-online.de" ??????? Habt ihr die Befugnis die DNS Einträge von T-Online.de zu ändern
?!Von intern würde das Autodiscover ja noch mit SplitDNS und scp gehen, aber von extern nur über VPN, oder Hosts.
Zitat von @142232:
Client Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2010
Die Migration ist noch nicht abgeschlossen - bisher habe ich nur ein Testpostfach migriert. Der alte Server (Exchange 2010) hat die .104 am Ende - der neue die .105 (Exchange 2016).
Genau deswegen solltest du dir mal folgenden Artikel zu Gemüte führenClient Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2010
Okay, haben den Artikel gelesen, weiß aber jetzt nicht direkt, wie das mein Problem erklären könnte.
Zitat von @142232:
Btw. "@t-online.de" ??????? Habt ihr die Befugnis die DNS Einträge von T-Online.de zu ändern?!
Nein, wie so sollte ich das auch? Die E-Mail werden per POP3-Connector von T-Online geholt und per T-Online Smarthost versendet. Funktioniert.Btw. "@t-online.de" ??????? Habt ihr die Befugnis die DNS Einträge von T-Online.de zu ändern
?!Zitat von @142232:
Von intern würde das Autodiscover ja noch mit SplitDNS und scp gehen, aber von extern nur über VPN, oder Hosts.
Ja von extern wird auch ausschließlich per VPN zugegriffen.Von intern würde das Autodiscover ja noch mit SplitDNS und scp gehen, aber von extern nur über VPN, oder Hosts.
Zitat von @thaddaeus93:
Okay, haben den Artikel gelesen, weiß aber jetzt nicht direkt, wie das mein Problem erklären könnte.
Dann lies ihn nochmal Okay, haben den Artikel gelesen, weiß aber jetzt nicht direkt, wie das mein Problem erklären könnte.
. Irgendwann macht's auch bei dir klick.Die E-Mail werden per POP3-Connector von T-Online geholt und per T-Online Smarthost versendet.
Aua und das 2020.`Die E-Mail werden per POP3-Connector von T-Online geholt und per T-Online Smarthost versendet.
Aua und das 2020.Leider sieht man diese Konfigurationen heutzutage noch sehr oft, gerade wenn die Kunden von SBS Servern kommen wird dies oft mit übernommen.
Natürlich nicht zu empfehlen -.-.
@ frank gibts was neues?
Hallo serial,
Sorry, bei mir Klickt da nichts :D
Zitat von @142232:
. Irgendwann macht's auch bei dir klick.
Zitat von @thaddaeus93:
Okay, haben den Artikel gelesen, weiß aber jetzt nicht direkt, wie das mein Problem erklären könnte.
Dann lies ihn nochmal Okay, haben den Artikel gelesen, weiß aber jetzt nicht direkt, wie das mein Problem erklären könnte.
. Irgendwann macht's auch bei dir klick.Sorry, bei mir Klickt da nichts :D
Leider gibt es nichts neues. Mit einem zweiten Testpotfach besteht der Fehler weiterhin, auch den Client habe ich komplett neu aufgesetzt.
Die Konfiguration mit T-Online habe ich einfach 1:1 übernommen, das funktionierte vorher schon problemlos, denke daran sollte es nicht liegen.
der Exchange kann hier sowieso keine E-Mails direkt empfangen bzw. senden, da nur ein Telekom-Anschluss mit dynamischer IP eingesetzt wird.
Die Konfiguration mit T-Online habe ich einfach 1:1 übernommen, das funktionierte vorher schon problemlos, denke daran sollte es nicht liegen.
der Exchange kann hier sowieso keine E-Mails direkt empfangen bzw. senden, da nur ein Telekom-Anschluss mit dynamischer IP eingesetzt wird.
Hallo Zusammen,
habe gerade nochmal etwas getestet - und zwar ein neues Postfach direkt auf dem neuen Exchange-Server angelegt.
Den Testclient habe ich auch nochmal komplett neu aufgesetzt.
Bei dem frisch angelegten Testpostfach kommt der Fehler nicht!
(Bei dem migrierten Testpostfach allerdings schon).
Also falls noch jemand eine Idee hat, woran das liegen könnte, gerne her damit
VG
habe gerade nochmal etwas getestet - und zwar ein neues Postfach direkt auf dem neuen Exchange-Server angelegt.
Den Testclient habe ich auch nochmal komplett neu aufgesetzt.
Bei dem frisch angelegten Testpostfach kommt der Fehler nicht!
(Bei dem migrierten Testpostfach allerdings schon).
Also falls noch jemand eine Idee hat, woran das liegen könnte, gerne her damit
VG
Genau das ist in obigem Artikel beschrieben, wenn du den Artikel also verstanden hast weist du was zu tun ist 😉. Wenn nicht, Ölkännchen rausholen und den "Klick" mal nach ölen 👍.
Das einzige was ich dem Artikel entnehmen kann, ist dass es eventuell am SCP-Eintrag liegen könnte, der noch auf den "alten" Exchange-Server verweist.
Aber auch dieser zeigt schon auf den neuen Exchange-Server:
Aber auch dieser zeigt schon auf den neuen Exchange-Server:
Soo.. Hallo Zusammen,
ich melde mich mal wieder.. in der Zwischenzeit hab ich alle Postfächer auf den neuen Server migriert und den Exchange 2010 komplett deinstalliert. Bei den bisherigen Clients (Windows 7 / Office 2010) kommt auch keine Zertifikatsfehlermeldung mehr (das war ja immer der Fall, auch schon vor der Installation des EX2016). Sehr erfreulich an dieser Stelle also
Allerdings nur leider bei dem neuen Testclient (Windows 10 / Office 2016) kommt wieder die alt bekannte Zertifikatswarnmeldung:
Wenn ich auf "Zertifiakt anzeigen" klicke.. Zeigt er mir das externe Zertifikat für "autodiscovery.ads-xx.de" an. Das würde ja perfekt passen, wenn er den Server nicht mit dem lokalen Namen ansprechen würde..... -.-
Hat jemand diesbezüglich vielleicht noch einen Tipp für mich, woher er diesen Namen nimmt? Vom alten EX2010-Server kann es jedenfalls nicht mehr kommen, dort ist Exchange komplett deinstalliert.
VG
Frank
ich melde mich mal wieder.. in der Zwischenzeit hab ich alle Postfächer auf den neuen Server migriert und den Exchange 2010 komplett deinstalliert. Bei den bisherigen Clients (Windows 7 / Office 2010) kommt auch keine Zertifikatsfehlermeldung mehr (das war ja immer der Fall, auch schon vor der Installation des EX2016). Sehr erfreulich an dieser Stelle also
Allerdings nur leider bei dem neuen Testclient (Windows 10 / Office 2016) kommt wieder die alt bekannte Zertifikatswarnmeldung:
Wenn ich auf "Zertifiakt anzeigen" klicke.. Zeigt er mir das externe Zertifikat für "autodiscovery.ads-xx.de" an. Das würde ja perfekt passen, wenn er den Server nicht mit dem lokalen Namen ansprechen würde..... -.-
Hat jemand diesbezüglich vielleicht noch einen Tipp für mich, woher er diesen Namen nimmt? Vom alten EX2010-Server kann es jedenfalls nicht mehr kommen, dort ist Exchange komplett deinstalliert.
VG
Frank
HI Frank,
ich vermute immer noch, dass etwas in der URL Konfiguration nicht passt.
Z.B. ein fehlender Eintrag bei der Outlook Annywhere habe ich mehrfach vorgefunden, weswegen die Outlook Clients auf den alten Namen connecten.
Bitte prüfe nochmals genau alle URLs. Du hast oben lediglich drei im Screenshot ausgegeben.
Ich habe zwar gelesen, dass du es wie bei "Frankysweb" konfiguriert hast, allerdings muss irgendwo noch ein Eintrag vorhanden sein:
Was steht im AD unter dem _autodiscover SRV Eintrag?
Grüße Phil
ich vermute immer noch, dass etwas in der URL Konfiguration nicht passt.
Z.B. ein fehlender Eintrag bei der Outlook Annywhere habe ich mehrfach vorgefunden, weswegen die Outlook Clients auf den alten Namen connecten.
Bitte prüfe nochmals genau alle URLs. Du hast oben lediglich drei im Screenshot ausgegeben.
Ich habe zwar gelesen, dass du es wie bei "Frankysweb" konfiguriert hast, allerdings muss irgendwo noch ein Eintrag vorhanden sein:
Get-OwaVirtualDirectory -Server Exchange | Set-OwaVirtualDirectory -internalurl "https://outlook.frankysweb.org/owa" -externalurl "https://outlook.frankysweb.org/owa"
Get-EcpVirtualDirectory -server Exchange | Set-EcpVirtualDirectory -internalurl "https://outlook.frankysweb.org/ecp" -externalurl "https://outlook.frankysweb.org/ecp"
Get-WebServicesVirtualDirectory -server Exchange | Set-WebServicesVirtualDirectory -internalurl "https://outlook.frankysweb.org/EWS/Exchange.asmx" -externalurl "https://outlook.frankysweb.org/EWS/Exchange.asmx"
Get-ActiveSyncVirtualDirectory -Server Exchange | Set-ActiveSyncVirtualDirectory -internalurl "https://outlook.frankysweb.org/Microsoft-Server-ActiveSync" -externalurl "https://outlook.frankysweb.org/Microsoft-Server-ActiveSync"
Get-OabVirtualDirectory -Server Exchange | Set-OabVirtualDirectory -internalurl "https://outlook.frankysweb.org/OAB" -externalurl "https://outlook.frankysweb.org/OAB"
Get-MapiVirtualDirectory -Server Exchange | Set-MapiVirtualDirectory -externalurl "https://outlook.frankysweb.org/mapi" -internalurl "https://outlook.frankysweb.org/mapi"
Get-OutlookAnywhere -Server Exchange | Set-OutlookAnywhere -externalhostname outlook.frankysweb.org -internalhostname outlook.frankysweb.org -ExternalClientsRequireSsl:$true -InternalClientsRequireSsl:$true -ExternalClientAuthenticationMethod 'Negotiate'
Get-ClientAccessService Exchange | Set-ClientAccessService -AutoDiscoverServiceInternalUri "https://autodiscover.frankysweb.org/Autodiscover/Autodiscover.xml" Was steht im AD unter dem _autodiscover SRV Eintrag?
Grüße Phil
Hi Phil,
die URL's habe ich gerade nochmal mit dem Script neu konfiguriert - allerdings gibt er schon die Rückmeldung in der PowerShell, dass sowieso schon alles so war:
Der SCP-Eintrag im AD sieht m.E. nach auch gut aus:
Das Einzige was noch fehlt ist ein SRV-Eintrag im DNS.. diesen lässt er mich aber auch nicht anlegen (_autodiscover gibt es nicht zur Auswahl)
Aber normalerweise müsste Outlook doch hergehen und zunächst den SCP-Eintrag im AD abchecken oder liege ich da falsch?
Grüße
Frank
die URL's habe ich gerade nochmal mit dem Script neu konfiguriert - allerdings gibt er schon die Rückmeldung in der PowerShell, dass sowieso schon alles so war:
Der SCP-Eintrag im AD sieht m.E. nach auch gut aus:
Das Einzige was noch fehlt ist ein SRV-Eintrag im DNS.. diesen lässt er mich aber auch nicht anlegen (_autodiscover gibt es nicht zur Auswahl)
Aber normalerweise müsste Outlook doch hergehen und zunächst den SCP-Eintrag im AD abchecken oder liege ich da falsch?
Grüße
Frank
Moin,
das Autodiscover kann durchaus nervig sein weil MS die Reihenfolge immer mal wieder ändert.
Du kannst einen Live-Test machen.
Strg gedrückt halten und rechte Maustaste auf das Outlooksymbol im Tray anklicken.
"E-Mail-Autokonfiguration testen".
Dann sieht man in welcher Reihenfolge er sucht.
Bei mir firma.de/autodiscover/autodiscover.xml, dann IMAP und POP und erst dann srv und autodiscover.firma.de.
Stefan
das Autodiscover kann durchaus nervig sein weil MS die Reihenfolge immer mal wieder ändert.
Du kannst einen Live-Test machen.
Strg gedrückt halten und rechte Maustaste auf das Outlooksymbol im Tray anklicken.
"E-Mail-Autokonfiguration testen".
Dann sieht man in welcher Reihenfolge er sucht.
Bei mir firma.de/autodiscover/autodiscover.xml, dann IMAP und POP und erst dann srv und autodiscover.firma.de.
Stefan
Morgen,
Alles Klar, schaut soweit gut aus.
Genau, wenn der Client Mitglied in einer Domäne ist wird zuerst der SCP gecheckt und danach per DNS.
Der SRV Eintrag sollte eigentlich beim installieren des Exchanges erstellt werden.
.. ...
Kannst du nochmal den SCP per Powershell auslesen und Posten.
Alternativ könntest du an einem betroffen Client testweise per Registry oder gpo den SCP Check überspringen und ihm angeben,dass er sich die Konfiguration direkt per DNS ziehen soll.
Grüße Phil
Alles Klar, schaut soweit gut aus.
Genau, wenn der Client Mitglied in einer Domäne ist wird zuerst der SCP gecheckt und danach per DNS.
Der SRV Eintrag sollte eigentlich beim installieren des Exchanges erstellt werden.
.. ...
Kannst du nochmal den SCP per Powershell auslesen und Posten.
Alternativ könntest du an einem betroffen Client testweise per Registry oder gpo den SCP Check überspringen und ihm angeben,dass er sich die Konfiguration direkt per DNS ziehen soll.
Grüße Phil
Morgen Frank,
wie ist der Stand der Dinge? Bist du weitergekommen?
Grüße
wie ist der Stand der Dinge? Bist du weitergekommen?
Grüße
Guten Morgen Phil,
bin gerade erst dazu gekommen - habe mal eine PowerShell-Abfrage bzgl. des SCP durchlaufen lassen:
Also hier steht der lokale Name (FO1VMSRM05) des neuen Exchange-Servers drinnen, aber ich denke das gehört auch so oder?
Werde später mal probieren, bei einem Test-PC den SCP-Check abzuschalten.
VG
Frank
bin gerade erst dazu gekommen - habe mal eine PowerShell-Abfrage bzgl. des SCP durchlaufen lassen:
Also hier steht der lokale Name (FO1VMSRM05) des neuen Exchange-Servers drinnen, aber ich denke das gehört auch so oder?
Werde später mal probieren, bei einem Test-PC den SCP-Check abzuschalten.
VG
Frank
Hi Frank,
nein stimmt leider nicht ganz.
Der SCP muss auf den Server zeigen, richtig. Allerdings sollte die Autodiscover URL mit der im Zertifikat hinterlegten Adresse übereinstimmen.
Was gibt der Befehl aus?
Get-ClientAccessService | fl *autod*
Dort sollte die korrekte URL ausgegeben und falls nicht angepasst werden.
Deswegen meinte ich auch zum Test einfach mal per Registry auf einem betroffenen Client den SCP übergehen und sehen was passiert.
Grüße Phil
nein stimmt leider nicht ganz.
Der SCP muss auf den Server zeigen, richtig. Allerdings sollte die Autodiscover URL mit der im Zertifikat hinterlegten Adresse übereinstimmen.
Was gibt der Befehl aus?
Get-ClientAccessService | fl *autod*
Dort sollte die korrekte URL ausgegeben und falls nicht angepasst werden.
Deswegen meinte ich auch zum Test einfach mal per Registry auf einem betroffenen Client den SCP übergehen und sehen was passiert.
Grüße Phil
Hi Phil,
habe den Power-Shell-Befehl nochmal reingejagt:
Die URL passt und diese ist auch über das Zertifikat abgedeckt.
Den Registry-Test werde ich nach meinem Urlaub mal ausprobieren
Danke schon mal.
VG
Frank
habe den Power-Shell-Befehl nochmal reingejagt:
Die URL passt und diese ist auch über das Zertifikat abgedeckt.
Den Registry-Test werde ich nach meinem Urlaub mal ausprobieren
Danke schon mal.
VG
Frank
Na dann mal einen schönen Urlaub.
Gib bitte Rückmeldung, sobald du die Tests durchgeführt hast.
Grüße Phil
Gib bitte Rückmeldung, sobald du die Tests durchgeführt hast.
Grüße Phil
Hi Frank,
gibts bereits Neuigkeiten von deiner Seite?
Grüße Phil
gibts bereits Neuigkeiten von deiner Seite?
Grüße Phil
1
Hi Phil,
hat sich leider alles etwas gezogen - mittlerweile hat sich das Problem "in Luft" aufgelöst, nachdem ich den alten Windows Server 2008 mit dem Exchange aus der Domäne genommen hatte.
Was auch immer das Problem war, es läuft jetzt.
Danke Dir und Danke Euch allen für die Mühen!
VG
Frank
hat sich leider alles etwas gezogen - mittlerweile hat sich das Problem "in Luft" aufgelöst, nachdem ich den alten Windows Server 2008 mit dem Exchange aus der Domäne genommen hatte.
Was auch immer das Problem war, es läuft jetzt.
Danke Dir und Danke Euch allen für die Mühen!
VG
Frank
1
Hi Frank,
danke für die Rückmeldung.
Dann weiterhin gutes gelingen.
Grüße
Phil
danke für die Rückmeldung.
Dann weiterhin gutes gelingen.
Grüße
Phil
