adrian.m
Goto Top

Nach neuem Zertifikat Outlook Fehler (Exchange 2010)

Hallo zusammen,

ich hoffe, dass mir hier jemand weiterhelfen kann...
Habe bei der Suche (administrator.de, Microsoft Technet und Google) leider nichts passendes gefunden.

Wir haben eine neue Domainadresse in unserer Firma und die Website ist auch erfolgreich umgezogen.
Nun ist auch das neues Zertifikat für unsere externen Exchange-Dienste da, damit OWA, etc. auch mit der neuen Domain funktioniert.

Die Eintragung des neuen Exchange-Zertifikates hat auch reibungslos geklappt, nur leider bekommen die Outlook-User folgende Fehler ausgegeben:

"Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Website überein."

ex
autodiscover

Das oben ausgegraute ist unsere alte Adresse, aber bei "Zertifikat anzeigen" ist das das neue Zertifikat hinterlegt. (So wie es auch sein soll.)
Also irgendwo auf dem Exchange muss noch die alte Adresse hinterlegt sein.

Diese Schritte wurden durchgeführt:
  • In der "Serverkonfiguration" --> "Clientzugriff" alle Elemente auf die neue Externe Adress-URL umgestellt (also den alten Hostname durch den neuen ersetzt)
  • In der Exchange Verwaltungsshell die AutoDiscoverServiceInternalUri auf den externen FQDN geändert, damit es dem ausgestellten Zertifikat entspricht
exchmms

Ich habe auch mal den Remote Connectivity Analyzer von Microsoft für Autodiscovery gemacht und der Test wurde mit Warnungen abgeschlossen:
autodiscover_post
autodiscover_as
Die Frage ist halt, ob dies auch das Problem fixt oder nur allgemeine Warnhinweise sind...

Leider habe ich solch ein "Umzug" noch nie vorher gemacht und weiß deshalb nicht genau, wo ich noch etwas eintragen/abändern muss, damit alles klappt, wie es sein sollte...

Schon mal vielen Dank im voraus!!

LG
Adrian

PS: Der Exchange funktionieren einwandfrei und der Versand der Mails, sowie OWA und externe Dienste sind verfügbar. Lediglich diese blöde Zertifikatsfehlermeldung kommt...

Content-Key: 303840

Url: https://administrator.de/contentid/303840

Printed on: April 19, 2024 at 14:04 o'clock

Member: atomique
atomique May 07, 2016 at 18:48:32 (UTC)
Goto Top
Hallo Adrian,

ich bin mir nicht ganz sicher ob es zur Lösung deines Problems beiträgt, aber in deinem letzten Screenshot steht etwas von "Update Root Certificate Feature is not enabled" - Hast du das mal überprüft?

--> Die hier laden einfach das "neue" Zertifikat über Windows Update nach.

Gruß Atomique
Member: Adrian.M
Adrian.M May 09, 2016 at 07:36:21 (UTC)
Goto Top
Danke für die Antwort, aber leider hat das auch nicht funktioniert.
Member: Dani
Solution Dani May 09, 2016 at 08:44:21 (UTC)
Goto Top
Moin,
Die Eintragung des neuen Exchange-Zertifikates hat auch reibungslos geklappt, nur leider bekommen die Outlook-User folgende Fehler ausgegeben:
Erscheint die Meldung bei Clients welche im LAN stehen oder bei Outlook Anywhere über das Internet?

In deinem Screenshot sehe ich einmal ex.domain.de und autodiscover.domain.de. Sind die beiden Domains im Zertifikat aufgeführt oder handelt es sich um ein Wildcard-Zertifikat?

Diese Schritte wurden durchgeführt:
Du kannst noch die Werte von
  • Get-ClientAccessServer
  • Get-WebServicesVirtualDirectory
  • Get-OABVirtualDirectory


Gruß,
Dani
Member: Adrian.M
Adrian.M May 10, 2016 at 14:00:01 (UTC)
Goto Top
Servus,

Erscheint die Meldung bei Clients welche im LAN stehen oder bei Outlook Anywhere über das Internet?
Die Meldung erscheint nur bei den lokalen Clients, welche im LAN sind.

Du kannst noch die Werte von
  • Get-ClientAccessServer
  • Get-WebServicesVirtualDirectory
  • Get-OABVirtualDirectory
Das passt auch. Also die richtige Adresse ist dort eingetragen.

1
Member: Dani
Dani May 10, 2016 at 14:52:23 (UTC)
Goto Top
Moin,
In deinem Screenshot sehe ich einmal ex.domain.de und autodiscover.domain.de. Sind die beiden Domains im Zertifikat aufgeführt oder handelt es sich um ein Wildcard-Zertifikat?
Was ist mit dieser Frage...


Gruß,
Dani
Member: Adrian.M
Adrian.M May 10, 2016 at 15:05:29 (UTC)
Goto Top
In deinem Screenshot sehe ich einmal ex.domain.de und autodiscover.domain.de. Sind die beiden Domains im Zertifikat aufgeführt oder handelt es sich um ein Wildcard-Zertifikat?
Was ist mit dieser Frage...

Sorry, hab ich überlesen face-smile

Beide Domains sind im Zertifikat mir drin.
CN = ex.domain.de und zusätzlich stehen noch 3 weitere als SAN mit im Zertifikat. Unter anderem auch autodiscover.domain.de.
Also das sollte auch passen...
Member: Dani
Dani May 10, 2016 at 15:13:08 (UTC)
Goto Top
Ein nslookup auf die genannten (Sub)Domains geben die richtige IP-Adresse zurück? Nicht das du evtl. beim Zugriff aus dem Internet ein ReverseProxy im Einsatz hast, welcher auf andere Domains hört.


Gruß,
Dani
Member: Adrian.M
Adrian.M May 10, 2016 at 15:28:40 (UTC)
Goto Top
Ein nslookup auf die genannten (Sub)Domains geben die richtige IP-Adresse zurück? Nicht das du evtl. beim Zugriff aus dem Internet ein ReverseProxy im Einsatz hast, welcher auf andere Domains hört.

Sollte auch passen.
*.8.127 ist unser DomainController und *.8.112 ist der Exchange...

capture
...das "Non-authoritative" steht doch nur dort, weil es nicht als CN, sondern als SAN eingetragen ist, oder?
Member: Dani
Solution Dani May 10, 2016 at 15:35:23 (UTC)
Goto Top
...das "Non-authoritative" steht doch nur dort, weil es nicht als CN, sondern als SAN eingetragen ist, oder?
Glaub ich kaum... face-wink Wenn du die Abfrage an einem Client, der in der Domäne ist, ausgeführt hast sieht die Abfrage standardmäßig so aus:
C:\>nslookup exchange.x.y.z.de
Server:  dc05.izbw.de
Address:  10.x.y.72

Name:    exchange02.x.y.z.de
Address:  10.x.x.72
Aliases:  exchange.x.y.z.de

C:\>
Somit gehe ich davon aus, dass die Konfiguration am DNS-Server auf dem DC fehlerhaft ist. Existiert für *.intern und *.domain.de jeweils eine Forward-Zone und für den Bereich 192.168.8.0/24 eine ReverseLookup-Zone? Ist an dem ausführenden Client als DNS-Server der DC angegeben oder gibt ein Router? Dann wiederrum würde die Ausgabe Sinn machen.


Gruß,
Dani
Member: Adrian.M
Adrian.M May 13, 2016 at 13:49:23 (UTC)
Goto Top
Somit gehe ich davon aus, dass die Konfiguration am DNS-Server auf dem DC fehlerhaft ist. Existiert für *.intern und *.domain.de jeweils eine Forward-Zone und für den Bereich 192.168.8.0/24 eine ReverseLookup-Zone? Ist an dem ausführenden Client als DNS-Server der DC angegeben oder gibt ein Router? Dann wiederrum würde die Ausgabe Sinn machen.

Wie du vermutet hast, war nur für ex.domain.de eine Forward-Zone eingerichtet. Habe es für die SAN noch zusätzlich eingetragen...
Eine ReverseLookup-Zone existert schon für diesen Bereich.
Als DNS ist auf dem ausführenden Client unser DC und als sekundärer zusätzlich noch unsere Sophos-Firewall eingetragen, auf welcher die DC (primär und Backup) hinterlegt sind...

Auch nach der Eintragung im DNS (s.Bild) tritt der Fehler weiterhin auf...
nslookup
Member: Dani
Solution Dani May 13, 2016 at 15:11:28 (UTC)
Goto Top
Moin,
somit bleibt aus meiner Sicht nur der Weg über Wireshark.

1) Sharki starten
2) Outlook öffnen
3) Sobald die Meldung in Outlook escheint, Sharki stoppen
4) Protokoll nach Domains durchsuchen, welches den Fehler verursacht.


Gruß,
Dani
Mitglied: 129148
129148 May 13, 2016 updated at 15:24:03 (UTC)
Goto Top
Hi,
wurde das vorhandene Outlook-Profil auf den neuen EX nur umgestellt oder wurde ein absolut neues Outlook Profil angelegt ?
Es ist nämlich so das Outlook nur bei einer Umstellung intern Verweise auf den alten Domain-Namen beibehält welche dann dieses krumme Verhalten provozieren können.

Also bei Domain-Namenwechsel solltest du dringend das Outlook-Profil resetten bzw. neu anlegen.
Member: YotYot
YotYot Jul 21, 2016 at 12:34:29 (UTC)
Goto Top
Moin!

Ist ja noch nicht sooo lange her. Gibt's hier schon was neues? Ich hab' nämlich das gleiche Problem, bin sämtliche Tips hier auch nochmal durchgegangen und behelfe mir im Moment damit, dass ich per GPO die Abfrage des Zertifikats verweigere, weil es reichlich egal ist, ob ich ja oder nein oder peng antworte.

In dem Zusammenhang ist mir aufgefallen: auch, wenn ich ein neues Outlook-Profil anlege und sogar dann, wenn ich das alte lösche, mich vom Terminalserver abmelde, wieder anmelde und erst dann ein neues Profil anlege, bleiben die alten Informationen enthalten, es gibt lediglich in der Registry einen Eintrag darüber, dass das Profil als gelöscht gilt. Entferne ich den Schlüssel, ist das Profil wieder da. Also habe ich mal manuell so richtig gelöscht und sogar das ganze Benutzerprofil schon zum Teufel gejagt. Immer dasselbe.

Und im Zusammenhang damit auch noch folgendes Problem: wenn ich mein Windows-Passwort wechseln will, erklärt mir der Server: "Die Sicherheitsdatenbank auf dem Server enthält kein Comupterkonto für diese Arbeitsstationsvertrauensstellung". Eine Passwortänderung der User ist also derzeit nur administrativ möglich.

Weiß da jemand was dazu?

Y.
Member: Adrian.M
Adrian.M Sep 19, 2016 at 14:22:28 (UTC)
Goto Top
Also der Fehler hat sich mehr oder weniger von selbst gelöst.

Ich habe wie "Dani" schon mal gesagt hat mit Wireshark mitgesnifft und leider auch keine alte Domain im Netzwerk erkennen können. Dort war immer nur die neue zu sehen.
Dann habe ich wie "129148" meinte das komplette Outlook-Profil gelöscht und neu erstellt. Leider auch keine Veränderung.

Vor ein paar Wochen musste ich dann nachts wegen Sicherheitsupdates einen Neustart unseres Exchanges machen und seit dem tritt der Fehler nicht mehr auf.

Also entweder scheint Windows das in irgendwelchen Einträgen erst nach einem reboot zu ändern oder unser Exchange hat das nicht richtig gegriffen...
Zu mindestens funktioniert es jetzt und keiner unserer Clients bekommt mehr die Meldung.

Ich werde noch mal tiefer graben und schauen woran es lag. Falls ich etwas raus bekomme werde ich hier natürlich berichten!!

Danke an alle, welche versucht haben eine Lösung zu finden und mir hilfreiche Antworten gegeben haben! face-smile

@YotYot: Ich vermute, dass es sich bei dir um ein anderes Problem handelt, da du von Terminalserver und PW Änderungsproblemen sprichst... Hierzu ist mehr zu beachten als bei einem "klassischen" WSBS-System.