Jump to content
ehcm

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

Recommended Posts

Hallo zusammen,

 

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

image.png.cd51e7cf3ea258457e324b836a38c973.png

 

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

Share this post


Link to post
Share on other sites

Exchange Dienste laufen alle:

image.png.f08f2d4997e589560e4d8028a80dbb76.png

 

Auch bei Get-ServerComponentState schaut alles gut aus.

image.png.11991cd50edef96cb26dcb842cd59219.png

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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:

image.png.e6d92f699a27d263ddf6b8788b38c070.png

 

 

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Werbepartner:



×
×
  • Create New...