IIS 7 500 Error When Accessing Virtual Folders

Question

I'm having an issue with IIS, attempting to reach a virtual folder path.

My application (.Net 3.5 SP1, MVC 1.0) generates reporting results files that land via a virtual path on a Unix based vfiler (I think the target is a NetApp appliance). When my users attempt to access the reports via an http request through IIS (Hosted on WinServ 2k8 R2 64-bit), they receive the following 500 error:

Log Name:      Application
Source:        ASP.NET 2.0.50727.0
Date:          3/14/2012 1:07:20 PM
Event ID:      1185
Task Category: File Monitoring
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      %APPLICATION_SERVER%
Description:
Failed to start monitoring changes to '%PATH_TO_FILE_SHARE%' because the network BIOS command limit has been reached. For more information on this error, please refer to Microsoft knowledge base article 810886. Hosting on a UNC share is not supported for the Windows XP Platform.

I don't have a lot of visibility in this environment (I'm the vendor of the app) but the issue seems to be accumulative, and only when IIS brokers the connection. If I manually type in the path in to a command/run window on the client machine, I am able to access the file - leading me to believe it is not permissions based. I am also able to access it in IIS Manager. When I do an IISRESET, the issue is briefly abated.

Any thoughts? I tried following the instructions in the (fairly old) KB article, but that has not helped.

EDIT: I should note that this is a production system

Answer 1

For reference, the following article allowed us to resolve the issue: http://blogs.msdn.com/b/carloc/archive/2009/09/06/hosting-on-a-unc-share-is-not-supported-for-the-windows-xp-platform.aspx

We set the HKLM\Software\Microsoft\ASP.NET\FCNMode value to "2" which was able to reduce our multiplex connections down to a manageable value. Microsoft's official recommendation was to increase the multiplex connection limit on the SAN, however that was not feasible for us as it would have required pushing down all the CIFS shares hosted on the SAN.

Hope this helps someone in the future.

Answer 2

This is one of the worst problems I've come across when hosting with IIS.

Here are all the things we've tried, to no avail - I'm posting them for you in case maybe they'll work in your case:

On IIS box:

1. DWORD FCNMode at HKLM\Software\Microsoft\ASP.NETchange/add with value 1 to disable.
2. DWORD FCNMode at HKLM\SOFTWARE\Wow6432Node\Microsoft\ASP.NET change/add with value 1 to disable.
3. DWORD MaxCmds at HKLM\SYSTEM\CurrentControlSet\Services\lanmanworkstation\Parameters change/add with value > 50, max of 65535 - we tried values all the way up to 65535.
4. DWORD MaxMpxCt at HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters change/add with value > 50, max of 65535 - on the IIS box, you'll want to configure this to be the same as MaxCmds.
5. Change Application Pool to have "No Managed Code"
6. Stop IIS from checking subdirs for web.config files - Go to the Top level Server in IIS manager -> configuration editor -> section "system.applicationHost/sites" -> open the Collection -> Within each site, change the virtualDirectoryDefaults->allowSubDirConfig to False -> Close collection editor and click Apply.

On File Server:

1. DWORD MaxWorkItems at HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters change/add with value > 4096, max 65535 - this is most easily calculated by IIS boxes * MaxCmds value on IIS box -- or just max at 65535.
2. DWORD MaxMpxCt at HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters change/add with value > 50, max 65535 - I was under the impression that this is negotiated between the client and the server which the lower value of the two is what is applied. We tried various values up to max.

I'm going to keep adding to this answer as we try/fail with various new options. One more thing I should mention - if you have weird flaky UNC path resolution errors: "Specified network name is no longer available or you do not have permission" - temporarily try disabling jumbo MTU and any offloading options your NICs have (on both the IIS and File Server boxes) to see if that helps (it fixed our problem with HP NICs).

UPDATE: We enabled SMB 2 on our file server (Linux NAS) and with the registry changes we've already made to the IIS box, we've finally stopped receiving the dreaded Network BIOS limit errors.