Hallo, zum Monatsbeginn nochmals Rol mit einem kurzen Ausflug zu FIM CM. Unsere PKI Experten erhielten kürzlich die Kunden Anfrage zu dem Problem, daß beim FIM CM Bulk SC Issuance Client beim Austausch einer Smart Card während der Ausstellung der Fehler "The smart card is either superseeded or in key escrow" auftrat.
Ungünstiger Weise wurde dadurch aber die alte Smart Card deaktivieret und die neue lediglich zugewiesen aber nicht aktiviert. Somit war es dann nicht möglich einen neuen Request durchzuführen, ohne die Key History (ref. Certificate Filtering - MSDN – Explore Windows, Web, Cloud, and ...; http://msdn.microsoft.com/en-us/library/windows/desktop/bb468090.aspx) verloren geht. Das Verhalten trat bei etwa 10% der Clients auf.

Beim weiteren Troubleshooting hat sich dann aber gezeigt, daß man den wahren Fehler jedoch schon im IIS Log des FIM CM Webservers ausmachen kann. Per default wird es unter %SystemDrive%\inetpub\logs\logfiles aufgezeichnet.

Hier konnte man folgenden Eintrag ausmachen:

2011-12-13 09:46:44 202.1.91.30 POST /certificatemanagement/remoterequests.rem - 443 - 160.59.169.196 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+6.1.7601.65536;+MS+.NET+Remoting;+MS+.NET+CLR+2.0.50727.5448+) 413 0 0 46

Nach der zweiten Klammer kam der Error Code 413. Den sucht man nun in der  Http Status Codes Liste:
REST Endpoint Http Status Codes - Microsoft TechNet: Resources ...; http://technet.microsoft.com/en-us/library/gg334391.aspx

Status Code

Text

Cause

413

Request Entity Too Large

The request attempts to set too much data, or the requested range contains too many rows, returned data is too big.

Nun gibt es einige Referenzen, wie man vom Fehler 413 “Request Entity Too Large” auf die IIS Metabase Property UploadReadAheadSize kommen kann, z.B.:
HTTP 413 Request Entity too Large - Can't upload large files using IIS6; http://blogs.msdn.com/b/jiruss/archive/2007/04/13/http-413-request-entity-too-large-can-t-upload-large-files-using-iis6.aspx

Eine gute Referenz zur IIS Metabase Property UploadReadAheadSize finden wir dann unter
http://www.iis.net/ConfigReference/system.webServer/serverRuntime

uploadReadAheadSize

Optional uint attribute.
Specifies the number of bytes that a Web server will read into a buffer and pass to an ISAPI extension or module. This occurs once per client request. The ISAPI extension or module receives any additional data directly from the client. The value must be between 0 and 2147483647.
The default value is 49152.

Und genau diese Einstellung gilt es nun für den FIM CM Web Server mit den folgenden Schritten zu erhöhen:

1. Zunächst bitte ein Backup der Datei c:\windows\system32\intetsrv\config\applicationhost.config erstellen, die wir in Anschluß indirekt bearbeiten.

2. Nun bitte die Datei applicationhost.config öffnen und prüfen ob es schon einen Eintrag für uploadreadaheadsize gibt, falls ja bitte erst eruieren wieso der gesetzt wurde. Per default gibt es ihn nicht und wir wollen ja nicht einfach etwas verstellen.

3. Wenn uploadreadaheadsize nicht gesetzt ist, werden wir das nun wir folgt über dem Command Prompt vornehmen (bitte Leerzeichen nach Parameter /serverruntime nicht vergessen):

a) cd c:\windows\system32\intetsrv\config

b) appcmd.exe set config -section:system.webserver/serverruntime
    /uploadreadaheadsize:1048576 /commit:apphost

4. Zur Kontrolle die Datei c:\windows\system32\intetsrv\config\applicationhost.config nochmals öffnen und prüfen, ob uploadreadaheadsize auf den Wert 1048576 gesetzt wurde.

5. Jetzt noch iisreset ausführen um die Änderung aktiv zu schalten und testen, ob das Problem damit gelöst ist.

Anmerkung:
Der Wert 1048576 ist noch nicht sehr hoch und es kann sein, daß er weiter erhöht werden muß. Wenn der Fehler jedoch deutlich weniger häufig auftritt, ist man zumindest auf dem richtigen Lösungsweg.

Dann hoffen wir mal, einen potentiellen Stolperstein für den FIM CM Bulk SC Issuance Client ausgeräumt zu haben.
Gutes Gelingen, euer Rol