Kürzlich hatte ich bei einem Kunden zwei Probleme:

Eins war schon unter DSM 7 RTM vorhanden, nämlich dass einige Admins beim Versuch mit der DSMC zu arbeiten, diesen unbekannten SOAP-Fehler #607 erhielten. Bei anderen Admins lief aber alles problemslos und wir konnten uns keinen wirklichen Reim auf das Verhalten machen.

Nachdem wir dann kürzlich auf DSM 7 Service Pack 2 aktualisiert hatten (und dabei auch gleich die PowerShell Extensions auf den aktuellen Release upgegradet haben), liefen auch einige Funktionen der PSX nicht mehr. Es wurde schon auf einen Bug in den PSX getippt, aber ein kurzer Test zeigte, dass die entsprechenden Funktionen in meiner Testumgebung problemlos funktionierten. Erstaunlicherweise konnte der Kunde die gleiche Funktion, die bei ihm über PSX Probleme machte und einen Fehler zurücklieferte, über die DSMC problemlos ausführen.

Mein Entwickler-Kollege kam dem Problem dann auf die Spur...

Nachdem die Logfiles des Administration Webservice und des Internet Information Servers keine wirklichen Hinweise auf die Problemursachen enthielten, entschieden wir uns dazu, Netzwerk-Traces zu machen. Es wurde dabei der fehlschlagende Versuch über die PowerShell Extensions protokolliert und in einem zweiten Trace das funktionierende Vorgehen über die DSM Konsole. Dadurch konnten wir vergleichen, worin sich die Aufrufe unterschieden.

Nach eingehender Analyse kam mein Kollege dann mit einer Vermutung auf mich zu: Er hatte in den Traces entdeckt, dass der User offensichtlich Mitglied in sehr vielen Benutzer-Gruppen war und dass dadurch der http-Header der Anfrage an den IIS ziemlich genau 16 KByte groß wurde. In dem Trace, wo der Aufruf nicht funktionierte, hatte er zusätzlich in einem Antwortpaket die Meldung "Bad Request - Request Too Long" und den http-Returncode 400 entdeckt.

In dem Trace der DSMC – der Benutzer war natürlich in den gleichen Gruppen – hat es offensichtlich deswegen funktioniert, weil diese in den Anfragen einen kürzeren User-Agent verwendet und daher die Anfrage ein paar Bytes unter der Grenze von 16 KByte geblieben ist.

Wir haben dann eine Weile gegooglet und rausgefunden, dass es tatsächlich passieren kann, dass diese Fehlermeldung zurückkommt, wenn der Benutzer über sehr viele Gruppenmitgliedschaften verfügt und dadurch der http-Header mehr als 16 KByte groß wird (http://support.microsoft.com/kb/2020943). Wie in diesem KB-Artikel beschrieben, haben wir dann auf dem IIS die Registry-Werte "MaxFieldLength" und "MaxRequestBytes" gesetzt und siehe da – sowohl das Problem mit den PowerShell Extensions als auch das Problem mit dem unbekannten SOAP-Fehler #607 waren dann nach einem BLS-Neustart behoben.