36
Zertifikatsfehler Exchange 2010 "Name des Sicherheitszertifikates"
Hallo Forum,
wir haben folgendes Problem, und zwar nach dem installieren eines Wildcard Zertifikates funktioniert zwar die OWA dienste mit SSL problemlos ,aber im Exchange könnenleider die Dienste dem Zertifikat nicht hinzugefügt werden und es poppt die Meldung auf, dass der Name auf dem Sicherheitszertifikat ungültig ist. Mit Sicherheit kommt das Problem daher, dass ja auf dem Thawte Cert *.domain steht und nicht die interne .local domain. Hat jemand eine Idee, wie ich das umgehen kann?
Vielen Dank im Voraus"
wir haben folgendes Problem, und zwar nach dem installieren eines Wildcard Zertifikates funktioniert zwar die OWA dienste mit SSL problemlos ,aber im Exchange könnenleider die Dienste dem Zertifikat nicht hinzugefügt werden und es poppt die Meldung auf, dass der Name auf dem Sicherheitszertifikat ungültig ist. Mit Sicherheit kommt das Problem daher, dass ja auf dem Thawte Cert *.domain steht und nicht die interne .local domain. Hat jemand eine Idee, wie ich das umgehen kann?
Vielen Dank im Voraus"
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: 361290
Url: https://administrator.de/contentid/361290
Ausgedruckt am: 26.11.2024 um 13:11 Uhr
36 Kommentare
Neuester Kommentar
Moin,
du musst die internen und extern URL' der virtuellen Verzeichnisse anpassen.
Gruß, V
du musst die internen und extern URL' der virtuellen Verzeichnisse anpassen.
Gruß, V
Mit Sicherheit kommt das Problem daher, dass ja auf dem Thawte Cert *.domain steht und nicht die interne .local domain. Hat jemand eine Idee, wie ich das umgehen kann?
Dito, einfach mal lesen und verstehen bevor man an Systemen bastelt die man nicht versteht ...https://www.frankysweb.de/exchange-2010-und-outlook-2016-autodiscover/
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-auto ...
Lieber Seppelhuber,
ich finde Ihre Aussage ganz schön frech.
Administrator.de ist ein Forum wo man Fragen stellen kann und auch soll, denn davon lebt das Forum.
Wenn alle hier so intelligent und überdurchschnittlich gute Admins wären, wie Sie es anscheinend sind, bräuchten wir kein solches Forum.
Ich kann an der Frage nichts verwerfliches erkennen. Es ist und bleibt eine ganz normale Frage auf die man hätte auch in einem normalen Ton antworten können.
Mit freundlichen Grüßen
Criemo
ich finde Ihre Aussage ganz schön frech.
Administrator.de ist ein Forum wo man Fragen stellen kann und auch soll, denn davon lebt das Forum.
Wenn alle hier so intelligent und überdurchschnittlich gute Admins wären, wie Sie es anscheinend sind, bräuchten wir kein solches Forum.
Ich kann an der Frage nichts verwerfliches erkennen. Es ist und bleibt eine ganz normale Frage auf die man hätte auch in einem normalen Ton antworten können.
Mit freundlichen Grüßen
Criemo
2
Hi,
Die links die Seppelhuber geschickt hat sind gut und erklären was getan werden muss.
Am einfachsten ist es wenn du die externen URLs des Virtuellen Directory’s auch intern benutzt. So ist er intern wie extern Erreichbar und der User muss sich keine unterschiedlichen URLs merken.
Viele Grüße
Criemo
Die links die Seppelhuber geschickt hat sind gut und erklären was getan werden muss.
Am einfachsten ist es wenn du die externen URLs des Virtuellen Directory’s auch intern benutzt. So ist er intern wie extern Erreichbar und der User muss sich keine unterschiedlichen URLs merken.
Viele Grüße
Criemo
Zitat von @135185:
Du hast schon nicht unrecht, aber, 1. Criemo hat völlig recht, bitte mal nachlesen, wozu ein Forum da ist. Mit Sicherheit kommt das Problem daher, dass ja auf dem Thawte Cert *.domain steht und nicht die interne .local domain. Hat jemand eine Idee, wie ich das umgehen kann?
Dito, einfach mal lesen und verstehen bevor man an Systemen bastelt die man nicht versteht ...2. Manchmal muss man sich auch in Themen rein arbeiten, die man nicht gleich auf Anhieb versteht, wenn man aus einem anderen Fachgebiet kommt. Also, Bälle flach halten und besten Dank für die Links.
https://www.frankysweb.de/exchange-2010-und-outlook-2016-autodiscover/
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-auto ...
https://www.frankysweb.de/exchange-2016-umfangreiches-whitepaper-zu-auto ...
Gruß Leo
Hallo Leo-le, hallo Alle,
habe gleiches Problem wie Leo-le nach der Installation eines SSL-Multidomain-Zertifikates von einer öffentlichen CA in unserem Exchange 2010 (SBS2011). Die Outlook 2016 Clients (Win10 Pro Maschinen) meckern den Zertifikatsnamen an, da Outlook nicht auf die im Zertifikat hinterlegte Domain "exchange.meinefirma.de" zugreift sondern auf die lokale "mein-exchange.domain.local".
Das habe ich bisher gemacht:
In der Exchange 2010 Konsole habe ich eine Zertifikatsanforderung erstellt. Habe darin auch alle benötigten Subdomains erfasst:
- autodiscover.meinefirma.de
- exchange.meinefirma.de
- mail.meinefirma.de
- imap.meinefirma.de
- smtp.meinefirma.de
Die Zertifikatsanforderung habe ich mit dem von der CA zugeschickten Zertifikat in der Exchange-Konsole ohne Fehler abgeschlossen und die Dienste IMAP, POP, IIS und SMTP daran angebunden.
Im DNS habe ich zwei Forward-Lookup Zonen "exchange.meinefirma.de" und "mail.meinefirma.de" angelegt und darin jeweils einen HOST ohne Namen (identisch mit übergeordnetem Ordner) mit der lokalen IP-Adresse des Exchange 2010 erstellt.
Weiterhin habe ich in der Forward-Lookup Zone "meinefirma.local" in dem Unterordner "_tcp" einen SRV Eintrag "_autodiscover" erstellt, der auf den Host "exchange.meinefirma.de" Port 443 verweist.
Den SCP des Exchange habe ich nach einem TechNet Artikel über die Management Shell ebenfalls angepasst:
_____________________________________________________________________________________________________________________________
[PS] C:\Windows\system32>$AutodiscoverHostName = "autodiscover.meinefirma.de"
[PS] C:\Windows\system32>Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like "Version 14*") -And ($_.ServerRole -Like "*ClientAccess*")} | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://$AutodiscoverHostName/Autodiscover/Autodiscover.xml
______________________________________________________________________________________________________________________________
Das Kommando
[PS] C:\Windows\system32>Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like "Version 14*") -And ($_.ServerRole -Like "*ClientAccess*")} | Get-ClientAccessServer | Format-Table Name, AutoDiscoverServiceInternalUri -Auto
gibt korrekt aus:
Name AutoDiscoverServiceInternalUri
MEIN-EXCHANGE https://autodiscover.meinefirma.de/Autodiscover/Autodiscover.xml
Trotzdem habe ich immer noch diese stressige Zertifikatswarnung beim Start von Outlook.
Alles Andere funktioniert gut.
Hat jemand eine Idee, was ich übersehen habe?
Gruß u. Dank, DQ
habe gleiches Problem wie Leo-le nach der Installation eines SSL-Multidomain-Zertifikates von einer öffentlichen CA in unserem Exchange 2010 (SBS2011). Die Outlook 2016 Clients (Win10 Pro Maschinen) meckern den Zertifikatsnamen an, da Outlook nicht auf die im Zertifikat hinterlegte Domain "exchange.meinefirma.de" zugreift sondern auf die lokale "mein-exchange.domain.local".
Das habe ich bisher gemacht:
In der Exchange 2010 Konsole habe ich eine Zertifikatsanforderung erstellt. Habe darin auch alle benötigten Subdomains erfasst:
- autodiscover.meinefirma.de
- exchange.meinefirma.de
- mail.meinefirma.de
- imap.meinefirma.de
- smtp.meinefirma.de
Die Zertifikatsanforderung habe ich mit dem von der CA zugeschickten Zertifikat in der Exchange-Konsole ohne Fehler abgeschlossen und die Dienste IMAP, POP, IIS und SMTP daran angebunden.
Im DNS habe ich zwei Forward-Lookup Zonen "exchange.meinefirma.de" und "mail.meinefirma.de" angelegt und darin jeweils einen HOST ohne Namen (identisch mit übergeordnetem Ordner) mit der lokalen IP-Adresse des Exchange 2010 erstellt.
Weiterhin habe ich in der Forward-Lookup Zone "meinefirma.local" in dem Unterordner "_tcp" einen SRV Eintrag "_autodiscover" erstellt, der auf den Host "exchange.meinefirma.de" Port 443 verweist.
Den SCP des Exchange habe ich nach einem TechNet Artikel über die Management Shell ebenfalls angepasst:
_____________________________________________________________________________________________________________________________
[PS] C:\Windows\system32>$AutodiscoverHostName = "autodiscover.meinefirma.de"
[PS] C:\Windows\system32>Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like "Version 14*") -And ($_.ServerRole -Like "*ClientAccess*")} | Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://$AutodiscoverHostName/Autodiscover/Autodiscover.xml
______________________________________________________________________________________________________________________________
Das Kommando
[PS] C:\Windows\system32>Get-ExchangeServer | Where {($_.AdminDisplayVersion -Like "Version 14*") -And ($_.ServerRole -Like "*ClientAccess*")} | Get-ClientAccessServer | Format-Table Name, AutoDiscoverServiceInternalUri -Auto
gibt korrekt aus:
Name AutoDiscoverServiceInternalUri
MEIN-EXCHANGE https://autodiscover.meinefirma.de/Autodiscover/Autodiscover.xml
Trotzdem habe ich immer noch diese stressige Zertifikatswarnung beim Start von Outlook.
Alles Andere funktioniert gut.
Hat jemand eine Idee, was ich übersehen habe?
Gruß u. Dank, DQ
Hi,
Hat jemand eine Idee, was ich übersehen habe?
Ja...die restlichen virtuellen Verzeichnisse.
https://www.msxfaq.de/exchange/e2007/casurls.htm
Gruß, V
Hat jemand eine Idee, was ich übersehen habe?
Ja...die restlichen virtuellen Verzeichnisse.
https://www.msxfaq.de/exchange/e2007/casurls.htm
Gruß, V
Hi V,
habe eben noch mal alle Verzeichnisse neu gesetzt. Interne u. externe URL auf "exchange.meinefirma.de", wie im Zertifikat der öffentlichen CA.
Habe den IIS neu gestartet u. warte jetzt mal eine halbe Stunde bis zum nächsten Test.
Danke für den Tipp!
Gruß, DQ
habe eben noch mal alle Verzeichnisse neu gesetzt. Interne u. externe URL auf "exchange.meinefirma.de", wie im Zertifikat der öffentlichen CA.
Habe den IIS neu gestartet u. warte jetzt mal eine halbe Stunde bis zum nächsten Test.
Danke für den Tipp!
Gruß, DQ
Okay, besten Dank für die Infos. Ich habe nun bei dem exchange Server, wo die Sicherheitsmeldung nach der Neueinbindung des Zertifikats bei einigen Nutzern kam, das virtuelle Verzeichnis geändert und die URL intern auch auf domain.de gesetzt. Zusätzlich habe ich den Host a Eintrag in der .de Zone des Servers auf die öffentliche IP gesetzt. Kann ich diese Zertifikatsabfrage irgendwie simulieren? Nach der Umstellung beschwerten sich innerhalb von 12 Stunden gerade mal 1 Kollege. Mich selber und meine Teamkollegen hatten auch nach mehreren Neustarts von Outlook keine Probleme. Nslookup auf autodiscover.domain
.de wird mit der .de Domain sauber im Internet aufgelöst.
.de wird mit der .de Domain sauber im Internet aufgelöst.
Du kannst das durchsimulieren lassen über:
https://mxtoolbox.com
Das kann dir alle Zertifikatsfehleranzeigen wenn du auf Details gehst.
https://mxtoolbox.com
Das kann dir alle Zertifikatsfehleranzeigen wenn du auf Details gehst.
Sieht alles sauber aus bei mxtools.com.
Seit Freitag ist die Umstellung aktiv, aber bei 1-2 Kollegen kommt es immer noch zu der Meldung. Woran könnte es noch liegen?
Vielen Dank im Voraus!
Seit Freitag ist die Umstellung aktiv, aber bei 1-2 Kollegen kommt es immer noch zu der Meldung. Woran könnte es noch liegen?
Vielen Dank im Voraus!
Zitat von @Leo-le:
Sieht alles sauber aus bei mxtools.com.
Seit Freitag ist die Umstellung aktiv, aber bei 1-2 Kollegen kommt es immer noch zu der Meldung. Woran könnte es noch liegen?
Vielen Dank im Voraus!
Moin,Sieht alles sauber aus bei mxtools.com.
Seit Freitag ist die Umstellung aktiv, aber bei 1-2 Kollegen kommt es immer noch zu der Meldung. Woran könnte es noch liegen?
Vielen Dank im Voraus!
einfach mal ein ipconfig /flushdns gemacht? Oder mal Outlook aus dem Cached Modus genommen zum testen?
Gruß, V
Flushdns ja, Cached Modus habe ich jetzt veranlasst.
Das Problem besteht weiterhin und anscheinend nur bei einer Person. Noch eine weitere Idee?
Lösch das Outlookprofil und lass es neu aufbauen. Wäre jetzt so noch eine Möglichkeit.
Das habe ich auch bei einigen Arbeitsplätzen machen müssen. War die einzige Möglichkeit das Problem zu beseitigen.
Blöd nur, wenn 6 oder mehr Konten in Outlook eingebunden sind, viel Handarbeit. Aber jetzt ist endlich Ruh!
Blöd nur, wenn 6 oder mehr Konten in Outlook eingebunden sind, viel Handarbeit. Aber jetzt ist endlich Ruh!
Wieso Handarbeit?
Beim nem EX2010 wenn die Konten über die EX Konsole berechtigt sind, zieht der sich die Konten automatisch.
Beim nem EX2010 wenn die Konten über die EX Konsole berechtigt sind, zieht der sich die Konten automatisch.
Bei uns sind nicht alle Konten auf unserem Exchange. Hatte auch einige geschäftliche IMAPs von extern wieder anzubinden. Daher die Handarbeit.
Zitat von @Criemo:
Lösch das Outlookprofil und lass es neu aufbauen. Wäre jetzt so noch eine Möglichkeit.
unter Systemsteuerung/e-mail/Profile anzeigenLösch das Outlookprofil und lass es neu aufbauen. Wäre jetzt so noch eine Möglichkeit.
Outlook Profil entfernen und dann erneut outlook einzugeben?
Jap genau.
Warum macht man den sowas, wenn man einen Exchange hat.
So, das ganze scheint leider doch nicht so ganz zu funktionieren. Ich fasse nochmal kurz zusammen, was ich geändert habe:
- separate DNS- Zone mit domain.de
- Host A -Eintrag autodiscover auf die öffentliche IP des Servers
- Unter get-OwaVirtualDirectory | fl *url* die interne URL auch auf die exchange.domain.de gesetzt
Ergebnis: ca. 5 % der Mitarbeiter bekamen eine Sicherheitsmeldung wegen des Zertifikats, wegen dem internen Namen des Exchange -Servers
Mit Sicherheit habe ich irgendwas vergessen.
- separate DNS- Zone mit domain.de
- Host A -Eintrag autodiscover auf die öffentliche IP des Servers
- Unter get-OwaVirtualDirectory | fl *url* die interne URL auch auf die exchange.domain.de gesetzt
Ergebnis: ca. 5 % der Mitarbeiter bekamen eine Sicherheitsmeldung wegen des Zertifikats, wegen dem internen Namen des Exchange -Servers
Mit Sicherheit habe ich irgendwas vergessen.
DNS-Zone domain.de oder exchange.domain.de?
Hallo Leo-Le,
in deinem internen DNS bekommt das autodiscover auch eine interne IP. Die externe IP für autodiscover wird duch den A Eintrag bei deinem ISP gemacht und NICHT über deinen internen DNS.
https://www.frankysweb.de/exchange-2010-und-outlook-2016-autodiscover/
Zitat:
[....Alles was jetzt noch benötigt wird ist ein Zertifikat welches die Namen „autodiscover.frankysweb.de“ und „outlook.frankysweb.de“ enthält und die DNS Einträge.
Die meisten werden wohl Split Brain DNS betreiben, sprich die externe Domain, in diesem Beispiel frankysweb.de. liegt bei irgendeinem Provider. Dort werden autodiscover.frankysweb.de und outlook.frankysweb.de als Subdomain, oder HOST-A (je nachdem wie der Provider das gerade nennt) eingetragen. Die HOST-A Einträge enthalten dann die externe IP Adresse unter der Exchange erreichbar ist.
Am internen DNS das gleiche Spiel, jedoch mit der internen IP-Adresse. Fertig. 15 Minuten warten nicht vergessen, so klappts auch mit Outlook 2016 und Exchange 2010......]
in deinem internen DNS bekommt das autodiscover auch eine interne IP. Die externe IP für autodiscover wird duch den A Eintrag bei deinem ISP gemacht und NICHT über deinen internen DNS.
https://www.frankysweb.de/exchange-2010-und-outlook-2016-autodiscover/
Zitat:
[....Alles was jetzt noch benötigt wird ist ein Zertifikat welches die Namen „autodiscover.frankysweb.de“ und „outlook.frankysweb.de“ enthält und die DNS Einträge.
Die meisten werden wohl Split Brain DNS betreiben, sprich die externe Domain, in diesem Beispiel frankysweb.de. liegt bei irgendeinem Provider. Dort werden autodiscover.frankysweb.de und outlook.frankysweb.de als Subdomain, oder HOST-A (je nachdem wie der Provider das gerade nennt) eingetragen. Die HOST-A Einträge enthalten dann die externe IP Adresse unter der Exchange erreichbar ist.
Am internen DNS das gleiche Spiel, jedoch mit der internen IP-Adresse. Fertig. 15 Minuten warten nicht vergessen, so klappts auch mit Outlook 2016 und Exchange 2010......]
Okay, langsam wird's. Vielen Dank für die Tipps. Die Einträge beim ISP habe ich schon länger gesetzt, aber intern dachte Ich, Outlook soll über die Domain.de Zone auf die öffentlich Ip gehen. Mir ist noch nicht ganz klar, wie das Zertifikat dann richtig gegengeprüft werden kann. Was mir auch noch aufgefallen Ist... kann das sein, dass exchange 2010 mit Wildcard Zertifikaten nicht klar kommt?
Hi,
Hier ein Link zum besseren Verständnis von Autodiscover & DNS
https://www.msxfaq.de/exchange/autodiscover/autodiscover_dns.htm
Jap stimmt der Exchange und Wildcards sind so ein Ding für sich.
Was du machen kannst sind die einzelnen Dienste benennen und diesen das immer Wcard zuweisen.
Owa.deinedomain.de
EWS.deinedomain.de
Autodiscover.deinedomain.de
Aber alle mit dem gleichen Wcard berechtigen.
Das funktioniert ohne Probleme.
Hier ein Link zum besseren Verständnis von Autodiscover & DNS
https://www.msxfaq.de/exchange/autodiscover/autodiscover_dns.htm
Jap stimmt der Exchange und Wildcards sind so ein Ding für sich.
Was du machen kannst sind die einzelnen Dienste benennen und diesen das immer Wcard zuweisen.
Owa.deinedomain.de
EWS.deinedomain.de
Autodiscover.deinedomain.de
Aber alle mit dem gleichen Wcard berechtigen.
Das funktioniert ohne Probleme.
Vielen, Dank. Wir hatten die Möglichkeit die Wildcard zurück zugeben und dieses habe ich nun in ein SAN -Zertifkat umgewandelt. Hier kamen wir am Ende nun auch noch viel günstiger. Autodiscover scheint jetzt ordentlich zu finktionieren. Einzig unsere Tochterfirmen haben nun noch ein Problem, welches aber ganz klar am Wildcard Cert liegt. Das Theme sollte sich dann in 2 Tagen erledigt haben.
Oder so. das geht auch.
Immer gerne.
Vergiss bitte nicht entsprechende Lösungen zu makieren.
VG
Mirco
Immer gerne.
Vergiss bitte nicht entsprechende Lösungen zu makieren.
VG
Mirco
Und falls du noch fragen hast, frag ruhig.
Ja, eine Frage brennt mir tatsächlich noch auf der Zunge...
Wir haben 3 Exchange Server ( 2 mit Postfachrolle in einer DAG unbd 1 OWA Server, der nach außen über NAT erreichbar ist)
Mir fehlt so ein bisschen die Logik, wieso alle Clients grundsätzlich mit der Exch2 sich verbinden und nicht mit dem Exch1. Wo kann man sowas einstellen? Nun sind alle Verzeichniss angepasst, soweit , so gut , aber die Clients verbinden sich immer noch mit dem Exch2. Wie wäre ein verfahren, wo ich die DAG auflöse und am Ende nur noch einen Exch habe?
Vielleicht kannst du mir auch hier nochmal kurz einen Denkanstoß geben?
Besten Dank!
Wir haben 3 Exchange Server ( 2 mit Postfachrolle in einer DAG unbd 1 OWA Server, der nach außen über NAT erreichbar ist)
Mir fehlt so ein bisschen die Logik, wieso alle Clients grundsätzlich mit der Exch2 sich verbinden und nicht mit dem Exch1. Wo kann man sowas einstellen? Nun sind alle Verzeichniss angepasst, soweit , so gut , aber die Clients verbinden sich immer noch mit dem Exch2. Wie wäre ein verfahren, wo ich die DAG auflöse und am Ende nur noch einen Exch habe?
Vielleicht kannst du mir auch hier nochmal kurz einen Denkanstoß geben?
Besten Dank!
Sorry, dass ich erst jetzt schreibe.
Klar geht das nur nicht einfach so.
Ich empfehle dir folgenden Artikel zulesen:
https://www.msxfaq.de/cluster/dnsroundrobin.htm
Viele Grüße
Criemo
Klar geht das nur nicht einfach so.
Ich empfehle dir folgenden Artikel zulesen:
https://www.msxfaq.de/cluster/dnsroundrobin.htm
Viele Grüße
Criemo
Hallo Criemo, besten Dank!
Leider ist bei einem einzelnen die Sicherheitsmeldung nun wieder aufgetreten. Wo genau kann ich mir die XML anschauen, die dieser Client benötigt?
Leider ist bei einem einzelnen die Sicherheitsmeldung nun wieder aufgetreten. Wo genau kann ich mir die XML anschauen, die dieser Client benötigt?
Moin,
in der Registry unter
oder für 1-Click installer
Dort findest du dann jeweils den Pfad
Gruß, V
Zitat von @Leo-le:
Hallo Criemo, besten Dank!
Leider ist bei einem einzelnen die Sicherheitsmeldung nun wieder aufgetreten. Wo genau kann ich mir die XML anschauen, die dieser Client benötigt?
Hallo Criemo, besten Dank!
Leider ist bei einem einzelnen die Sicherheitsmeldung nun wieder aufgetreten. Wo genau kann ich mir die XML anschauen, die dieser Client benötigt?
in der Registry unter
[HKLM\SOFTWARE\Microsoft\Office\<Version>\Outlook\AutoDiscover] bzw. [HKCU\SOFTWARE\Microsoft\Office\<Version>\Outlook\AutoDiscover][Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Outlook\AutoDiscover]Dort findest du dann jeweils den Pfad
Gruß, V
Besten Dank! Dort sehe ich jetzt aber nur irgendwelche Schlüssel, wie z.B. yahoo.co.nz. Hier müsste doch auch ein Schlüssel mit unserer Domain stehen, so dass ich den Verweis auf die XML habe?
Hi,
Mache es doch einfacher:
öffne Outlook am Client, da wo der Fehler auftritt
Dann gehe auf das Status Symbol von Outlook unten rechts an der Uhr
drücke die STRG Taste und gehe auf "E-Mail - Autokonfiguration testen"
lass das Häckchen nur bei Auto- Ermittlung gesetzt.
gib die Email adresse des Users samt Passwort ein und drücke auf Test.
dann schau dir genau an was da Sache ist.
du kannst es dann gerne auch Posten und wir schauen dann mal drücber.
VG
Criemo
Mache es doch einfacher:
öffne Outlook am Client, da wo der Fehler auftritt
Dann gehe auf das Status Symbol von Outlook unten rechts an der Uhr
drücke die STRG Taste und gehe auf "E-Mail - Autokonfiguration testen"
lass das Häckchen nur bei Auto- Ermittlung gesetzt.
gib die Email adresse des Users samt Passwort ein und drücke auf Test.
dann schau dir genau an was da Sache ist.
du kannst es dann gerne auch Posten und wir schauen dann mal drücber.
VG
Criemo
Hallo Criemo, vielen Dank!
Und okay, ich habe mir das Ganze nun mal bei der Auto-Ermittlung angeschaut. Es tritt nun nach einer Woche bei ca 3 -5 Personen erneut auf und danach bei jedem Start von Outlook. Hat das zufällig mit den internal Namen noch zu tun?
Hier ein Ausschnitt der XML:
<?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>Max Muster</DisplayName>
<LegacyDN>/o=xx GmbH/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Max Muster130</LegacyDN>
<AutoDiscoverSMTPAddress>Max.Muster@xx.com</AutoDiscoverSMTPAddress>
<DeploymentId>fa62e35b-64a9-4629-98e0-24101d0b721c</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>EXCH</Type>
<Server>EXCH02.xx.xx.intern</Server>
<ServerDN>/o=xx GmbH/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCH02</ServerDN>
<ServerVersion>738180DA</ServerVersion>
<MdbDN>/o=xx GmbH/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCH02/cn=Microsoft Private MDB</MdbDN>
<PublicFolderServer>EXCH02.xx.xx.intern</PublicFolderServer>
<AD>DC02.xx.xx.intern</AD>
<ASUrl>https://exch02.xx.xx.intern/EWS/Exchange.asmx</ASUrl>
<EwsUrl>https://exch02.xx.xx.intern/EWS/Exchange.asmx</EwsUrl>
<EcpUrl>https://exch02.xx.xx.intern/ecp/</EcpUrl>
<EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
<EcpUrl-ret>?p=organize/retentionpolicytags.slab&exsvurl=1</EcpUrl-ret>
<EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
<OOFUrl>https://exch02.xx.xx.intern/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://exch02.xx.xx.intern/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl>http://exch02.xx.xx.intern/OAB/9170d1ea-d70c-474e-b172-f4dea58ed576/</OABUrl>
</Protocol>
<Protocol>
<Type>EXPR</Type>
<Server>exchange.xx.de</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
<ASUrl>https://exchange.xx.de/EWS/Exchange.asmx</ASUrl>
<EwsUrl>https://exchange.xx.de/EWS/Exchange.asmx</EwsUrl>
<OOFUrl>https://exchange.xx.de/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://exchange.xx.de/EWS/UM2007Legacy.asmx</UMUrl>
<CertPrincipalName>none</CertPrincipalName>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Fba">https://exch01.xx.xx.intern/owa/</OWAUrl>
<OWAUrl AuthenticationMethod="Basic, Fba">https://exch02.xx.xx.intern/owa/</OWAUrl>
<OWAUrl AuthenticationMethod="Basic, Fba">https://exchowa.xx.xx.intern/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://exch02.xx.xx.intern/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
<External>
<OWAUrl AuthenticationMethod="Fba">https://exchange.xx.de/owa/</OWAUrl>
<Protocol>
<Type>EXPR</Type>
<ASUrl>https://exchange.xx.de/EWS/Exchange.asmx</ASUrl>
</Protocol>
</External>
</Protocol>
<AlternativeMailbox>
<Type>Delegate</Type>
<DisplayName>Quarantäne User</DisplayName>
<LegacyDN>/o=xx GmbH/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=useracadb038</LegacyDN>
<Server>EXCH01.xx.xx.intern</Server>
</AlternativeMailbox>
<AlternativeMailbox>
<Type>Delegate</Type>
<DisplayName>Administrator</DisplayName>
<LegacyDN>/o=xx GmbH/ou=HARDWARE/cn=Recipients/cn=Administrator</LegacyDN>
<Server>EXCH02.xx.xx.intern</Server>
</AlternativeMailbox>
</Account>
</Response>
</Autodiscover>
Hier ein
Und okay, ich habe mir das Ganze nun mal bei der Auto-Ermittlung angeschaut. Es tritt nun nach einer Woche bei ca 3 -5 Personen erneut auf und danach bei jedem Start von Outlook. Hat das zufällig mit den internal Namen noch zu tun?
Hier ein Ausschnitt der XML:
<?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>Max Muster</DisplayName>
<LegacyDN>/o=xx GmbH/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Max Muster130</LegacyDN>
<AutoDiscoverSMTPAddress>Max.Muster@xx.com</AutoDiscoverSMTPAddress>
<DeploymentId>fa62e35b-64a9-4629-98e0-24101d0b721c</DeploymentId>
</User>
<Account>
<AccountType>email</AccountType>
<Action>settings</Action>
<Protocol>
<Type>EXCH</Type>
<Server>EXCH02.xx.xx.intern</Server>
<ServerDN>/o=xx GmbH/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCH02</ServerDN>
<ServerVersion>738180DA</ServerVersion>
<MdbDN>/o=xx GmbH/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCH02/cn=Microsoft Private MDB</MdbDN>
<PublicFolderServer>EXCH02.xx.xx.intern</PublicFolderServer>
<AD>DC02.xx.xx.intern</AD>
<ASUrl>https://exch02.xx.xx.intern/EWS/Exchange.asmx</ASUrl>
<EwsUrl>https://exch02.xx.xx.intern/EWS/Exchange.asmx</EwsUrl>
<EcpUrl>https://exch02.xx.xx.intern/ecp/</EcpUrl>
<EcpUrl-um>?p=customize/voicemail.aspx&exsvurl=1</EcpUrl-um>
<EcpUrl-aggr>?p=personalsettings/EmailSubscriptions.slab&exsvurl=1</EcpUrl-aggr>
<EcpUrl-mt>PersonalSettings/DeliveryReport.aspx?exsvurl=1&IsOWA=<IsOWA>&MsgID=<MsgID>&Mbx=<Mbx></EcpUrl-mt>
<EcpUrl-ret>?p=organize/retentionpolicytags.slab&exsvurl=1</EcpUrl-ret>
<EcpUrl-sms>?p=sms/textmessaging.slab&exsvurl=1</EcpUrl-sms>
<OOFUrl>https://exch02.xx.xx.intern/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://exch02.xx.xx.intern/EWS/UM2007Legacy.asmx</UMUrl>
<OABUrl>http://exch02.xx.xx.intern/OAB/9170d1ea-d70c-474e-b172-f4dea58ed576/</OABUrl>
</Protocol>
<Protocol>
<Type>EXPR</Type>
<Server>exchange.xx.de</Server>
<SSL>On</SSL>
<AuthPackage>Ntlm</AuthPackage>
<ASUrl>https://exchange.xx.de/EWS/Exchange.asmx</ASUrl>
<EwsUrl>https://exchange.xx.de/EWS/Exchange.asmx</EwsUrl>
<OOFUrl>https://exchange.xx.de/EWS/Exchange.asmx</OOFUrl>
<UMUrl>https://exchange.xx.de/EWS/UM2007Legacy.asmx</UMUrl>
<CertPrincipalName>none</CertPrincipalName>
</Protocol>
<Protocol>
<Type>WEB</Type>
<Internal>
<OWAUrl AuthenticationMethod="Basic, Fba">https://exch01.xx.xx.intern/owa/</OWAUrl>
<OWAUrl AuthenticationMethod="Basic, Fba">https://exch02.xx.xx.intern/owa/</OWAUrl>
<OWAUrl AuthenticationMethod="Basic, Fba">https://exchowa.xx.xx.intern/owa/</OWAUrl>
<Protocol>
<Type>EXCH</Type>
<ASUrl>https://exch02.xx.xx.intern/EWS/Exchange.asmx</ASUrl>
</Protocol>
</Internal>
<External>
<OWAUrl AuthenticationMethod="Fba">https://exchange.xx.de/owa/</OWAUrl>
<Protocol>
<Type>EXPR</Type>
<ASUrl>https://exchange.xx.de/EWS/Exchange.asmx</ASUrl>
</Protocol>
</External>
</Protocol>
<AlternativeMailbox>
<Type>Delegate</Type>
<DisplayName>Quarantäne User</DisplayName>
<LegacyDN>/o=xx GmbH/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=useracadb038</LegacyDN>
<Server>EXCH01.xx.xx.intern</Server>
</AlternativeMailbox>
<AlternativeMailbox>
<Type>Delegate</Type>
<DisplayName>Administrator</DisplayName>
<LegacyDN>/o=xx GmbH/ou=HARDWARE/cn=Recipients/cn=Administrator</LegacyDN>
<Server>EXCH02.xx.xx.intern</Server>
</AlternativeMailbox>
</Account>
</Response>
</Autodiscover>
Hier ein
