Fehler beim setzen der Abwesenheitsnotiz in Outlook - Server zurzeit nicht verfügbar

[ehcm 0]

Hallo zusammen,

 

bei uns tritt zurzeit bei einzelnen Postfächern folgende Fehlermeldung auf, beim Versuch in Outlook eine automatische Antwort zu erstellen:

 

Das Problem tritt nur in Outlook auf. Ein erstellen der automatischen Antwort in OWA und über Powershell ist auch für die betroffenen Postfächer möglich.

Bis jetzt kann ich leider noch kein Schema feststellen, welche Postfächer betroffen sind.

Es ist egal...

...auf welcher Datenbank sie liegen

...über welchen der beiden Exchangeserver zugegriffen wird

...welcher Arbeitsplatz/Outlook verwendet wird

 

Folgendes habe ich bereits getestet:

- Neueinbindung des Postfachs

- Zugriff auf https://exchange.domain.com/ews/exchange.asmx ohne Zertifikatsmeldung möglich. Hier erscheint direkt die Login-Abfrage.

- Reduzierung der zugehörigen AD-Gruppen des betroffenen Benutzers

- Erhöhung des Wertes HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\HTTP\Parameters "MaxFieldLength" und "MaxRequestBytes" von "65534" auf "65536" inkl. Neustart der Server

 

 

Zur Umgebung:

- Kemp-Loadbalancer mit der Version 7.1.34.1.12802

- 2x Exchange 2013 (Build 1367.3) in der DAG

- Outlook Standard 2013

 

 

 

Habt ihr Ideen, was ich noch testen kann, um dieses Problem zu lösen?

 

Viele Grüße

ehcm

[magheinz 110]

Hat das schon mal funktioniert? Laufen alle Exchangedienste? 

[ehcm 0]

Exchange Dienste laufen alle:

 

Auch bei Get-ServerComponentState schaut alles gut aus.

 

Das Ganze hat schon funktioniert. Allerdings kann ich nicht sagen, seit wann genau es nicht mehr funktioniert.

[Nobbyaushb 1.471]

In der Regel deutet das auf nicht funktionierendes Autodiscover hin.

 

Was spricht der Support von Kemp dazu?

 

Kannst ja mal testweise an einem Client einen Exchange in der Hosts eintragen, ist es weg, ist der Kemp schuld.

[ehcm 0]

Ich habe den Hosts-Eintrag testweise mal angepasst.

Die Fehlermeldung bleibt die Gleiche, auch nach einem /flushdns und einem Rechnerneustart.

Zusätzlich erhalte ich auch nach der Installation des Self-Signed Zertifikats einen Sicherheitshinweis:

 

 

Den Kemp Support habe ich bis jetzt hierzu noch nicht ins Boot geholt.

[Nobbyaushb 1.471]

Self-Signed Zertifikate sind nicht supportet.

[ehcm 0]

Das heißt, ich sollte am besten das *.domain.com Zertifikat vom Loadbalancer auch auf beiden Exchangeservern einspielen?

[NorbertFe 2.035]

Immer diese Wildcardzertifikate ;)

[ehcm 0]

Wäre es besser eigene Zertifikate für die einzelnen Server zu kaufen? Bzw. welche Vorteile bringt das?

[NorbertFe 2.035]

Nein. wieviele Exchangeserver hast du, wie sind dort die URLs konfiguriert?

[ehcm 0]

Es handelt sich um 2 Exchange-Server in der DAG.

 

Die URLs sind sowohl für intern, als auch für extern immer nach diesem Schema aufgebaut:

https://exchange.domain.com/ecp

 

exchange.domain.com und autodiscover.domain.com werden vom DNS aufgelöst und verweisen auf den Loadbalancer.

[gelöscht 0]

vor einer Stunde schrieb Nobbyaushb:

Self-Signed Zertifikate sind nicht supportet.

Unsinn. Natürlich kann ein x509 Zertifikat von einer eigenen CA, openSSL usw. grundsätzlich verwendet werden. Das ist auch der Default Zustand nach der Installation von Exchange seit 2007. Weiterhin wird in dem Screenshot der CN angemeckert.

 

Zum Problem. Wenn Du das Problem reproduzierst. Was steht dazu im IISlog der Server? 400, 401,500?

Kannst Du ein Fiddler Trace (mit SSL decryption) für einen der betroffenen User machen? Evtl. findest Du sowas wie:  “HTTP Error 400. The size of the request headers is too long”

Funktioniert Autodiscover für diesen User? Auch davon ein Fiddler Trace?

Hast Du Layer4 oder Layer7 am LoadBalancer? SSL Bridging?

 

ASR

[NorbertFe 2.035]

vor 10 Minuten schrieb ASR:

Natürlich kann ein x509 Zertifikat von einer eigenen CA

Das wäre auch nicht selfsigned. ;)

[Nobbyaushb 1.471]

vor 7 Minuten schrieb NorbertFe:

Das wäre auch nicht selfsigned. ;)

Eben

[gelöscht 0]

vor 1 Stunde schrieb Nobbyaushb:

Eben

Nein? 

Wenn ich es mit New-ExchangeCertificate erzeuge ist es auch nicht "selfsigned", dann macht es das CommandLet. 

 

Der Unterschied zu einem Third-Party CA Signed ist die Vertrauenswürdigkeit. Alles was ich selbst mache, sei es eine CA installieren, mit dem CMDLet, OpenSSL ist grundsätzlich nicht vertraueneswürdig, eben selbst gebastelt.

 

Supported sind grundsätzlich alle Typen von Zertifikaten die dem hier entsprechen: https://docs.microsoft.com/en-us/Exchange/architecture/client-access/certificates?view=exchserver-2019

Das schließt explizit "Self-Signed", wie immer man das definieren möchte mit ein.

 

ASR