解决方法：在IIS中网站管理->高级设置->应用程序池 将DefaultAppPool修改为ASP.NET v4.0. 如下图所示：

本文链接

   今天部署AD RMS的时候，需要为RMS单独创建一个服务账号，于是联想起Server 2008 R2中的一个新功能：托管服务账号。首先我们先了解一下它是什么吧？

托管服务帐号：由于对运行的服务的域用户账号密码管理起来较麻烦，因此托管服务帐号（Managed Service Account）应运而生。所谓托管服务帐号，也即委托给操作系统进行管理的帐号。托管服务帐号（MSA）的密码由操作系统自动设定、维护，定期自动更新，并不需要管理员手工干预，对管理员来说，好像此帐号没有密码一样。

托管服务帐号（MSA）的作用

托管服务账号使得服务相互隔离，需要单独进行自动密码管理

减少服务中断，从而降低TCO

对于每服务或每服务器使用单一的托管服务账号（服务账号不能被多台计算机共享）

在Windows Server 2008 R2域功能级别上能更好的进行SPN管理（允许服务器对服务账号的重命名）

　　了解完托管服务账号，我们来创建一个RMS服务账号吧！

　　1. 创建MSA帐号：

　　登陆到DC上，以管理员身份打开Powershell，输入New-ADServiceAccount 进行服务账号创建。

　　2.安装MSA帐号

　　创建帐号完成之后，就可以进行MSA帐号的安装操作了。在一台Windows Server 2008 R2的成员服务器或Windows 7的客户端计算机上安装托管服务账号，我这里的环境是Server 2012做为域成员服务器部署RMS。

　　以管理员身份打开PowerShell，输入Install-ADServiceAccount命令。

　　3. 为服务分配MSA帐号

　　打开服务控制管理器，展开配置-服务，在右侧双击所需配置的服务，在登录标签页下，选择“此账户”-“浏览”，导航到之前创建的MSA帐号，点击确定。使用该服务以选定MSA帐号运行。

本文链接

上周二，我接到了一个很诡异的案例，表现为任务栏右下角网络连接图标始终为一个红叉，已排除网卡硬件、链路和网卡驱动的问题。主板都新换了一块，可是问题依旧，这无疑将问题的根源指向了操作系统。本想通过网络疑难解答包先自动排错，可是发现该疑难解答提示服务未能启动因此不能进行自动排错，经查证，Diagnostic Policy Service 服务处于起不来的状态，报错"错误5：拒绝访问"。

经过我的排查，我发现系统的很多服务都未能启动，尤其是网络相关的很多服务，例如DHCP，防火墙，ICS，IPSec Policy Agent 等等。当我手动尝试启动这些服务时，除了有些报相关服务尚未启动之外，无一例外地，都报了一个错误——错误5：拒绝访问。（需要先启动的相关服务都是该错误）

查看系统日志，将里面的更详细的错误代码拿去微软搜索，发现没有什么收获。在一些社区解决方案中，也没能找到行之有效的解决办法，甚至微软官方论坛有一个同样的案例，一个错误的/不太相关的解答被标记为正解……

这显然不是正解，我得找到一个解决该问题的办法。于是经过各种尝试，我最后通过 Process Monitor 的帮助，找到了服务无法启动的直接原因和解决办法。由于当时没有截图，所以今天我还原了一个当时的情景，以 Base Filtering Engine 服务的无法启动为例，阐述当时我的解决思路。Base Filtering Engine 服务简称 BFE，相关的网络安全服务（如 Windows 防火墙和 IPSec）依赖于它。

在打开 Process Monitor 的记录以后，我立即点击启动服务，来尝试启动 BFE。它立即报错"拒绝访问"，我同时也尝试启动了那些不能启动的服务，都成功地重现了问题。停止 ProcMon 的记录后，在已记录下的log中，我可以看见当该问题重现时系统各进程所做的一些操作。通过粗略的快速浏览翻查和关键字"denied"搜索，引起我注意的是，很多注册表的访问遇到了 access denied 的错误。而在文件访问中，尚未发现该错误。为了精细地验证，我对当前记录下的log进行了筛选器的应用。

应用筛选后，我们可以看见所有相关的 Access Denied 的条目。当时真实环境里的可以看见很多这样的条目，因为很多服务都出现了无法启动的故障，而撰写本文时的实验环境里，我只制造了 BFE 这一种服务的该问题。通过 Path 列，我们可以看见其具体的路径为 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent . 右击该条目，选择 Jump To… ，注册表编辑器便会被调用打开打开，并且自动定位到该键。我查看其权限设置，发现所有条目继承于 Policy 键。

那我们就来看看该处的 Policy 键上的权限设置，与正常的计算机的同一位置的权限设置有何不同。

不难发现，服务不能启动（尤其是提示拒绝访问）的直接原因是因为，该服务无权访问注册表的这个键。（通过 Process Monitor 可以看出，它实际上要访问的是 Policy 的子键"Persistent"却遭到拒绝）

要尝试恢复，那我们要做的就是至少在 Persistent 键及其子键/键值上授予 BFE 合适的访问权限。为了一步到位，我做的是参照正常的系统，将正常的 ACE 项在权限传播的起始处——Policy 键上设置，并往下传播。设置时，除了还原应有的 BFE 的权限，还完全一致地将其他缺失权限补齐，将多余权限删除，这样可以避免一些额外的潜在问题。（例如权限仍过小或者过大）

值得注意的是，BFE 这个服务账号不同于一般用户账号和组，所以直接键入 BFE 时间查不到名称的。正确的做法是键入"NT Service\BFE"检查名称。

而默认地，BFE 在 BFE 服务的注册表项上的访问权限是特殊的。虽然我们可以直接授予完全控制权限来解决该问题，但是我们最好还是参照 LUA 原则，跟系统默认的一样，将其设为特殊权限。特殊权限的具体项目如下图所示：

好了，设置好并且应用权限之后，再次点击启动服务按钮，就可以看到该服务正常启动了。

最后，对于该诡异案例，有几个说明：

1. 究竟是什么操作导致了系统出现这样的问题，让诸多系统服务注册表键权限变成非默认值，至今尚不明确。据用户称，他就是出了个差，回来后就这样了，其间没有装过什么软件或者手动做过这种设置注册表权限的危险操作。搜索互联网，很多人都有遇到此问题的经历，但是没有哪个帖子能够明确指出是什么操作引起了这个问题。如果您恰好有过此方面的研究，欢迎告诉我。

2. 事实上，该用户最后重装系统了，这也是我建议他做的。因为，该问题的发生，可能还伴有其他的一些未知的系统严重性更改，修复了注册表权限，并且让服务启动后，不能确保他在该系统上，今后不会遇到其他的怪异问题。

3. 就像我遇到的这个真实案例一样，该错误一旦发生，往往会伴有很多系统服务遇到此拒绝访问的启动问题。如果要应用此方法全面修复，那是非常耗费时间和精力的。这里给出一个能尽量加速解决此问题的思路：