31.08.2018, aktualisiert um 15:45:18 Uhr

2415

Exchange 2016 Abwesenheitsassistent - Performanceprobleme?

Moin.

Ich würde mich sehr freuen, wenn der eine oder andere von Euch, der ebenso Outlook 2016 mit der letzten Version von Exchange nutzt (2016 CU9 oder CU10), folgendes nachstellt:

Outlook 2016 öffnen, Abwesenheitsassistenten starten (->Datei -> automatische Antworten).

Ca. seit CU9 kommt es da bei uns bei allen Nutzern oft zu seltsamen Verzögerungen. Mal geht das Ding sofort auf, mal wartet er bis zu satten 30 Sekunden. Ich habe nicht die leiseste Ahnung, woran das liegt und kann auch keine Ressourcenengpässe am Exchange erkennen. In Tests konnte ich herausfinden, dass es selbst dann passiert, wenn ich der einzige Nutzer bin, der Outlook offen hat.

Ich betone, es passiert nur manchmal (etwa jedes 2. Mal) und die Verzögerungen variieren auch stark. Abgesehen davon sind keine Performanceprobleme in Outlook zu erkennen.

Wie ist das bei Euch?

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

Content-ID: 385091

Url: https://administrator.de/forum/exchange-2016-abwesenheitsassistent-performanceprobleme-385091.html

Ausgedruckt am: 14.04.2025 um 19:04 Uhr

28 Kommentare

Neuester Kommentar

Da wir weder Outlook 2016 noch Exchange CU9 haben, kann ich dazu keine Erfahrungen nennen.
Aber ich würde Vorschlagen den netzwerkverkehr mal bei dem Vogang mitzuschneiden - weil vom 2010er Outlook Client kenne ich es das er gerne bullshit macht bei bestimmten Userinteraktionen (z.B. ohne Grund mal wieder autodiscovered (und dabei alle möglichkeiten durchprobiert) und dann ewig timeoutet und irgendwann weitermacht).

Falls du nichts auffäliges siehst, kann man zumindest den Fehler so eingrenzen auf den Server

Ich kann auch nur mit Exchange 2013 dienen aber auch ich habe die Erfahrung gemacht das ein fertig konfiguriertes OL hervorragend läuft aber der Abwesenheitsassistent beim Aufruf ein Autodiscover macht. Hat sich da was bei euch geändert?

Servus DWW,
hier im gleichen Setup im LAB keine solchen Probleme feststellbar.
Wie die anderen schon angedeutet haben, prüfe die Exchange-Webservice Dienste (EWS) und URL fürs Autodiscover auf flüssige Antworten des IIS. Die OOF Funktion setzt beim Autodiscover auf die EWS URL (https://<deinfqdn>/EWS/Exchange.asmx). Zusätzlich am Client auch noch ProcMon mitlaufen lassen.

Grüße Uwe

Moin Uwe und Danke für den Versuch, es zu reproduzieren.

Was soll ich denn bei diesen Diensten prüfen? Ich kenne schon Wege, dem IIS Zeiten zu entlocken, aber was habe ich davon?

Jedes zweite Mal läuft es doch ohne jegliche Verzögerung. Ich kann also bei gestartetem Outlook diesen Assistenten 10 Mal aufmachen und er wird ca. 5 Mal sofort da sein, und bei den anderen Malen je nach Lust und Laune 5-30 Sekunden brauchen. Parallel kann man Autodiscover testen - succeeded - jedes Mal sofort. Auch die Website https://<deinfqdn>/EWS/Exchange.asmx geht durchgängig ohne Zeitverzug auf.

Wenn er im Problemzustand ist und ich Warten muss, ist auf dem Exchangeserver immer ein Core voll ausgelastet mit IIS Worker, und zwar der applicationPool:MSExchangeServicesAppPool, wie mir der IIS manager mitteilt.

Nur weiß ich nicht, was ich daran ändern soll. Es hat ja auch mit Serverlast nichts zu tun - ich hatte gestern am späten Abend getestet und war der Einzige auf dem Mailserver - das Problem blieb unverändert. Neustart des Mailservers - keine Änderung.

@NetzwerkDude und @4400667902

ich würde Vorschlagen den netzwerkverkehr mal bei dem Vogang mitzuschneiden

Wozu? Was könnte ich denn ändern, wenn mir da etwas auffiele? Der Exchange ist frisch (CU10 gerade erst installiert), die DB ist "healthy", ich sehe keinen Ansatz. Es ist ja kein Fehler, sondern nur eine Unregelmäßigkeit. Vermutlich dauert das Öffnen bei vielen ein paar Sekunden - hier jedoch teilweise bis zu 30 - und das war vor CU9 definitiv nie so.

Hat sich da was bei euch geändert?

Nicht das ich wüsste. CU9 ist seit Ende Juni drauf und erst Mitte August kamen die ersten Klagen. Es hat aber auch mit dem letzten Patch für Exchange nichts zu tun, der wurde testhalber zurückgerollt. Gestern dann CU10 installiert - keine Änderung.

Hi,

ich kenne solch ein Verhalten (mit der Verzögerung) in Kombination mit falschen/nicht vorhandenen Zertifikaten.

Hallo Stefan.

Und von welchem Zertifikat sprichst Du? Das Zertifikat des Exchangeservers hier (IMAP, POP, IIS, SMTP) ist gültig und von der Domain-CA ausgestellt.

Moin,

hast du schon ein Outlook /safe versucht um mal zu prüfen ob der Client eventuell das Problem verursacht?

Hi bitboy.

Ja, keine Änderung.
--

Ich stelle nebenbei fest, dass außer Uwe in seinem Lab, von den 150 Aufrufen wohl niemand die Kombi Outlook 2016 & Exchange 2016 einsetzt oder für einen Test bemühen mag.

ich teste das gleich für dich, setze eben alles auf.

Zitat von @DerWoWusste:

Hallo Stefan.

Und von welchem Zertifikat sprichst Du? Das Zertifikat des Exchangeservers hier (IMAP, POP, IIS, SMTP) ist gültig und von der Domain-CA ausgestellt.

Autodiscover hast du auch im Zertifikat, korrekt?

Falls Du damit meinen solltest "hast Du als alternativen Antragsteller autodiscover.deinedom.local drin?", dann kann ich das bestätigen.

Scheint zumindest auch andere User zu geben die seit CU10 Probleme mit OOF haben, aber wie so oft nur ein Teil, da wird es schwer genau zu sagen was an diesen Umgebungen anders ist, da müsstest du schon weiter ausholen.
https://www.reddit.com/r/exchangeserver/comments/8x5nrm/exchange_2016_cu ...

Upgrade von anderem CU oder komplett neu direkt mit CU10?

Irgendwelche Loadbalancer im Einsatz die man Testweise mal umgehen könnte?

Upgrade von anderem CU oder komplett neu direkt mit CU10?

Upgrade von CU9. Problem trat ja irgendwann nach CU9 auf (das widerum upgegradet von CU8).

Irgendwelche Loadbalancer im Einsatz

Nein, nichts dergleichen.

Noch eine Frage an Uwe: ist deine "Lab-Datenbank" denn auch befüllt, also zumindest >10 GB?

Zitat von @DerWoWusste:
Noch eine Frage an Uwe: ist deine "Lab-Datenbank" denn auch befüllt, also zumindest >10 GB?

Ja drei volle Postfächer mit je 15GB und 20 kleine mit ca 200MB each. Ist aber ein clean CU10, wurde erst vor kurzem neu aufgesetzt.
Haben das Verhalten alle User? Untersuch mal die Mailboxen der User die sich gemeldet haben auf Fehler und die Größe der Mailboxen.

Hallo,

tritt dieser Fehler auch im Abwesenheitsassistent im OWA auf?
Der müßte ja auf die gleiche Schnittstelle am Exchange zugreifen.

Stefan

Haben das Verhalten alle User?

Ja, sogar jetzt neu angelegte, insofern erscheint eine Reparatur dewr (leeren) Mailbox sinnlos.

Hi Stefan K.

tritt dieser Fehler auch im Abwesenheitsassistent im OWA auf?

Nein, dort nie.

Ups, Stefan K's sollte nun nicht die Lösung sein... verklickt.

Zitat von @DerWoWusste:
Hi Stefan K.

tritt dieser Fehler auch im Abwesenheitsassistent im OWA auf?

Nein, dort nie.

Und wie siehts mit der Powershell (Get-MailboxautoreplyConfiguration) oder per EWSEditor aus?
Hört sich irgendwie nach einer Cache-Problematik nur zwischen OL und EX an, hmm ...

-edit- Noch was, ist auf dem EX zufällig Exchange Web Services Managed API 2.2 manuell nachinstalliert worden? Wenn ja, runter damit.

Noch was, ist auf dem EX zufällig Exchange Web Services Managed API 2.2 manuell nachinstalliert worden? Wenn ja, runter damit

Ähh... ja, das hatte ich ja in meiner vorigen Frage zu geskripteten Buchungsabfragen von dir empfohlen bekommen und es ist noch drauf. installiert am 07.08.18 - evt. tritt das Problem seitdem auf.

Was ist an dieser API nicht in Ordnung?

Zitat von @DerWoWusste:
Was ist an dieser WebAPI nicht in Ordnung?

Ich installiere das Teil nie vor allem nicht auf EX-Servern da ist das sowieso überflüssig weil dort die entsprechende DLL bereits vorhanden ist, für die Verwendung mit der PS brauchst du nur die Webservices-DLL aus dem Archiv und die kann überall portable abgelegt werden, mehr nicht. Die API kann auf einem EX installiert genau das geschilderte Verhalten der 100% Last auf dem EWSPool verursachen.

@dww Installation läuft, ich melde mich sobald ich getestet habe!

Die API kann auf einem EX installiert genau das geschilderte Verhalten der 100% Last auf dem EWSPool verursachen.

Ok, woher weißt Du das? Ich habe sie jetzt deinstalliert, aber nichts ändert sich - vermutlich muss der Ex. neu gestartet werden, das werde ich heute Nacht veranlassen.

Zitat von @DerWoWusste:
Ok, woher weißt Du das?

Erfahrungswert, selbst schon mal drüber gestolpert und konnte es glücklicherweise darauf zurückführen. Und ja, rebooten sollte man hier sicherheitshalber.

p.s. Hier hab ich dir mal einen Thread dazu ausgegraben
http://exchangeitup.blogspot.com/2017/02/exchange-2016-100-cpu-and-even ...

Ahhhhh *Seufzer der Erleichterung* - auch ohne Neustart ist das Problem nun Geschichte. Es hat offenbar ein paar Minuten gedauert, bis diese Deinstallation intern Auswirkungen hatte... Ich habe jetzt 10 Mal Outlook geschlossen und wieder geöffnet und der Abw.Assistent erscheint bliztschnell!

Geil, vielen Dank an alle, besonders an Uwe!

Klassischer Fall von "a fool with a tool is still a fool"... siehe Kalenderabfrage Gerätepostfach per Powershell - ich hatte nur eine dll gebraucht, aber dank Installation der ganzen API (die weit vor Exchange 2016 erschienen ist) ungeahnte Nebenwirkungen reingeladen...