IIS6 – Caching of UNC content: Reverting back to the Last-Modified Time method

As explained in the white paper on IIS and remote storage, IIS 6.0 offers two methods of file caching which need to be considered when configuring your server to host remote content.  The two methods are on-demand polling based (using the content file’s Last-Modified Timestamp), and change notification based (using the File System Change Notifications).  The white paper does an excellent job explaining in detail what these two methods entail, specifically in the Optimizing IIS Caching for Remote Content section. 


Your IIS server may have a file system that is not reliable in providing change notifications to IIS; if so, you should revert back to using the polling method referred to as Last-Modified Time method.  One way to tell that the Last-Modified Time method is better for your web application environment than the Change Notification method is if you see stale content being served by IIS when the actual content files have been changed, and you have the Change Notification method enabled.


Last-Modified Time is the default caching method.  However, if you have disabled it and need to revert back to the Last-Modified Time method, follow these steps:


1)      Set the registry property DoDirMonitoringForUNC, a DWORD value located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters, to 0.

2)      Set the registry property EnableChangeNotificationForUNC, a DWORD value located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ASP\Parameters, to 0.


After enabling the Last-Modified Time method, you may need to change how often IIS checks the Last-Modified Time property of the content files.  IIS will by default check the files every five seconds; this may be too short or too long for your site.  You can configure the sampling intervals for static and ASP content with the following registry keys, which are not present by default:


1)      For static content like HTML or STM files, set the registry property FileAttributeCheckThreshold, a DWORD value located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters.  Give it a value in seconds, between 0 and 4,294,967.

2)      For dynamic ASP content, set the registry property FileMonitoringTimeoutSeconds, a DWORD value located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ASP\Parameters.  Give it a value in seconds, between 0 and 4,294,967.


Comments (8)

  1. Uday says:

    Hi Mike,

    It seems that link to that white paper is broken. could you please update the link?


  2. Mike Laing says:

    Hi Uday,

    Thanks for pointing this out.  I’ll see if I can find out what happend to the content location and get it updated.



  3. Mike Laing says:

    Hi Uday,

    I’ve got the ball rolling on getting the link fixed.  It’s actually a problem on the Technet side of things that they’re aware of and working on a fix.



  4. See-Heng says:

    The link to the white paper is still broken

  5. Mike Laing says:

    I’m not sure why that link keeps breaking.  Sorry about that.  I found the whitepaper in the IIS7 Operations Guide though…you can see it here (assuming this link doesn’t break too!):


  6. Ng Boon Seong says:

    Will the registry change for the dynamic ASP content applies to ASP.NET aspx page and /bin/* dlls as well?

  7. xdansmith says:

    this apparently doesn't work for ASP.Net content. I've been searching around for a solution, basically what I'm doing is pointing an IIS website to a UNC path shared via VMWare so that windows can host files that exist on the OS X host. Long story short, ASP.net is caching the source files, so when a .CSHTML  file changes, asp.net doesn't pick up the change and continues to show the original version until IIS is reset. Any insight?

Skip to main content