pheelix

Das witzige dabei war, dass ich bei der Deinstallation extra den Schalter für die korrekte De- bzw. Reinstallation der Netzwerkkarte angegeben habe ... 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.

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.

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)). ....

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.

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.

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.

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: 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.