常规 IIS 7.0 问题

必须手动完成此操作。

影响将取决于服务器负载。 如果要执行 10,000 个请求/秒，你会非常怀念内核缓存；但是，如果执行 100 个请求/秒，则你可能不会注意到有什么影响。 在很大程度上取决于提供的内容，IIS 5.0 没有内核模式组件，却适用于大多数客户。

提供了基本的 ruby 支持。 有关详细信息，请参阅以下链接：

http://mvolo.com/10-steps-to-get-ruby-on-rails-running-on-windows-with-iis-fastcgi/

如果是通过服务器管理器 GUI（“添加功能”）进行安装，则安装顺序并不重要。 “添加功能”向导检查所有依赖项，如果缺少任何必需的模块，则会发出警报。 此外，“添加功能”向导还知道模块的正确排序。

如果是从命令行安装或使用无人参与安装，模块的顺序并不重要（同样，安装程序知道模块的正确顺序），但你要负责标识所有依赖项。 如果未能包含一个需要的依赖项，无人参与/命令行设置将失败。

只提供静态文件且安装了所有功能的应用程序池占用 3 MB 专用字节，5 MB 页面文件。 （这比 IIS 6.0 大）。 在处理多个应用程序池方面，Windows Server 2008 优于 WS03。 发出 ASP.NET 请求后，我们在启动期间预加载少量 CLR（约 100kb）。 可通过 ApplicationPool 上的属性配置预加载。 它称为 managedRuntimeVersion。 将在第一个 ASPX 请求上加载 CLR 的剩余部分（大约 8mb）。

Access 仅适用于 32 位应用程序池。 使用经典 ASP 时，加载用户配置文件（AppPool 上的 loadUserProfile 属性）是一个问题，因为 Access 使用的是临时目录，在加载了用户配置文件时不允许匿名用户访问该目录。

Windows Server 2008 Web Edition 有很大的改进，我们专注于消除人为限制。 最终许可尚未完成，但我们计划删除所有硬件限制，允许使用 4 个处理器和 32GB RAM（在 x64 上）。 允许使用 SQL，并且将在 SKU 上安装 SharePoint。

FPSE 不再是 Windows Server 的一部分。 我们正在与第三方合作创建下载包，以便 FPSE 在 Windows Server 2008/IIS 7.0 上运行。 它没有任何新功能或增强功能，只进行了一些修复以使其兼容。

建议新安装 Windows Server 2008 并将其迁移到新服务器上；或者，只将新客户放在新服务器上。 建议为每个服务器记录一个管理完善的第三方组件和配置列表，以便在新服务器上复制当前环境。 有关站点和应用程序池配置，请参阅共享托管文章中的建议。 将在不久的将来发布一个用于帮助迁移的工具。

以下方案支持就地升级：

• Windows Server 2003 可升级到 WS2K8 Beta3、WS2K8 RC0、WS2K8 RC1 和 WS2K8 RT
• Windows Server 2008 Beta3 可升级到 WS2K8 Beta3 和 WS2K8 RC0
• Windows Server 2008 RC0 可升级到 WS2K8 RC0、WS2K8 RC1 和 WS2K8 RTM
• Windows Server 2008 RC1 可升级到 WS2K8 RC1 和 WS2K8 RTM

如果服务器处于共享配置模式，必须在运行升级前将其还原为独立配置。 为此，请禁用共享配置，将 applicationhost.config 和加密密钥复制到本地计算机，在每个服务器上运行升级，然后重新启用共享配置。

安装程序正在写入的日志文件和 iis7.log 都始终可用。 对于要记录的内容，并无精细的说明。

我们不提供在安装过程中配置模块（Windows 模块除外）的任何方法。 安装完成后，可能有一种方法可通过通用的无人参与安装来运行一些内容，在此过程中用户可以执行一些编码操作。

以 < 1000 个请求/秒的速度跟踪所有请求占用的 CPU 应 <5%。 为所有站点配置一个全局跟踪规则是可能的。 可以通过更改 <siteDefaults> 部分来为所有站点启用跟踪。

不可能，但存在基于内存的回收，这将回收超过配置的内存限制的 AppPool。

在 sysprep 之前进行的加密在 sysprep 后丢失。 目前没有解决方法。

你可以导出计算机密钥并将它们导入所有服务器中，以便解密正常运行。 Server Beta 3 的 UI 包含一个名为“共享配置”的功能，可用于执行此操作。 单击“导出...”，系统将加密计算机密钥，请将这些密钥连同 applicationHost.config 和 administration.config 一起复制到路径。 之后，可从所有其他计算机中选择“导入...”，这将导入计算机密钥并将配置指向共享配置。

对于此设置，不同的 AppPool 可有不同的值。 可将应用程序分配到不同的 AppPool

处理此错误的默认文件包含在 \inetpub\custerr\en-us 中。 此错误的页脚包含“服务器版本信息：Internet Information Services 7.0”，当然可以直接在 .htm 文件中删除或编辑该内容。

托管 API (Microsoft.Web.Administration) 有权访问本机 API 执行的所有设置，并通过使用 ServerManager.OpenRemote 静态方法享有 DCOM 远程处理支持。 你可以设置任何配置设置，但 Beta 3 不支持运行时信息，例如 AppPool 的状态或请求/工作进程的列表。

在以前的 IIS 版本中，必须通过文件系统 ACL 来控制访问权限。 这很枯燥，没有 Web 界面用于执行此操作。 借助 URL 授权，你可以使用 IIS 用户界面或直接使用 web.config 来控制对 URL 的访问。 此外，还可以使用非 Windows 标识，例如窗体身份验证提供的成员资格用户和角色。

applicationPool 部分中与该应用池相关的任何数据（无论是在 applicationPoolDefaults 中，还是特定于该应用池）都会导致 WAS 回收该应用池。 工作进程可以要求 WAS 根据某些配置更改回收应用池，目前我们仅针对 globalModules 这样做，但这不是一个封闭式列表（因为模块可以根据配置更改请求回收）。

NLB 是 Windows Server 2008 的一部分。 实质上，它与 Windows 2003 中的相同。 若要安装 NLB，请转到“服务器管理器”>“功能”>“添加功能”，然后从列表中选择“网络负载均衡”。 若要配置 NLB，需要打开命令提示符并运行 nlbmgr。 这是存在于 Windows 2003 中的 UI。

如果系统范围的 CPU 超出动态阈值，压缩将停止，释放正占用的 CPU。 如果系统范围的 CPU 降至低于一个不同的限制，动态压缩将恢复，从而节省带宽。

不同用户对最佳 CPU 使用率有不同的看法。 有的用户认为 20% 的平均使用率很完美，另一些用户则认为应该是 75%。 如果你希望的是 X 且你始终高于 X，则不妨完全删除动态压缩，因为永远不会用到它。

它考虑了自上一个示例起的 30 秒时段内的平均使用率。因此，即使出现异常峰值，峰值后执行动态压缩的时间为最多 30 秒。如果峰值是瞬间出现的（因而影响平均 CPU 使用率的时间不超过 30 秒），则它们不会影响动态压缩。

对于共享托管方案而言，在 applicationPoolDefaults 中设置 loadUserProfile=false 是一个好主意。 AppPool 的启动时间要快得多，可避免出现任何临时目录权限问题。

500.19 错误是由 IIS 7.0 功能委派模式造成的。 将功能委托给网站所有者后，网站所有者修改该功能，然后将更改保存在 web.config 中。如果服务器管理撤销了该功能的委派管理，则网站所有者负责从 web.config 中清理功能详细信息。否则，修改了该委派的功能的所有网站将立即发出“Http 错误：500.19 - 内部服务器错误”消息。 为了避免此问题，我们建议托管商不要在委派的功能发布给最终客户后立即撤销委派的功能。

如果托管网站没有 web.config，IIS 7.0 将创建一个。 如果它有 web.config，IIS 7.0 将对其进行修改。 如果修改了 web.config，则网站所有者负责合并更改并确保手动合并和维护更改。

安装管理服务根本不会修改 AppHost.config 或 Administration.config。 你将看到的唯一的更改是新的二进制文件 (wmsvc.exe)。 将创建一个自签名证书，并添加一些注册表项。 这意味着从理论上讲，不会有任何中断。

在大多数情况下，它是现成可用的，因为我们使用 redirection.config 设置来读取 apphost/admon.config。但是，如果要详细回答，这实际取决于你将使用的方案：

• 使用本地内容的共享配置：常规 Windows 或 IIS 用户连接以修改本地内容及 web.config 内容 - 无需执行任何操作，一切现成可用。
• 使用远程内容、使用 Windows 用户的共享配置：应该能正常工作，前提是 Windows 帐户有权访问其内容。
• 使用远程内容、使用 IIS 用户的共享配置：对于此方案，你必须将服务的标识 (WMSVC) 更改为有权访问远程内容的帐户，因为我们使用进程标识来访问内容。 请注意，apphost.config/admon.config 将正常工作，因为我们使用 redirection.config。
• 管理服务器连接的 Windows 管理员：应该能正常工作，前提是 Windows 管理员拥有对共享配置的写权限。

有关在 IIS 7.0 中创建站点的信息，请参阅以下链接。

只提供静态文件且安装了所有功能的应用程序池占用 3 MB 专用字节，5 MB 页面文件。 发出 ASP.NET 请求后，我们在启动期间预加载少量 CLR（约 100kb）。 可通过 ApplicationPool 上的属性配置预加载。 它称为 managedRuntimeVersion。 将在第一个 ASPX 请求上加载 CLR 的剩余部分（大约 8mb）。

如果这些文件夹不存在，Http.sys会自动创建这些文件夹。 如果将这些权限替换为其他权限，则应保留新权限。

我们已在内部进行了测试，如果安装了 ISAPI 和 Metabase，兼容性似乎不错。 网上还有一些博客，提供有关如何使其兼容的说明。 有关详细信息，请参阅以下链接：

https://blogs.iis.net/bills/archive/2007/03/06/coldfusion-on-iis7.aspx。

服务器是在 AD 帐户创建模式下设置的。 AD 创建模式是一项已弃用的功能，虽然仍受支持，但将在 V4 中删除它。 建议在 WSS 外部执行用户预配，而不是允许 WSS 自动在 AD 中创建用户。

有关集中式全局配置的详细信息，请访问：IIS 7.0 中的配置系统

x64 目前没有 FPSE。 我们的共享托管推荐体系结构是具有 32 位 AppPool 的 64 位 OS。 遗憾的是，此方案目前有一个 bug，阻止在 64 位 OS 上安装 FPSE。

可以通过完成以下步骤来重置系统三次：

若要运行 slmgr /rearm，请打开 regedit.exe 并导航到 HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL。 验证值“skiprearm”是否设置为“0”。 如果此值不为零，则重置功能不会重置系统激活计时器。

在核实 skiprearm 注册表值等于零 (0) 后，从提升的命令提示符运行 slmgr /rearm。 等待该进程已完成的通知。 这可能需要一两分钟的时间。 完成后，按照提示关闭计算机。 重启后，计算机将在 OOB Grace 中运行，并且将另有 30 天的激活时间。 此过程不会对系统进行其他任何更改。

IIS 7.0 中仍然有 IIS.CertObj COM-object，我们认为它仍然是在多个 Web 服务器上部署证书的最佳选择。 此组件行为保持不变，因此所有旧脚本都应有效（如果已启用 ABOMapper）。

set iiscertobj = CreateObject("IIS.CertObj")

iiscertobj.InstanceName = "0.0.0.0:443"

iiscertobj.Import pfxfile, pfxfilepassword, true, true

这样的脚本不依赖 ABOMapper。