iis 7 - 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 HKLMSoftwareMicrosoftASP.NETFCNMode 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.