18.01.2017

7994

Test-ActiveSyncConnectivity Error nach neuem Zertifikat

Hallo zusammen,

folgendes Problem stellt sich seit gestern bei meinem Exchange 2013 CU15 auf einem Windows Server 2012R2 dar:

Im Zuge der Einbindung eines neuen SAN-Zertifikats von einer gültigen Zertifizierungsstelle und der Einrichtung von Autodiscover usw. bekomme ich beim Cmdlet Test-ActiveSyncConnectivity folgende Ausgabe (und damit Fehlermeldung) zurück:

RunspaceId : c8ce1e04-5e07-4741-83ed-9e60f0d8dd2f
LocalSite : Sitename
SecureAccess : True
VirtualDirectoryName :
Url :
UrlType : Unknown
Port : 0
ConnectionType : Plaintext
ClientAccessServerShortName : mail
LocalSiteShortName : Sitename
ClientAccessServer : server.domain.local
Scenario : Optionen
ScenarioDescription : Geben Sie einen Befehl vom Typ "HTTP OPTIONS" aus, um die Protokollversion von Exchange
ActiveSync abzurufen.
PerformanceCounterName : DirectPush Latency
Result : Fehler
Error : [System.Net.WebException]: Die zugrunde liegende Verbindung wurde geschlossen: Für den
geschützten SSL/TLS-Kanal konnte keine Vertrauensstellung hergestellt werden.. Interner
Fehler [System.Security.Authentication.AuthenticationException]: Das Remotezertifikat
ist laut Validierungsverfahren ungültig.
UserName : extest_8ced6128b3394
StartTime : 18.01.2017 11:45:35
Latency : -00:00:01
EventType : Error
LatencyInMillisecondsString :
Identity :
IsValid : True
ObjectState : New

Die Funktionalität aller Services ist komplett gegeben, die Anbindung der Clients und auch Mobile Devices per ActiveSync/Autodiscover läuft wunderbar. Lediglich dieser Fehler stört mich in meiner Überwachung und ich kann beim besten Willen nichts finden, wie ich das aus der Welt schaffen kann. Eventuell hat einer von euch noch einen Lösungsvorschlag?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 326732

Url: https://administrator.de/forum/test-activesyncconnectivity-error-nach-neuem-zertifikat-326732.html

Ausgedruckt am: 07.04.2025 um 15:04 Uhr

22 Kommentare

Neuester Kommentar

ClientAccessServer : server.domain.local

Ihr habt ein Zertifikat mit einer nicht öffentlichen Domain? Halte ich für unwahrscheinlich

Prüfe ob wirklich alle URLs stimmen
Powershell: Konfigurieren der internen und externen URLs von Exchange Server 2013, 2016

Gruß mik

Natürlich nicht - ist nur unkenntlich gemacht. Es ist ein SAN-Zertifikat welches autodiscover.domain.de und mail.domain.de beinhaltet.

Mit exakt diesem Script habe ich die URLs gesetzt. Siehe Zeile 56 bis 59:

Set-ClientAccessService $ExchangeServer -AutodiscoverServiceInternalUri https://$InternalFQDN/Autodiscover/Autodiscover.xml
Set-ClientAccessServer $ExchangeServer -AutodiscoverServiceInternalUri https://$InternalFQDN/Autodiscover/Autodiscover.xml

Es wird also für den CAS die internal URL mit dem internen FQDN besetzt. Deswegen steht wohl auch im Test-ActiveSyncConnectivity der mail.domain.local (interner FQDN). Ob das nun so richtig ist, bin ich mir ehrlich gesagt nicht sicher - denn für alle anderen Virtual Directories wird ja sowohl die interne als die externe URL mit der öffentliche Domain beschrieben.

Scheint mir irgendwie etwas paradox. Kannst du etwas dazu sagen?

Zitat von @Driphex:
Mit exakt diesem Script habe ich die URLs gesetzt. Siehe Zeile 56 bis 59:

Set-ClientAccessService $ExchangeServer -AutodiscoverServiceInternalUri https://$InternalFQDN/Autodiscover/Autodiscover.xml
Set-ClientAccessServer $ExchangeServer -AutodiscoverServiceInternalUri https://$InternalFQDN/Autodiscover/Autodiscover.xml

Das sind beides die selben Befehle, nur der letztere ist als depricated gekennzeichnet, das erstere der Nachfolger.

Wenn du hier die interne Domain angegeben hast hast du einen Fehler gemacht.
Denn wenn du intern eine andere URL setzt (*.local )als du im Zertifikat nutzt hast du es falsch konfiguriert.
Wenn interne und externe URLs unterschiedlich konfiguriert werden müssen auch alle genutzten Domains im Zertifikat auftauchen! Ansonsten solltest du beide auf die externe Domain konfigurieren und intern SplitDNS verwenden.

Scheint mir irgendwie etwas paradox. Kannst du etwas dazu sagen?

Ist aber so OK.

Stimmt, der ClientAccessService existiert scheinbar unter 2013 nicht.

Naja, die Sache mit der .local-Domain habe ich so vom Vorgänger übernommen - hätte ich persönlich auch mit der externen Domain gemacht. Wie dem auch sei, ich denke, ich hab einfach den Wald vor lauter Bäumen nicht gesehen. Klar ist natürlich, dass nichts validiert werden kann, was nicht im Zertifikat auftaucht.

Ich setze jetzt die URLs, die ich mit .local gesetzt habe nochmal mit .de - im DNS hab ich Zonen die auf das gleiche Ziel im internen Subnetz verweisen, sollte somit kein Problem machen.

Ich teste das mal und berichte wieder - danke für den Hinweis!

Da bin ich auch schon wieder: Skript nun mit entsprechend .de ausgeführt, passt soweit.
Test-ActiveSyncConnectivity wieder durchgeführt - gleiche Fehlermeldung. Der CAS steht immer noch auf dem internen FQDN - das sollte aber so richtig sein.

Server einmal durchstarten.

Mal sehen, ob ich meine User mal kurz dazu bewegen kann für 2 Minuten auf Ihr Outlook zu verzichten... Melde mich wieder.

War erfolgreich was meine User angeht, allerdings weniger was den Exchange angeht. Nach dem Reboot keine veränderten Verhältnisse. Noch andere Ideen?

Exchange Backend-Website im IIS hat das richtige Zertifikat zugewiesen?

Kurz und knapp: ja!

Was sagt das Ergebnis von
https://testconnectivity.microsoft.com ?
Poste auch die Zertifikatsdetails wie Hashing etc. pp..
Lass uns nicht dumm sterben

Ich lass hier einfach mal das exportierte HTML-File da: https://kundl-my.sharepoint.com/personal/p_wirth_kl-electronics_de/_layo ...

Ich vermute mal das kommt wegen dem

Analyzing the certificate chains for compatibility problems with Windows Phone devices.
Potential compatibility problems were identified with some versions of Windows Phone.
Tell me more about this issue and how to resolve it
Additional Details
The certificate is trusted on Windows Phone 7 and later versions. Devices running Windows Mobile 6.0 or earlier may not be able to sync. Root = CN=GeoTrust Primary Certification Authority - G3, OU=(c) 2008 GeoTrust Inc. - For authorized use only, O=GeoTrust Inc., C=US.

Wenn alles läuft kannst du es vermutlich ignorieren, das wird dann einfach am Zertifikat(CA) liegen was für die Testroutine von Test-Auto... nicht vollständig koscher ist.

Ist mir auch bereits aufgefallen. Nach eigener Recherche ist das aber ein reiner Hinweis der tatsächlich nur auf Windows Phones hindeutet - die setzten wir im Unternehmen nicht ein und schon gar nicht in so einer alten Version.

Und wie bereits gesagt funktioniert der Autodiscover/EAS ja einwandfrei. Ignorieren möchte ich das dennoch aber nicht unbedingt... Ich schätze, ich öffne mal bei Microsoft nen Support-Case - haben da glücklicherweise durch den Partnerstatus ein paar Calls frei.

Falls du noch eine Idee haben solltest, lass es mich wissen - ansonsten melde ich mich wieder, wenn ich von MS was gehört habe.

Falls du noch eine Idee haben solltest, lass es mich wissen

Och das kann noch eine ganze Menge sein, aber wir kennen hier die Vorgeschichte der Kiste leider nicht, da wird das ein Katz und Mausspiel

Ich könnte schon alle möglichen Informationen zur Verfügung stellen, schätze aber dass wir wohl so effektiv nicht weiter kommen werden. Das interessante ist eben, dass der Test-ActiveSyncConnectivity vor dem einspielen des neuen Zertifikats ohne Fehlermeldung durchlief. Vorher war eben ein Self-Signed Cert drin, mit allen möglichen lokalen FQDNs als SANs. Das kann ich natürlich beim Drittanbieter-Cert nicht machen... Ich vermute aber wohl, dass hier genau das Problem liegt. Der FQDN des Servers stimmt eben nicht mit der öffentlichen Domain überein, daher wird die Validierung fehlschlagen. Wenn dem so ist, hab ich eigentlich nur drei Optionen:
a) ignorieren und damit abfinden (da ja keine Einschränkung besteht)
b) MS kontaktieren und hoffen, dass die können zaubern
c) lokale Domain der öffentlichen Domain angleichen, was wohl eine ziemliche Schweinerei werden würde

Ich werde aber trotzdem nicht den Gedanken los, dass das nur ein Überbleibsel aus einem vorherigen Test ist, der während einer Fehlkonfiguration durchgeführt wurde. Mit einer einfachen bereinigen des EventLogs wird das wohl nicht erledigt sein... Meinungen dazu?

Ich würde mal andere Optionen beim Aufruf benutzen

Test-ActiveSyncConnectivity -MailboxCredential (Get-Credential) -UseAutodiscoverForClientAccessServer

Hie steht noch mehr
http://practical365.com/exchange-server/activesync-policies-cause-test- ...

Der Test mit echten Credentials (bspw. meinen) bringt mir den gleichen Fehler. Die AccessStates der Devices wie in dem Link beschrieben habe ich auch geprüft, stehen alle auf Allowed. Eine Möglichkeit wäre es noch, mit -TrustAnySSLCertificate die Abfrage zu starten - dann meckert er logischerweise nicht. Ist aber irgendwie nicht Sinn der Sache... Ich versuche mal, den Server intern unter dem FQDN mit .de erreichbar zu machen.

Ich versuche mal, den Server intern unter dem FQDN mit .de erreichbar zu machen.

Öhm das hatte ich doch oben schon vorausgesetzt.

Naja, im DNS gibts eine Zone die intern den Server so auflöst, also maximal ein Workaround. Bin jetzt noch auf was anderes gestoßen: hab mal mit netdom einen zweiten Computernamen hinzugefügt, den als primär gesetzt und StrictNameChecking disabled. Reboot ist erforderlich, versuche das im Laufe des Tages zu machen und reporte dann wieder.

Naja, im DNS gibts eine Zone die intern den Server so auflöst, also maximal ein Workaround.

Das ist kein Workaround, Split-Brain-DNS ist gängige Praxis wenn man intern nicht öffentliche Domain-Namen verwendet.
Lesen:
https://www.frankysweb.de/exchange-2016-zertifikate-konfigurieren/
https://www.frankysweb.de/exchange-2016-zertifikate-konfigurieren-teil-2 ...
https://www.frankysweb.de/exchange-2016-zertifikate-konfigurieren-teil-3 ...

hab mal mit netdom einen zweiten Computernamen hinzugefügt

Nö, das wird dir nichts bringen.

Ich würde mal per netsh http show sslcert nachsehen ob sich da noch ein Zertifikat im Speicher tummelt was da nichts mehr verloren hat.

Zitat von @131381:

Naja, im DNS gibts eine Zone die intern den Server so auflöst, also maximal ein Workaround.

Ich muss ganz ehrlich sagen, dass ich das erste mal von SplitDNS im Zusammenhang mit Office365 gehört habe und noch nicht so recht dahinter gestiegen bin. Hab mich mal eben eingelesen - nun weiß ich auch, dass ich das bereits ohne es zu wissen angewandt habe.

Ich würde mal per netsh http show sslcert nachsehen ob sich da noch ein Zertifikat im Speicher tummelt was da nichts mehr verloren hat.

Alles sauber, nur das korrekte Cert auf der Default Web Site und dem Exchange Back End.

Edit: Die Links habe ich mir auch mal durchgelesen. Exakt dieselbe Konfiguration ist vorhanden - rumpfuschen wäre ja quatsch!

Ich habe das ganze jetzt für mich Ad acta gelegt - ist ja nicht so, als ob ich ein Admin wäre, der sich langweilt... Damit es mich nicht mehr stört, hab ich im Monitoring zum Test-ActiveSyncConnectivity noch -TrustAnySSLCertificate hinzugefügt. Normalerweise fummel ich an sowas, bis es gelöst ist - in dem Fall lass ich das mal hinter mir, habe ja keine Einschränkung in der Funktion.

Trotzdem danke ich vielmals für deine Hilfe!

gelöst Frage Microsoft Exchange Server

Mehr von Driphex

Windows Server 2012 R2 reboot nach Zugriff über HTTPDriphex - 2 Kommentare

Heiß diskutiert