Zebbi 11 Geschrieben 26. April 2018 Melden Teilen Geschrieben 26. April 2018 (bearbeitet) Hallo, ich hab hier mehrere 2008R2 Terminalserver übernommen auf denen noch ein Outlook 2010 läuft sowie einen externen Exchange, weshalb wir hier auf den Cachemodus angewiesen sind. Da das alleine ja nicht schlimm genug ist, liegen die lokalen OST-Datein dummerweise auf der gleichen physikalischen Platte wie das OS der Terminalserver und je größer die OST-Dateien werden, desto häufiger kommt es vor, dass bei dem ein oder anderen User mal ein Outlook abstürzt. Leider kommt Outlook beim nächsten Start auf die Idee, die teils 50GB große .OST-Datei auf Fehler überprüfen zu wollen. Das ist zwar sehr nett gedacht, führt aber i.d.R. zu 100% Last auf der Platte und damit praktisch zum Stillstand des ganzen Servers für alle User bis diese Datei repariert ist. Im Ressourcenmonitor kann ich dann (sofern ich überhaupt noch drauf komme) 100%-Plattenauslastung bei 1-2 MB Datendurchsatz sehen. Bisher kann ich allerdings noch nicht beweisen, dass es wirklich die übergroßen OST-Dateien in Verbindung mit reperaturversuchen durch Outlook sind. Ich habs mit der Leistungsüberwachung probiert, in dem ich die Physikalische Platte überwache, aber Beweise bringt mir das auch nicht, da es ja die verursachenden Dateien nicht mit auflistet. Habt Ihr eine Idee wie ich es sicher Beweisen kann und idealer weise wie ich das bestehende System zukünfig vor sowas schützen kann? Klar, die OSTs müssen VIEL kleiner werden und am besten von der OS-Platte verschwinden, aber sonst noch Ideen? Ein lokaler Exchange steht leider nicht zur Debatte. bearbeitet 26. April 2018 von Zebbi Tippfehlerteufel erschlagen... Zitieren Link zu diesem Kommentar
NorbertFe 2.013 Geschrieben 26. April 2018 Melden Teilen Geschrieben 26. April 2018 vor 24 Minuten schrieb Zebbi: läuft sowie einen externen Exchange, weshalb wir hier auf den Cachemodus angewiesen sind So dünn die Leitung? Oder habt ihr das mal wenigstens getestet im Online Modus? Wieso sind die OST Dateien eigentlich so groß? Du solltest verhindern, dass freigegebene Ordner anderer Postfächer da mit reinwandern (kann man per GPO deaktivieren). Oder sind die Postfächer einfach so groß? Eine OST Datei kann hardcoded nicht größer als 50GB werden, also hast du wenn dann sowieso ein Problem. Bye Norbert Zitieren Link zu diesem Kommentar
Zebbi 11 Geschrieben 26. April 2018 Autor Melden Teilen Geschrieben 26. April 2018 vor 1 Minute schrieb NorbertFe: So dünn die Leitung? Oder habt ihr das mal wenigstens getestet im Online Modus? Wieso sind die OST Dateien eigentlich so groß? Du solltest verhindern, dass freigegebene Ordner anderer Postfächer da mit reinwandern (kann man per GPO deaktivieren). Oder sind die Postfächer einfach so groß? Eine OST Datei kann hardcoded nicht größer als 50GB werden, also hast du wenn dann sowieso ein Problem. Bye Norbert Hi Norbert, die Leitung ist wirklich so dünn und mehr gibts hier auch erstmal nicht. Onlinemodus ist getest und als unzumutbar eingestuft, genau deswegen landen auch die freigegeben Postfächer bewußt mit in der OST. Wenn das Maximum wirklich 50GB ist (ich könnte schwören ich hätte schon eine 70er gesehen) erklärt es das natürlich, hilft mir aber noch nicht den direkten Zusammenhang zu beweisen den ich brauch um das Geld für z.B. eine Mail-Archivierungssoftware zu bekommen. Zitieren Link zu diesem Kommentar
NorbertFe 2.013 Geschrieben 26. April 2018 Melden Teilen Geschrieben 26. April 2018 Is doch ganz einfach. Online Modus einschalten, terminalserver schnell nur Outlook ggf. Langsam. Cachemodus outlook meist schnell, aber wenn terminalserver langsam, dann auch Outlook langsam. ;) https://support.microsoft.com/de-de/help/832925/how-to-configure-the-size-limit-for-both-pst-and-ost-files-in-outlook Schau dir mal den Datenbereich an. Zitieren Link zu diesem Kommentar
Zebbi 11 Geschrieben 26. April 2018 Autor Melden Teilen Geschrieben 26. April 2018 Danke, das erklärts und das wäre eigentlich die Lösung, aber da das Ganze ja nur sporadisch ist fehlt mir (besser gesagt meinem Chef) noch der Beweis das es wirklich daran liegt. Gibts da keinen Kniff um doch noch irgendwie mitzuloggen was/welche Datei gerade die Platte auslastet? Ich glaub das könnte mir auch bei einigen anderen Problemen sehr helfen. Zitieren Link zu diesem Kommentar
NorbertFe 2.013 Geschrieben 26. April 2018 Melden Teilen Geschrieben 26. April 2018 Im Ressourcenmonitor sollte man doch sehen wie die Auslastung ist und durch welche Datei das ggf. verursacht wird. Einfach mal auf den Prozess Outlook filtern und dann unter Datenträger nachschauen. Da sollten dann alle Dateien welche von Outlook in Beschlag genommen sind gelistet sein. Zumindest für den schnellen Überblick reicht die Variante sicher aus. Bye Norbert Zitieren Link zu diesem Kommentar
Zebbi 11 Geschrieben 26. April 2018 Autor Melden Teilen Geschrieben 26. April 2018 Jein, das ist ja mein Problem. Der Datendurchsatz fällt ja angeblich auf 1-2MB/s, bei 50 Usern dann zu sagen wer schuld ist weil gerade diese eine Datei nun seit dem letzten Intervall am meisten gelesen/geschrieben hat ist halt nur ein schöner Verdacht, aber kein Beweis. Da steht ja nur "Datei X hat in den letzten Sekunden Y-Bytes gelesen/geschrieben" aber nicht "Datei X verursacht 99,99% der Zugriffe in den letzten 5 Minuten" und das ist hier leider bei weitem nicht immer das Selbe. :( Hier mal der letzte Screenshot im Moment des Problems. Zitieren Link zu diesem Kommentar
NorbertFe 2.013 Geschrieben 26. April 2018 Melden Teilen Geschrieben 26. April 2018 Deswegen sollst du ja auf outlook.exe filtern, dann hat man nicht soviel unnötigen Wust im Überblick. Natürlich ist das kein Beweis, aber wie willst du es denn beweisen? Task abschießen und wenn dann die Last runtergeht hast du deinen Beweis (ist nur nicht besonders nutzerfreundlich :)) Bye Norbert Zitieren Link zu diesem Kommentar
Zebbi 11 Geschrieben 26. April 2018 Autor Melden Teilen Geschrieben 26. April 2018 vor 4 Minuten schrieb NorbertFe: Deswegen sollst du ja auf outlook.exe filtern, dann hat man nicht soviel unnötigen Wust im Überblick. Natürlich ist das kein Beweis, aber wie willst du es denn beweisen? Task abschießen und wenn dann die Last runtergeht hast du deinen Beweis (ist nur nicht besonders nutzerfreundlich :)) Bye Norbert Das hab ich natürlich schon probiert, aber an der Stelle hängt das System schon so stark, das es nicht mehr Hilft den Prozess zu killen, Outlook ist in dem Moment extrem hartnäckig. :( Ich kann ja nicht einmal erkennen welches Outlook es ist, das war bisher eher ein austesten der üblichen Verdächtigen. Zitieren Link zu diesem Kommentar
testperson 1.660 Geschrieben 26. April 2018 Melden Teilen Geschrieben 26. April 2018 Hi, aus https://technet.microsoft.com/de-de/library/gg602061(v=office.14).aspx: Zitat Cached Exchange Mode is supported when Outlook 2010 is deployed in a RDS environment. However, for better scalability, we recommend that you use Online Mode with RDS for large deployments. For more information, see Cached Exchange Mode in a Remote Desktop Session Host environment: planning considerations (Outlook 2010) (white paper) (http://go.microsoft.com/fwlink/p/?LinkId=208740). Gruß Jan Zitieren Link zu diesem Kommentar
djmaker 95 Geschrieben 26. April 2018 Melden Teilen Geschrieben 26. April 2018 Schau mal mit dem Systernals Process Explorer, da solltest Du das besser eingrenzen können. Zitieren Link zu diesem Kommentar
speer 19 Geschrieben 28. April 2018 Melden Teilen Geschrieben 28. April 2018 Hi, wie viele Personen arbeiten überhaupt auf dem besagtem Terminalserver? Wie groß ist in dem Fall die Betriebssystempartition? Ist die Outlook Verwendung festgeschrieben oder käme ggf. OWA in Frage? Zitieren Link zu diesem Kommentar
Zebbi 11 Geschrieben 30. April 2018 Autor Melden Teilen Geschrieben 30. April 2018 Danke für die Antworten, OWA kommt leider nicht in Frage, unter anderem weil das Warenwirtschaftssystem direkt auf Outlook zugreift. Auf dem TS arbeiten ca. 40 Leute, quasi alles was nicht im AppData-Ordner oder auf dem Desktop landet wird per Ordnerumleitung auf den Fileserver geschoben (Ja, OST/PST im LAN ist nicht supportet, geht aber nicht anders in der Konstellation und problematisch sind ja gerade die LOKALEN OSTs.) Damit ist die Systemplatte derzeit 500GB groß und zu 2/3 voll. Der Prozessexplorer zeichnet ja leider auch nicht auf und Warnungen oder gar Scripte kann ich so auch nicht starten. :( Zitieren Link zu diesem Kommentar
Nobbyaushb 1.464 Geschrieben 30. April 2018 Melden Teilen Geschrieben 30. April 2018 Moin, in der aktuellen Konfiguration hast du gleich mehrere Probleme auf einmal. Cache-Mode würde ich sogar mit aktuellem Office und auf neuer, performanter Hardware verweigern. In der aktuellen Konfig geht z.b. Jede Mail zwei Mal über das Lan und belastet die Schnittstelle doppelt. Wer hat denn den Cache-Mode empfohlen bzw. vorgeschrieben? Und, wie du selber schreibst, sind Pst bzw. Ost auf shares nicht supported. Ich würde das Design mal auf den Prüfstand stellen. Was für eine Netzwerkkarte ist verbaut, welcher Treiber? Und wie ist der Exchange an das Netz angebunden, welchen Stand hat der? Zitieren Link zu diesem Kommentar
Ebenezer 13 Geschrieben 30. April 2018 Melden Teilen Geschrieben 30. April 2018 Hi, werden die OSTs nun auf einen anderen Server umgeleitet, oder nicht? Das Outlook die OST-Dateien sporadisch reparieren möchte passiert nach meiner Erfahrungen eigentlich nur bei SMB Zugriff. Ich kenne einige Umgebungen mit RDS 2008 R2 + Outlook 2010 + Exchange Online + Cache Modus (OSts liegen hier immer lokal) und das läuft total problemlos. Also m.E. nicht zwangsläufig ein Design Problem. Wenn die OSTs an Ihre maximal konfigurierte Grenze stoßen dann könnte ich mir auch vorstellen, das Outlook einen Reparaturversuch unternimmt. Handelt es sich denn um eine RDS Farm und die Benutzer werden automatisch verteilt? Grüße, Nico Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.