DOCUMENT:Q281253 15-AUG-2002 [iis] TITLE :File Change Notifications Are Lost When Content Is on UNC Share PRODUCT :Internet Information Server PROD/VER::4.0,5.0 OPER/SYS: KEYWORDS:kbCOMIS kbWin2000sp3fix ====================================================================== ------------------------------------------------------------------------------- The information in this article applies to: - Microsoft Internet Information Server version 4.0 - Microsoft Internet Information Services version 5.0 ------------------------------------------------------------------------------- IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base: Q256986 Description of the Microsoft Windows Registry SYMPTOMS ======== When content is located on a UNC share, File Change Notifications are lost. Changes to the content are not detected and cached content is sent to the client. This affects both static content and dynamic ASP content that is located on a UNC share. CAUSE ===== An unexpected network problem causes the File Change Notification request to be lost. This can be the result of any number of network related problems that cause the current session between IIS and the file server to close. When a request is made for content that is not in the cache, a new session may get established if the network conditions that caused the initial session to close have been resolved. However, IIS does not request File Change Notifications again. Therefore, any new content changes do not appear until the Web service is stopped and restarted. NOTE: If the cause of the File Change Notification being lost is due to the connection being closed or reset from the IIS server, make sure that you apply the hotfix for Q282185. This hotfix corrects an issue where the redirector incorrectly parses server message block (SMB) packets and closes the session unexpectedly. For additional information, click the article number below to view the article in the Microsoft Knowledge Base: Q282185 Indexing Service Loses File System Change Notification Request WORKAROUND ========== As a troubleshooting step and/or workaround, disable ASP and static file caching: To disable ASP file caching: 1. Open the Internet Service Manager (ISM). 2. Right-click the , and then click Properties. where is the name of your computer. 3. Click Edit to edit the WWW Service Master Properties. 4. On the Home Directory tab, click Configuration. 5. On the Process Options tab, select the "Do not cache ASP files" option. 6. Click Apply, and then click OK to save your changes and then restart IIS. To disable static file caching editing registry warning: WARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. You must add a value to the registry: HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters DisableMemoryCache: REG_DWORD: 1 For additional information, click the article number below to view the article in the Microsoft Knowledge Base: Q182626 Access Is Denied When Attempting to Put Files on FTP Server RESOLUTION ========== A supported fix is now available from Microsoft, but it is only intended to correct the problem that is described in this article. Apply it only to computers that are experiencing this specific problem. This fix may receive additional testing. Therefore, if you are not severely affected by this problem, Microsoft recommends that you wait for the next Windows NT service pack that contains this fix. To resolve this problem immediately, contact Microsoft Product Support Services to obtain the fix. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, visit the following Microsoft Web site: http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS NOTE: In special cases, charges that are ordinarily incurred for support calls may be canceled if a Microsoft Support Professional determines that a specific update will resolve your problem. The typical support costs will apply to additional support questions and issues that do not qualify for the specific update in question. The English version of the IIS 4.0 fix should have the following file attributes or later: NOTE: The IIS 4.0 hotfix was completed in May 2000. There are several newer IIS 4.0 hotfixes that include this one. If your file versions and dates are newer than these, you do not need to install this fix. Date Time Version Size File name Platform ------------------------------------------------------------- 5/17/2000 7:45:31PM 4.2.745.1 330,080 Asp.dll x86 5/17/2000 7:43:50PM 4.2.745.1 185,776 Infocomm.dll x86 5/17/2000 7:44:44PM 4.2.745.1 38,256 Ssinc.dll x86 5/17/2000 7:44:52PM 4.2.745.1 25,360 Sspifilt.dll x86 5/17/2000 7:44:31PM 4.2.745.1 228,496 W3svc.dll x86 5/17/2000 7:47:33PM 4.2.745.1 551,696 Asp.dll ALPHA 5/17/2000 7:45:54PM 4.2.745.1 304,912 Infocomm.dll ALPHA 5/17/2000 7:46:48PM 4.2.745.1 60,176 Ssinc.dll ALPHA 5/17/2000 7:46:54PM 4.2.745.1 39,696 Sspifilt.dll ALPHA 5/17/2000 7:46:36PM 4.2.745.1 383,760 W3svc.dll ALPHA To resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in the Microsoft Knowledge Base: Q260910 How to Obtain the Latest Windows 2000 Service Pack The English version of the IIS 5.0 fix should have the following file attributes or later: Date Time Version Size File name Platform ------------------------------------------------------------- 5/31/2001 3:31:22PM 5.0.2195.3649 332,560 Asp.dll x86 5/31/2001 3:31:42PM 5.0.2195.3649 245,520 Infocomm.dll x86 5/31/2001 3:31:42PM 5.0.2195.3649 62,736 Isatq.dll x86 5/31/2001 3:31:42PM 5.0.2195.3649 13,584 Infoadmn.dll x86 5/31/2001 3:32:02PM 5.0.2195.3649 7,440 W3ctrs.dll x86 STATUS ====== Microsoft has confirmed that this is a problem in IIS 4.0 and 5.0. This problem was first corrected in Windows 2000 Service Pack 3. MORE INFORMATION ================ Some network related problems do not cause the server message block (SMB) session between IIS and the file server to be lost. Instead, File Change Notifications are simply not returned or do not contain valid file information, which causes IIS to miss changes to the content. This fix cannot address those kinds of issues. Also, there are several conditions that can cause this symptom. Some of these conditions can cause the problem to persist or cause performance degradation, even when you apply the fix listed in this article. In these cases, it is necessary to identify why the File Change Notifications are not being returned or why they do not contain valid information. Some of the known issues and conditions are listed in this section. Troubleshooting information is provided to help identify the root cause of the symptoms. Common Causes for Losing File Change Notifications -------------------------------------------------- Some common causes for losing or not establishing File Change Notifications are loss of network connectivity, lack of permissions or invalid user accounts, exceeding the maximum command limit or work contexts for the redirector or server, the file server not returning complete information, or the file server not returning any notification at all. For additional information, click the article numbers below to view the articles in the Microsoft Knowledge Base: Q221790 IIS Runs Out of Work Items and Causes RPC Failures When Connecting to a Remote UNC Path Q271148 MaxMpxCt and MaxCmds Limits in Windows 2000 Loss of Network Connectivity: The network connection, on which the SMB session is established, may become disconnected. Therefore, the SMB session is lost. When the SMB session is lost, open file and directory handles are invalidated. Directory handles are used to establish File Change Notifications. Prior to this hotfix, when a session loss occurs, IIS loses any outstanding File Change Notifications and does not try to re-establish them, because the directory handle being used becomes invalid. With this fix, IIS now attempts to re-establish file change notifications on the first successful re-connection of an SMB session. For example, the next time an HTML file is retrieved from the file server, a new SMB session is created. At this time, IIS also attempts to re-establish File Change Notifications. Loss of network connectivity can occur for several reasons, including hardware problems, bugs in the client redirector, or bugs in the server code. One known cause is a bug in the Microsoft Windows 2000 redirector. This bug has been addressed by the fix included in Q282185. By using a network analyzer, you should be able to determine where the loss of connectivity is originating. See the "Troubleshooting" section of this article for more information. Lack of Permissions or Invalid User Accounts: For File Change Notifications to work, a directory handle must be created on the directory in question. When an SMB session is established, a specific user context is used. This context must have sufficient permissions to create a file handle on any of the directories. The account used by IIS is the account created when the virtual directory or Web site is created and a UNC path is used. The "Connect As" account must be an account with sufficient permissions on the file server for the directory tree in question. A supported configuration is the use of a domain account that is trusted by both servers. Often, users want to use non-domain accounts or no account at all (also known as Pass-Through Authentication). This method is not supported by Microsoft. Additionally, mapped drives are also not supported. This often fails because when IIS first starts, it enumerates the virtual directories, which include virtual directories on UNC shares, and then attempts to create a directory handle for each and establish File Change Notifications on them. This can fail because there is no account, an account without sufficient permissions, or an account that is unknown to the target file server. In those cases, the SMB session is not established or is established with a guest account that does not have proper permissions. Exceeding the Maximum Command Limit or Work Contexts for the Redirector or Server: This can occur if the amount of long term commands is greater than the negotiated maximum command limit between the client (IIS server) and file server. If an IIS server has a large number of sites or virtual directories mapped to a UNC path, they can exceed these limits. The solution is to increase the values for MaxCmds on the IIS server and MaxMpxCt on the file server side. This is important because each outstanding File Change Notification requires a work context. If there are not enough work contexts or if MaxCmds is too low, some File Change Notification requests will not be satisfied. The limit that can be used is the lesser of MaxCmds or MaxMpxCt, and the explicit number is sent from the server to the client in the negotiation part of an SMB session setup. For additional information, click the article numbers below to view the articles in the Microsoft Knowledge Base: Q221790 IIS Runs Out of Work Items and Causes RPC Failures When Connecting to a Remote UNC Path Q271148 MaxMpxCt and MaxCmds Limits in Windows 2000 The File Server Does Not Return Complete Information or the File Server Does Not Return Any Notification: When a File Change Notification is requested, IIS specifies whether to be notified only for changes in the current directory or to include changes in any subdirectories. ASP specifies only the current directory, and IIS specifies to include subdirectories. If the file server responds to a File Change Notification that occurs in a subdirectory, but it does not send complete path information, it is not possible to know which file in the cache to flush. Therefore, it will appear that IIS did not respond to the File Change Notification. A common indicator that this is a problem is that ASP pages in that same subdirectory may seem to get updated, while static HTML content does not. In other cases, a file server may respond with a status other than SUCCESS, but not include any other file change information. In that case, the return is ignored and treated as an error. This is normal. Some Samba systems exhibit this behavior. Another situation that can occur is a file server that does not send a notification at all. This can occur with system that attempt to multiplex their replies. For example, if a change occurs in a directory that IIS and ASP have both requested File Change Notifications for, the file server should send two replies; however, it may only respond to one. In each of these cases, analyzing a network trace will show what is occurring. Troubleshooting --------------- It is important to note some common troubleshooting tools and methods that apply to all causes of this symptom. Because the problem is network related, almost all of the causes can be identified by examining the network traffic between the IIS server and the file server. A network capture tool, such as Microsoft Network Monitor, can often provide the most useful and complete information in determining the cause. For example, by using Microsoft Network Monitor, the following steps have proved very effective in capturing the needed network traffic for inspection. The goal in using a network analyzer is to see all of the communication between IIS and the file server from the time that IIS starts until the File Change Notifications stop occurring, as indicated by stale content, and so on. Although this can result in a large capture file, it is necessary to capture valid data. An incomplete network trace can waste more time than it saves. 1. Stop all IIS services, and make sure that the IIS process is not running. In IIS 4.0, you can do this by closing the Internet Information Server Management console, and then running the following command at a CMD prompt: "NET STOP IISADMIN /Y" (without the quotation marks) In IIS 5.0, you can do this by closing the Internet Services Manager console, and then running the following command at a CMD prompt: "iisreset /stop" (without the quotation marks) Verify that the IIS process is not running by checking the Task Manager to make sure Inetinfo.exe is not loaded. 2. Configure Network Monitor. Start Network Monitor on the IIS server and configure it to capture data on the network between the IIS server and the file server where the content resides. To do this: a. On the Capture menu, click Networks. b. Choose the correct interface that is used to communicate with the file server. c. Configure the buffer settings to allow enough space to capture the entire communication up until the problem occurs. The size needed depends on the load as well as how long it takes before the problem appears. Common sizes are 100 MB to 2 GB. To set the buffer size, click Buffer Settings on the Capture menu, enter the size, and then make sure that the Frame Size is set to Full. d. Set a trigger to stop the tracing when the buffer is full. To do this, click Trigger on the Capture menu, select Buffer Space, and then choose 100%. For Trigger Action, select Stop Capture. 3. Start capturing. To do this, click Start on the Capture menu. 4. Start the IIS services. In IIS 4.0, you can do this by running the following command at a CMD prompt: "NET START W3SVC" (without the quotation marks) In IIS 5.0, you can do this by running the following command at a CMD prompt: "iisreset /start" (without the quotation marks) 5. When the problem occurs, stop the capture. To do this, click the Capture menu, and then click Stop. If the capture has stopped automatically because of the trigger and the problem has not yet occurred, you need to repeat the above steps by using a larger buffer. 6. When the problem has been captured successfully, save the capture by clicking the File menu, and then clicking Save As. NOTE: Although it is common to set filters to reduce the size of the trace, it is not recommended, because important frames may be missed. Microsoft recommends that you do not have any Microsoft Windows Explorer windows open or any mapped drives to the file server on the IIS server. This will reduce the number of sessions and applications that make File Change Notifications, so that the trace only contains the sessions and notifications for IIS. This makes analyzing the trace much easier. Things to Look for in the Captured Trace: The first things to identify in the trace are the SMB sessions that were established when IIS first started. This shows the account context used, as well as the negotiated worker contexts. You also want to identify that File Change Notification requests that were sent by IIS for each of the virtual directories. File Change Notification requests are long term commands, because the server does not reply to them until a file change actually occurs. When you have verified that they were sent from IIS, see if any were replied to by the server. Typically, you should use a known file that is not getting updated. For example, if Test.htm in a directory that has stale content, verify that a File Change Notification request was made for that directory or its parent directory (with the watch subdirectories flag set), and then see if the file server ever replies that a change was made. Examining the traces requires some knowledge of the SMB (CIFS) spec. In general, once you have found a File Change Notification request, you can use the MID (Multiplex ID) to find any corresponding reply from the server. Additional query words: kbIISCom ====================================================================== Keywords : kbCOMIS kbWin2000sp3fix Technology : kbiisSearch kbiis500 kbiis400 Version : :4.0,5.0 Hardware : ALPHA x86 Issue type : kbbug Solution Type : kbfix ============================================================================= THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY. Copyright Microsoft Corporation 2002.