Deploying and Configuring Internet Information Services (IIS) 6.0 with Remotely Stored Content on UNC Servers and NAS Devices
On This Page
Introduction
A common function of a Web server such as IIS is to accept requests for files from a Web client and service the request by obtaining the file and transmitting the contents back to the client. In many cases, files delivered to clients are stored locally on the IIS server. This is the optimum design for speed and also ensures that new content is delivered as soon as the files are updated. For installations with a few Web sites that deliver a small set of easy-to-manage files, hosting the content locally on the IIS server is the best choice from the simplicity and performance perspectives.
However, there are many situations where storing files on the IIS server is neither practical nor possible. Some systems have many files to manage and placing the content on the IIS server combines the tasks of managing the content and managing IIS on the same system. If the workload can be handled by a single server, it may be beneficial to keep the content locally, but it also creates administrative complexities when it is necessary to scale out by adding Web servers, because the file systems must be continually replicated between servers. Replication is time consuming, which can result in stale content being delivered or in other synchronization issues. Additionally, it is necessary to manage security on the file systems for multiple servers, adding yet another layer of complexity. Finally, as needs for file storage grow, you have to expand storage capabilities on each server—resulting in additional expense—and by having more hardware, you have increased exposure to downtime due to hardware failures.
To mitigate these problems, IIS can be used as a front end to deliver content stored on a remote system. This paper focuses on the configuration and tuning of IIS 6.0 and a remote server acting as a centralized store for files, applications, or other network resources made available to IIS using a UNC (Universal Naming Convention) pathname. While this discussion is limited to accessing Microsoft server operating systems acting as file servers, much of the information applies to other storage solutions where remote file shares accessed with UNC pathnames are employed, such as an NAS device.
Architectures
Whether your server needs are simple with light loads or complex with heavy loads, a good understanding of the capabilities and techniques available to you in IIS 6.0 and Windows Server 2003 to access remote content using a UNC pathname will help you in implementing your design.
Distributed Scenario
As an example of a situation where IIS enables remote storage and distribution, consider an educational institution that has 100 educators producing schedules and papers, and posting grades for their classes (see Figure 1). IIS can be used to map to individual shared folders on each educator’s system, allowing them to quickly and easily publish important content to their students. In this case, IIS acts as a concentrator of distributed information using remote storage.
Figure 1: IIS 6.0 acts as a concentrator of distributed information using remote storage
See full-sized image.
This kind of a system could be made more reliable and manageable by using distributed file system (DFS) as a means to the underlying directory structure. For instance, if Anthro101 was mapped to a UNC pathname that was part of a DFS directory, when the instructor changes next semester, you need only change the association for \\Instructor\Anthro101 to the \\NewInstructor\Anthro101 in DFS. There is no need to change the IIS configuration.
ISP Scenario
IIS offers remote content benefits to Internet Service Providers (ISPs). For example, an ISP might have thousands of Web sites on a single server in a shared hosting environment. The content is spread out over many sites but traffic is low per site. By placing the content off the IIS server, the ISP can store content for multiple servers on a single RAID (Redundant Array of Independent Disks) device (see Figure 2). The ISP’s investment in storage is optimized by being concentrated instead of distributed to many Web servers. This reduces exposure to hardware failures, and simplifies recovery strategies.
High Volume Scenario
High-volume Web sites often use Web farms consisting of multiple, identically-configured IIS servers receiving traffic from a load balancer. In this scenario, it is common for the servers in the Web farm to access a cluster (or clusters) of Microsoft SQL™ servers, often using Microsoft Cluster Server (MSCS), as a common data store. Note that this cluster scenario does not use Network Load Balancing (NLB) between file servers because Server Message Block (SMB) communications used in Microsoft networks are session-dependent. This high-availability scenario provides the applications running on IIS 6.0 with a common database that has failover capability in the event of a problem with one of the servers. Similarly, the content and applications delivered by IIS 6.0 can be hosted on a clustered file server or NAS device, so that a failure of one of the remote stores is transparent to users (see Figure 3).
Figure 3: Multiple IIS servers provide their applications and content with a common database in a high volume or Web farm scenario
See full-sized image.
Accessing Remote Content
As with any benefit, centralized content comes with tradeoffs. While remote storage gives the administrator more options on the IIS server, extra security requirements become necessary in this environment.
Logging on to IIS
When a user enters a URL in a Web browser to access content on IIS, IIS always associates the user with a user account. If anonymous access is enabled and the Web site and NTFS permissions allow the kind of access requested, the user is assigned to the anonymous account, typically IUSR_ComputerName. Otherwise, the user must authenticate using one of the authentication methods enabled for the requested resource. The user name and password associated with the user are the user’s “credentials.” Requests for local NTFS permissions are checked against the user’s security identifier (SID) to determine access permissions. Applications launched by IIS on behalf of the user are said to run in the “security context” of the user.
Accessing the Remote File Server
When a user requests information from IIS that is mapped with UNC pathnames to a remote file server, the file server challenges IIS to authenticate before that user is granted access. In IIS 4.0 and IIS 5.0, when a new Web site or virtual directory is created in which the content is located on a UNC share, IIS prompts the administrator creating the site for user name and password credentials, as shown in figure 4. The user name and password are stored in the metabase and are subsequently used to authenticate to the share to view the files in Internet Service Manager. Consequently, the user entered in the User name text box must be a valid local user on the remote file server or, if both the IIS server and file server are domain members, a domain user.
When a Web user accesses the Web site or virtual directory, IIS retrieves the credentials from the metabase and uses them for authentication to the UNC share.
For example, if 100 different users authenticate to IIS and request access to a remote file server, IIS authorizes access to content stored on the local disk with each user’s credentials. For remotely-stored content, IIS doesn’t use the authenticated user’s credentials but submits the user name and password credentials that the administrator created for the Web site to the remote file server to authorize access. Using a single user’s credentials to deliver content is an effective technique for ensuring that remote content is always available; however, it reduces both the effectiveness of using NTFS permissions to secure such content and the usefulness of auditing.
In IIS 6.0, IIS Manager still allows you to configure a fixed set of credentials, like in IIS 4.0 and IIS 5.0, or you can submit the user’s credentials to the file server. This pass-through authentication (sometimes called user delegation) is the default configuration in IIS 6.0, as shown in figure 5.
When enabled, IIS 6.0 provides the user’s credentials to the remote system so that administrators may secure and audit remote content at a much more granular level than possible in previous versions of IIS. Additionally, applications residing on the file server that are launched when pass-through authentication is used are run in the security context of the user.
The changes visible in IIS Manager reflect underlying changes in the metabase and in how IIS now uses authentication credentials with remote file servers. First when the UNCUsername and UNCPassword metabase properties are left blank, the credentials of the authenticated user are passed on to the remote file server, rather than the credentials being stored in the metabase. Second, if the authenticated user’s credentials are submitted to authenticate the user, but are incorrect, the server returns a 401 error (Unauthorized) to the Web browser. If UNCUserName and UNCPassword are submitted to authenticate the user, but are incorrect, a 500 error (Internal Server Error) is returned. The minimum necessary amount of information is provided in IIS error messages in order to inform legitimate users, but thwart attempts by hacking tools to determine how to circumvent the security of IIS.
Figure 6 outlines the authentication process for all content processed by IIS, including static content such as .gif files and HTML pages, script-mapped files, CGI scripts, and ISAPI extension DLLs (like ASP and Microsoft ASP.NET), all run under the proper user context. ISAPI filters run under the context of the worker process identity. By default, the worker process runs as Network Service, which is a built-in service account with minimal permissions. For more information about IIS architecture and worker process identity see the IIS Overview.
Pass-Through Authentication in a Workgroup Environment
In a workgroup environment, all user accounts are local. Pass-through authentication using Basic authentication can still function, as long as both the IIS and file servers have user accounts with identical user names and passwords. This configuration quickly becomes an administrative burden and consequently is not widely implemented. For these circumstances, designating a single user account designed specifically for use with the UNC connection is likely the best choice.
Pass-Through Authentication in a Domain Environment
There are several ways to configure pass-through authentication in a domain environment. Each way assumes that the file server(s) and the server running IIS are members of the same domain or of trusted domains. Each way also uses some form of delegation, which is a server’s ability to pass through a user’s credentials to another server. Using delegation eliminates the need to re-authenticate the user.
In Windows 2000 and Windows Server 2003 domains, both the Basic and Kerberos authentication methods support delegation. However, in Windows Server 2003 native domains, you can also configure delegation for NTLM, Digest, and client certificate authentication methods. These additional authentication methods, along with Kerberos, can use a new feature for Windows Server 2003 native domains called constrained delegation. This feature allows you to implement delegation with increased security and to delegate other logon credentials in addition to those provided by the Basic and Kerberos authentication methods. Constrained delegation works with IIS 6.0 worker process isolation mode.
If you use Basic authentication—which should always be implemented with Secure Sockets Layer (SSL) to encrypt the user name and password data—you do not need to do any additional configuration at the domain controller level. If you use Kerberos via Integrated Windows authentication for pass-through authentication, read the section called “Configuring Servers for Delegation” below. For NTLM, Digest, and client certificate authentication configuration, read both the “Configuration Servers for Delegation” and the “Using Protocol Transition for Authentication” sections below.
Table 1 shows the pass-through authentication configuration requirements for each authentication method.
Table 1 Pass-through authentication configuration requirements
| Authentication method | Additional configuration for pass-through authentication |
Basic with SSL | None |
Kerberos via Integrated Windows authentication | Constrained delegation |
NTLM via Integrated Windows authentication | Constrained delegation and protocol transitioning |
Digest | Constrained delegation and protocol transitioning |
Client certificate | Constrained delegation and protocol transitioning |
The next section of this white paper explains how constrained delegation works. For more information about constrained delegation, see Help and Support Center for Windows Server 2003.
Windows Server 2003 Constrained Delegation
Windows 2000 supports delegation, but you cannot constrain the delegation to a specific set of services on a system, which makes it difficult to implement this capability securely. Windows Server 2003 native domains use constrained delegation (sometimes referred to as “Service4User2Proxy”), which entrusts IIS to give delegated credentials to a specified list of services on remote servers. The ability to implement constrained delegation on a network creates new possibilities for configuring a Windows Server 2003 file server running IIS; the credentials from a user are passed through to designated services on designated computers. This allows you to secure NTFS permissions on remote content using domain-based users and groups rather than a single, designated user for UNC access from the IIS server.
Using Protocol Transition for Authentication
When delegation is enabled on a Windows Server 2003 file server, you can delegate a user’s credentials obtained with NTLM, Basic, Digest, Client Certificate, and Kerberos authentications to a remote server: Clients can authenticate to IIS using any of these authentication protocols and IIS delegates the credentials using the capabilities of Kerberos. This feature of Windows Server 2003 is known as protocol transition, sometimes referred to as ”Service4User2Self”, because IIS (the ”Service”) is able to obtain a service on behalf of the authenticated user to itself. This is perfectly reasonable because IIS has already authenticated the user and is in effect telling Kerberos that it trusts the user’s identity for use in operations to itself. Constrained delegation is related to protocol transition, and allows IIS (the ”Service”) to use the User’s service ticket in a request to the Kerberos Domain Controller (KDC) for a ticket to a specific remote server (the “Proxy”). The ticket can be delegated only to services on the remote server that are specified by the domain administrator, which is why this type of delegation is called constrained delegation. This gives you maximum flexibility in choosing how you authenticate users on IIS, while preserving the ability to securely connect to network resources with pass-through authentication.
Finally, the service ticket sent by IIS is used by the remote file server to authorize access to the requested shares, directories, and files, which are secured by ACLs. The service ticket represents a domain user’s identity, for example “MyWebSiteAnonymousUser”. The entire process of Authentication, Protocol Transition, Constrained Delegation, and Authorization is shown in Figure 7.
Protocol Transition and NTLM
As an example of protocol transition, if your client authenticates to the Web server via Integrated Windows authentication using NTLM, the user’s token on IIS does not have sufficient permissions to access another server, such as a file or SQL server. Consequently, pass-through authentication for a user authenticated with NTLM (or any method other than Basic or Kerberos authentication) will fail. Windows Server 2003 allows you to configure Microsoft Active Directory® so that logons using NTLM can be authorized for delegation (see the instructions below). Once you have enabled this delegation, the token that the Web server receives is now a Kerberos ticket, which has permission to access another server. Basically, the NTLM-based token gets upgraded to a Kerberos-based ticket. See the Windows Server 2003 documentation for more details.
Constrained Delegation in IIS 5.0 Isolation Mode
If you have upgraded from IIS 5.0 to IIS 6.0, by default IIS 6.0 runs in IIS 5.0 isolation mode. In IIS 5.0 isolation mode, out-of-process applications run as the local IWAM_ComputerName account, which prevents constrained delegation from working correctly. A process that runs as a local account cannot be used to obtain a Kerberos ticket on behalf of an authenticated user. Constrained delegation can be enabled, however, by switching IIS to run in worker process isolation mode. Worker processes running in worker process isolation mode will run as Network Service user accounts, a computer account with sufficient rights on the domain to delegate credentials.
Configuring Servers for Delegation
How you configure delegation on Windows Server 2003 depends on whether you are supporting a network that has both Windows 2000 and Windows Server 2003 domain controllers. When both Windows 2000 and Windows Server 2003 domain controllers are supported, Windows Server 2003 must run in mixed mode. This limits you to using Windows 2000 delegation throughout the Active Directory forest.
Configuring Delegation in Windows 2000 Mixed Domains
On the domain controller for your Web server’s domain:
1. | Click Start, Administrative Tools, and then click Active Directory Users and Computers. |
2. | Expand domain if necessary (for instance, iishost.microsoft.com) and expand the Computers folder. |
3. | In the right pane will be the list of computers in your domain. Right-click on the computer name for the Web server, and then click Properties. |
4. | On the General tab, as shown in figure 8, make sure the Trust computer for delegation checkbox is selected. |
5. | Press OK at the message box advising you this operation “should not be done indiscriminately.” |
Important Enable “Trust computer for delegation” on only the servers where it is required. It must be set on the Web server, but is not required for the remote file servers.
Configuring Delegation in Windows Server 2003 Domains
Configuring delegation in a Windows Server 2003 domain that is not supporting Windows 2000 domain controllers permits you to use protocol transition and constrained delegation.
To verify that your domain is in Windows 2003 Server mode
1. | Click Start, Administrative Tools, and then click Active Directory Users and Computers. |
2. | Select the domain in the left pane. |
3. | Click Action from the menu, and then select Raise Domain Functional Level |
The Raise Domain Functional Level dialog box appears, as shown in Figure 9. If your domain is in Windows 2000 native or Windows 2000 mixed mode, you will need to raise it to Windows Server 2003 mode.
To raise the domain functional level
1. | Continuing the previous procedure, from the Raise Domain Functional dialog box, select Windows Server 2003 from the drop-down list, and then click Raise. Important: This change is irreversible and may take 15 minutes to propagate. |
2. | Click OK on the warning “This change affects the entire domain. After you raise the domain functional level it cannot be reversed.” |
3. | Click OK on the message “The functional level was raised successfully.” |
To configure delegation
1. | Click Start, Administrative Tools, and then click Active Directory Users and Computers. |
2. | Expand domain if necessary (for instance, iishost.microsoft.com) and expand the Computers folder. |
3. | The right pane of the Active Directory Users and Computers MMC tool lists the computers in your domain. Right-click on the computer name for the Web server, select Properties, and then click the Delegation tab (figure 10). |
4. | By default, delegation is disabled. To enable protocol transition and constrained delegation, select Trust this computer for delegation to specified services only. |
5. | In addition, you can specify if you would like delegation to work based on Kerberos or on any authentication protocol. This allows you to use pass-through authentication with Basic, NTLM, Digest, Kerberos, or any other IIS authentication provider. |
6. | Click the Add button. |
7. | In the Add Services dialog box, click Users or Computers, and then search for or type in the name of the file server that is to receive the users credentials from IIS (figure 11.) |
8. | Click OK when done. |
9. | In the ComputerName Properties dialog box, click the Add button. The Add Services dialog box appears. |
10. | In the Add Services dialog box, click Users or Computers, and in the Select Users or Computers dialog box, search for or type in the name of the file server that is to receive the user’s credentials from IIS (figure 12).  Figure 12: Using the Windows Server 2003 Select Users or Computers dialog to specify the file server |
11. | Click OK when done. The Add Services dialog box, shown in figure 13, now lists the services that are registered as Service Principal Names (SPNs) with Kerberos for the selected computer. |
12. | From the Service Types list, select the HOST (the server service) and Common Internet File System (CIFS) services, and then click OK. Important Only add the services that you are sure you need to receive delegated credentials. Be sure to use service names on the file server, not the Web server. Note If you intend to access a remote SQL server using constrained delegation, you will need to add that service as well (for the SQL server machine). A common example of this is if you have an Active Server Page (ASP) that makes an ActiveX Data Object (ADO) connection to a SQL server. The SQL Server SPN is MSSQLSvc.  Figure 14: Result of configuring Active Directory for protocol transition and constrained delegation |
13. | From the Delegation tab on the ComputerNameProperties dialog box, verify that the new services were added, as shown in figure 14. Click OK. This completes the process of configuring Active Directory for protocol transition and constrained delegation from the IIS server to the file server. |
Setting Permissions on the File Server
The file server permissions must be carefully implemented to provide appropriate access to content. This involves combining the IIS authentication protocol with features like delegation and pass-through authentication, or specifying a user account for IIS to use when authenticating to a remote resource. Of course, your servers should always use NTFS permissions in order to properly enforce security.
File Server Shared Folders
The default share permission for shares is Everyone Read. If you're using IIS as a publishing server (WebDAV, Microsoft FrontPage®, FTP, etc.) and the file server is the back end, you'll need to set permissions for share and NTFS sufficient to allow writing to the resource. Share permissions should be Change or Full Control, and will require the Modify Write permissions for these applications to work correctly. The specific settings required are dependent on how you implement publishing.
To set share permissions
1. | Right-click on the folder you want to share. |
2. | Select Sharing and Security. |
3. | Select the Sharing tab (set ShareName and Comment as appropriate). |
4. | Click Permissions. |
5. | Remove the Everyone group (if it exists); this may allow unexpected access. |
6. | Add the appropriate User or Group (Authenticated Users is a good choice) that should have access to the share. For delegated access, this will typically be Domain groups or users. It is recommended that you use groups to control access to local resources. |
7. | Give this user or group the minimum permissions required to access the content. Read is the least share privilege allowed. If this location is to be used for FrontPage publishing, Change or Full Control permissions may be required. |
To set NTFS permissions
Important: Be careful when editing any of the default NTFS ACL settings; you'll need to make sure the administrators can still control the file content.
1. | Right-click on the folder or file you want to secure. |
2. | Select Sharing and Security. |
3. | Select the Security tab. |
4. | Click the Add button. |
5. | Type in the name of the domain user or group that you want to have access to this resource, and then click OK. The default NTFS settings apply only to local accounts on the server. Domain users must be explicitly allowed appropriate access. |
6. | Verify that the Allow checkboxes are set to permit minimum access. (For IIS to retrieve content, it needs only Read access to be checked.) |
Note: Unchecking Allow List Folder Contents does not disable IIS Directory Browsing in IIS Manager. Unchecking Allow Read and Execute does not disable IIS Script or Execute permission in IIS Manager.
In some environments, such as a shared hosting provider, it is common to leave the share permissions reasonably open and rely on NTFS permissions to control security. Remember that share and NTFS permissions combine to provide the least privilege allowed by both. Regardless of how you choose to integrate share and NTFS permissions, be certain they are set up correctly, as these permissions are the foundation for your Web server security.
Increasing File Server Availability
To increase availability, consider clustering your file servers like you would a SQL server. In addition (or alternatively), you can use DFS to provide a non-machine-specific UNC naming convention, and File Replication Service (FRS) to provide redundancy. These technologies have been proven to increase reliability with Windows 2000 Service Pack 3 (SP3) and Windows Server 2003. Additionally, Network Load Balancing can be used to distribute traffic to a set of identical file servers. The following are several Knowledge Base (KB) articles that help explain how to get this scenario to work; they are especially significant when using FrontPage Server Extensions.
Description of the Properties of the Cluster Network Name Resource in Windows Server 2003:
How to Troubleshoot the Cluster Service Account When It Modifies Computer Objects:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q307532
Kerberos Support on Windows 2000Based Server Clusters:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q235529
Distributed File System:
Optimizing IIS Caching for Remote Content
As IIS delivers content, it will cache pages in order to deliver them quickly upon subsequent requests. This is especially important with remote file servers because the network subsystem is interposed between IIS and its content, thus increasing latency. When caching is used, some mechanism must be in place for IIS to know that content on the remote server is more current than the version stored in the IIS cache.
IIS 6.0 supports two methods for determining whether the file cache needs to be updated with new content from a remote file server: last-modified time, which is new to IIS 6.0, and file change notification, as implemented in IIS 4.0 and IIS 5.0. In addition, the caching method used can be set independently for static files and ASP.
Effective with Windows Server 2003 Service Pack 1 (SP1), UNC content is cached both in the worker process file cache and in the HTTP.sys cache. The caching behavior depends on the value of the DoDirMonitoringForUnc registry property as discussed in “Last-Modified Time” and “File Change Notification” below.
Last-Modified Time
By default, IIS 6.0 simply asks the file system on the file server for the last-modified time on the cached file. If the last-modified time on the file has changed, the file cache on IIS is updated with the new content. If the last-modified time has not changed, the cached version of the file on IIS is sent. By using the last-modified time instead of monitoring each virtual directory for change notifications (which can be quite expensive in terms of file system resources), scalability is increased when large numbers of virtual directories are mapped to UNC shares. Checking the last-modified time on a file is a more reliable mechanism than file change notification because some NAS devices don’t fully implement change notifications. Furthermore, security is enhanced as share and NTFS permissions are validated when the last-modified time is sampled.
The last-modified time cache method works best when:
| • | The number of sites or virtual directories is high. |
| • | Files are large (files larger than 256K will not be cached using either caching algorithm; if you deliver larger files, the absence of the HTTP.sys cache with the last-modified time algorithm has a lower impact. In Windows Server 2003 SP1, this limit will be configurable through a registry key and may be larger than 256K). |
| • | The cache hit rate is low. |
| • | Reliability/availability is more important than performance. |
| • | Your NAS device doesn't support change notification reliably. |
| • | You're concerned about honoring the share permissions during cache hits. |
On a busy server, it is impractical to check the last-modified time every time a file is accessed. Consequently, by default, IIS 6.0 checks the last-modified time at most every five seconds; otherwise, it assumes the file has not changed. There is a five-second window where IIS will deliver a stale file out of the cache.
For some sites, a five-second window will be too large a window, and for others, too small. The sampling interval is configurable with the following registry keys, which are not present by default:
| • | Static pages Set the registry property, FileAttributeCheckThreshold, a DWORD value, located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters. Also, note that the server-side includes file handler (Ssinc.dll) makes use of the user-mode static-file cache, so the configuration you apply to the user-mode static-file cache also applies to .stm, .shtml, and any other files you have mapped to Ssinc.dll. If the DoDirMonitoringForUnc registry property, a DWORD value located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters, is set to False, IIS checks the cache entries for change after a period of time equal to the value set for the FileAttributeCheckThreshold registry property. Effective with Windows Server 2003 SP1, IIS checks both the worker process file cache entries and the HTTP.sys cache entries. |
| • | ASP Scripts Set the registry property, FileMonitoringTimeoutSeconds, a DWORD value, located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ASP\Parameters. |
Using the last-modified cache update mechanism will result in more reliable and secure delivery of content. Additionally, it will scale well on a wide application structure (where your Web server has lots of applications pointing at thousands of different directories). There is, however, a performance penalty that may be noticeable in regards to static content.
File Change Notification
In most cases, performance of UNC-based content will be slightly slower in the default caching configuration (as compared with using change notification–based caching). If you do observe a difference, it will likely be with static files rather than ASP files. With ASP requests, the performance penalty between checking the last-modified time and listening to change notifications is quite small, because no matter which method is used for cache updates, the biggest portion of any latency is in the re-compilation and execution of the ASP page.
IIS monitors for change notification events at the root level of every virtual directory. Large numbers of virtual directories can cause significant overhead, but if you use a file server that reliably reports change notifications and you have a small number of sites or virtual directories using remote content, using change notification is faster. For example, if you have a single Web site using a couple of applications with all your content stored on a Windows Server 2003 file server, it is recommended that you use the change notification method of caching.
Change notification-based caching works best when:
| • | The number of sites or virtual directories using UNC content is low. |
| • | Files are small enough to be cached (under 256K). |
| • | Requests are concentrated among a few files, that is, the cache hit rate is high. |
| • | The performance of benefits provided by the kernel-mode cache is important. |
You can enable change notification-based caching by adding the following registry keys, which are not present by default:
| • | Static Pages Set the registry property, DoDirMonitoringForUNC, a DWORD value located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters, to True. Also, note that the server-side includes file handler (Ssinc.dll) makes use of the user-mode static-file cache, so the configuration you apply to the user-mode static-file cache also applies to .stm, .shtml, and any other files you’ve mapped to Ssinc.dll. Effective with Windows Server 2003 SP1, IIS checks both the worker process file cache entries and the HTTP.sys cache entries. |
| • | ASP Scripts Set the registry property, EnableChangeNotificationForUNC, a DWORD value, located at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ASP\Parameters. |
Tuning the Servers for UNC Content
High stress conditions over a UNC path may require specialized tuning to optimize server performance. Under such circumstances, certain errors can show up on the browser, in the event log on the IIS server and the remote file server, and in the Win32 error messages of the IIS logs. The following discussion presents these errors and discusses their solutions.
Shortage of Outbound TCP Ports
Using UNC paths under load, you may see the following event viewer error messages:
“Windows cannot find the network path. Verify that the network path is correct and the destination computer is not busy or turned off. If Windows still cannot find the network path, contact your network administrator. Error code 0x80070033.”
“The network location cannot be reached. For information about network troubleshooting, see Windows Help. Error code 0x800704CF.”
These errors can be returned when the IIS server has a shortage of outbound TCP ports when making the UNC connection. Under these conditions, IIS returns HTTP 500 errors for all requests, until TCP ports are available again. To fix this problem, use the MaxUserPort registry setting (on the IIS server) to increase the number of available ports. For more information about MaxUserPort, see Registry Keys: http://www.microsoft.com/technet/prodtechnol/isa/2000/proddocs/isadocs/cmt_regkey.mspx.
For instance, if you have a large number of virtual directories, or if you use pass-through authentication and have a lot of authenticated users, you can potentially have many concurrent authenticated users using resources on a UNC path. A different SMB connection is opened for each individual user from the IIS server to the remote file server. Each SMB connection uses a port. By default, you are limited to ports 1,024 to 5,000 for outbound TCP connections (a little less than 4,000 ports available), so you may need to increase this value to a higher number, such as 10,000 or 20,000, to allow for additional ports to be used for each SMB connection. Be aware that this may cause problems with other applications creating sockets on these higher ports. For more information, see the following MSDN document: http://www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/tcpip_implement.asp.
File Server Nonpaged Memory
In some cases, errors reported by IIS related to UNC pathnames are caused by problems on the file server rather than IIS. As stated above, a UNC connection results in a SMB connection. This results in the creation of one or more work items to be used by the SMB connections. Work items are data structure objects used by SMB for I/O operations and can be consumed in a variety of ways and for varying amounts of time. For example, doing an operation against a file such as CreateFile or GetFileAttributes only takes up an I/O work item for a short amount of time, but asking for a change notification on a directory structure will take up a work item for the duration of the connection to the IIS server. So, the kind of work performed by a work item can impact the overall availability of work items to serve SMB connections.
Work items are created in the file server’s nonpaged pooled memory, usually referred to as the nonpaged pool. This memory is referred to as nonpaged because it cannot be dynamically swapped out or paged to the system pagefile. Consequently, it is vital that your server have a sufficient amount of free nonpaged pool to function properly.
A large number of work items on a file server can result in over allocation of nonpaged pool memory. In these circumstances, you may see the following event viewer error messages:
“Not enough server storage space available to process this command.”
”The server was unable to allocate from the system nonpaged pool because the pool was empty.”
”The server was unable to allocate a work item <n> times in the last 60 seconds.”
You can quickly check memory use on the file server by opening Task Manager, selecting the Performance tab and examining the nonpaged value under Kernel Memory frame. There are two ways to manage these kinds of problems: reducing the number of work items or tuning the IIS and file servers to manage more work items.
Before making a decision about how best to proceed, you should run the server under a simulated workload for several hours and examine the performance monitor counters for the following counters on the file server:
| • | Server\Files Open provides information that can be helpful in estimating appropriate SMB settings. |
| • | Server\Server Sessions provides information that can be helpful in estimating appropriate SMB settings. |
| • | Server\Work Item Shortages if this counter increases, it indicates a need for more Work Items. |
| • | Server\Pooled NonPaged Bytes if this counter is too low, the server has nearly exhausted its available nonpaged pool. It may be necessary to decrease SMB work items. |
Monitoring these settings while you tune the server will help you assess the effectiveness of your adjustments.
Important: On the x86 platform, the maximum amount of nonpaged pool memory is 256 MB; however, your system may have less than this because the maximum amount is dynamically determined.
Reducing the Number of Work Items
Nonpaged pool memory consumption on the file server can be affected by reducing the number of work items allocated on the file server. This can be accomplished using a number of techniques.
| • | Changing the caching algorithm for IIS; using the default last-modified time method for cache updates results in fewer work items being created. |
| • | Reducing the number of authenticated users connecting to the file server. A connection is created for each unique user. If you designate a user for the connection instead of using pass-through authentication, the number of connections is reduced. |
| • | Reducing the number of virtual directories or Web sites using remote resources. |
Tuning the Servers
Adjustments made to the IIS server affect the load on the file server. Consequently, when tuning these parameters, the settings on the file server are determined by the settings on the IIS server. Specifically, you can control the number of work items required on the file server by adjusting the registry setting MaxCmds on the IIS server and then modifying MaxMpxCt and MaxWorkItems on the file server to accommodate the MaxCmds setting. MaxCmds determines the number of simultaneous SMB connections that are allowed from the IIS server to the file server, MaxMpxCt is configured on the file server to limit the number of simultaneous connections to that server, and MaxWorkItems specifies the maximum number of receive buffers that a file server can allocate. It is important to determine the proper value for MaxCmds in to order to know what values should be entered for MaxMpxCt and for MaxWorkItems on the file server. After MaxCmds is determined, the setting for MaxMpxCt on the file server should equal MaxCmds on the IIS server. Additionally, the setting for MaxWorkItems must be at least (MaxCmds * the number of IIS servers).
Table 2 shows the default and maximum registry values for some SMB settings on Windows Server 2003 (the same as on Windows 2000):
Table 2 SMB registry settings
| Registry Setting | Default Value | Maximum Value |
HKLM\System\CurrentControlSet\Services\LanmanWorkstation | 50 | 65535 |
HKLM\System\CurrentControlSet\Services\LanmanServer | 50 | 65535 (Windows 2000 SP2+; max 125 on Windows 2000 pre-SP2) |
HKLM\System\CurrentControlSet\Services\LanmanServer | 4096 | 65535 (see 232476 below) |
To assist with determining the correct values for these settings, here are some general details about work item configuration:
| • | When using pass-through authentication to access remote content (as shown in figure 5), each uniquely authenticated user creates an SMB connection. When designating a user for access to remote content (as shown in figure 4), only one SMB connection is used. |
| • | Using file change notification as the cache update algorithm increases the number of work items consumed for a long period of time, because each change notification instance uses a work item until the connection is lost. |
| • | MaxWorkItems is configured on the remote file server at the registry location HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters. |
| • | MaxCmds and MaxMpxCt are configured on the IIS server at the registry location HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters. |
| • | As a general rule, MaxCmds cannot exceed 12,000 due to memory constraints on the x86 platforms with over 512 MB of RAM. |
| • | For the MaxWorkItems, MaxCmds, and, MaxMpxCt registry values to take effect, you must stop and start the server service on the remote file server and the workstation service on the IIS server. You may also need to restart dependent services. You do not need to restart the servers. |
The following formulas will help you estimate a starting value for MaxCmds. To make it clear how to apply this information, these formulas are used in a few scenarios in the next section IIS and File Server Configuration Scenarios for SMB Scaling.
Estimating MaxCmds When Using File Change Notification
The formula to estimate MaxCmds when using file change notification for caching is as follows: (number of distinct physical directories that IIS needs to monitor for change notifications) * (1 [if static files exist] + 1 [if ASP content exists] + 1 [if ASP.NET content exists]) + 50 (for concurrent default/regular file I/O).
The value provided by this formula presumes that 100% of the IIS server connections would be active at any given time. Generally, this is not the case, so MaxCmds may be reduced by 25 to 50 percent, depending on the characteristics of your activity.
Important: This calculation is only a rough estimate. Using the performance monitor counter studies recommended above, you can make informed adjustments.
Estimating MaxCmds When Using Last-Modified Time
The formula to estimate MaxCmds when using last-modified time for caching is as follows: (peak number of requests per second / staleness time) / 2. Staleness time refers to how frequently IIS checks for a file change, which is five seconds by default. The value provided by this formula presumes that a high percentage of IIS resources are in use at any time. If that is not the case, you may be able to reduce MaxCmds by 50 to 75 percent, depending on the characteristics of your activity.
Important: This calculation is only a rough estimate. Using the performance monitor counter studies recommended above, you can make informed adjustments.
Calculating MaxWorkItems and Nonpaged Pooled Memory Use
After determining the value for MaxCmds, you would set the value for MaxWorkItems to equal the value of (MaxCmds * [number of IIS servers connecting to the file server]). If you used one IIS server, then MaxWorkItems would equal MaxCmds. If you have four IIS servers, then MaxWorkItems = 4 * MaxCmds.
On a Windows 2003 Server with over 512 MB or more of RAM, each work item used takes up 20K of nonpaged pooled memory. If there is less than 512 MB of RAM in the server, each work item uses 8K of nonpaged pooled memory. In order to assure that there is sufficient nonpaged pooled memory available for other server resources, try to minimize the amount of nonpaged pooled memory used by work items.
Important The nonpaged pooled maximum size on the x86 platform is 256 MB. However, your servers may allocate less than this on factors including physical memory size. After set, nonpaged pooled size may be dynamically adjusted, based on the system hardware configuration, including physical memory size and installed devices. You can monitor nonpaged pooled usage using the system PerfMon tool by looking at two counters: Memory\Pool nonpaged Bytes and Memory\Pool nonpaged Alloc, which indicate how much nonpaged pooled memory is currently being used. There are two ways to indirectly determine when nonpaged pooled memory usage has exceeded the maximum size. First, the Server service logs events in the system event log when it fails to allocate nonpaged pooled memory. Second, the PerfMon counter “Server\Pool Nonpaged Peak” indicates the maximum amount of nonpaged pooled memory that’s been allocated at any one time during the lifetime of the server. If you believe your server’s consumption of nonpaged pooled memory has reached the actual maximum, the value can roughly indicate what the maximum available nonpaged pooled memory is.
In some circumstances, you may find that you need a high number of work items, but at a cost of 20K per work item, you would consume too much nonpaged pooled memory. If your server has 512 MB of RAM or more, you can configure the work item’s size to be 8K instead of 20K. On the file server, set the registry key SizReqBuf, REG_DWORD at HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters to 0x1104 (4356d). This allows more work items to be used on the file server without consuming as much nonpaged pooled memory. The costs for this workaround are slower enumerations of large directories and potentially slower network performance.
Note For the purposes of this paper, we are presuming the server has more than 512 MB of RAM or more, the maximum nonpaged pooled memory size is 256 MB, and a work item consumes 20K.
IIS and File Server Configuration Scenarios for SMB Scaling
In order to determine the proper configuration for the IIS and file servers, let’s examine how the caching algorithms (last-modified time and file change notification) affect the aforementioned MaxCmds, MaxMpxCt, and MaxWorkItems registry settings. These considerations, in conjunction with performance monitor studies, can tell you how to best configure your servers. For the purpose of this discussion, each application is considered a UNC-mapped Web site or virtual directory.
In the following scenarios, assume that each server has more than 512 MB of RAM and that there are four IIS servers connecting the file server.
Scenario 1: Very Wide Content Low Traffic
In this scenario, each IIS server hosts up to 20,000 applications. Of those 20,000 applications, only 1,000 or so would be active at any given time. Each active site runs in its own application pool and has two users; a publishing user (using FrontPage or WebDAV publishing) and an anonymous user. The content is dominantly ASP and static files, with a small number of ASP.NET applications.
File-change notification algorithm
Using the formula given in “Estimating MaxCmds When Using File Change Notification,” the value for MaxCmds is estimated as follows:
20,000 * (1(static) + 1(ASP) + 1(ASP.NET)) + 50 = 60,000
Next, the maximum number of work items on the file server is calculated:
MaxWorkItems = (60,000 * 4 IIS servers) = 240,000 work items
Finally the nonpaged pool memory requirement on the file server is calculated as:
Nonpaged Pool = (60,000 * 4) * 20K ≈ 4.6 GB
The nonpaged pool memory requirement is larger than the 256 MB limit. In this scenario, there is not enough memory to use file change notification.
Last-modified time algorithm
Using the last-modified time method for cache updates, you would not use up any work items for change notifications. This is the default configuration, and as you can see from this analysis, is required for this scenario.
Using the formula given in “Estimating MaxCmds When Using File Change Notification”:
MaxCmds = ([1,000 for the peak number of requests] / [5 seconds for the staleness interval]) / 2 = 100
Next, calculate MaxWorkItems:
MaxWorkItems = (100 * 4 IIS servers) = 400
Finally the estimated nonpaged pooled memory required on the file server is calculated as:
Nonpaged Pool = 400 * 20K = 8 MB
The nonpaged pool memory requirement is within the 256 MB limit.
Depending on active traffic for file I/O and your analysis of the performance counters (Server\Files Open, Server\Server Sessions, and Server\Work Item Shortages mentioned above), you may still need to increase the settings for MaxCmds, MaxWorkItems, and MaxMpxCt from your estimated values.
Conclusion
Recommended settings for Scenario 1, using the default last-modified time caching algorithm:
| Registry Setting | IIS Server | File Server |
MaxCmds | 100 | Default |
MaxMpxCt | Default | 100 |
MaxWorkItems | Default | 400 |
This scenario works well where the large number of sites means that using the file change notification algorithm would prevent the configuration from scaling because there is insufficient nonpaged pool memory available. With SMB removed as a constraint to scaling, you should be sure to consider the aggregate traffic volume to the sites in addition to how adding more sites affects administrative burden, to determine how many sites you can configure per server in practice.
Scenario 2: Wide Content-High Traffic
This scenario discusses a large site with very high volume running several hundred applications; for this example, assume 300 applications. Also assume that this site contains static files, ASP content, and ASP.NET content, and that most of the users are anonymous users.
File-change notification algorithm
Using the formula given in “Estimating MaxCmds When Using File Change Notification”:
MaxCmds = 300 * (1(static) + 1(ASP) + 1(ASP.NET)) + 50 = 950
Next, the maximum number of work items on the file server is calculated:
MaxWorkItems = (950 * 4 IIS servers) = 3,800
Finally the estimated nonpaged pooled memory required on the file server is calculated as:
Nonpaged pool = 3,800 * 20K ≈ 76 MB
Last-modified time algorithm
You would not use any work items for last-modified time, but you would have many temporary work items in use due to the heavy traffic between the Web server and the file server. When using the last-modified time algorithm, caches in user mode are used, but the kernel-mode response cache is not. This results in a potentially significant increase in the volume of file traffic. Due to the heavy volume, the CPU overhead associated with checking the last-modified time algorithm for the three caches would be significant.
Conclusion
Recommended settings for Scenario 2, using the IIS change notification caching algorithm:
| Registry setting | IIS Server | File Server |
MaxCmds | 950 | Default |
MaxMpxCt | Default | 1,024 |
MaxWorkItems | Default | 4,096 |
In this scenario, choosing the change notification algorithm is a good idea even though it results in more work items being used. Due to the high volume, it is better to reduce the amount of traffic to the file servers as much as possible. If using change notification, the number of directories to monitor is not going to exhaust memory and you significantly reduce back-end traffic. Traffic is reduced by eliminating the need to check the last-modified time on the file servers for every sampling interval and by using the HTTP.sys cache.
If, after implementing these settings, you find that there are too many applications to cache in this manner, you could use the last-modified time algorithm and extend the staleness time of the cache to 30 seconds, which would also dramatically reduce the amount of back-end network traffic.
Scenario 3: Narrow Content High Traffic
This scenario discusses a small site with 10 applications, consisting of static, ASP, and ASP.NET content that receives very frequent requests.
File-change notification algorithm
Using the formula given in “Estimating MaxCmds When Using File Change Notification”:
MaxCmds = 10 * (1(static) + 1(ASP) + 1(ASP.NET)) + 50 = 80
Next, the maximum number of work items on the file server is calculated:
MaxWorkItems = (80 * 4) = 320
Finally the estimated nonpaged pooled memory required on the file server is calculated as:
NonPagedPool = 320 * 20K ≈ 1.6 MB
Last-modified time algorithm
You would not use up any work items that are tied to change notifications, but you would have temporary work items and heavy traffic between the Web server and the file server.
In this scenario, it is easy to recommend using the file-change notification caching mechanism. Since the content is organized in just a handful of applications, we only need a few work items to reliably cache the content.
Note that MaxWorkItems is (MaxCmds * number of IIS servers) which is 80 * 4 = 320. This is well below the default value of 4,096 for MaxWorkItems, so this value does not need to be adjusted.
Additional Considerations
If the remote file server also delivers files to computers other than the IIS servers, you will need to increase the value of MpxCt and MaxWorkItems to allow for the additional connections. As a general rule, increase MpxCt by 50 for each connection to a different server. Include 25 to 50 percent of the increase in the value for MaxWorkItems.
It is important to note that MaxMpxCt, used in conjunction with MaxCmds, is what allows a single client to use more resources on a remote server than would otherwise be allowed, and thus can increase your exposure to a denial of service (DoS) attack from a malicious client.
Conclusion
Recommended settings for Scenario 3, using the IIS change notification caching algorithm:
| Registry Setting | IIS Server | File Server |
MaxCmds | 80 | Default |
MaxMpxCt | Default | 80 |
MaxWorkItems | Default | Default |
For high traffic servers with only one or a few sites, SMB scale isn’t the primary factor affecting scale. Instead, you should tune the SMB and caching algorithm settings to optimize the efficiency of handling requests.
Reliability testing in Microsoft labs has found that adjusting these registry keys can produce dramatic differences in performance. However, testing your application with the defaults and then increasing the settings as appropriate is strongly recommended. You should also consult the SMB documentation in Windows, as well as read the related Knowledge Base articles that are listed in the appendix.
Troubleshooting UNC-Related Problems
Every technology has its own set of benefits and accompanying difficulties. Problems associated with storing content on remote servers are often network- or authentication-related. These problems are addressed in the following sections: stale content being served, IIS Manager not showing remote content, changes in the support for mapped drives, and the role of offline files.
Stale Content Served
If IIS serves stale content, you can disable the appropriate cache, static or ASP, as a troubleshooting technique. If IIS is using last-modified time as the means for updating the cache, ensure you have waited the default five seconds (or the configured interval) for the cached item to be refreshed.
To disable ASP file caching
1. | Open IIS Manager. |
2. | Right-click <ComputerName>, where <ComputerName> is the name of your computer, and then click Properties. |
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. |
7. | Restart IIS. |
To disable static file caching
Add the following value to the registry:
HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters
DisableMemoryCache: REG_DWORD: 1
You need to restart the server for this setting to take effect.
WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use the Registry Editor at your own risk.
For more information on how to disable the static file and ASP template caches, see this Knowledge Base article: http://support.microsoft.com/default.aspx?scid=kb;EN-US;q250925.
UNC Files Not Shown in the IIS Manager
When using IIS Manager to create virtual directories or Web sites mapped to a remote file server, you may notice what seems to be some confusing error messages and behavior. You may see the error “Logon Failure: Unknown user name and password” or “The system cannot find the path specified.” Also, IIS Manager may simply not show files that are present, yet when you access the virtual directory with the URL in Microsoft Internet Explorer, the files are delivered without error.
This occurs because IIS Manager uses the currently logged on user, such as the Web Administrator to access the remote content, rather than the credentials provided when you created the Web site or virtual directory. You will notice that if you create a connection to the file server with net use (or any other means that creates a connection in the user context of the signed on user), IIS Manager suddenly shows the files. You can eliminate this problem by configuring the file server so that the IIS administrator has rights to read the remote file system.
To verify you’ve configured your site or virtual directory correctly, make some requests with a Web browser to remote content. Unless properly configured, IIS Manager is not a reliable way to verify that your customers are able to access the remote content.
Mapped Drives Will Not Work
For security concerns, services cannot use drives mapped via the credentials supplied by another logged on user. In IIS 5.0, you could potentially get this to work, but it is not recommended. In Windows XP, Windows 2003 Server, and future versions of Windows, services cannot use these mapped drives. For more information, see this Knowledge Base article: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q180362
Index Server Does Not Support UNC Content
As of this writing, Index Server on Windows Server 2003 only supports indexing of local content; therefore, UNC content searching is not supported. In addition, FrontPage Server Extensions 2002 on Windows Server 2003 no longer includes the Wide Area Information Server (WAIS) search engine, which is used by FrontPage webs that use a search component. As the currently recommended replacement is to use Index Server in place of WAIS, FrontPage webs using the search component will not work on UNC-based storage. See http://support.microsoft.com/default.aspx?scid=kb;en-us;203796 for more information on replacing WAIS with Index Server.
Summary
This paper reviews important new capabilities of Windows 2003 Server as they relate to IIS using remote storage accessed with UNC pathnames. The ability to use pass-through authentication in conjunction with constrained delegation and protocol transition, opens new possibilities for integrating IIS into your network, while at the same time increasing security, performance, and reliability. Also introduced are the caching methods available to IIS and how they impact performance in different scenarios. The section about tuning different scenarios illustrates how you can employ this information to correctly configure IIS and your file servers for optimum performance and reliability.
Related Links
See the following resources for further information:
| • | |
| • | Terminal Server Client Connections and Logon Limited by MaxWorkItem and MaxMpxCt Values |
| • | Technical Overview of Internet Information Services (IIS) 6.0 |
For the latest information about Windows Server 2003, see the Windows Server 2003 Web site at http://www.microsoft.com/windowsserver2003/default.mspx.
IIS UNC-Related Knowledge Base Articles for IIS 4.0 and IIS 5.0
Historically, many of the problems that customers have encountered setting up UNC share arise from confusion about how to configure a Web server and file server to ensure secure and reliable access to the right resources, especially when using third-party file servers. For your reference, here is a list of some of the most common Knowledge Base articles related to configuring Windows 2000 Web servers hosting content on file servers.
General
Q197964: PRB: Cannot Access Remote Files with the FileSystemObject
Q286401: UNCAuthenticationPassThrough Support Limitation in IIS 5.0
FrontPage
Q215421: Incorrect Error Installing Server Extensions to a UNC Path
Q215459: Error Converting a UNC Virtual Directory to a Sub Web
File Change Notification
Q281253: File Change Notifications Are Lost When Content Is on a UNC Share
Q221790: IIS Runs Out of Work Items and Causes RPC Failures When Connecting to a Remote UNC Path
Q232476: Terminal Server Client Connections and Logon Limited by MaxWorkItem and MaxMpxCt Values
Q171148: MaxMpxCt and MaxCmds Limits in Windows 2000
Authentication
Q280383: IIS Security Recommendations When You Use a UNC Share and Username and Password Credentials
Q257174: Using Mapped Drives with IIS
Q180362: INFO: Services and Redirected Drives
Q269009: Red Stop Sign Appears in MMC on UNC-Mapped Content Directory
Q222069: IIS 4.0 Requires Username and Password When Using a Remote Computer
Q207671: HOWTO: Accessing Network Files from IIS Applications
Q124184: Service Running as System Account Fails Accessing Network (Null Session Shares)
Interoperability: NOVELL
Q267283: Inetmgr Displays Screen Errors When a Virtual Server Is on a Novell Share
Q271214: Unable to Access FoxPro Databases on Netware 5 Server from IIS 5.0
Q271228: IIS 5.0: Unable to Obtain Data from Access Database Residing on Netware 5 Server Using ASP
Q285159: How to Create Virtual Directories to a Remote Novell NetWare Share
Q250502: Cannot Access Novell UNC Share When You Run a Program as a Service
Q250925: ASP Refresh Problems with IIS and a Network Appliance File Server