SharePoint Explorer View Error white paper from Microsoft微软关于SharePoint 资源管理器视图出现各种问题的白皮书
MicrosoftÒ SharePoint Services
Understanding and Troubleshooting the SharePoint Explorer View
Microsoft Product Support Services White Paper
Written by Steve Sheppard
Additional contributions by Dustin Friesenhahn, Dan Szepesi, Dan Winter, Jon Waite, Tony McIntyre, Alonzo Millow, Scott Jiles and Drew Leaumont.
Published on September 25, 2006
Abstract
The Explorer View feature that is included with Windows SharePoint Services and is also available in Microsoft SharePoint Portal Server lets users access files stored in the SharePoint database using the familiar Windows Explorer interface. To the end user, this appears to be a very simple and robust feature. In reality, it is the result of a complex series of interactions between many individual components provided by separate Microsoft products.
This white paper is an effort to accomplish three things:
- Provide an overview of the Explorer View architecture.
- Document the causes and resolutions of problems you are likely to encounter when using the Explorer View in a corporate environment.
- Describe basic troubleshooting steps to be performed before engaging Microsoft Customer Support Services (CSS).
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
2006 Microsoft Corporation. All rights reserved.
IE, Microsoft Internet Explorer, Microsoft FrontPage, Microsoft Office, SharePoint Portal Server, Windows SharePoint Server, Windows Server 2003, Windows XP are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
The names of actual companies and products mentioned herein may be the trademarks of their respective owners.
Contents
Introduction 1
Understanding WebDAV and FPRPC 3
Windows WebDAV Client details 3
FrontPage RPC details 5
Protocol features 6
The Two Faces of Explorer View 9
Explorer View using the WebDAV Protocol 9
Explorer View using the FPRPC protocol 10
Customizing The Explorer View Experience 11
Removing the Explorer Bar from the Explorer View 11
Disabling the "Unsafe" Warning when you right-click 11
Forcing Explorer View to use FPRPC 12
Option 1: Hosting documents on non-standard ports 12
Option 2: Use SSL encryption 12
Option 3: Disable the Web Client Service 13
Forcing Explorer View to use WebDAV 13
important Information for troubleshooting Explorer View 15
Explorer View and SMB 15
The SMB and ICMP protocols 15
Windows Server 2003, SMB, and strict name checking 16
WebDAV, IIS, and SharePoint 16
Configuring security zones 17
Application support for WebDAV 17
Unable to access a site using FQDN 18
The Web Client Service and sites on ports other than 80 18
Reinstalling FPRPC via Webfldrs.MSI 18
Installing WebFolders on Windows Server 2003 19
Common Explorer View Problems 20
Stopping and starting the Web Client Service 20
Explorer View does not work on Windows Server 2003 20
Explorer View causes users to be prompted for credentials 21
"Cannot find 'file://\\...' " error message appears when using FPRPC 21
Drag-and-drop operations using Explorer View fail 22
Explorer View is very slow to render 22
WebDAV continues to use a proxy after it is disabled in Internet Explorer 23
Long URLS do not work with FrontPage RPC 24
Appendix A 25
Transcripts of successful Explorer View conversations 25
Explorer View using WebDAV 25
Explorer View using FPRPC 29
Information to gather before engaging Microsoft Customer Support Services 36
Conclusion 37
This Page Intentionally Left Blank 38
Introduction
The Explorer View is a feature of Windows SharePoint Services that allows you to access a document library as if you were manipulating a file system through a Windows Explorer window. This functionality leverages a feature of Internet Explorer known as the Web Folder Behaviors.
The Web Folder Behaviors were introduced in Microsoft Internet Explorer 5 to let you navigate to a folder view of file data stored on a Web site. On a default workstation installation, it will attempt to connect using SMB in addition to Web Distributed Authoring and Versioning (WebDAV) and the FrontPage Server Extensions Remote Procedure Call (FPRPC) protocol.
The only protocols capable of directly manipulating file data stored in SharePoint are WebDAV and FPRPC. Both of these protocols define how to set and retrieve properties on HTTP resources, but in any given situation, one may have more capabilities than the other.
The files and folders represented in SharePoint do not actually exist as individual items on a file system. They are just representations of file data and properties stored in the SharePoint database. It is only through the complex interactions of a large number of technologies that we can manipulate them as if they were actual files and folders. At a high level, that stack of technologies and their various relationships can be envisioned like this:
This diagram should give you some idea of the components involved. Fortunately, for purposes of understanding and troubleshooting the Explorer View, these components can be ignored. Troubleshooting the Explorer View typically only involves inspection of the Internet Explorer configuration, the operating system's network configuration settings, or the actual packet data as it traverses the network. For these reasons, any direct, detailed discussion of the client and server components, their architecture, or their configuration, are outside the scope of this white paper.
As you can see in the diagram above, there are two possible paths the client can take to access SharePoint data. Which stack is used depends on the design and configuration of the client operating system, application, network environment, and server configuration.
With regard to troubleshooting the SharePoint Explorer View, you only need to concern yourself with the two protocols capable of accessing data stored in SharePoint via the Explorer View. These two protocols are WebDAV and FPRPC:
- WebDAV is a simple extension to the HTTP protocol based on a public specification. It provides an extended vocabulary that defines how basic file functions, such as copy, move, delete, and create folder, are performed across HTTP.
- FPRPC provides WebDAV capabilities using extensions to the HTTP vocabulary, but it also has the ability to embed more complex Remote Procedure Call (RPC) communications in the data portion of the packet.
Understanding WebDAV and FPRPC
Before discussing these protocols, it is important to point out that they are provided by two different components, the Web Client Service and WebFolders. From this point forward, we will primarily discuss this difference at the protocol level and only refer to the hosting component when absolutely necessary.
The Microsoft WebDAV implementation is based on a public standard for authoring and versioning via HTTP. The vehicle used by the Windows development team to provide WebDAV client support is the Web Client Service.
The Web Client Service is built as part of the Windows operating system. Any client application running on Windows has the ability to access a WebDAV resource transparently by simply accessing drives mapped in the operating system or using the Windows Networking APIs. No special knowledge of WebDAV is required by the developer or the application.
FPRCP is a Microsoft technology that is primarily used for its value-added FrontPage capabilities. These provide robust content management features that are detailed later in this document, such as custom properties and alternate encodings. The components that provide FPRPC are older than those which support WebDAV. Explicitly using the functionality provided by FPRPC in your application requires specific knowledge and coding by the developer.
Windows WebDAV Client details
The WebDAV support in Microsoft Windows XP is a client only. Microsoft Windows Server 2003 provides both a WebDAV client (the Web Client Service) and a WebDAV server (the WebDAV extension in Internet Information Services 6.0). The client feature is not available on Microsoft Windows 2000. Some of the obvious benefits of building WebDAV client capabilities into the operating system are that it:
- Provides you with an integrated way to access the Web folders provided by Internet Information Services (IIS) and SharePoint.
- Manages files and folders via WebDAV using Windows Explorer.
- Supports the mapping of drives to a Web folder using Windows Explorer, My Network Places, the Net Use command, or the WNET APIs documented in MSDN.
Because the Web Client Service was built together with the rest of these operating systems, the look and feel of the resources it provides reflect those of Windows XP and Windows Server 2003. This is why the icons and the context menu choices on an Explorer View page are similar to those of Windows Explorer when it is using the Web Client Service and WebDAV as the underlying communication mechanism.
A subtle advantage of the Web Client Service is that it is one of the built-in network providers. This means that it is automatically queried whenever a connection attempt is made using the Windows networking APIs. You can easily see a list of the providers installed on your computer by following these steps:
- On the Start menu, right-click My Network Places and then click Properties.
- On the top menu bar, click Advanced and then click Advanced Settings.
- Click the Provider Order tab.
You will see a dialog box with your provider order listed. The screenshot below shows the default provider list in the default order for Windows XP. Note that the Web Client Network (WebDAV) is last in the list.
For more details on providers see chapter 13 of Microsoft Windows Internals, Fourth Edition.
You should not alter the provider order unless you are very sure of the impact those changes will have. For example, reversing the order of the Microsoft Windows Network and the Web Client Network will improve performance accessing WebDAV resources, but this has some unintended side effects.
By forcing the client to connect using WebDAV first, you will have to wait for it to fail every time you access Microsoft Windows Network (SMB) resources. The overwhelming majority of connections made by typical users are to SMB resources. Therefore, you have effectively reduced the overall performance of the client.
Additionally, you will not be able to connect to some servers at all if the following things are true:
- You have not disabled strict name-checking on the server.
- You are attempting to access them using SMB.
- You are using a name other than their FQDN or NetBIOS name.
FrontPage RPC details
WebFolders is the underlying technology that lets FrontPage and other applications in the Office suite of products, like Word and Excel, to manage content and edit documents via HTTP.
Unlike the Web Client Service, WebFolders is not a Windows network provider. Because of this, it has a few limitations you should be aware of:
- Only applications using the WebFolders APIs can create connections using FPRPC. The only applications that are included with the operating system that have this capability are Windows Explorer, My Network Places, and Internet Explorer. FPRPC can be included in any application by leveraging the FrontPage Server Extensions Remote Procedure Call protocol.
- WebFolders currently ships in one operating system, Windows XP. This means Windows Server 2003 does not support FPRPC out of the box.
- WebFolders is not a Windows network provider, therefore you cannot map drives using WebFolders via Windows Explorer or the Net Use command.
Here is a list of the current distribution vehicles for WebDAV and FPRCP components:
WebDAV | FPRPC | |
Internet Explorer 5 | No | 1.5 |
Windows 2000 | No | 1.0 |
Windows XP | Yes | 1.5 |
Windows Server 2003 | Yes (Off by default) | No |
Office 2000 | No | 1.5 |
Office XP | No | 2.0 |
Office 2003 | No | 2.5 |
SPS 2001 | No | 2.0 |
SPS 2003 | No | 2.5 |
Windows Update | No | 2.5 |
The fact that the WebFolders components were built prior to Windows XP is the reason that the icons and context menu options do not match those of Windows Explorer.
Protocol features
FPRPC and WebDAV each have a different set of capabilities largely determined by their original purposes. As we have said previously, FPRPC was originally designed as a mechanism to support content editing and management. It was only intended to be used by Microsoft FrontPage to interact with the specific functionality provided by FrontPage Server Extensions, not as a general purpose networking protocol.
The fact that these two protocols were designed with different purposes means that they have different features, some of which overlap. This overlap allows them to be used interchangeably for many operations supported by the Explorer View feature of SharePoint.
The fact that they do not provide exactly the same feature set means that in some instances customers may want to use one protocol over the other. Unfortunately, there is no obvious or user-friendly way to force the Explorer view to use a specific protocol.
Before trying to manage which protocol Explorer View will use, you should first understand the features of each protocol. To that end, we have provided a short list of their features:
Protocol feature comparison chart
Feature | Windows WebDAV | FPRPC |
Browse | Yes | Yes |
Open/Save | Yes | Yes |
Win32 APIs | Yes | No |
UNC/Mapped Drive | Yes | No |
SSL | No | Yes |
Custom Properties | No | Yes |
Alternate encodings | No | Yes |
Basic Authentication | Registry change | Yes |
FPSE Integration | No | Yes |
Root level browsing | Yes (requires DavWWWRoot) | Yes |
Alternate web ports | No | Yes |
After reviewing the features above, you should have a better understanding of the capabilities of each protocol and some idea of why you might want to use one over the other.
DavWWWRoot is a special keyword that alerts the WebDAV client that you are referring to the root of a WebDAV server. A simple validation of this can be obtained by linking a drive to the root of the SharePoint server. An example of using this keyword would be:
Net Use * http://www.adatum.com/DavWWWRoot
A directory listing of the resulting drive connection will produce output similar to this example:
The Two Faces of Explorer View
Because there are two different protocols for accessing data via the SharePoint Explorer View, you may experience two different levels of functionality when accessing the same data. Now that you understand the capabilities of each of these protocols, you can easily tell which is in use by examining a functioning Explorer View page.
Explorer View using the WebDAV Protocol
The screenshot below is of an Explorer View page rendered using the WebDAV protocol. You will notice two things:
- The folders have the same 3D appearance you typically see in Windows XP.
- The panes on the Explorer Bar and the context menu have a robust set of options that match those in Windows Explorer.
Screenshot of the Explorer View using WebDAV
We have implied that the Web Client Service is more tightly integrated with Windows, therefore, it should come as no surprise that the appearance of the Explorer View when using WebDAV matches that of Windows Explorer.
Explorer View using the FPRPC protocol
After looking at the screenshot of the Explorer View using the WebDAV protocol and comparing it to the screenshot below of the Explorer View rendered using the FPRPC protocol, you can easily see the differences:
- The folders have the older, flat appearance of Windows 98.
- The Explorer Bar and the context menu are missing many of the options available when you render the Explorer View using WebDAV.
Screenshot of the Explorer View Using the FPRPC
As we previously stated, the FPRPC components were built prior to Windows XP and Windows Server 2003, and they were designed for a different purpose than the Web Client Service. This explains the difference in the appearance of the icons and context menus.
Customizing The Explorer View Experience
Removing the Explorer Bar from the Explorer View
Many people have expressed a desire to change the appearance of the Explorer View. For example, most people would prefer to see the items in the Explorer View in the Details view rather than the default thumbnail view.
Unfortunately, the Web Folder Behavior, which ultimately renders the content in the Explorer View, does not have a mechanism to configure this. The one thing you can do is remove the Explorer Bar. If you switch your default view in Windows Explorer to the classic view, it will disable the Explorer Bar in the Web Folder Behavior.
Disabling the "Unsafe" Warning when you right-click
When you right-click in an Explorer View you will see this warning:
This warning is the result of the default security settings in Internet Explorer regarding launching applications from within an IFrame. You can change this setting by following the steps below:
- Open Internet Explorer.
- On the menu bar, click Tools and then click Internet Options.
- Click the Security tab
- Click the appropriate zone.
- Click Custom Level.
- Select Enable for item labeled Launching programs and files in an IFRAME
- Click OK.
- Click Yes when prompted to change the settings,
- Click OK.
- Restart Internet Explorer.
Forcing Explorer View to use FPRPC
If you need specific functionality provided only by FPRPC and you want to coerce the Explorer View to use that protocol, you have a few options. The first two can be implemented on the server side, which greatly reduces the amount of work involved. They rely on a limitation of the current release of the WebDAV client implementation, which may be different from the default WebDAV specifications. This limitation is the inability to access WebDAV resources hosted on ports other than 80.
This limitation is likely to disappear with the release of the Microsoft Windows Vista operating system so there is some risk in using it as a long term solution.
The third option is more of a brute force choice and is implemented on the client. It greatly increases the cost and the implementation effort.
Option 1: Hosting documents on non-standard ports
This option appears to be the easiest to implement, but it has some subtle side effects:
- Without some complicated DNS trickery you will have to remember to add the port to the end of the URL every time you type it in, for example: HTTP://server:8080
- You cannot use the Microsoft WebDAV implementation to access resources on this site at all. This is a limitation of the Microsoft WebDAV client, not a limitation of the WebDAV protocol. You would have to map this site back to the standard Web port (80) to be able to access it again using the Microsoft WebDAV implementation.
- Most monitoring tools will not recognize the traffic to and from this site to be HTTP. This makes troubleshooting slightly more difficult.
Option 2: Use SSL encryption
This is really a variation on the first option with a different set of side effects. Encrypting traffic using SSL forces the server to use port 443, which is not supported by the Microsoft WebDAV client implementation and will cause Explorer View to fail over to FPRPC. The side effects are:
- You will not have to type in the port at the end of the URL, but you will have to use the HTTPS moniker instead of HTTP when entering the URL.
- Your server's CPU will take on the additional load of encrypting and decrypting all traffic to and from the site. You will also need to buy a certificate or implement a certificate server in your environment.
- Most monitoring tools will not recognize the traffic to and from this site to be HTTP. This makes troubleshooting slightly more difficult.
- The traffic to and from your site will be encrypted on the wire, which eliminates any troubleshooting of these sites using standard network monitoring tools.
- You cannot use WebDAV to access resources on this site at all. You would have to map this site back to a standard port to be able to access it again using WebDAV.
Option 3: Disable the Web Client Service
This service hosts the WebDAV client functionality on Windows XP and Windows Server 2003. By disabling the service, you eliminate all native WebDAV client capabilities from that computer. This choice has the following ramifications:
- You cannot map a drive to any Web folder. When you attempt to access a URL through Windows Explorer or attempt to map a connection using the Net Use command, Windows attempts to use the WebDAV protocol just like any other supported protocol installed on the machine to access that resource. By disabling the Web Client Service, you have removed that protocol from the available choices and attempts to connect to WebDAV resources will fail.
- Any applications that require a WebDAV protocol on the computer will no longer function. While Microsoft does not maintain a list of applications that require the WebDAV protocol, some Microsoft products do take advantage of it from time to time.
If you choose to implement this workaround, it is your responsibility to test the applications and configurations in your environment to make sure that this change does not adversely affect their functionality.
Forcing Explorer View to use WebDAV
The Explorer View prefers WebDAV over FPRPC. Because of the underlying design of the Explorer View and the default network provider order, it always tries to use SMB first, then WebDAV. Only when SMB and WebDAV have failed does it actually attempt to use FPRPC. This means that forcing the Explorer View to use WebDAV is more a case of creating an environment that makes sure WebDAV is successful instead of actually forcing the Explorer View to choose it.
The next logical question is what ensures WebDAVs success? Here is a list of things that you should avoid if you want WebDAV to be used as the underlying protocol for the Explorer View:
- Make sure all computers accessing the Explorer View have the Web Client Service enabled and running. This is the default behavior for Windows XP, but not for Windows Server 2003.
- Only host content on the default Web port of 80. If you need to host multiple Web sites on a single server, use host headers or multiple IPs to make those Web sites unique.
- Do not encrypt Explorer View traffic using SSL. SSL uses port 443, and the Microsoft WebDAV implementation does not work on ports other than 80.
important Information for troubleshooting Explorer View
Explorer View and SMB
While Explorer View does not use the SMB protocol to access SharePoint, it will almost always attempt to use that protocol first. This is a side effect of the SharePoint browser script that attempts to find a reliable protocol for the Explorer View. Because there is no way to directly specify that a particular protocol should be used when rendering the Explorer View, SharePoint uses a script to test for a successful connection and then, if necessary, rewrites the URL and tries again in an effort to trick Windows into trying a particular transport.
The script causes the computer to first attempt to use the normal transports installed on the server, usually just SMB and WebDAV, and if those fail it will rewrite the URL to leverage the FPRPC protocol. Because of this, if you have additional transports that are higher in the network provider order than Web Client Network, you may experience longer delays in rendering the Explorer View.
See the section titled "Windows WebDAV Client Details" for a discussion on adjusting the network provider order.
The SMB and ICMP protocols
These two protocols have more in common than you may think. The Microsoft SMB protocol implementation comes in two flavors, a TCP over NetBIOS version and the direct hosting version. The NetBIOS over TCP version uses ports 137, 138, and 139 for the actual SMB traffic. The direct hosted version uses port 445.
In addition to these ports, both versions of SMB send an initial ICMP echo request to the target server. If this request succeeds but a connection cannot be made using 137, 137, 139, or 445, then the SMB protocol will experience multiple retry attempts resulting in delays in rendering the Explorer View. This delays the inevitable SMB failure and the transition to the other protocols which may actually succeed.
For this reason, if you block access to ports 137, 138, 139, or 445 on your server, you should also block ICMP to improve Explorer View performance.
The usage of ICMP by the SMB protocol is documented in KB article 832017, "Service overview and network port requirements for the Windows Server system" in the "Server" section.
Windows Server 2003, SMB, and strict name checking
By default, Windows Server 2003 does not respond to SMB queries that use a server name other than the server's true NetBIOS name or FQDN. If this is attempted, the server will respond with a STATUS_DUPLICATE_NAME error that looks like this in a Network Monitor trace:
SMB: C session setup & X
SMB: R session setup & X
SMB: C tree connect & X, Share = \\WWW.ADATUM.COM\IPC$
SMB: R tree connect & X - NT error, System, Error, Code = (189) STATUS_DUPLICATE_NAME
Because of the robust nature of the Microsoft SMB implementation, the client will attempt this connection many more times before failing. This can cause significant delays in rendering of the Explorer View.
We can force the server to respond to SMB requests regardless of the server name being used and thereby improve the performance of the SMB portion of the Explorer View protocol negotiation. While this will not result in a successful SMB connection being created, it will result in failing over to WebDAV much faster.
KB article 281308, "Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name" describes how to use the DisableStrictNameChecking registry key to resolve this problem.
WebDAV, IIS, and SharePoint
Many people are under the misconception that SharePoint uses the WebDAV functionality provided by IIS 6.0. Actually, SharePoint provides its own WebDAV implementation using the Stsfilt.dll ISAPI filter that is installed with both Windows SharePoint Services and SharePoint Portal Server. Enabling or disabling the WebDAV extension in IIS 6.0 has no effect on SharePoint functionality. By default, the IIS WebDAV extension is disabled:
You only need to enable WebDAV on IIS if you want to use the Web Sharing feature.
Configuring security zones
If you are unfamiliar with security zones and how to configure them, documentation is available in the Microsoft Internet Explorer online documentation. Great care should be taken when adjusting these settings because improperly configuring them can result in exposing security holes in your environment.
The setting within security zones that affects Explorer View functionality most often is the User Authentication setting. This setting is found in the Custom Level section for each zone. Depending on how you are accessing your site, you may need to specifically add the site to one of the zones or change the Authentication setting for the zone to properly control how authentication is handled.
Application support for WebDAV
There is a common misconception that applications that want to access resources via WebDAV must be created with this capability in mind, and this is not true.
Because the Web Client Network is a standard network provider in Windows XP and Windows Server 2003, it can be accessed using any of the standard Windows Networking APIs which are used by most applications to create a connection to a remote file system. As an example of this, you can use a simple application like Notepad.exe to access resources via WebDAV, which the screenshot below demonstrates:
Unable to access a site using FQDN
How you access your site can have an effect on the Explorer View as well. If you are accessing your intranet site using FQDN, you will likely want to add the site to the Trusted Sites zone on your client computers. When Internet Explorer is given a URL with dots (.) in it, it automatically puts that site into the Internet security zone. The default Authentication setting for this zone is Automatic logon only in Intranet zone. This will not allow SharePoint, much less Explorer View, to function without prompting you.
If you are accessing your site using the server's NetBIOS name and you are using the default settings in the Intranet security zone, then you should already have the correct authentication settings for accessing the Explorer View.
The Web Client Service and sites on ports other than 80
If a site is hosted on a port other than 80, then the Explorer View will be forced to use FPRPC. The Web Client Service is not capable of handling communications on ports other than 80, so this type of connection cannot succeed, and this will result in a failover to FPRPC. There is no workaround for this behavior.
Reinstalling FPRPC via Webfldrs.MSI
Executing the Webfldrs.msi package from C:\%SystemRoot%\System32 has been touted from time to time as a way to refresh the WebFolders configuration in Windows XP. This probably originates from KB article 888123, "You cannot connect to a Web folder from a Windows Server 2003 or Windows XP x64 machine," which describes how to install WebFolders on Windows Server 2003. Unfortunately, most of the time this will just result in making things worse. To understand why, you must examine the contents of the Webfldrs.msi file. You can do this using Orca, the MSI database editor.
As you can see from the version information in this screenshot, the files contained in the MSI file are much older than anything you are likely to have on your system today. For example, the Office System 2003 version of these DLLs start with a major version number of 11.
For this reason we would not recommend you repair your WebFolders installation using the Webfldrs.msi unless you have never installed Office on the computer. Even then, you should install the software update for WebFolders found in KB article 892211, "Description of the Software Update for Web Folders: January 25, 2005."
Installing WebFolders on Windows Server 2003
Windows Server 2003 does not ship with the WebFolders technology. If you need this functionality on a computer running Windows Server 2003, to support the SharePoint Explorer view for example, KB article 888123,"You cannot connect to a Web folder from a Windows Server 2003 or Windows XP x64 machine," describes how to accomplish this. We would recommend that you also install the software update for WebFolders found in KB article 892211, "Description of the Software Update for Web Folders: January 25, 2005."
Common Explorer View Problems
Now that we have had a high level overview of the Explorer View technology, let's look at some common problems you may encounter.
Always restart your browser after making any Internet Explorer configuration changes to make sure you get consistent results.
While it would be quite valuable to have a series of flowcharts that walk you through troubleshooting an Explorer View problem, it is simply not reasonable to provide that level of detail on such a complex subject in a white paper.
Instead, we will use the approach of providing you with documented solutions and leaving it to you to determine which solution applies to your problem. Along with the solutions we will attempt to describe the symptoms for the problem well enough so that you can match them up fairly easily.
Stopping and starting the Web Client Service
When you stop and start the Web Client Service and attempt to use the Explorer View, you will not receive an error and the Explorer View page will render a blank view.
The Web Client Service in Windows XP and Windows Server 2003 does not function correctly if you stop it and then start it again without restarting the computer. Although a bug has been opened on this problem, the changes required to fix it are too large for a hotfix or a service pack and have therefore been delayed until a future major release of Windows. In the meantime, you should always restart the client if, after stopping the Web Client Service, you want to restart it.
The Beta 2 builds of the Microsoft Windows Vista operating system and the Microsoft Windows Server Code Name "Longhorn" operating system currently have this fix implemented in them; however, this does not guarantee that this change will be included in the released version of either product.
Explorer View does not work on Windows Server 2003
When you try to access an Explorer View page on Windows Server 2003, you will receive the following error: "Explorer View requires Internet Explorer 5.0 or greater and Web Folders."
This is typically caused by the fact that Windows Server 2003 does not include Web Folders (FPRPC) technology and, by default, the Web Client Service is disabled.
You can resolve this in one of two ways:
- Install Microsoft Office 2003 or FrontPage on the server. Office 2003 and FrontPage install Web Folders components which will then allow you to access the Explorer View using FPRPC.
- Enable the Web Client Service on the server.
Explorer View causes users to be prompted for credentials
Users may or may not be required to use basic authentication when accessing the site initially, but they will always be prompted for credentials when attempting to use the Explorer View.
This behavior is usually the result of the Explorer View using FPRPC. The components that provide FPRPC use their own session of the Windows Internet (WININET) API, not the session in use by Internet Explorer itself. Therefore, session information that is not persisted, such as server cookies, is unavailable in FPRPC requests. This makes some servers require re-authentication or re-navigation to the URL for FPRPC-based connections to communicate with those servers. This behavior is documented in KB article 838028, "How documents are opened from a Web site in Office 2003.".
The only way to avoid this problem is to help the Explorer View to successfully connect using WebDAV. This is explained in the section of this document titled "Forcing Explorer View to use WebDAV."
A less common cause of this problem is that the server is using basic authentication. For security purposes, Windows XP SP2 disables basic authentication for WebDAV. A workaround using a registry key is available in this KB article 841215, "You cannot connect to a document library in Windows SharePoint Services by using Windows shell commands or by using Explorer View."
"Cannot find 'file://\\...' " error message appears when using FPRPC
When attempting to use the Explorer View, an error message like the one below is presented. After clicking OK, the Web folder is blank.
After the blank Web folder is rendered, the browser status bar will indicate that it is still downloading the page:
When navigating away from this page, an error will flash in the Explorer View pane of the page. Clicking Stop on the Internet Explorer menu bar instead of navigating away from the page will cause the "Action cancelled" error page to be displayed in the Web Folder behavior.
This problem occurs after applying Windows XP SP2 and only when you are using FPRPC to render the Explorer View. The WebFldr.aspx page that provides the Explorer View contains scripts that attempt to force the Internet Explorer Web Folder Behavior to use protocols in a certain order by rewriting the URL and resubmitting the connection request when an error occurs. When the Show Friendly HTTP error messages setting is disabled, the browser script that Explorer View relies on raises the error dialog box and the Explorer View will fail to render.
To resolve this problem, you have to enable the Show Friendly HTTP error messages setting in Internet Explorer. This setting is found on the Advanced tab of the Internet Explorer Internet Options configuration dialog box.
This setting has no effect when the page is rendered using WebDAV.
Drag-and-drop operations using Explorer View fail
When dropping folders in the Explorer View, the folder is created, but the files fail to copy and an error message is presented to the user.
This can be caused by insufficient permissions for the Temporary Internet Files folder for the BUILTIN\NetworkService account. This account must have read and write access to this folder to successfully complete a drag-and-drop operation.
Explorer View is very slow to render
After clicking the Explorer View link, the page changes to WebFldr.aspx and then the browser takes from 45 seconds to 5 minutes to render the Web Folder view.
There are a few causes and solutions for this:
- Ports 137, 138, 139 and 445 are blocked, and ICMP is not. See the section titled "Important Information for Troubleshooting Explorer View" to resolve this problem.
- The server is being accessed using a name other than its configured NetBIOS or Fully Qualified Domain Name. This occurs most often in load balancing and extranet scenarios. See the section titled "Important Information for Troubleshooting Explorer View" to resolve this problem.
- WebDAV is trying to use a proxy to access a server on the local network. See the section titled "Explorer View Causes Users to be Prompted For Credentials."
WebDAV continues to use a proxy after it is disabled in Internet Explorer
The Web Folder Behavior on the WebFldr.aspx page fails with the "The page cannot be displayed" error.
The Web Client Service provides the WebDAV functionality for Windows XP and Windows Server 2003. This service uses the proxy configuration information stored in:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\SavedLegacySettings.
These settings are set via the Internet Explorer proxy settings, but they do not reflect the enabled or disabled state of the proxy and they are not cleared when you clear the Internet Explorer proxy settings. The only way to stop the Web Client Service from using a proxy after one has been configured is to follow these steps:
- Clear all of the proxy settings in Internet Explorer. This means you have to clear the check boxes for Automatically detect settings, Use automatic configuration script, and Use a proxy server for your LAN in the Local Area Network Settings area in Internet Explorer. Prior to clearing the check box for Use a proxy server for your LAN, you must also erase any information stored in the underlying configuration settings, including the proxy server address, the port, and any advanced settings. You must also clear the check box for Bypass proxy server for local addresses.
- Manually verify that the following registry key does not have any of those settings stored in it:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\SavedLegacySettings
This is a REG_BINARY value so it may be difficult to know for sure. You can manually delete the values stored there, and the base value will be recreated automatically.
In some environments, Internet Explorer proxy settings may be set automatically, even when all the proxy settings are disabled.
This behavior is documented in a note section of KB article 832161, "You experience a delay when you use your Windows XP computer to log on to a domain or to connect to a network resource."
Long URLS do not work with FrontPage RPC
When you try to locate a Web folder or open a Web folder document that is stored in Microsoft SharePoint Server, you may receive the following error message:
"The Web folder address Internet Explorer was given is too long. Please use a shorter address."
This problem occurs even after you install the hotfix that is described in KB article 325355, "You cannot access Word documents by using Outlook Web Access on a server that is running SharePoint Portal Server." This problem is caused by a URL length limitation imposed on Internet Explorer. You can increase this limit by following the steps described in KB article 329919, "Cannot open a Web folder document that is located on a Microsoft Sharepoint Portal Server-based server."
Appendix A
This section assumes the reader already knows how to capture and analyze network traffic. For a very brief introduction about capturing network traffic with Microsoft Network Monitor, see KB article 148942, "How to capture network traffic with Network Monitor."
Transcripts of successful Explorer View conversations
While it is not reasonable to provide a transcript of every unsuccessful Explorer View conversation, it is usually very helpful to understand what success looks like. With that in mind, we are providing a transcript of a successful Explorer View connection using WebDAV and FPRPC.
Explorer View using WebDAV
An Explorer View conversation always starts with an HTTP request for the WebFldr.aspx page that looks like this:
HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/Document%20Library/Forms/WebFldr.aspx
HTTP: Protocol Version =HTTP/1.1
HTTP: Accept = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, appli
HTTP: Referer =http://www.adatum.com/Document%20Library/Forms/AllItems.aspx
HTTP: Accept-Language =en-us
HTTP: Accept-Encoding =gzip, deflate
HTTP: User-Agent =Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
HTTP: Host =www.adatum.com
HTTP: Connection =Keep-Alive
HTTP: Cookie =MSOWebPartPage_AnonymousAccessCookie=; SPSLastVisitedSitePage=%2fDocum
When the browser makes a request, it always considers the first request to be Anonymous. Therefore, it does not send any credentials. If the server does not accept Anonymous or if the Anonymous user account on the server does not have permissions to the file being requested, the IIS server responds with an "Access Denied" error message and sends a list of the authentication types that are supported. This response invites the client to log on. That packet looks like this:
HTTP: Response to Client; HTTP/1.1; Status Code = 401 - Unauthorized
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Unauthorized
HTTP: Reason =Unauthorized
HTTP: Content-Length =1656
HTTP: Content-Type =text/html
HTTP: Server =Microsoft-IIS/6.0
HTTP: WWW-Authenticate =NTLM
HTTP: X-Powered-By =ASP.NET
HTTP: MicrosoftSharePointTeamServices =6.0.2.5530
HTTP: Date =Wed, 09 Aug 2006 19:16:10 GMT
HTTP: Data: Number of data bytes remaining = 1228 (0x04CC)
You can see in this example that the server only supports NTLM (Windows NT Challenge/Response). For more information about other authentication types see KB article 264921, "How IIS authenticates browser clients."
The client will then complete the Windows NT Challenge/Response login sequence as documented in the article "Authentication and Security for Internet Developers."
After authentication, IIS will respond with the page that was requested, and the response will look like this:
HTTP: Response to Client; HTTP/1.1; Status Code = 200 - OK
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = OK
HTTP: Reason =OK
HTTP: Date =Tue, 08 Aug 2006 14:06:55 GMT
HTTP: Server =Microsoft-IIS/6.0
HTTP: X-Powered-By =ASP.NET
HTTP: MicrosoftSharePointTeamServices = 6.0.2.5530
HTTP: X-AspNet-Version = 1.1.4322
HTTP: Set-Cookie =http%3A%2F%2Fwww%2Eadatum%2Ecom%2FDiscovery=WorkspaceS
HTTP: Cache-Control =private
HTTP: Expires =Mon, 24 Jul 2006 14:06:55 GMT
HTTP: Content-Type =text/html; charset=utf-8
HTTP: Content-Length =26801
HTTP: Data: Number of data bytes remaining = 893 (0x037D)
This will be followed by a sequence of HTTP continuation response packets. These additional packets contain the remaining page data that was requested because the entire page could not fit in a single packet. Those packets will be noted in the trace like this:
HTTP: Continuation Response Packet
As the page is downloaded to the browser, Internet Explorer will start to process the scripts on the page. The script embedded in the page is what initiates the Explorer View. You will know when this starts to happen because you will see an SMB conversation starting in the trace. Remember earlier in the document when we stated that Explorer View almost always starts with an attempt to connect via SMB? This is that behavior in action. A detailed discussion of this SMB traffic is outside the scope of this document, however, we can say that responses like the ones below look like errors, but they are expected in this scenario. I have included them here for reference along with a brief description of why they occur:
SMB: R session setup & X - NT error, System, Error, Code = (22) STATUS_MORE_PROCESSING_REQUIRED
The above text means it needs to authenticate to continue. You will see the same request come again with a security blob attached and then it will succeed, assuming you have access to the server.
SMB: R tree connect & X - NT error, System, Error, Code = (189) STATUS_DUPLICATE_NAME
The above text means that the server is being addressed by a name other than its true NetBIOS name or FQDN and strict name checking is enabled. We explain how to disable this in the section of this document titled "Windows Server 2003, SMB, and strict name checking."
SMB: R tree connect & X - NT error, System, Error, Code = (204) STATUS_BAD_NETWORK_NAME
The above text means that you attempted to connect to a device that does not exist. This is because SMB is trying to treat the URL as a UNC and there is no share on the server with the name that was provided. You will often see this happen several times in a single connection attempt. You may notice that the share name provided in the tree connect request is truncated, for example, "SMB: C tree connect & X, Share = \\WWW.ADATUM.COM\DOCUMENT LIBRAR." For whatever reason, this is typical behavior in this type of conversation and can be ignored.
Next you will see WebDAV traffic appear in the trace. Assuming you have not connected to this resource via WebDav recently, the first WebDAV request you should see will be an OPTIONS request. After you connect once, the Web Client Service caches this information for a while.
The OPTIONS request is how a WebDAV client discovers if a server has WebDAV enabled and what the server's capabilities are. The OPTIONS request looks like this:
HTTP: OPTIONS Request from Client
HTTP: Request Method =OPTIONS
HTTP: Uniform Resource Identifier =/
HTTP: Protocol Version =HTTP/1.1
HTTP: translate =f
HTTP: User-Agent =Microsoft-WebDAV-MiniRedir/5.1.2600
HTTP: Host =www.adatum.com
HTTP: Content-Length =0
HTTP: Connection =Keep-Alive
You will notice that the User-Agent for this request is identified as "Microsoft-WebDAV-MiniRedir/5.1.2600." This is the User-Agent string for the Web Client Service, the service that hosts the Windows WebDAV client feature.
Assuming that you are using Integrated Authentication on the Web server and the security zone in which your URL resides is configured to automatically send the user name and password, you will usually see the client and server repeat the Windows NT Challenge/Response sequence. This is because protocols have changed. You should expect to eventually see an OPTIONS request that elicits a response of "200 – OK". That OPTIONS request will contain a list of the server's capabilities, like this:
HTTP: Response to Client; HTTP/1.1; Status Code = 200 - OK
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = OK
HTTP: Reason =OK
HTTP: Date =Tue, 08 Aug 2006 14:07:27 GMT
HTTP: Server =Microsoft-IIS/6.0
HTTP: X-Powered-By =ASP.NET
HTTP: MicrosoftSharePointTeamServices = 6.0.2.5530
HTTP: MS-Author-Via = MS-FP/4.0,DAV
HTTP: DAV =1,2
HTTP: Accept-Ranges =none
HTTP: Allow =GET, POST, OPTIONS, HEAD, MKCOL, PUT, PROPFIND, PROPPATCH, DELETE, MOVE
HTTP: Cache-Control =private
HTTP: Content-Length =0
HTTP: Public-Extension = http://schemas.microsoft.com/repl-2
There are a few important pieces of information highlighted in this packet that you should be aware of:
- MicrosoftSharePointTeamServices – This header value tells you that you are attempting to connect to a SharePoint server.
- DAV – This header value tells you that you are connected to a WebDAV-capable server and it tells you what level of WebDAV support it is capable of.
- Allow – This tells you what WebDAV verbs the server supports.
After the WebDAV client discovers that this server is WebDAV-capable, it will attempt to gather information about the folder it is going to display. It starts with a PROPFIND request on the root of the folder. PROPFIND is a WebDAV verb that requests a list of properties on a URI. In this case, it first attempts to discover the properties of the folder itself. This is done using a PROPFIND request for the folder's URI with a Depth setting of zero (0). This PROPFIND request is often done twice with the same headers and the same result. This is not an error. This behavior is by design and you can safely ignore it. The HTTP portion of the packet should look similar to this:
HTTP: PROPFIND Request from Client
HTTP: Request Method =PROPFIND
HTTP: Uniform Resource Identifier =/Document%20Library
HTTP: Protocol Version =HTTP/1.1
HTTP: Depth =0
HTTP: translate =f
HTTP: User-Agent =Microsoft-WebDAV-MiniRedir/5.1.2600
HTTP: Host =www.adatum.com
HTTP: Content-Length =0
HTTP: Connection =Keep-Alive
After the WebDAV client discovers the folder properties, it moves on to the folder contents. This is accomplished using another PROPFIND request with a Depth setting of one (1):
HTTP: PROPFIND Request from Client
HTTP: Request Method =PROPFIND
HTTP: Uniform Resource Identifier =/Document%20Library
HTTP: Protocol Version =HTTP/1.1
HTTP: Depth =1
HTTP: translate =f
HTTP: User-Agent =Microsoft-WebDAV-MiniRedir/5.1.2600
HTTP: Host =www.adatum.com
HTTP: Content-Length =0
HTTP: Connection =Keep-Alive
HTTP: Pragma =no-cache
If you review the response to this request, you will see that the server returns a variety of properties on any files and folders that already exist inside of the folder it started with.
The final WebDAV request you will see is a PROPFIND for the folder URI with "/desktop.ini" appended to it. This is because the Web Folder Behaviors does not know if the server it is querying is a file server or a Web server. Because an SMB share on a Windows server might have a file on the root named Desktop.ini, which is used by the Windows shell, it needs to check for that. This request typically results in a response of "404 - Not found." This apparent error can safely be ignored. Here is an example of this type of request:
HTTP: PROPFIND Request from Client
HTTP: Request Method =PROPFIND
HTTP: Uniform Resource Identifier =/Document%20Library/desktop.ini
HTTP: Protocol Version =HTTP/1.1
HTTP: Depth =0
HTTP: translate =f
HTTP: User-Agent =Microsoft-WebDAV-MiniRedir/5.1.2600
HTTP: Host =www.adatum.com
HTTP: Content-Length =0
HTTP: Connection =Keep-Alive
That is the end of the WebDAV conversation. At this point you should have the fully rendered Explorer View on your screen.
Explorer View using FPRPC
An Explorer View conversation using FPRPC starts the same way as one using WebDAV, with an HTTP request for the WebFldr.aspx page that looks like this:
HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/Document%20Library/Forms/WebFldr.aspx
HTTP: Protocol Version =HTTP/1.1
HTTP: Accept = image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, appli
HTTP: Referer =http://www.adatum.com/Document%20Library/Forms/AllItems.aspx
HTTP: Accept-Language =en-us
HTTP: Accept-Encoding =gzip, deflate
HTTP: User-Agent =Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
HTTP: Host =www.adatum.com
HTTP: Connection =Keep-Alive
HTTP: Cookie =MSOWebPartPage_AnonymousAccessCookie=; SPSLastVisitedSitePage=%2fDocum
When the browser makes a request, it always considers the first request to be Anonymous. Therefore, it does not send any credentials. If the server does not accept Anonymous or if the Anonymous user account on the server does not have permissions to the file being requested, the IIS server responds with an "Access Denied" error message and sends a list of the authentication types that are supported. This effectively invites the client to log on. That packet looks like this:
HTTP: Response to Client; HTTP/1.1; Status Code = 401 - Unauthorized
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = Unauthorized
HTTP: Reason =Unauthorized
HTTP: Content-Length =1656
HTTP: Content-Type =text/html
HTTP: Server =Microsoft-IIS/6.0
HTTP: WWW-Authenticate =NTLM
HTTP: X-Powered-By =ASP.NET
HTTP: MicrosoftSharePointTeamServices =6.0.2.5530
HTTP: Date =Wed, 09 Aug 2006 19:16:10 GMT
HTTP: Data: Number of data bytes remaining = 1228 (0x04CC)
You can see in this example that the server only supports NTLM (Windows NT Challenge/Response). For more information about other authentication types see KB article 264921, "How IIS authenticates browser clients."
The client will then complete the Windows NT Challenge/Response login sequence as documented in the article "Authentication and Security for Internet Developers."
After authentication, IIS will respond with the page that was requested, and the response will look like this:
HTTP: Response to Client; HTTP/1.1; Status Code = 200 - OK
HTTP: Protocol Version =HTTP/1.1
HTTP: Status Code = OK
HTTP: Reason =OK
HTTP: Date =Tue, 08 Aug 2006 14:06:55 GMT
HTTP: Server =Microsoft-IIS/6.0
HTTP: X-Powered-By =ASP.NET
HTTP: MicrosoftSharePointTeamServices = 6.0.2.5530
HTTP: X-AspNet-Version = 1.1.4322
HTTP: Set-Cookie =http%3A%2F%2Fwww%2Eadatum%2Ecom%2FDiscovery=WorkspaceS
HTTP: Cache-Control =private
HTTP: Expires =Mon, 24 Jul 2006 14:06:55 GMT
HTTP: Content-Type =text/html; charset=utf-8
HTTP: Content-Length =26801
HTTP: Data: Number of data bytes remaining = 893 (0x037D)
This will be followed by a sequence of HTTP continuation response packets. These additional packets contain the remaining page data that was requested because the entire page could not fit in a single packet. Those packets will be noted in the trace like this:
HTTP: Continuation Response Packet
As the page is downloaded to the browser, Internet Explorer will start to process the scripts on the page. The script embedded in the page is what initiates the Explorer View. You will know when this starts to happen because you will see an SMB conversation starting in the trace. Remember earlier in the document when we stated that Explorer View almost always starts with an attempt to connect via SMB? This is that behavior in action. A detailed discussion of this SMB traffic is outside the scope of this document, however, we can say that responses like the ones below look like errors, but they are expected in this scenario. I have included them here for reference along with a brief description of why they occur:
SMB: R session setup & X - NT error, System, Error, Code = (22) STATUS_MORE_PROCESSING_REQUIRED
The above text means it needs to authenticate to continue. You will see the same request come again with a security blob attached and then it will succeed, assuming you have access to the server.
SMB: R tree connect & X - NT error, System, Error, Code = (189) STATUS_DUPLICATE_NAME
The above text means that the server is being addressed by a name other than its true NetBIOS name or FQDN and strict name checking is enabled. We explain how to disable this in the section titled "Windows Server 2003, SMB, and strict name checking."
SMB: R tree connect & X - NT error, System, Error, Code = (204) STATUS_BAD_NETWORK_NAME
The above text means that you attempted to connect to a device that does not exist. This is because SMB is trying to treat the URL as a UNC and there is no share on the server with the name that was provided. You will often see this happen several times in a single connection attempt. You may notice that the share name provided in the tree connect request is truncated, for example, "SMB: C tree connect & X, Share = \\WWW.ADATUM.COM\DOCUMENT LIBRAR." For whatever reason, this is typical behavior in this type of conversation and can be ignored.
Next you will see FPRPC traffic appear in the trace. From a high level it looks the same as the OPTIONS request generated by the Web Client Service:
HTTP: OPTIONS Request from Client
HTTP: Request Method =OPTIONS
HTTP: Uniform Resource Identifier =/Document%20Library
HTTP: Protocol Version =HTTP/1.1
HTTP: User-Agent =Microsoft Data Access Internet Publishing Provider Ca
HTTP: Host =www.adatum.com
HTTP: Content-Length =0
HTTP: Connection =Keep-Alive
HTTP: Cookie =MSOWebPartPage_AnonymousAccessCookie=; SPSLastVisitedSitePage=%2fDocum
You will notice that the User-Agent header value is different. For FPRPC it lists "Microsoft Data Access Internet Publishing Provider Cache Manager." This tells us that it is using FPRPC for this OPTIONS request to make this connection. This is more commonly known as the Office Discovery Protocol
If you were to review the contents of the response packet, you would notice that it is exactly the same as the response packet from the WebDAV transcript. Although you are using a different client mechanism in this case, FPRPC instead of WebDAV, the server mechanism in this conversation is the same. It is the Stsfilt.dll ISAPI filter installed by SharePoint.
The next request you will see is a GET for "/_vti_inf.html":
HTTP: GET Request from Client
HTTP: Request Method =GET
HTTP: Uniform Resource Identifier =/_vti_inf.html
HTTP: Protocol Version =HTTP/1.1
HTTP: Date =Wed, 09 Aug 2006 19:16:17 GMT
HTTP: MIME-Version =1.0
HTTP: Accept = */*
HTTP: User-Agent =Mozilla/2.0 (compatible; MS FrontPage 4.0)
HTTP: Host =www.adatum.com
HTTP: Accept = auth/sicily
HTTP: Content-Length =0
HTTP: Connection =Keep-Alive
HTTP: Cache-Control =no-cache
HTTP: Cookie =MSOWebPartPage_AnonymousAccessCookie=; SPSLastVisitedSitePage=%2fDocum
The HTTP header portion of the response to this is fairly unremarkable. However, if you extract the data portion, you can see that you are really discovering what components should be used to interact with this server:
<!—
FrontPage Configuration Information
FPVersion="6025530"
FPShtmlScriptUrl="_vti_bin/shtmldll/_vti_rpc"
FPAuthorScriptUrl="_vti_bin/_vti_aut/authordll"
FPAdminScriptUrl="_vti_bin/_vti_adm/admindll"
TPScriptUrl="_vti_bin/owssvrdll"
-->
After the _vti_inf.html file is retrieved, the next step in the process is to send a POST request with a URI of "/_vti_bin/shtml.dll/_vti_rpc" and the actual request method is encoded in the data portion of the packet.
You will also notice the presence of a header named "X-Vermeer-Content-Type." This is another indication that this packet is part of a FPRPC conversation. Here is an example of that type of packet:
HTTP: POST Request from Client
HTTP: Request Method =POST
HTTP: Uniform Resource Identifier =/_vti_bin/shtml.dll/_vti_rpc
HTTP: Protocol Version =HTTP/1.1
HTTP: Date =Wed, 09 Aug 2006 19:16:17 GMT
HTTP: MIME-Version =1.0
HTTP: User-Agent =MSFrontPage/4.0
HTTP: Host =www.adatum.com
HTTP: Accept = auth/sicily
HTTP: Authorization =NTLM TlRMTVNTUAADAAAAGAAYAHgAAAAYABgAkAAAAAw
HTTP: Content-Type =application/x-www-form-urlencoded
HTTP: X-Vermeer-Content-Type = application/x-www-form-urlencoded
HTTP: Connection =Keep-Alive
HTTP: Cache-Control =no-cache
HTTP: Content-Length =41
HTTP: Data: Number of data bytes remaining = 41 (0x0029)
00280: 67 74 68 3A 20 34 31 0D 0A 0D 0A 6D 65 74 68 6F gth: 41....metho
00290: 64 3D 73 65 72 76 65 72 2B 76 65 72 73 69 6F 6E d=server+version
002A0: 25 33 61 34 25 32 65 30 25 32 65 32 25 32 65 34 %3a4%2e0%2e2%2e4
Because all the interesting action in an FPRPC conversation takes place in the data portion of the packet, throughout the rest of this trace analysis we will extract the contents of the data portion to make it easier for you to see what is going on. In this case, the version of FPRPC on the server is being requested:
method=server+version%3a4%2e0%2e2%2e4715
If you review the data portion of the response packet, including the continuation response packets, you can see where the server responded with the version information:
00030: FB D5 D7 68 00 00 43 6F 6E 74 65 6E 74 2D 74 79 ûÕ×h..Content-ty
00040: 70 65 3A 20 61 70 70 6C 69 63 61 74 69 6F 6E 2F pe: application/
00050: 78 2D 76 65 72 6D 65 65 72 2D 72 70 63 0D 0A 0D x-vermeer-rpc...
00060: 0A 3C 68 74 6D 6C 3E 3C 68 65 61 64 3E 3C 74 69 .<html><head><ti
00070: 74 6C 65 3E 76 65 72 6D 65 65 72 20 52 50 43 20 tle>vermeer RPC
00080: 70 61 63 6B 65 74 3C 2F 74 69 74 6C 65 3E 3C 2F packet</title></
00090: 68 65 61 64 3E 0A 3C 62 6F 64 79 3E 0A 3C 70 3E head>.<body>.<p>
000A0: 6D 65 74 68 6F 64 3D 73 65 72 76 65 72 20 76 65 method=server ve
000B0: 72 73 69 6F 6E 3A 34 2E 30 2E 32 2E 34 37 31 35 rsion:4.0.2.4715
000C0: 0A 3C 70 3E 73 65 72 76 65 72 20 76 65 72 73 69 .<p>server versi
000D0: 6F 6E 3D 0A 3C 75 6C 3E 0A 3C 6C 69 3E 6D 61 6A on=.<ul>.<li>maj
000E0: 6F 72 20 76 65 72 3D 36 0A 3C 6C 69 3E 6D 69 6E or ver=6.<li>min
000F0: 6F 72 20 76 65 72 3D 30 0A 3C 6C 69 3E 70 68 61 or ver=0.<li>pha
00100: 73 65 20 76 65 72 3D 32 0A 3C 6C 69 3E 76 65 72 se ver=2.<li>ver
00110: 20 69 6E 63 72 3D 35 35 33 30 0A 3C 2F 75 6C 3E incr=5530.</ul>
00120: 0A 3C 70 3E 73 6F 75 72 63 65 20 63 6F 6E 74 72 .<p>source contr
00130: 6F 6C 3D 31 0A 3C 2F 62 6F 64 79 3E 0A 3C 2F 68 ol=1.</body>.</h
00140: 74 6D 6C 3E 0A tml>
If you decode that data, you can see that the response is using HTML:
<html>
<head>
<title>vermeer RPC packet</title>
</head>
<body>
<p>method=server version:4.0.2.4715<p>
server version=
<ul>
<li>major ver=6
<li>minor ver=0
<li>phase ver=2
<li>verincr=5530
</ul>
<p>source control=1
</body>
</html>
If you extract the data portion of the next successful POST request packet, you can see that the server is being asked to translate a URL:
method=url+to+web+url%3a4%2e0%2e2%2e4715&url=%2fDocument+Library&flags=0
The response to that request contains a reference to the method call that generated this response, the version of the responding server, and the actual translated URL:
<html>
<head>
<title>vermeer RPC packet</title>
</head>
<body>
<p>method=url to web url:4.0.2.4715<p>
webUrl=/<p>fileUrl=Document Library
</body>
</html>
After it has the right URL, it sends a request to open the FPRPC service:
method=open+service%3a4%2e0%2e2%2e4715&service%5fname=%2f
The server response to that request is too large and too convoluted to discuss here, but it just describes the server capabilities for the client.
The next request is for a list of properties of the "Document Library" folder, its files, and its immediate subfolders:
method=list+documents%3a4%2e0%2e2%2e4715&service%5fname=&listHiddenDocs=false&listExplorerDocs=false&listRecurse=false&listFiles=true&listFolders=true&listLinkInfo=true&listIncludeParent=true&listDerived=false&listBorders=false&listChildWebs=true&initialUrl=Document+Library
The extracted response is large, but it basically contains the properties that the Explorer View needs to render the view of the folder, the files in the folder, and any subfolders:
<html>
<head>
<title>vermeer RPC packet</title>
</head>
<body>
<p>method=list documents:4024715</p>
<p>document_list=</p>
<p>urldirs=</p>
<div style="margin-left: 2em">
<ul>
<li>url=Document Library</li>
<li>meta_info=
<ul>
<li>vti_isexecutable</li>
<li>BR|false</li>
<li>vti_isbrowsable</li>
<li>BR|true</li>
<li>vti_isscriptable</li>
<li>BR|false</li>
<li>vti_hassubdirs</li>
<li>BR|true</li>
<li>vti_listbasetype</li>
<li>IR|1</li>
<li>vti_timecreated</li>
<li>TR|29 Jul 2006 18:03:04 -0000</li>
<li>vti_listservertemplate</li>
<li>IR|101</li>
<li>vti_listname</li>
<li>SR|{7B63EC81-6C44-44B2-B273-F33116D93F62}</li>
<li>vti_listtitle</li>
<li>SR|Document Library</li>
<li>vti_dirlateststamp</li>
<li>TW|09 Aug 2006 19:11:10 -0000</li>
<li>vti_timelastmodified</li>
<li>TR|29 Jul 2006 18:03:04 -0000</li>
</ul>
</li>
</ul>
<ul>
<li>url=Document Library/Forms</li>
<li>meta_info=
<ul>
<li>vti_isexecutable</li>
<li>BR|false</li>
<li>vti_isbrowsable</li>
<li>BR|true</li>
<li>vti_isscriptable</li>
<li>BR|false</li>
<li>vti_hassubdirs</li>
<li>BR|true</li>
<li>vti_timecreated</li>
<li>TR|29 Jul 2006 18:03:04 -0000</li>
<li>vti_dirlateststamp</li>
<li>TW|09 Aug 2006 19:11:10 -0000</li>
<li>vti_timelastmodified</li>
<li>TR|29 Jul 2006 18:03:04 -0000</li>
</ul>
</li>
</ul>
</div>
</body>
</html>
That is the end of the conversation. At this point, you should have a successfully rendered Explorer View.
Information to gather before engaging Microsoft Customer Support Services
If you encounter a problem with the Explorer View that cannot be resolved with this white paper, then you have probably reached the point where you need to engage Microsoft Customer Support Services (CSS). You can save some time and effort by gathering the following information ahead of time:
- Determine if the problem is specific to one client computer or group of client computers.
- Create a simple network diagram that describes the network architecture between the client computers and the server. Take special care to note if there is NLB or another load balancing product involved. If so, it would be wise to gather the configuration information or that device as well.
- Identify the Windows patch level of the client computer.
- Gather a simultaneous network trace of the failure, and a successful connection if you can get it, from both a client computer and the server. If you are load balancing, you will need to gather a trace from all of the servers in the cluster.
- Export the following keys from an affected client computer while the affected user is logged on:
- HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Internet Settings
- HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Internet Settings
- HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
Conclusion
After reading this white paper you should have a solid understanding of what the Explorer View is and the components it uses to accomplish its work. It should be clear that despite the many components involved, you typically need to work with only a few of them to identify and resolve a problem with the Explorer View.
From the "Common Explorer View problems" section of this white paper, you should be able to identify and eliminate the most common causes for the Explorer View to fail.
Many of the problems described in this white paper come from what seem to be unrelated and mundane configuration choices in a typical corporate network. By writing this white paper, we hope to have exposed some of the relationships that were not obvious before and to have given you enough information to solve your own Explorer View problems without having to engage outside resources.
