OWA weiße Seite / IIS Limit?

[Dingo 10]

Hallo@all,

 

irgend etwas ist ja immer... darauf ist man schon gefasst aber nun brauche ich wirklich mal Nachhilfe. Mr. Google konnte mir leider auch nicht helfen. Notfalls bin ich zwar zu dämlich zum Suchen aber doch bestimmt nicht der Erste mit diesem Problem, oder!? :/

 

Das Problem zu erklären bedarf schon einiger Zeilen, wäre aber dankbar wenn Ihr trotzdem mal drüber schaut.

 

Ich steckte mitten in einer Intra-Forest-Migration und habe fleißig (universelle und globale) Gruppen in eine andere Domäne verschoben. Am nächsten Tag beschwerten sich zwei Benutzer, sie können mit ihrem Smartphones keine Emails mehr empfangen. Um weitere Fehlerquellen auszuschließen (Geräte, Mobilfunk, etc.), haben wir die Benutzer sich direkt am OWA anmelden lassen und festgestellt, dass das ebenfalls nicht funktionierte. Die Anmeldedaten werden angenommen aber anstelle des Postfachs wird nur eine weiße Seite angezeigt! Keine Fehlermeldung. Alle anderen Benutzer können diesen OWA-Server dagegen Problemlos benutzen!

 

Das Problem konnten wir leider nicht sofort lösen und währenddessen wurde die Migration weiter fortgeführt. Am nächsten Morgen konnten genau die Benutzer vom Vortag kein Outlook mehr benutzen!?

 

Es hat nicht lange gedauert, da fand ich heraus, dass das Access Token durch die Gruppenverschiebung zu groß geworden war. (Wie ich jetzt gelernt habe kostet die Mitgliedschaft in einer Universellen Gruppe einer anderen Domäne mehr Speicherplatz als die einer Globalen Gruppe derselben Domäne). Abhilfe schaffte hier der Regkey "MaxTokenSize" am Client. Nach dem Neustart funktioniert Outlook sofort wieder. Outlook Webacces jedoch nicht! :/

 

Um das Problem noch etwas komplizierter zu machen: Da alle anderen Benutzer den OWA ohne Fehler benutzen, ist man geneigt den Fehler am Benutzer zu suchen. JETZT kommt es aber: An einem weiteren OWA kann sich auch der Problemfall anmelden und bekommt wie gewohnt ein Postfach angezeigt!

 

- Wie bringe ich nun den ersten Server dazu ebenfalls das Postfach anzuzeigen? Oberflächlich sehen die Einstellungen beider OWAs gleich aus.

- Kann ich am IIS irgendwo das Logging sehen/ erhöhen um den Fehler besser eingrenzen zu können? Eine weiße Seite ohne Fehlermeldung ist arg dürftig.

 

Die Rede ist übrigens von einer Windows Server 2003 Umgebung (AD+Echange SP2) mit IIS6.

 

Ich hoffe ich konnte das Problem verständlich erklären. Bin langsam verzweifelt aber für jeden Hinweis dankbar. :]

 

thx

D.

[Dingo 10]

Hier noch ein weiterer Hinweis:

 

Ich habe einen neuen Benutzer erstellt, bei dem OWA zunächst wie erwartet funktionierte. Anschließend habe ich ihn in die gleichen Gruppen gesteckt wie eines der Problemfälle und siehe da, OWA zeigt nur noch die weiße Seite!

 

Dann habe ich Stück für Stück die Gruppen reduziert und das Verhalten beobachtet. Der Benutzer hatte wirklich verdammt viele Gruppenmitgliedschaften. Anfangs 436 jetzt 213, damit geht es und OWA funktioniert (ermittelt mit whoami -all).

 

Nach allem was ich herausgefunden habe scheint die Gruppenanzahl alleine aber nicht das aussagekräftig zu sein, da die Gruppentypen IMHO unterschiedlich viel "Speicherplatz" belegen. Da immer die Rede von der TokenSize ist, wollte ich die tatsächliche Tokengröße ermitteln. Hierfür gibt es das Tool TokenSZ von Microsoft und mit dem Befehl Tokensz /compute_tokensize wird der Wert für den angemeldeten Benutzer ermittelt.

 

Bei 213 Gruppen wird eine Größe von 9094 Bytes angezeigt. Fügt man nun eine Gruppe hinzu (ok - durch Verschachtelung sind es dann zwei) sind die Werte 215 Gruppen und 9182 Byte, damit funktioniert OWA nicht mehr.

 

Kann jemand mit dieser Grenze/Schwellwert etwas anfangen?

 

thx

D.

[BrainStorm 10]

Hallo Dingo,

 

das Problem kann auch mit den IIS Parametern MaxFieldLength und MaxRequestBytes zusammenhängen.

 

Schau dir die beiden folgenden Artikel mal an und experimentiere vorsichtig mit den Werten.

 

 

The MaxRequestBytes registry value, which is not present by default, determines the upper limit for the total size of the Request line and the headers. This value is typically set in tandem with a companion value, MaxFieldLength. The MaxFieldLength IIS registry parameter specifies the maximum size of any individual HTTP client request. In larger environments, if these values are not set to 32768, Microsoft Office Outlook® Web Access for Exchange Server users can experience logon failures. Specifically, the absence of these values can cause HTTP 400 - Bad Request errors. When configuring the MaxFieldLength registry value, you must also set the MaxRequestBytes parameter to 32768 to enable users who are members of more than 75 groups to log on to Outlook Web Access. If its value is lower than MaxFieldLength, the MaxFieldLength value is adjusted.

IIS 6.0 MaxRequestBytes parameter not set correctly

 

 

The MaxFieldLength IIS registry parameter, which is not present by default, specifies the maximum size of any individual HTTP client request. This value is typically set in tandem with a companion value, MaxRequestBytes. In larger environments, if these values are not set to 32768, Microsoft Office Outlook® Web Access for Exchange Server users can experience logon failures

IIS 6.0 MaxFieldLength parameter not set correctly

[Dingo 10]

Hi BrainStorm,

 

danke für Deine Mühe! Das ist ein vielversprechender Hinweis wie ich fand.

Habe ihn jedoch schon ausprobiert und es brachte leider keine Veränderung. :/

 

Ich hatte den Hinweis hier gefunden und es sogar mit den dort genannten höheren Werten versucht.

 

thx

D.

[BrainStorm 10]

mhmm, ich gehe mal davon aus dass du auch die IIS-Dienste nach der Änderung einmal neugestartet hast.

 

Du könntest auch mal in den IIS Logs - zu finden unter %windir%\System32\LogFiles\HTTPERR und %windir%\System32\LogFiles\W3SVC - schauen was zum Zeitpunkt des Zugriffs dort protokolliert wird.

[Dingo 10]

Moin,

 

leider war in den Logfiles überhaupt keine Information über einen gescheiterten Anmeldeversuch zu finden! Habe jedoch eine für mich gültige Übergangslösung gefunden.

 

Kurze Zusammenfassung:

 

Im Verlauf der Domänenmigration wurden viele Gruppen in die neue Domäne verschoben. Ein Mitgliedschaft einer Universellen Gruppen einer anderen Domäne belegt nun 40 statt vorher 8 Bytes. Dadurch wurde u. a. irgendwann die maximale Puffergröße von 12.000 Bytes erreicht. Das war der Moment als Outlook nicht mehr funktionierte und behauptete es könne sich nicht am Exchange Server anmelden. Dagegen half der Regkey "MaxTokenSize".

 

OWA bzw. IIS und ActiveSync funktionierten damit allerdings noch längst nicht. In Tests fand ich heraus, dass die Tokensize unter 9.000 Bytes liegen muss damit OWA wieder mitspielt. Dazu kann man den Benutzer aus sämlichen Gruppen austragen, leider wird das beim Kunden wenig Begeisterung hervorrufen, da er danach auf wenig bis kein Verzeichnis mehr Zugriff hat.

 

Die Temporäre Lösung sieht nun vor die Mitgliedschaften zu reduzieren. Es wird eine neue globale oder universelle Gruppe zu erstellt, die nur für diesen speziellen Benutzer erstellt wird. Er fliegt aus allen anderen GlobalenGruppen heraus und die neu erstellte Gruppe wird Mitglied der DomänenlokalenGruppen.

 

Ist als Bild vielleicht etwas verständlicher...

 

Gruppenverschachtelung Normal:

(B)enutzerY -> (G)lobaleGruppe1 -> (D)omänenlokaleGruppe1 -> Ressouce1

(B)enutzerY -> (G)lobaleGruppe2 -> (D)omänenlokaleGruppe2 -> Ressouce2

(B)enutzerY -> (G)lobaleGruppe3 -> (D)omänenlokaleGruppe3 -> Ressouce3

 

 

Gruppen temporär:

(B)enutzerY -> (G)lobaleGruppeY

-> (D)omänenlokaleGruppe1 -> Ressouce1

-> (D)omänenlokaleGruppe2 -> Ressouce2

-> (D)omänenlokaleGruppe3 -> Ressouce3

 

Der Benutzer wird nur noch Mitglied einer einzigen G-Gruppe, was die Anzahl der Gruppenmitgliedschaften nahezu halbiert. OWA + ActiveSync funktionieren wieder. Trotzdem bleibt der Zugriff auf alle Ressourcen garantiert.

 

Wenn sich nach der Migration Gruppen und Benutzer wieder in der selben Domäne befinden, werden die Mitgliedschaften (zurück) korrigiert.

 

 

Gruß :]

D.