none
Event ID 9646 MSExchangeIS RRS feed

  • Frage

  • Servus Community,

    ich habe bei einem Exchange 2010 folgende Fehlermeldung täglich mehrfach im Logfile:

    ---snip---

    Protokollname: Application
    Quelle:            MSExchangeIS
    Datum:           14.01.2015 07:13:27
    Ereignis-ID:     9646
    Aufgabenkategorie:Allgemein
    Ebene:            Fehler
    Schlüsselwörter: Klassisch
    Benutzer:           Nicht zutreffend
    Computer:          MTA.DOMAIN.local
    Beschreibung:
    Die MAPI-Sitzung '74b4aa8e-384a-443d-af63-a27481b83571: /o=Mail-Domain/ou=Erste administrative Gruppe/cn=Recipients/cn=dtp' hat die maximal zulässige Anzahl von 16 Objekten vom Typ 'session' überschritten.
    ---snap---

    Das Postfach ist ein Service Postfach und es greifen darauf tatsächlich idR mehr als 16 Mail Clients darauf zu, die Meldung 'Typ 'session' überschritten' scheint demnach plausibel. Jetzt habe ich gestern ein wenig gestöbert und das hier gefunden [1] und dementsprechend den Schlüssel 'MaximunAllowedSessionsPerUser' mit dem Wert 0x32 angelegt, die Meldung erscheint aber weiterhin, war das der falsche Schlüssel oder was muss ich noch einstellen?

    Thx & Bye Tom

    [1] http://technet.microsoft.com/de-de/library/ff477612%28v=exchg.141%29.aspx

    Mittwoch, 14. Januar 2015 07:54

Antworten

  • Moin Tom,

    der Event 9646 ist ein Schutz des Exchangeservers vor Überlastung.

    Das Problem ist, dass der für den gesamten Server gültig ist. In der Theorie müsstest Du bei einer Erhöhung also das komplette Sizing des Servers, sprich RAM und CPU, ändern. Denn Du musst damit rechnen, dass dann, ohne dass Du es merkst viele/alle Clients bei Fehlern oder Problemen eine unerwartete Mehrlast bringen.

    Hast Du Auswirkungen, hast Du keine Chance, dann musst Du ändern. Wenn Du keine Auswirkungen merkst, würde ich den nicht ändern. Dann wäre mir der Schutz im Notfall wichtiger.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Donnerstag, 15. Januar 2015 15:42

Alle Antworten

  • Hallo Tom,

    sollte ein Service Account auf den Exchange Server zugreifen und mehr als die maximal erlaubte Anzahl an MAPI Sitzungen öffnen, wird das oben beschriebene Event geloggt.
    Sollte dies der Fall sein, kann diese Beschränkung wie unter [1] beschrieben umgangen werden.

    [1] http://support.microsoft.com/kb/2742012/en-us

    Viele Grüße,
    Philipp Löwer
    TechNet Deployment Hotline

    TechNet Deployment-Hotline

    Disclaimer:

    Bitte haben Sie Verständnis dafür, dass wir hier auf Rückfragen gar nicht oder nur sehr zeitverzögert antworten können.
    Bitte nutzen Sie für Rückfragen oder neue Fragen den telefonischen Weg über die TechNet Deployment Hotline: http://technet.microsoft.com/de-de/ff959330

    TechNet Deployment-Hotline
    Telefon: 0800-6087338*
    Email: msdn-technet-support@escde.net

    * 16:00 – 18:00 Uhr (außer an bundeseinheitlichen Feiertagen). Kostenfrei aus dem dt. Festnetz, Mobilfunknetz ggfs. abweichend. Anrufer aus Österreich und der Schweiz können die Telefon-Hotline aus technischen Gründen über +49 721 693 7233 zum Tarif für Auslandsverbindungen des jeweiligen Telefonanbieters erreichen.
    Es gelten Nutzungsbedingungen, Hinweise zu Markenzeichen sowie die allgemein gültigen Informationen zu Datenschutz und Cookies. Bitte beachten Sie auch die gesonderten Nutzungsbedingungen für die Deployment-Hotline.

    Mittwoch, 14. Januar 2015 10:10
  • Servus Philipp,

    >sollte ein Service Account auf den Exchange Server zugreifen und mehr als die maximal erlaubte Anzahl an MAPI Sitzungen öffnen, wird das oben beschriebene Event geloggt.
    Sollte dies der Fall sein, kann diese Beschränkung wie unter [1] beschrieben umgangen werden.

    >[1] http://support.microsoft.com/kb/2742012/en-us

    Danke für den Link, das liest sich tatsächlich so als ob das mein Problem beschreibt aber ich bekomme im Moment überhaupt keine Erklärung was das AD Recht "View information store status" mit meinem Problem zu tun hat. Also da ist nicht mal im Ansatz was dabei, was ich nachvollziehen könnte.

    Kann es sein, dass der Terminus "Service Account" bzw "Service Postfach" von mir unglücklich gewählt wurde und das im Microsoft Jargon was ganz anderes bedeutet? Ich meinte mit Service Account halt ein ganz normales Postfach auf das mehrere Personen gleichzeitig zugreifen, die sind (bei uns) halt zufällig im Service...

    ...bin ich beim verlinkten Workaround jetzt immer noch richtig? ;-)

    Thx & Bye Tom

    Mittwoch, 14. Januar 2015 13:38
  • Moin,

    rein technisch gibt es keinen Unterschied zwischen den verschiedenen Accounttypen. Sie werden nur anders genutzt und daher würde man anders an die Drosselungen rangehen.

    Der KB-Artikel passt daher bei Deinem Fall nicht. Dein Artikel ist daher immer noch aktuell.

    Allerdings gibt es seit 2010 auch "Throttelinpolicys". Findest Du Fehlereinträge hierzu?

    Außerdem muss Du nach den Regkey-Änderungen den MSexchangeIS neustarten. Ist das passiert?


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Donnerstag, 15. Januar 2015 10:28
  • Servus Robert,

    > Allerdings gibt es seit 2010 auch "Throttelinpolicys". Findest Du Fehlereinträge hierzu?

    wir hatten diesbzgl. tatsächlich Fehlermeldungen:

    ---snip---

    Protokollname: Application
    Quelle: MSExchange ADAccess
    Datum: 12.01.2015 09:12:27
    Ereignis-ID: 2915
    Aufgabenkategorie: General
    Ebene: Fehler
    Schlüsselwörter: Klassisch
    Benutzer: Nicht zutreffend
    Computer: MAILSERVER.DOMAIN.local
    Beschreibung:
    Prozess w3wp.exe () (PID=7016). Benutzer 'Sid~DOMAIN\alias~EWS~false' hat das Budget innerhalb eines einminütigen Zeitraums
    130 Mal für Komponente 'EWS' überschritten. Info: 'Policy:DefaultThrottlingPolicy_9cef4252-1079-4075-afc0-b613b94723aa,
    Parts:MaxConcurrency:129;'. Schwellenwert: '100'.

    ---snap---

    Dieser Fehler hatte jedoch, im Gegensatz zu dem hier im Topic diskutierten, Auswirkungen auf den Betrieb. Wir hatten etliche gestörte Mailclients, die vereinzelt Ordner einfach nicht mehr anzeigten oder grau und unantastbar anzeigten. Den eingangs hier erwähnten Fehler  (Event ID 9646 MSExchangeIS) haben wir schon länger, vielleicht sogar schon immer, immer wieder mal aber das ohne Auswirkungen auf den Betrieb. Es hat sich niemand bislang beschwert.

    Wir haben dann eine neue Throtteling Policy angelegt und mit dem Benutzerpostfach verknüpft, in diesem Zusammenhang auch den Registrywert 'MaximunAllowedSessionsPerUser' angelegt und...

    > Außerdem muss Du nach den Regkey-Änderungen den MSexchangeIS neustarten. Ist das passiert?

    ...abschließend den kompletten Server neu gestartet.

    Die Störungen im Betrieb waren danach, bis auf ein Mail Client, wieder verschwunden. Den einen Mailclient (Apple Mail) haben wir seine Datenbank neu aufbauen lassen und dann wars auch da wieder gut. Ich weiß jetzt natürlich nicht ob die neue Throtteling Policy das Problem gefixt hat oder ob es schlicht und einfach nur der Neustart gewesen ist. Es gab eigentlich keinen Grund, warum sich plötzlich irgendein Throttelingmechanismus greifen sollte, es hat sich nichts verändert.

    Den hier diskutierten Fehler Event ID 9646 würde ich jetzt halt gerne auch mal wegbringen, auch wenn er (bislang) keine Auswirkungen zu haben scheint.

    Thx & Bye Tom 



    Donnerstag, 15. Januar 2015 15:08
  • Moin Tom,

    der Event 9646 ist ein Schutz des Exchangeservers vor Überlastung.

    Das Problem ist, dass der für den gesamten Server gültig ist. In der Theorie müsstest Du bei einer Erhöhung also das komplette Sizing des Servers, sprich RAM und CPU, ändern. Denn Du musst damit rechnen, dass dann, ohne dass Du es merkst viele/alle Clients bei Fehlern oder Problemen eine unerwartete Mehrlast bringen.

    Hast Du Auswirkungen, hast Du keine Chance, dann musst Du ändern. Wenn Du keine Auswirkungen merkst, würde ich den nicht ändern. Dann wäre mir der Schutz im Notfall wichtiger.


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Donnerstag, 15. Januar 2015 15:42
  • Servus Robert,

    > Hast Du Auswirkungen, hast Du keine Chance, dann musst Du ändern. Wenn Du keine Auswirkungen merkst, würde ich den nicht ändern. Dann wäre mir der Schutz im Notfall wichtiger.

    Okay, dann lasse ich den jetzt mal so stehen. Wir haben für unsere paar Accounts (zZ < 100) zwar einen wirklich großzügig dimensionierten Server aber zumindest dieser Fehler (9646) hatte bislang nur kosmetische Auswirkungen im Logfile. Die andere Sache mit der Throtteling Policy (2915) war da schon kritischer aber wie erwähnt, weiß ich nicht ob es die neue Throtteling Policy oder der folgende Neustart war, der die Sache dann wieder gerade gebogen hat.

    Thx & Bye Tom

    Donnerstag, 15. Januar 2015 15:54
  • Für die Überlast reicht ja schon ein Client, wenn der Virenscanner wild läuft.

    Bei uns erzeugen manche Leute Überlast, wenn sie ihre OST-Datei löschen und neusychronisieren. Dann werden die zwar mal kurz gebremst, aber es zieht eben nicht den ganzen Server runter.

    Die Throtteling Policy sollte eigentlich ohne Neustart wirken. Aber wie so oft, braucht es wenig Geduld. Dann ist irgendwann der Neustart schneller. :)


    Gruesse aus Berlin schickt Robert - MVP Exchange Server

    Donnerstag, 15. Januar 2015 15:59