2010 - lange (durchschnittliche) RPC-Wartezeit

[pheelix 10]

Hallo,

 

ich hab schon einige Exchange 2010 Installation für Unternehmen mit mehr als tausend Benutzern gemacht. Jetzt stehe ich vor einem Problem bei einem Exchange 2010 Server in einem KMU.

 

Ich hab die Migration von 2007 auf 2010 vorgenommen. Es gibt insgesamt 33 Postfächer auf einem Exchange 2010 Server (CAS, DB und Hub-Transport)(Es sind alle verfügbaren Exchange 2010 Updates installiert).

Der Server läuft unter VMware virtualisiert, hat 4 virtuelle CPU's, 16 GB Speicher und eine LUN, für die DBs, auf einem schnellen Storage.

 

Die Benutzer arbeiten auf mehreren Terminalservern (2008R2) verteilt jeweils mit Outlook 2010.

 

Bei einigen wenigen Nutzern tritt das Problem auf, dass sich Outlook aufhängt bzw. die Nachricht in der Taskleiste kommt "Outlook versucht Daten von mailserver.xy abzurufen".

 

Das führt oftmals dazu, dass sich Outlook aufhängt bzw. richtig crasht.

 

Der alte Exchange-Server hängt momentan noch in der Exchange-Organisation, aber vollführt keine Aufgaben mehr.

 

Die Leistungsproblembehandlung von Exchange meldet bei allen drei Tests "Keine Leistungsproblem" und auch die Hardware (HP Blade) langweilt sich laut VMware und auch im virtuellen Windows selber.

 

Unpassend dazu:

Meldungen im RCA-Log:

2012-08-20T16:57:33.830Z,5,234,/o=contoso-ORG/ou=Erste administrative Gruppe/cn=Recipients/cn=userXY,,OUTLOOK.EXE,11.0.8303.0,Classic,,,ncacn_ip_tcp,,,0x6BB (rpc::Exception),00:00:00,,RpcEndPoint: [serverTooBusyException] Client is being backed off -> [ClientBackoffException] Client is over budget

 

Die Meldung taucht für kurze Zeit permanent auf und dazu gabs bei dem Nutzer (Und das ist natürlich gerade der GF (24GB großes Postfach)) einen Timeout nach 91 Sekunden. Andere Benutzer arbeiten parallel ohne Probleme.

 

Das Problem trifft aber auf Nutzer mit Postfächern die "nur" 2GB groß sind.

 

Im Exchange-Server-Systemmonitor sieht man, dass die "Durchschnittliche RPC-Wartezeit (ms)" jetzt zur Nachtzeit immernoch sehr hoch ist (Screenshot). Und das obwohl es so gut wie keine RPC-Anfragen gibt.

 

Tagsüber ist der Wert bei weit über 100,000 (ich nehm mal an, dass das "," der Tausendertrenner ist) und damit immer am oberen Anschlag der Skalierung der Anzeige.

 

Aus vorhergehenden Installationen (allerdings immer mit CAS-Clustern und mehreren DB-Servern mit eigenem, direkt angeschlossenem Storagesystem) kenne ich solche Werte nicht. Der Wert für die RPC-Wartezeit auf dem problematischen Server liegt 60 mal höher als auf den anderen Systemen, die ich bisher eingerichtet habe.

 

Mich irritiert dabei besonders, dass der Wert zur Nachtzeit immernoch so hoch ist, obwohl höchstens 1-2 Nutzer aktiv sind.

 

Für Hinweise wäre ich sehr dankbar.

 

Vielen Dank.

bearbeitet 20. August 2012 von pheelix

[pheelix 10]

Nur informativ:

Ich habe die öffentlichen Ordner gestern noch auf den alten Server zurückgeschoben bzw. den Pfad für öffentliche Ordner bei den Postfachdatenbanken umgestellt (natürlich vorher die Replikation kontrolliert).

 

Über die Nacht hat es sich damit sehr langsam nach unten geregelt (Screenshot). Jetzt arbeitet ein Großteil der Nutzer und die Wartezeit bleibt fast konstant bei 2,600.

[RobertWi 81]

Moin,

 

das ist aus der Ferne vermutlich sehr schwer zu lösen, weil da neben Software auch Hardware-Probleme in Frage kommen. Dann ist das noch virtualisiert, mit externen SAN -> wieder zwei mögliche Fehlerquellen.

 

Grundsätzlich klingen Deine Daten gut (d.h. die VM sind leistungsmäßig angemessen). Nun heißt es, vermutlich mit Try&Error andere Komponenten auszuschließen.

 

Als erstes solltest Du Dich mal mit ExMon (MSXFAQ.DE - ExMon) auf die Suche machen, ob Du eventuell Glück hast, und nur ein Client die Probleme verursacht (unwahrscheinlich, dank ThrottelingPolicy).

[pheelix 10]

Hallo,

 

ich hatte gestern (am Vormittag) schon eine neue ThrottlingPolicy erstellt und allen Nutzern zugeordnet. Greift eine ThrottlingPolicy sofort oder erst wenn sich der Nutzer neu anmeldet?

 

Den ExMon habe ich gestern ebenfalls schon installiert. Der zeichnet auch momentan Daten auf. Wobei ich da noch nicht genau weiß, ob ich die Daten dann auch richtig interpretieren kann.

 

Die Werte im Systemmonitor sehen nachwievor gut aus.

Ein Schlingel meldet sich mit einem 2003er Outlook an.

[RobertWi 81]

Moin,

 

die Policy greift IMHO sofort (im Gegensatz zu manch anderen Einstellungen). Sollte das nicht so sein, wäre die normale Cache-Zeit 2 Stunden.

 

Auf dem Client könnte dann z.B. ein Virenscanner oder ein anderes Dritt-Programm dafür verantwortlich sein.

 

Hast Du noch mehr 2003 im Einsatz? Sonst sperr ihn doch einfach aus, und wenn dann das Problem weg ist, weiß Du das es an dem Client gelegen hat. Nicht nett, aber was bringt es, wenn der eine Client warum auch immer alle Benutzer beeinträchtigt.

[pheelix 10]

Das Problem sitzt, wie so oft, vor dem Terminalserver :)

 

Es gibt noch einen alten Terminalserver, der offiziell nicht mehr benutzt werden soll. Dort läuft noch Office 2003.

 

Prinzipiell sollen alle Mitarbeiter auf dem neuen Terminalserver mit dem neuen Office (2010) arbeiten und sich daran gewöhnen. Wie immer gibt es da auch Verweigerer. Das löst sich spätestens mittelfristig, weil der alte Terminalserver nicht mehr ewig am Leben erhalten wird.

 

Ich muss mir also nochmal ein Vorgehen für den 2. Anlauf überlegen.

[pheelix 10]

10:40 Uhr trat das Problem erneut auf und dabei ist der ExMon gecrasht und lässt sich auch nicht mehr öffnen (Unknown StartTrace error (183)).

 

....

[pheelix 10]

Noch als Info:

 

Das Problem trat am Dienstag 10:40 Uhr erneut auf, obwohl alle User schon seit mehreren Stunden gearbeitet haben.

 

Wir haben dabei dann abermals alle möglichen Leistungsindikatoren auf dem Exchange kontrolliert, genauso den Virtualisierungsserver und das Storage bzw. die Storagevirtualisierung.

 

ExMon hat keine auffälligen Dinge gezeigt. Ja es gibt noch zwei Benutzer mit einem 2003er Outlook, aber von denen hat auch keiner das Problem ausgelöst.

 

Letztendlich haben wir dann über den Ressourcenmonitor von Windows gemeinsam mit dem Process Monitor von Microsoft gesehen, dass außer Exchange nur noch der Virenscanner (ESET Mailsecurity für Exchange) läuft. Eigentlich hatte ich den ESET schon längst deaktiviert, um den als Fehlerquelle auszuschließen, aber anhand der beiden Tools sieht man, dass er fröhlich weiter scannt.

 

Dann kam die Idee, den ESET zu deinstallieren. Das war dann leider der nächste Fehler. Das habe ich anhand eines KB Artikels von ESET gemacht, genau nach der Anleitung. Das Uninstaller-Log hat angeblich alles erfolgreich ausgeführt. Dabei entfernt ESET auch gleich die Netzwerkkarte vom Server bzw. den Treiber. Das hat dazu geführt, dass wir zwei Stunden gebraucht haben, um die virtuelle Netzwerkkarte wieder zum laufen zu bringen. Einfach in VMware einen neuen Adapter einfügen etc. hat da keinen Erfolg gebracht. VMware Tools mit den Treibern haben sich erst nach 15 Minuten installieren lassen, weil die "kaputte Netzwerkkarte" den ganzen Server (in Windows) lahmgelegt hat. Dann war der Treiber drauf und wir haben der NIC wieder die richtige IP verpasst, rebootet, und das gleiche Problem wieder gehabt ... dann haben wir die NIC per cmd auf DHCP eingestellt und danach händisch die eigentliche IP eingetragen. Dann die Exchange-Dienste durchgestartet.

 

Dann lief der Transportdienst nicht mehr an. Ich hatte übrigens kurz zuvor mit dem ESET-Support telefoniert, um zu fragen, ob es solche Probleme schon mal bei anderen Kunden gab - natürlich nicht. Okay. ESET hatte sich angeblich vollständig deinstalliert. Ein Blick ins Eventlog von Windows zeigt, dass sich der Transportdienst nicht starten lässt, weil er den Transportagent von ESET nicht findet ... ok ... soviel zu "erfolgreich deinstalliert". Nachdem wir noch mit Disable-Transportagent in Exchange beide ESET-Agents deaktiviert haben, ging Exchange erstmal wieder wie gewohnt.

 

Ich vermute (!) mal, dass ESET sich da nicht selber vollkommen entfernen kann, weil man die Deinstallation im abgesicherten Modus von Windows ausführen muss und dabei die Exchange-Dienste nicht laufen, so dass die Agents nicht entfernt werden können. Ist nur eine Vermutung, aber auf jeden Fall unpraktisch. Oder es wurde in der Routine einfach vergessen.

 

Nachdem mir dann 30 Leute im Nacken saßen, war das Problem dann nach 4 Stunden gelöst.

 

Der eigentliche Auslöser ist vermutlich (!) der Hintergrundscanner von ESET gewesen. Der ist so nett und scannt bei jedem Signaturupdate die kompletten Postfachdatenbanken neu. Das würde auch erklären, warum das zu unterschiedlichen Zeiten bei unterschiedlichen Nutzerzahlen aufgetreten ist. Und ja, den Hintergrundscanner kann bzw. sollte man wohl (jetzt aus Erfahrung) deaktivieren. Letztendlich wars also ein Konfigurationsproblem, wobei es auch schade ist, dass ESET sich so verhält, dass es den Exchange komplett ausbremst und nicht in kleineren Häppchen scannt.

 

Vielleicht hilft es jemandem an anderer Stelle weiter.

[RobertWi 81]

Dann kam die Idee, den ESET zu deinstallieren. Das war dann leider der nächste Fehler.

 

Wenn ich das alles lese: Es war sicher KEIN Fehler, ESET zu deinstallieren. Lieber ein Ende mit Schrecken als ein Schrecken ohne Ende....

 

Ich vermute (!) mal, dass ESET sich da nicht selber vollkommen entfernen kann, weil man die Deinstallation im abgesicherten Modus von Windows ausführen muss

 

WIE BITTE? Das Ding muss im abgesicherten Modus deinstalliert werden?

 

und dabei die Exchange-Dienste nicht laufen, so dass die Agents nicht entfernt werden können.

 

Ja, ziemlich sicher wurde da nur die Datei entfernt, nicht aber die Verknüpfung in Exchange.

 

 

Ich persönlich würde der Installation nach dieser Geschichte keine fünf Minuten mehr trauen und den Server neuinstallieren. Entweder mit eine Swing-Migration (kaum Beeinträchtigungen, aber mehr Aufwand) oder mit einer RecoverServer-Installation (weniger Aufwand, aber Ausfall während der Installation).

 

Wer weiß sonst schon, wo sich das Ding noch alles zu reingehängt hat und was nun noch alles so kaputt ist.

[pheelix 10]

Das witzige dabei war, dass ich bei der Deinstallation extra den Schalter für die korrekte De- bzw. Reinstallation der Netzwerkkarte angegeben habe ...

 

Ich persönlich würde der Installation nach dieser Geschichte keine fünf Minuten mehr trauen und den Server neuinstallieren. Entweder mit eine Swing-Migration (kaum Beeinträchtigungen, aber mehr Aufwand) oder mit einer RecoverServer-Installation (weniger Aufwand, aber Ausfall während der Installation).

 

Nach dem alles wieder lief, sind keinerlei Probleme mehr aufgetreten. Die Windowslogs sind seit zwei Tagen ohne Fehler und die Leistungsindikatoren im Exchange Server-Systemmonitor sehen so aus, wie es sein sollte. Deswegen warte ich im Moment noch mit weiteren Aktionen.