作者 ：Thomas Deml
介绍
Windows 7 或 Windows Server 2008 R2 上的 IIS 7.5 支持名为“应用程序池标识”的新功能。 它允许对应用程序池进行有效的隔离，而无需为每个应进行沙盒化的应用程序池维护用户帐户。 应用程序池标识是自动生成的，不需要密码-管理成本下降。
每个新功能都有一些缺点，应用程序池标识功能也不例外。 本文介绍将 IIS 7.5 与 SQL Express 一起使用时 Web 应用程序开发人员可能遇到的问题。
谜题的片段
SQL Express 支持名为 “用户实例”或 RANU（运行为普通用户）的功能。 如果启用此功能（打开此功能与将“UserInstance=true”添加到连接字符串一样简单），则当用户打开数据库连接时启动的 SQL Server 进程将在与连接用户相同的帐户下运行。 从安全的角度来看，RANU 非常理想。
使用 Visual Studio 2008 或 Visual Studio 2010 进行开发时，默认连接字符串存储在 machine.config 文件中。 这就是：
<connectionStrings>
<add name="LocalSqlServer" connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true" providerName="System.Data.SqlClient"/>
...
默认连接字符串使用 RANU（用户实例=true），如你所看到的。 例如，当功能要求数据库存储某些数据但尚未配置数据库时，将使用默认连接字符串。 ASP.NET 成员身份是一个很好的示例。 如果开发人员将成员资格功能添加到他的 Web 应用程序，ASP.NET 将自动创建数据库和必要的表，方法是使用 machine.config中的默认连接字符串。
问题
现在，问题如下：
开箱即用的 RANU 不适用于新的“应用程序池标识”功能。 “应用程序池标识”功能是 IIS 7.5 中的默认标识。 例如，IIS 7.5 DefaultAppPool 在“IIS AppPool\DefaultAppPool 标识下运行，不再作为 NetworkService 运行。 出于此原因，如果还使用 Visual Studio 进行开发，则可能会遇到此问题。
下面是你可能会看到的错误页：
此错误的原因是 SQL Server Express RANU 要求加载用户配置文件，并且 IIS 7.5 默认不会加载 用户配置文件 。 在早期版本的 IIS 中看不到此错误，因为 DefaultAppPool 作为 NetworkService 运行，操作系统预加载 NetworkService 的用户配置文件。
修复
幸运的是，此问题的修复非常简单。 通过 IIS，只需将 Application Pool 上的 LoadUserProfile 设置设置为 true 即可加载应用程序池的用户配置文件。
这可以通过用户界面完成：
- 单击 IIS 管理器中的“应用程序池”节点。
- 选择正在讨论的应用程序池，例如 DefaultAppPool
- 单击“高级设置...”右侧的“操作”菜单中。
- 在“进程模型”子部分中，可以找到名为“加载用户配置文件”的行。 将其切换到“true”
如果要通过命令行执行此操作，请在提升的命令提示符中执行以下命令：
%windir%\system32\inetsrv\appcmd set config -section:applicationPools /[name='DefaultAppPool'].processModel.loadUserProfile:false
加载用户配置文件的副作用
加载用户配置文件的最大副作用可以是临时目录。 如果未加载用户配置文件，则 %temp% 环境变量指向 \windows\temp 目录。 每个人都可以写入此目录。 如果加载用户配置文件，则 %temp% 环境变量指向仅用户有权访问的专用目录。 因此，如果 DefaultAppPool 作为“IIS AppPool\DefaultAppPool”运行，则 %temp% 变量将指向 C:\Users\DefaultAppPool\AppData\Local\Temp 目录。 只有 DefaultAppPool 和管理员组才有此目录的写访问权限。
那么，为什么这是个问题？ 遗憾的是，Windows 操作系统支持名为“模拟”的功能。 模拟允许一段代码在与进程运行身份不同的标识下运行。 某些 Web 应用程序框架利用此功能。 例如，经典 ASP 会将所有代码以模拟身份执行。 使用的标识是 IIS 配置存储中配置的匿名用户，或者通过 IIS 提供的身份验证方案（基本、摘要或 Windows）进行身份验证的用户。 ASP.NET 不会模拟它默认运行的代码。 通过配置中的 system.web identity 节 或 .NET API 仍支持模拟。 问题是模拟标识可能无权访问 %temp% 目录。 下面是 文章 ，其中解释了此问题的一个实例。
如果您仅开发 ASP.NET 应用程序，并且不使用身份验证部分，您可能永远不会遇到这些问题，并且加载用户配置文件应该是完全安全的。
总结
本文介绍了 SQL Express 和新 IIS 7.5 应用程序池标识的问题。 由于应用程序池标识功能是 IIS 7.5 用户中的默认设置，因此在开发环境中使用 SQL Express 时（即使用 Visual Studio 进行开发时）可能会看到上述问题。 此问题不会在生产环境中发生，因为生产环境中不支持 SQL Express。