使用在UNC服务器上的远程存储内容及NAS设备部署和配置 Internet信息服务（IIS） 6.0

本页内容

简介

Web服务器（如：IIS）的一项常规功能就是接受来自 Web 客户端对文件的请求，通过获取文件并将内容传输回客户端来响应请求。在一些情况下，传输到客户端的文件会被存储在 IIS本地服务器上。这是考虑到速度的最佳设计，也确保了文件一经更新即可传送新的内容。对于传递一小组易于管理的文件的几个 Web站点，从便利性和性能的角度考虑，在 IIS 服务器上本地托管内容是最佳选择。

然而，在许多情况下将文件存储在 IIS服务器上，既不实际也不可能实现。某些系统需要管理许多文件，并将文件放置在 IIS 服务器上，把内容管理任务和 IIS管理任务同时结合在一个相同的系统。如果工作负载能够由单个服务器处理，就有益于本地保存内容，但当需要通过添加 Web服务器进行外扩时，引发了管理复杂性，因为文件系统必须在服务器间不断地进行复制。复制需要消耗时间，这可能导致传送过期的内容或造成其它一些同步问题。另外，需要管理多台服务器的文件系统安全性，这又进一步加剧了复杂性。最后，为满足文件存储增长的需要，您必须在每一台服务器上扩展存储容量，从而需要增加硬件，而这样就带来了额外的开支，同时由于硬件故障，更易出现停机状况。

为减轻这些问题，IIS可以作为前端来传送存储在远程系统上的内容。本文的主要介绍 IIS 6.0和远程服务器的配置和调整，其中远程服务器作为文件、应用程序或其它可供使用 UNC （通用命名惯例）路径名的 IIS使用的网络资源的集中式存储库。虽然本文仅限讨论对作为文件服务器的 Microsoft 服务器操作系统的访问，但也提供了许多适用于其他通过 UNC路径名访问远程文件共享的存储解决方案的信息，如：NAS 设备。

体系结构

无论您的服务器的需求是简单的轻负载还是复杂的重负载，深入了解 IIS 6.0 和 Windows Server 2003 的功能和技术以便使用 UNC 路径名远程访问内容，将有助于实现您的设计。

分布式方案

作为 IIS 启用远程存储和分布情况的一个例子，考虑到一个教育机构中有 100 位教员在制定课程表和考卷，并为他们的班级邮寄分数（见图1）。IIS 可用于在每位教员的系统上映射单独的共享文件夹，使他们能快速、轻松地向学生发布重要内容。在这种情况下，IIS作为运用远程存储器的分布式信息集中器。

图 1：IIS 6.0 作为运用远程存储器的分布式信息集中器
查看大图

通过运用分布式文件系统（DFS）作为提取低层目录结构的途径，可将这种系统设计地更加可靠和更具可管理性。例如，如果 Anthro101 被映射到属于DFS 目录的一个 UNC 路径名，当下学期教员更换时，您只需要在分布式文件系统（DFS）中将 \\Instructor\Anthro101更改 \\NewInstructor\Anthro101 即可，而无需更改 IIS 配置。

ISP 方案

IIS也可对 Internet 服务提供商（ISP）方案提供远程内容方面的优点。在一个共享的托管环境中，Internet服务提供商（ISP）可以在单个服务器上拥有数千个 Web 站点，内容散布到许多站点上，但每个站点的流量较低。通过将内容从 IIS服务器中导出，Internet 服务提供商（ISP）可以在单个冗余磁盘阵列（Redundant Array of IndependentDisks，RAID）或其它存储解决方案上为多台服务器存储内容（见图 2）。Internet服务提供商（ISP）在存储器上的投资通过集中而非分散于众多 Web 服务器而实现了优化。这减少了硬件故障的出现，并简化了恢复策略。

图 2：IIS 从远程存储设备分布信息
查看大图。

高容量方案

高容量 Web 站点经常使用由多台统一配置的 IIS 服务器组成的 Web 场，这些 IIS 服务器从负载平衡器接收流量。在此方案中，对 Web场中的服务器来说，访问一个或多个 Microsoft SQL 服务器群集是很普遍的，这些群集服务器经常使用 Microsoft ClusterServer（MSCS）作为一个公共数据存储库。注意：这时并不在文件服务器间运用网络负载平衡（NLB），因为在 Microsoft网络中使用的服务器消息块（Server Message Block，SMB）通信采用独立的话路。这一高可用性方案为运行于 IIS 6.0的应用程序提供一个公共数据库，后者可在任何一台服务器出现故障时，运用故障转移功能。同样，IIS 6.0所提供的内容和应用程序可以托管于一个群集文件服务器或 NAS 设备，因此任何一个远程存储器的故障对用户来说都是透明的。（见图 3）。

图 3：在高容量和 Web 场方案中，多台 IIS 服务器为其应用程序和内容提供了一个公共数据库
查看大图。

有关设计高可用性服务器系统的更多信息，请登陆：http://www.microsoft.com/technet/archive/windows2000serv/plan/hiavsys.mspx.

访问远程内容

考虑到各方利益，应对集中式内容权衡利弊。虽然在 IIS 服务器上远程存储器给于管理员更多的选项，但是带来了额外的安全要求。

登录 IIS

当用户在 Web 浏览器中键入一个 URL，在 IIS 上访问内容时，IIS 总将用户与某个用户帐户相关联。若启用匿名访问，同时 Web 站点和 NTFS 许可允许请求访问，将对用户分配匿名帐户，通常为：IUSR_<ComputerName>。否则，用户必须使用对所请求的资源启用身份验证方法之一进行身份验证。与用户相关联的用户名和密码就是用户凭证。检查本地 NTFS 许可请求的用户安全标识符（SID）以确定访问许可。据说，IIS 代表用户启动的应用程序运行于用户的安全环境。

访问远程文件服务器

当用户从 IIS 请求通过 UNC 路径名映射到远程文件服务器的信息时，文件服务器在授予用户访问许可之前将要求 IIS 执行身份验证。在 IIS4.0 和 IIS 5.0 中，当创建一个其内容位于 UNC 共享区中的新的 Web 站点或虚拟目录时，IIS会提示管理员针对用户名和密码凭证创建站点，如图 4 所示。用户名和密码存储在元数据库中，以便用于在共享区上进行身份验证，从而在 Internet服务管理器中查看共享文件。因此，用户在“用户名”文本框中键入的用户名在远程文件服务器中必须是一个有效的用户，或者，如果 IIS 服务器和文件服务器都是域成员，键入的用户名必须是域用户。

图 4：虚拟目录创建向导（IIS 4.0 和 IIS 5.0）
查看大图。

当一个 Web 用户访问 Web 站点或虚拟目录时，IIS 在元数据库中检索凭证，并使用其在 UNC 共享区上执行身份验证。

例如，如果有 100 位不同的用户在 IIS 上进行身份验证，并请求访问远程文件服务器，IIS通过每个用户凭证授权对存储在本地磁盘的内容的访问。对远程存储的内容来说，IIS 不使用已验证的用户凭证，而是将管理员为 Web站点创建的用户名和密码凭证提交给远程服务器来授权访问。运用单一用户凭证传送内容是一项有效的技术，可确保远程内容总是可用；然而，这样同时降低了用NTFS 许可权保护这些内容安全的有效性和审查的实用性。

与 IIS 4.0 和 IIS 5.0 一样，在 IIS 6.0 中，IIS 管理器仍然允许您配置一组固定的凭证，或者您可以将用户凭证提交给文件服务器。在 IIS 6.0 中，这种通行身份验证（有时称为用户委派）属于默认的配置，如图 5 所示。

图 5：虚拟目录创建向导（IIS 6.0）
查看大图。

启用时，IIS 6.0 可将用户凭证提交给远程系统，以便管理员可以在较以前更高的精细层次上保护和核查远程内容。另外，在运用通行身份验证时启动的驻留于文件服务器的应用程序均运行于用户的安全环境下。

在IIS 管理器中看到的更改反映了元数据库中的底层更改以及 IIS 目前对远程文件服务器运用身份验证凭证的方式。首先，当 “UNC 用户名”和“UNC 密码”元数据库属性是空白时，已验证的用户凭证将被发送到远程服务器，而不会被保存在元数据库中。其次，如果提交已验证的用户凭证用于验证用户，而所提交的凭证是错误的，服务器将向 Web 浏览器返回一个 401 错误（未经授权）。如果提交“UNC 用户名”和 “UNC密码”用于验证用户，而所提交的用户名和密码是错误的，将会返回一个 500 错误（内部服务器错误）。IIS错误信息提供了最小的必备信息量，以便通知合法用户阻止黑客工具尝试确定如何突破 IIS 安全防护的企图。

图 6 简要描绘了针对IIS 所处理的所有内容执行的身份验证过程，包括所有运行于正确的用户环境的静态内容，如：.gif 文件和 HTML 页面、脚本映射文件、CGI脚本和 ISAPI 扩展 DLL（如：ASP 和 Microsoft ASP.NET）。ISAPI筛选器在工作者进程身份环境下运行。工作者进程默认作为网络服务运行，网络服务是具有最小许可权的内部服务帐户。如要了解关于 IIS体系结构和工作者进程身份的更多信息，请参阅“IIS 概述”。

图 6：针对 IIS 执行或检索的所有内容的身份验证过程
查看大图。

工作组环境中的通行验证

在工作组环境中，所有用户帐户都是本地帐户。只要 IIS 和文件服务器拥有用户名和密码均相同的用户帐户，使用 Basic验证的通行验证就仍然有效。该配置很快会变成管理负担，从而无法得到广泛实施。在这类环境中，指派一个特别针对同 UNC连接配合使用的单一用户帐户，可能是最佳选择。

域环境中的通行验证

在域环境下，如果您使用应与安全套接字层（SSL）一起实施以加密用户名和密码的 Basic 验证或 Kerberos，通过综合 Windows身份验证，通行验证在无需额外配置的情况下即可运作。当然，前提是文件服务器和 IIS 都属于同一个域或信任域的成员。Windows Server2003 有一个新增的特性，称为强制委派，允许您以更安全的方式进行委派，并委派其他种类的登录凭证（包括 Basic 和 Kerberos）。下面提供了更多有关设置“强制委派”的信息和指导。您可以在“Windows Server 2003 帮助”中查找附加信息。

Windows Server 2003 强制委派

委派是一种将用户凭证从一台服务器传递给另一台服务器的功能，无需重新对用户执行身份验证。Windows 2000支持委派，但您无法对系统上特定的一组服务执行强制委派，从而难以安全地执行系统的功能。另外，委派只受 Basic 和 Kerberos 协议支持。

Windows Server 2003 使用强制委派（有时称为：Service4User2Proxy），委托 IIS将委托凭证授予远程服务器上特定的服务列表。在网络上执行强制委派的能力为配置运行IIS 的 Windows Server 2003文件服务器带来了新的可能性；来自用户的凭证被传递给指定计算机上的 指定服务。这让您可以使用基于域的用户或组，而不是针对来自 IIS 服务器的 UNC 访问的单一指定用户来保护远程内容上的 NTFS 许可。

对身份验证运用协议转换

当Windows Server 2003 文件服务器启用了委派功能时，您就可以对远程服务器委派通过NTLM、Basic、Digest、客户端凭证和 Kerberos 身份验证获得的用户凭证：客户端可以在使用任何上述身份验证协议的 IIS上进行身份验证，同时 IIS 可以委派使用 Kerberos 功能的凭证。Windows Server 2003的这个特点称为协议转换（Protocol Transition），有时称为：Service4User2Self，因为IIS（服务）能够代表经验证的用户获得一项服务。这是非常合理，因为 IIS 已经验证完用户，并能够告知Kerberos，它信任用户的身份，允许用户在其上进行操作。强制委派与协议转换相关联，允许 IIS（服务）使用用户的服务权证，请求Kerberos域控制器（KDC）对远程服务器（代理）授予一个权证。该权证只可以委派给域管理员所指定的远程服务器上的服务，因此称为强制委派。这给了您最大限度的灵活性来选择 IIS 上的用户，并确保了通过通行验证安全接入网络资源。

最后，IIS 发出的服务权证被远程文件服务器用于授权访问所请求的共享区、目录和文件，上述对象均受 ACL 的保护。服务权证代表域用户身份，如：MyWebSiteAnonymousUser。有关身份验证、协议转换、强制委派和授权的整个过程如图 7 所示。

图 7：强制委派下的授权
查看大图。

协议转换和 NTLM

举一个协议转换的例子，如果您的客户端通过使用 NTLM 的综合 Windows 身份验证在 Web 服务器上进行身份验证，IIS上的用户令牌就没有足够的许可权可以访问其他服务器，如文件或 SQL 服务器。因此，针对通过 NTLM（或任何 Basic 或 Kerberos的其他方法）进行验证的用户的通行验证将失败。Windows Server 2003 允许您配置 Microsoft ActiveDirectory，从而采用 NTLM 的登录可以获得委派授权（详见以下说明）。一旦您启用了这项委派，Web 服务器收到的令牌就属于Kerberos 权证，其拥有访问其他服务器的许可权。基本上，基于 NTLM 的令牌可以升级到基于 Kerberos 的权证。参见 Windows Server 2003 文档，了解更多详细信息。

IIS 5.0 隔离模式中的强制委派

如果您已经从 IIS 5.0 升级到了 IIS 6.0，IIS 6.0 默认运行于 IIS 5.0 隔离模式。在 IIS 5.0 隔离模式中，进程以外的应用程序作为本地 IWAM_<ComputerName>帐户运行，从而妨碍了强制委派的正常运作。作为本地帐户运行的进程不能代表已验证的用户获得 Kerberos 权证。当时，可以通过切换 IIS使之运行于工作者进程模式，启用强制委派。运行于工作者进程隔离模式的工作者进程将作为网络服务用户帐户运行，即作为域中具有充分权限以委派凭证的计算机帐户。

设置服务器的委派功能

在 Windows Server 2003 上设置委派功能的方式取决于您是否支持一个同时拥有 Windows 2000 和 Windows Server 2003 域控制器的网络。当同时支持 Windows 2000 and Windows Server 2003 域控制器时，Windows Server 2003 必须运行于混合模式。这限制了您在整个域林使用 Windows 2000 委派功能。

在 Windows 2000 混合域中设置委派功能

在 Web 服务器域的域控制器上：

1.

单击开始，管理工具，再单击活动目录用户和计算机

2.

必要时展开域（如：iishost.microsoft.com）和“计算机”文件夹。

3.

在右边的方框中会列出您的域中的计算机。右击 Web 服务器计算机名，再单击属性。

4.

在常规选项卡上，如图 8 所示，确定已经选中了信任计算机可执行委派复选框。

5.

在提醒您不能随便执行此操作的消息框中，单击确定。

图 8：在混合模式域中设置服务器的委派功能。
查看大图。

重要须知： 仅在所需的服务器上启用“信任计算机可执行委派”，必须在 Web 服务器上进行设置，但对于远程文件服务器则没有此要求。

在 Windows Server 2003 域中设置委派功能

在不支持 Windows 2000 域控制器的 Windows Server 2003 域中设置委派功能，允许您使用协议转换和强制委派。

校验您的域处于 Windows 2003 Server 模式下

1.

单击开始，管理工具，再单击活动目录用户和计算机。

2.

在左边的方框中选择域。

3.

在菜单上单击操作，再选择提升域功能等级

将弹出“提升域功能等级”对话框，如图 9 所示。如果您的域处在 Windows 2000 本级模式或 Windows 2000 混合模式下，您需要将其提升到 Windows Server 2003 模式。

如要提升域功能等级

1.

继续上述步骤，在“提升域功能”对话框中，从下拉菜单中选择 Windows Server 2003 ，然后单击提升。

重要须知： 这个更改是不可逆的并可能需要 15 分钟的时间。

图 9：提升域功能等级
查看大图。

2.

在“此更改将影响整个域”警告上，单击 确定。提升完域功能等级后，就不能再逆转了。

3.

在“成功提升了功能等级”消息上，单击 确定。

如要设置委派功能

1.

单击开始，管理工具，然后单击 活动目录用户和计算机。

2.

必要时展开域（如：iishost.microsoft.com）和“计算机”文件夹

3.

在活动的目录用户和计算机 的右边方框中，MMC 工具列出了您的域中的计算机，双击 Web 服务器的计算机名，选择 属性，然后单击 委派选项卡（图 10）。

图 10：计算机属性的“委派”选项卡上的默认设置
查看大图。

4.

默认禁用委派功能。如要启用协议转换和强制委派，选择仅对指定的服务信任计算机可执行委派功能。

5.

另外，您可以随意对基于 Kerberos 或任何验证协议的工作指定委派功能。这样您就可以结合 Basic、NTLM、Digest、Kerberos 或任何其他 IIS 验证提供器使用通行验证。

6.

单击添加按钮。

7.

在添加服务对话框中，单击 用户或计算机，然后搜索或输入将要从 IIS 接收用户凭证的文件服务器的名称（图 11）。

图 11：识别将接收委派凭证的文件服务器
查看大图。

8.

结束时单击确定 。

9.

在计算机名属性对话框中，单击 添加按钮。将弹出添加服务对话框。

10.

在添加服务对话框中，单击 用户或计算机，在选择用户或计算机 对话框中，搜索或输入将要从 IIS 接收用户凭证的文件服务器的名称（图 12）。

图 12：使用 Windows Server 2003 的“选择用户或计算机”对话框指定文件服务器
查看大图。

11.

结束时单击确定。如图 13 所示，“添加服务”对话框，现在列出了针对选定的计算机注册为结合 Kerberos 的服务主体名的服务。

图 13：Windows Server 2003 “添加服务”对话框列出了已注册的服务
查看大图。

12.

从服务类型 列表，选择“HOST” （服务器服务）和“通用 Internet 文件系统”（CIFS）服务，然后单击“确定”。

重要须知： 仅添加您确定需要接收委派凭证的服务。请确认使用的是文件服务器而不是 Web 服务器上的服务名称。 注意： 如果您想使用强制委派访问远程 SQL 服务器，就必须添加相应的服务（针对 SQL 服务器）。常见例子是，您有一个可建立对 SQL 服务器的活动数据对象（ADO）连接的活动服务器页面（ASP）。SQL Server 服务主体名为：MSSQLSvc。

图 14：对 Active Directory 设置协议转换和强制委派的结果
查看大图。

13.

在计算机名属性对话框上的委派选项卡中，确认是否已添加了新的服务，如图 14 所示。单击确定。这样就完成了对 Active Directory 设置从 IIS 服务器到文件服务器的协议转换和强制委派的步骤。

在文件服务器上设置许可

必须谨慎实施文件服务器许可，以便提供对内容的正确访问。这一过程涉及将 IIS 身份验证协议同委派和通行验证相结合，或为 IIS 指定一个用于在验证远程资源时使用的用户帐户。当然，您的服务器应该总是使用 NTFS 许可，以便正确地实施安全性。

文件服务器共享文件夹

共享区的默认共享许可为“每个人均可读取”。如果您正在使用 IIS 作为一台发布服务器（WebDAV、Microsoft FrontPage、FTP等）并且文件服务器处于后端，您需要为共享区和 NTFS设置充分的许可，以便可以写入资源。共享许可应该可以“更改”或“完全控制”，并需要“修改写入”许可，以便使有关应用程序正常运行。所需的特定设置取决于您实施发布的方式。

设置共享许可

1.

右击您想共享的文件夹。

2.

选择共享和安全。

3.

选择共享选项卡（设置正确的共享名和注释）。

4.

单击许可。

5.

删除“每个人”组（如果存在的话）；这可能允许意外的访问。

6.

添加适当的用户或群组（通行验证的用户是一个很好的选择），可以访问共享文件夹。授权访问可以输入群组或用户。建议您使用群组来控制本地资源的访问权。

7.

给用户或群组最小的必需的权限来访问目录。读取是最小的允许权限。如果本地用于 Frontpage 发布，更改或完全控制权限可能是必需的。

设置 NTFS 权限

重要须知：注意当编辑任何默认的 NTFS ACL 设置时；您需要确认管理员仍然可以控制文件目录。

1.

右击您想保护的文件夹或文件

2.

选择共享和安全。

3.

选择安全选项卡。

4.

单击添加按钮。

5.

输入您想访问的域用户或组的名称，然后单击确定。默认的 NTFS 设置仅用于服务器上的本地帐户。域用户必须明确允许正确的访问。

6.

确认允许 复选框被设为允许最低限度的访问。（要让 IIS 检索内容，只需选定“读取”访问。）

注意:取消选定“允许列表文件夹内容”不会在 IIS 管理器中禁用 IIS 目录浏览。取消选定“允许读取和执行”不会 在 IIS 管理器中禁用“IIS 脚本或执行”许可。

在一些环境下，例如共享托管提供商，通常允许共享许可合理开放并依靠 NTFS 许可来控制安全性。记得共享和 NTFS许可共同提供双方所允许的最低特权。无论您如何选择集成共享区和 NTFS 许可，都要确定它们经过正确的设置，因为这些许可是您的 Web服务器安全的基础。

提高文件服务器的可用性

为了提高可用性，请考虑像 SQL服务器一样群集您的文件服务器。另外（或者），您可以使用 DFS 提供一个非特定于机器的 UNC命名惯例和文件复制服务（FRS）来提供冗余度。这个技术已证明可随 Windows 2000 Service Pack 3（SP3）和Windows Server 2003提高可靠性。此外，网络负载平衡能用于给一组相同的文件服务器分配流量。下面是几篇知识库文章，可帮助解释如何使该方案运作；当使用 Frontpage扩展服务器时，这些文章非常有用。

Windows Server 2003 的群集网络名称资源的属性描述：

http://support.microsoft.com/default.aspx?scid=kb;en-us;302389&sd=tech

在更改了计算机对象时如何对群集服务帐户执行故障诊断：

http://support.microsoft.com/default.aspx?scid=kb;en-us;307532&sd=tech

基于 Windows 2000 的服务器群集上的Kerberos 支持：

http://support.microsoft.com/default.aspx?scid=kb;en-us;235529&sd=tech

分布式文件系统：

http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/windows2000/techinfo/reskit/en-us/distrib/dsdb_dfs_kale.asp

对远程内容优化 IIS 缓冲

当IIS 传输内容时，将缓冲页面，以便响应请求。更快地进行传输。这对于远程文件服务器特别重要，因为网络子系统介于 IIS与其内容之间，从而增加了等待时间。当进行缓冲时，一些机制必须就位，以便让 IIS 了解远程服务器上的内容比保存在 IIS 缓存中的版本更新。

IIS6.0 支持通过两种方式来决定文件缓存是否需要使用远程文件服务器上的新内容进行更新：如 IIS 4.0 和 IIS 5.0中所执行的文件变更通知，以及 IIS 6.0 所新增的最后一次修改时间。另外，缓冲方法必须针对静态文件和 ASP 进行单独设置。

最后一次修改时间

默认情况下，IIS 6.0 只是简单地查询在文件服务器上的文件系统对缓冲文件的最后一次修改时间。如果最后一次修改时间在文件上已经改变，IIS上的文件缓存就用新的内容进行更新。如果最后一次修改时间没有改变，在 IIS上的文件缓冲版本就被发送出去。通过使用最后一次修改时间替代监测每个变更通知的虚拟目录（这会大量消耗文件系统的资源），当大量虚拟目录映射到 UNC共享区时，可伸缩性将得到提升。检查一个文件的最后修改日期是一个比文件变更通知更可靠的机制，因为一些 NAS设备不会完全执行变更通知。此外，当最后一次修改时间被抽样后，随着共享区和 NTFS许可的生效，安全性将得到提升。使用该缓冲方法的一个重要考虑事项是，不通过 HTTP.sys 缓存缓冲 UNC 内容。然而，在 ASP内的缓存和静态文件使用缓存的方式不受这种设置的影响。

在该情况中，最后一次修改时间缓冲方法表现最佳：

当站点或虚拟目录的数量很大时。

文 件很庞大（超过 256 K 的文件将不会使用任何缓冲算法进行缓冲；如果您传输大型文件，缺少使用最后一次修改时间算法的 HTTP.sys 缓存，效果会比较差。在 Windows Server 2003 SP1 中，可以通过一个注册表键配置该限制，可能大于 256 K）。

缓存命中率低。

可靠性/可用性比性能更重要。

您的 NAS 设备不能可靠地支持变更通知。

在缓存采样期间，您关注授权共享许可。

在一台繁忙的服务器上，每当访问完一个文件就去检查最后一次修改时间是不切实际的。因此，在默认情况下，IIS 6.0 大多每隔 5 秒检查一次最后一次修改时间，此外，它假定文件没有改变。IIS 在 5 秒间隔内从缓存中传出旧文件。

对于某些站点，5 秒间隔太大，而对其他站点来说又太小。这个采样间隔可以通过下面的注册表键（非默认值）来配置：

静态页面设置注册属性，FileAttributeCheckThreshold，一个 DWORD 值，位于：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters。 另外，注意到包含文件处理程序（ssinc.dll）的服务器端利用用户模式静态文件缓存，因此您应用于用户模式静态文件缓存的配置也被应用于 .stm、.shtml 以及任何其它您将其映射到 ssinc.dll 的文件。

ASP 脚本设置注册属性，FileMonitoringTimeoutSeconds，一个 DWORD 值，位于：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ASP\Parameters。

使用最后的修改缓存更新机制将使传输的内容更安全和更可靠。另外，它可以在一个广泛的应用结构上很好地进行扩展（您的 Web 服务器拥有大量指向成千个不同目录的应用程序）。然而，在静态内容方面存在明显的性能损失。

文件变更通知

在很多情况下，基于 UNC 的内容的性能在默认的缓存设置下稍低（和使用基于变更通知的缓冲相比较）。如前面提到的，HTTP.sys缓存没有用作使用最后修改缓存方式的 UNC内容访问。因此，如果您传输庞大的文件，不会使用任何缓存算法进行缓冲，您将无法观察到性能差异。如果您观察到差异，那么可能使用了静态文件而不是ASP 文件。使用ASP，检查最后一次修改时间和监听变更通知之间的性能损失很小，因为无论哪种方法用作缓冲更新，等待时间的最大部分来自于重新编译和执行 ASP页面。

变更通知事件的 IIS 监控器位于每个虚拟目录的根目录。大量虚拟目录能够导致巨大的开销，但如果您使用一个文件服务器可靠地报告变更通知 并且 您只有少量的站点和使用远程内容的虚拟目录，使用变更通知速度会更快。例如，如果您拥有附带几个应用程序的单一站点，同时您的所有内容都存储在一台 Windows Server 2003 文件服务器上，那么推荐您使用变更通知的缓存方式。

在下列情况中，基于变更通知的缓冲表现最佳：

站点或使用 UNC 内容的虚拟目录的数量较少。

文件小到足以执行缓冲（小于 256 K）。

要求都集中在几个文件中，即缓冲命中率较高。

核心模式缓存所提供的性能优点很重要。

您可以通过添加下列注册键（非默认值），启用基于通知的缓冲：

静态页面设置注册属性，DoDirMonitoringForUNC，一个 DWORD 值，位于：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters。 另外，注意到包含文件处理程序（ssinc.dll）的服务器端利用用户模式静态文件缓存，因此您应用于用户模式静态文件缓存的配置也被应用于 .stm、.shtml 以及任何其它您将其映射到 ssinc.dll 的文件。

ASP 脚本设置注册属性， EnableChangeNotificationForUNC，一个 DWORD 值，位于：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ASP\Parameters。

针对 UNC 内容调整服务器

对于高压条件下的 UNC 路径，可能需要进行专门调整以优化服务器性能。在这样的环境下，某些错误可能会在浏览器、IIS 服务器和远程文件服务器的事件日志以及 IIS 日志的 Win32 错误信息中显示。下面将列出这些错误并讨论其解决办法。

缺乏外部 TCP 端口

使用 UNC 路径下载，您可能看到下面事件的错误信息：

Windows 找不到网络路径。检查网络路径是否正确并确定目标计算机不忙或已关机。如果 Windows 仍然找不到网络路径，请联系您的网络管理员。错误代号：0x80070033。

不能到达网络位置。关于网络故障的信息，请查阅 Windows 帮助。错误代号：0x800704CF。

建立 UNC 连接，当 IIS 服务器缺乏外部 TCP 端口时这些错误不会被返回。在这种情况下，IIS 向所有请求返回 HTTP 500 错误信息，直到 TCP 端口重新可用为止。如要解决这个问题，使用 MaxUserPort注册表设置（在 IIS 服务器上）增加可用的端口数量。关于 MaxUserPort 的更多信息，参见注册表键：http://www.microsoft.com/resources/documentation/isa/2000/enterprise/proddocs/en-us/isadocs/cmt_regkey.mspx。

例如，如果您有庞大数量的虚拟目录，或您使用通行验证并有大量已验证的用户，那么就有可能在一个 UNC 路径上让大量已验证的用户同时使用资源。从IIS 服务器到远程文件服务器的 SMB 连接对每一个独立用户开放。每一个 SMB 连接使用一个端口。默认情况下，您可将外部 TCP 连接限制到1,024 至 5,000 个端口（不少于 4,000 个端口可用），因此您需要增加很大的数量，例如 10,000 或 20,000个，允许每个 SMB 连接使用其他端口。显然使用其他的应用程序在这么多的端口上创建套接字可能会导致问题。更详细的信息，参见下面的 MSDN文档：http://www.microsoft.com/windows2000/techinfo/howitworks/communications/networkbasics/tcpip_implement.asp。

文件服务器的未分页内存

在某些情况下，由 IIS 报告的与 UNC 路径名相关的错误是由于文件服务器而不是 IIS 上的问题所引发的。如前面提到的，一个 UNC 连接可引入一个 SMB 连接。结果将创建一个或更多的工作项目用于 SMB 连接。工作项目是 SMB 针对 I/O操作所用的数据结构对象，可以在不同的时间以各种方式加以使用。例如，对文件执行一项操作，如：CreateFile 或GetFileAttributes，仅在短时间内占用一个 I/O 工作项目，但在一个目录结构中查询一个变更通知将在对 IIS服务器的整个连接期间占用一个工作项目。因此，工作项目所执行的这类工作能够影响用以维持 SMB 连接的工作项目的总体可用性。

工作项目在文件服务器的未分页 池式内存（通常称为未分页池）中进行创建。这种内存之所以成为未分页内存，是因为其无法对系统页面文件进行动态交换或分页。因此，您的服务器拥有可供正常使用的充足的空余未分页池是很重要的。

在一台文件服务器上的大量的工作项目可能导致未分页池式内存的分配超支。在这种情形下，您可能在事件查看器中看到下列错误信息：

没有足够的服务器存储空间用以处理此命令。

服务器无法从系统未分页池进行分配，因为池是空的。

服务器在最后的 60 秒时间内无法分配一个工作项目。

您可以使用文件服务器打开任务管理器快速检查内存，选择执行选项卡和在核心内存框中检查未分页的值。有两种方法可解决这类问题：减少工作项目的数量或调整 IIS 和文件服务器以管理更多的工作项目。

在决定如何进行最佳处理前，您应该在模拟工作负载环境下将服务器运行几个小时，在文件服务器上检查下列计数器的性能监控计数器：

“打开服务器\文件”提供了有助于估计正确的 SMB 设置的信息。

“服务器\服务器会话”提供了有助于估计正确的 SMB 设置的信息。

“服务器\工作项目缺乏”：如果该计数器增加，意味着需要更多的工作项目。

“服务器\池式未分页字节” ：如果计数器太少，服务器几乎耗尽其可用的未分页池。可能就需要减少 SMB 的工作项目。

当您调整服务器时监控这些设置，可以帮助您评估调整的效果。

重要须知： 在 x86 平台上，最大的未分页池式内存是 256 MB；然而，您的系统可能小于该数值，因为最大的内存数量是动态确定的。

减少工作项目数量

在页面服务器上通过减少分配的工作项目数量，可以影响在页面服务器上的未分页池式内存的消耗。这可以使用一些技巧来完成。

对 IIS 更改缓存算法；使用针对缓存更新的默认的最后一次修改时间方法，会导致所创建的工作项目减少。

减少连接到文件服务器的已验证的用户数量。对每个唯一的用户创建一个连接。如果您对连接指定一个用户，而不使用通行验证，连接数将减少。

减少使用远程资源的虚拟目录或 Web 站点的数量

调整服务器

对 IIS 服务器的调整会对文件服务器上的负载造成影响。因此，当调整这些参数时，在文件服务器上的设置就由 IIS 服务器上的设置决定。尤其，您可以控制文件服务器所需工作项目的数量，这可以通过在 IIS 服务器上调整注册表设置MaxCmds，然后在文件服务器上修改 MaxMpxCt 和 MaxWorkItems 来调节MaxCmds的设置加以实现。MaxCmds 决定允许从 IIS 服务器到文件服务器同时连接的 SMB 的数量，MaxMpxCt 在文件服务器上配置用以限制同时连接到那个服务器的数量，而 MaxWorkItems 指定一个文件服务器所能分配的接收缓冲区的最大数量。为 MaxCmds 确定正确的值是很重要的，旨在了解应该在文件服务器上将何值输入给 MaxMpxCt 和MaxWorkItems。在MaxCmds被确定后，在文件服务器上的MaxMpxCt设置，应该等同于在IIS服务器上的 MaxCmds设置。另外，MaxWorkItems的设置至少必须等于MaxCmds * IIS 服务器的数量。

表 1 显示了在 Windows Server 2003 中一些 SMB 设置的默认和最大注册表值（和 Windows 2000 一样）：

表 1 SMB 注册表设置

HKLM\System\CurrentControlSet\Services\LanmanWorkstation
\Parameters\ MaxCmds

50

65535

HKLM\System\CurrentControlSet\Services\LanmanServer
\Parameters\MaxMpxCt.

50

65535 (Windows 2000 SP2+; max 125 on Windows 2000 pre-SP2)

HKLM\System\CurrentControlSet\Services\LanmanServer
\Parameters\MaxWorkItems

4096

65535 (see 232476 below)

为帮助确定设置了正确的值，这里提供一些关于工作项目设置的详细资料：

当使用通行验证访问远程内容时（如图 5 所示），对每一个唯一的已验证用户创建一个 SMB 连接。当指定一个用户访问远程内容时（如图 4 所示），仅有使用一个 SMB 连接。

使用文件变更通知作为缓冲更新算法，长期增加了工作项目数量的消耗，因为每个变更通知要求使用一个工作项目，直到连接中断为止。

MaxWorkItems 在 远程文件服务器的本地注册表配置 HKLM\System\CurrentControlSet\Services\LanmanServer\参数。

MaxCmds 和 MaxMpxCt 在IIS服务器上的本地注册表配置 HKLM\System\CurrentControlSet\Services\LanmanWorkstation\参数。

通常，MaxCmds不得超过 12,000，因为在 X86 平台上内存的上限为 512 MB。

要使 MaxWorkItems、 MaxCmds和 MaxMpxCt 注册表值生效，您必须分别在远程文件服务器和 IIS 服务器上停止和启动服务器服务和工作站服务。您可能需要重新启动独立的服务，但不需要重新启动服务器。

下列公式可以帮助您为 MaxCmds 估算起始值。为了清楚地应用这些信息，这些公式将在下一节中应用于几个方案中，即扩展 SMB 的 IIS 和文件服务器配置方案。

在使用文件变更通知时评估 MaxCmds

当对缓冲使用文件变更通知时，评估MaxCmds的公式如下：(IIS 需要针对变更通知监测的确切的物理目录数) * (1 [如果静态文件存在] + 1 [如果 ASP 内容存在] + 1 [如果 ASP.NET 内容存在]) + 50 (并行的缺省/常规文件 I/O )。

这个公式提供的值假定 100% 的 IIS 服务器连接在给定的时间内处于活动状态。一般来说，不存在这种情况，因此MaxCmds可能减少 25% 或 50%，具体情况根据您的活动的特征而定。

重要须知： 这些计算只是一个粗略估计。利用上面推荐的性能监控计数器研究，您可以进行更多的调整。

在使用最后一次修改时间时评估 MaxCmds

当为缓存使用最后一次修改时间时，评估 MaxCmds的公式如下：(每秒请求量峰值 / 用时) * 2。 用时指 IIS 检查文件变更的频率，默认为 5 秒。这个公式提供的值假定在任何时候 IIS 资源的使用比率都很高。如果不是这种情况，您可以MaxCmds降低 50% 到 75%，具体情况根据您的活动的特征而定。

重要须知： 这些计算只是一个粗略估计。利用上面推荐的性能监控计数器研究，您可以进行更多的调整。

计算 MaxWorkItems 和所用的未分页池式内存

在确定MaxCmds 的值后，您应该设置 MaxWorkItems 的值，与（ MaxCmds 的值相同* [连接到文件服务器的 IIS 服务器的数量）。 如果您使用 IIS 服务器，那么 MaxWorkItems 将等同于 MaxCmds。如果您有 4 个 IIS 服务器，那么 MaxWorkItems = 4 * MaxCmds。

在一个内存为 512MB 或更多的 Windows 2003 Server 上，每个工作项目占用 20 K的未分页池式内存。如果在服务器上的内存不足 512 MB，每个工作项目占用 8 K的未分页池式内存。其目的在于确保有足够的未分页池式内存供其他服务器资源使用，并试图最小化工作项目占用未分页池式内存的总量。

重要须知：在 X86 平台上未分页池式内存的最大值是 256MB。然而，由于物理内存容量等因素，您的服务器实际可以分配量会小于该值。设置之后，可以根据系统硬件配置，包括物理内存和已安装的设备，动态调整未分页池式内存容量。您可以使用系统工具 PerfMon 观察两个计数器监控未分页池内存的使用情况：内存\未分页字节和内存\池 未分页Alloc，可指出有多少未分页池式内存当前正在使用。有两种方法可用以间接确定什么时候未分页池式内存使用已经超过了最大值。其一，当分配未分页池式内存失效时，服务器服务会在系统事件日志中记录该事件。其二，服务器计数器工具PerfMon\未分页池峰值表明在服务器的一生中任何时间分配的未分页池式内存的最大值。如果您认为您的服务器的未分页池式内存消耗已经达到实际的最大值，就可以粗略地表示出最大可用的未分页池式内存。

在某些情况下，您可能发现您需要大量的工作项目。但每个工作项目占用 20K，您消耗了太多的未分页池式内存。如果您的服务器有 512 MB 内存或更多，您可以配置工作项目的占用内存是8K而不是 20 K。在文件服务器中，将注册表键SizReqBuf， REG_DWORD 位于HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters设为：0x1104 (4356d)。 这就允许在文件服务器上使用更多的工作项目，而不需要消耗大量的未分页池式内存。这种解决方法的代价是：对于大量目录的枚举减少，并能降低网络性能。

注意：按照本文的意图，我们假定服务器有 512 MB 或更多的内存，最大的未分页池式内存是 256 MB，一个工作项目占用 20 K 的空间。

扩展 SMB 的 IIS 和文件服务器配置方案

为了对 IIS 和文件服务器确定正确的配置，让我们调查缓冲算法（最后一次修改时间和文件变更通知）是如何影响上述的MaxCmds、MaxMpxCt和 MaxWorkItems 注册表设置。这些考虑事项，结合性能监控器的研究，能够告诉您如何最好地配置您的服务器。基于此处所讨论的目的，将每个应用程序假定为一个 UNC 映射 Web 站点或虚拟目录。

在下列方案中，假定每个服务器有 512 MB 或更大的内存，共有四个 IIS 服务器连接到文件服务器上。

方案 1：超大容量 低流量

在此方案下，每个 IIS 服务器托管多达 20,000 个应用程序。在 20,000 个应用程序当中，仅有大约 1,000在任何给定的时间都处于活动状态，每个活动的站点在它自己的应用程序池中运行并有两个用户；一个发布用户（使用 FrontPage 或 WebDAV发布）和一个匿名用户。这些内容主要是 ASP 或静态文件，还有少量的 ASP.NET 应用程序。

文件变更通知算法

当使用文件变更通知运用给定的公式估算 MaxCmds 的值时，MaxCmds 的值按下面公式估算：

20,000 * (1(static) + 1(ASP) + 1(ASP.NET)) + 50 = 60,000

下一步，在文件服务器上的工作项目的最大数量是这样计算的：

MaxWorkItems = (60,000 * 4 IIS 服务器) = 240,000 工作项目

最后，在文件服务器上要求的未分页池式内存是这样计算的：

NonPagedPool = (60,000 * 4) * 20K 4.6 GB

要求的未分页池式内存比 235MB 的限制要大的多。在此方案中，没有足够的内存用以使用文件变更通知。

最后一次修改时间算法

对缓冲更新运用最后一次修改时间算法，您不需要为变更通知使用任何工作项目。您可以从分析中看到，这个默认的设置是此方案所要求的。

当使用文件变更通知时，运用给定的公式估算MaxCmds的值：

MaxCmds = ([1,000 峰值请求量] / [5 秒钟用时间隔]) / 2 = 1,000

下一步，计算 MaxWorkItems:

MaxWorkItems = (1,000 * 4 IIS 服务器) = 4,000

最后，在文件服务器上要求的未分页池式内存是这样计算的：

NonPagedPool = 4,000 * 20K 80 MB

要求的页面池式内存在256MB限制以内。

取决于文件 I/O 活动流量和计数器性能的分析 (服务器\文件打开，服务器\服务器会话，和服务器\上面提到的工作项目缺乏)，您仍然需要在您估算的值上为 MaxCmds，MaxWorkItems，和 MaxMpxCt 添加设置。

结论

方案 1 中的推荐设置是使用默认的最后一次修改时间缓冲算法：

MaxCmds

1,000

默认值

MaxMpxCt

默认值

1,000

MaxWorkItems

默认值

4,000

在存在大量站点的地方会运作的很好，这意味着使用文件变更通知算法将防止配置的扩展，因为有足够的未分页池式内存可用。SMB 作为强制扩展被删除，您应该确切考虑除如何增加更多的站点影响管理负担外，还有总的流通量，确定实际上您能给每个服务器配置多少个站点。

方案 2：大容量 高流量

此方案讨论一个巨大的站点，有很高的流量，运行几百个应用程序；例如，假定有 300 个应用程序，同时假定这个站点包含静态文件、ASP 内容和 ASP.NET 内容，大多数用户属于匿名用户。

文件变更通知算法

当使用文件变更通知时，运用给定的公式估算 MaxCmds 的值：

MaxCmds = 300 * (1(static) + 1(ASP) + 1(ASP.NET)) + 50 = 950

下一步，在文件服务器上的工作项目的最大数量是这样计算的：

MaxWorkItems = (950 * 4 IIS 服务器) = 3,800

最后，在文件服务器上要求的未分页池式内存是这样计算的：

NonPagedPool = 3,800 * 20K 76 MB

最后一次修改时间算法

您不需要为最后一次修改时间使用任何工作项目，但您可能由于 Web服务器和文件服务器之间的大量流量而使用很多临时的工作项目。当使用最后一次修改时间算法时，将在用户模式下使用缓存，而未使用核心模式的应答缓存。这可能导致文件流量的大量增加。由于容量巨大，与 CPU 开销相关联的针对三个缓存检验最后一次修改时间算法非常重要。

结论

方案 2 中的推荐设置是使用 IIS 变更通知缓存算法：

MaxCmds

950

默认值

MaxMpxCt

默认值

1,024

MaxWorkItems

默认值

4,096

在此方案中，选择变更通知算法是一个好办法，即使它会导致使用更多的工作项目。基于高流量，尽可能减少了对文件服务器的流量，效果更好。如果使用变更通知，监控目录的数量不会占用内存，您可以大量减少后台流量。通过排除在文件服务器上为每个抽样间隔校验最后一次修改时间的需求并使用 HTTP.sys缓存，流量就会减少。

在执行这些设置后，如果您发现在这种方式下有太多的应用程序需要缓存，您可以使用最后一次修改时间算法和扩展缓存的过时时间到 30 秒，这样可以大幅减少后台网络流量的总量。

方案 3：小容量 高流量

此方案讨论的是一个拥有 10 个应用程序的小站点，包括静态、ASP 和 ASP.NET 内容，接收到频繁的请求。

文件变更通知算法

当使用文件变更通知时，运用给定的公式估算 MaxCmds 的值：

MaxCmds = 10 * (1(static) + 1(ASP) + 1(ASP.NET)) + 50 = 80

下一步，在文件服务器上的工作项目的最大数量是这样计算的：

MaxWorkItems = (80 * 4) = 320

最后，在文件服务器上要求的未分页池式内存是这样计算的：

NonPagedPool = 320 * 20K 1.6 MB

最后一次修改时间算法

您不需要使用任何工作项目捆绑到变更通知，但您会有临时的工作项目，并在 Web 服务器和文件服务器之间存在巨大的流量。

在此方案中，很容易推荐使用文件变更通知缓存机制。由于只有少量的应用程序用以组织内容，我们仅需要很少的工作项目来可靠地缓冲内容。

注意 MaxWorkItems 是(MaxCmds * IIS 服务器数量)，即 80 * 4 = 320。 对于 MaxWorkItems 来说处于默认值 4,096 之下比较合理，因此这个值不需要调整。

附加考虑事项

如果除 IIS 服务器，远程文件服务器也对计算机传输文件，您需要增加 MpxCt 和MaxWorkItems 的值，允许另外的连接。通常，对每个到不同服务器的连接，将MpxCt增加 50%，包括将MaxWorkItems值增加 25% 到 50%。

注意到MaxMpxCt是很重要的，通过和 MaxCmds 联合，允许单个用户在一个远程服务器上比其他的允许用户使用更多的资源，这样能增加从一个匿名用户进行拒绝服务（DoS）攻击的可能性。

结论

在方案 3 下推荐设置是使用 IIS 变更通知缓冲算法：

MaxCmds

80

默认值

MaxMpxCt

默认值

80

MaxWorkItems

默认值

默认值

对于只有一个或少量的站点的高流量服务器，SMB 性能不是影响性能的最初因素。相反，您可以调整SMB和缓冲算法设置来优化处理请求的效率。

在 Microsoft 实验室的可靠性测试发现调节注册键能够在性能上产生巨大差异。无论如何，强烈推荐您通过默认值测试您的应用程序，然后适当地增加配置。您也应参考 Windows 中的 SMB 文档，阅读附录列出的相关知识库文章。

故障诊断与 UNC 有关的问题

每种技术都有它自己的一套优点以及相应的缺点。在远程服务器上与存储内容相关的问题经常出在网络或相关的身份验证上。这些问题经常在下列情况中出现：过期的内容服务，IIS 管理器没有显示远程内容，映射驱动器支持的更改，脱机文件的角色。

过期的内容服务

如果 IIS 服务内容过期，作为故障诊断技巧，您可以关闭适当的缓存、静态或 ASP。如果 IIS 使用最后一次修改时间作为更新缓冲的方式，确定您已经等待了缓冲更新时间 5 秒钟（或设定的时间间隔）。

关闭 ASP 文件缓冲

1.

打开 IIS 管理器

2.

右击 <计算机名>，该 <计算机名>就是您的计算机名字，然后单击 属性。

3.

单击 编辑 编辑 WWW 主要服务属性。

4.

在 主目录 选项卡上，单击 配置。

5.

在 处理选项 选项卡上，选中 不缓冲 ASP 文件选项。

6.

单击 应用，然后单击 确定 保存您更改的设置。

7.

重启 IIS。

禁用静态文件缓存

在注册表中添加下面的值：

HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

DisableMemoryCache: REG_DWORD: 1

要使设置生效，您需要重新启动服务器。

警告： 不正确地使用注册表编辑器会导致严重的问题，可能需要您重新安装您的操作系统。 Microsoft 不能保证解决由于不正确地使用注册表编辑器而产生的问题。您要自己承担使用注册表编辑器的风险。

如何关闭静态文件和 ASP 模板缓存的更多信息，请参考知识库文章： http://support.microsoft.com/default.aspx?scid=kb;en-us;250925&sd=tech.

IIS 管理器未显示 UNC 文件

当使用 IIS 管理器创建虚拟目录或 Web站点映射到一个远程文件服务器时，您可能注意到看似混乱的错误信息和行为。您可能看到登录失败的错误：未知的用户名和密码或系统，无法找到指定的路径。同样，IIS 管理器可能完全不显示当前的文件，而当您在 Microsoft IE 浏览器中使用 URL 访问虚拟目录时，文件却无误地执行传输。

发生这样的事情，是因为 IIS 管理器使用当前登录的用户，例如 Web 管理员访问远程内容，胜于您创建 Web站点或虚拟目录提供的凭证。您将注意到如果您用网络用户创建一个连接到文件服务器（或使用任何其他方式在注册用户的用户环境下创建一个连接），IIS管理器会突然显示这些文件。您可以通过配置文件服务器消除这个问题，这样 IIS 管理员就有权读取远程文件系统。

为了验证您已经正确地配置了您的站点或虚拟目录，使用一个 Web 浏览器发送一些请求到远程内容。除非配置适当，IIS 管理器不是一个检验您的客户是否能够访问远程内容的可靠途经。

映射驱动器不工作

为安全起见，服务不能通过其他登录用户提供的凭证使用映射驱动器。在 IIS 5.0 中，您可以使其运作，但不推荐这样做。在 WindowsXP、Windows 2003 Server 和未来的 Windows 版本中，服务都不能使用这些映射驱动器。更多信息请参考知识库文章：

http://support.microsoft.com/default.aspx?scid=kb;en-us;180362&sd=tech。

索引服务器不支持 UNC 内容

到目前为止，Windows Server 2003 索引服务器仅支持本地内容的索引；因此，不支持UNC内容搜索。另外， WindowsServer 2003 的 FrontPage Server Extensions 2002 不再包括广域信息服务器（WAIS）搜索引擎，而使用FrontPage 环球网搜索组件。现在推荐的替代品是使用 WAIS 位置的索引服务器，FrontPage 环球网搜索组件在基于 UNC存储器上将不再工作。使用索引服务器替代 WAIS 的更多信息，请参考 http://support.microsoft.com/default.aspx?scid=kb;en-us;203796&sd=tech 。

总结

本文讨论了 Windows 2003 Server 的一些重要的新增功能，这些功能涉运用远程存储器的 IIS，后者通过 UNC路径名访问远程存储器。结合强制委派和协议转换运用通行验证的能力，为将 IIS集成到您的网络中，并在同时提高安全、性能和可靠性带来了新的可能性。另外，还介绍了 IIS可运用的缓冲方法，以及这些方法在不同的情况下如何影响性能。有关针对不同方案进行调整一节，解释了如何利用有关信息正确配置 IIS和文件服务器以实现最佳的性能和可靠性。

相关链接

查处以下资源了解更多信息：

面向 Internet 开发人员的身份验证与安全性

受 MaxWorkItem 和 MaxMpxCt 值限制的终端服务器客户端连接和登录。

Internet Information Services（IIS）6.0 技术概况

IIS 6.0 帮助

关于 Windows Server 2003 的最新信息，请参考 Windows Server 2003 Web 站点，位于：http://www.microsoft.com/windowsserver2003/default.mspx。

针对 IIS 4.0 和 5.0 的涉及 IIS UNC 的知识库文章

至今，用户在设置 UNC 共享区时遇到的许多问题，都是因为不清楚如何配置 Web服务器和文件服务器以确保对正确资源的安全和可靠的访问（尤其当使用第三方文件服务器时）而引起的。作为参考，这里提供了一个列表，列出了一些关于配置Windows 2000 Web 服务器以托管文件服务器上的内容的最常用的知识库文章。

综合文章

197964: PRB：无法通过文件系统对象访问远程文件

286401：IIS 5.0 中的 UNCAuthenticationPassThrough 支持限制

FrontPage

215421：将 Server Extensions 错误安装到 UNC 路径

215459：错误将 UNC 虚拟目录转化为一个子网

文件变更通知

281253：当内容在 UNC 共享区上时，文件变更通知丢失

221790：当连接到一个远程 UNC 路径时，IIS 溢出工作项目并导致 RPC 失效以及http://support.microsoft.com/default.aspx?scid=kb;en-us;232476（Terminal Server 上出现相同症状，参见更详细的知识库文章）

271148：MaxMpxCt 和 MaxCmds 在 Windows 2000 中的限制

身份验证

280383：对于使用 UNC 共享区以及用户名和密码凭证的 IIS 安全建议

257174：通过 IIS 使用映射驱动器

180362: 信息：服务和重定向的驱动器

269009：在 UNC 映射内容目录上红色禁止标志出现在 MMC 中

222069：使用远程计算机时 IIS 4.0 要求用户名和密码

207671：HOWTO：从 IIS 应用程序访问网络文件

124184：作为系统帐户运行的服务导致网络访问故障（空会话共享区）

互操作性：NOVELL

267283：当虚拟服务器位于 Novell 共享区时，Inetmgr 显示屏幕错误提示

271214：无法从 IIS 5.0 访问 Netware 5 Server 上的 FoxPro 数据库

271228: IIS 5.0：无法从位于使用 ASP 的 Netware 5 Server 的 Access 数据库获取数据

285159：如何对远程 Novell NetWare 共享区创建虚拟目录

250502：当您将一个程序作为服务运行时，无法访问 Novell UNC 共享区

250925：IIS 和网络设备文件服务器的 ASP 刷新问题