RemoteAccess 服务卡死导致 RRAS 安装失败

角色安装会以一个笼统的失败停下，事件日志几乎给不出可用的线索。在出现这种情况的服务器上，缺失的一环根本不在向导里：Remote Access 服务始终不离开 Starting 状态。无法完成自身初始化的角色，每次重试都会再次失败，所以应当先看服务，再看向导。修复登录权限只要几分钟，反复重装角色则不然。

从服务入手，而不是从角色向导入手

打开提权命令提示符，在碰角色之前先读取服务配置。有两个值要紧：启动类型，以及服务运行时所用的账户。默认安装会把该服务注册为 Network Service 下的自动、延迟启动。

如果状态停在 Starting 而不是 Running，说明服务在等待它拿不到的东西，而登录权限就是常见的嫌疑。等更久没有用，因为启动已经以服务控制管理器报告为“挂起”的方式失败了。干净地停止服务，再读一遍它的配置。然后去事件日志里看服务的启动尝试，账户名正是出现在失败旁边的地方。

角色向导只会报告初始化失败，正因如此，服务诊断必须先做。

在重装之前先读登录权限

Network Service 需要“作为服务登录”的权限才能启动。内置账户通常通过组成员身份获得它，而加固基线和策略刷新可能把它拿走。组策略会在下一次刷新时胜出，所以手工授予的权限可能毫无预警地再次消失。

导出本地安全策略， 不要相信界面，直接读取条目。这样你会留下一个文件，刷新之后可以对比，而这是唯一能知道改动是否存活的办法。如果条目为空或漏掉了该账户，问题就找到了。记下是哪条策略对象设置了它，因为那才是需要永久修复的对象。

secedit /export /cfg C:\Windows\Temp\secpol-export.inf
Select-String -Path C:\Windows\Temp\secpol-export.inf -Pattern SeServiceLogonRight
sc.exe qc RemoteAccess
Get-Service RemoteAccess | Format-List Name, Status, StartType

在本地施加、又在下次刷新时被策略覆盖的授权，看起来就像一次失效的修复，它还会以同样的方式再次失败。

改写配置的账户往返

有个捷径不必手工改策略就能修复服务的登录配置：改账户、应用，然后再改回来，密码字段留空。

这次往返会重写服务记录，并把账户需要的权限重新授予。它是绕行方案，而不是根因修复，所以应当带日期记入变更记录。在以基线管理服务器的环境里，正确的修法是把账户加入那条基线的“作为服务登录”分配。能先做就先做，往返只用来解开会卡住的安装。

sc.exe config RemoteAccess obj= "NT AUTHORITY\LocalService" start= demand
Start-Service RemoteAccess
sc.exe config RemoteAccess obj= "NT AUTHORITY\NetworkService" start= delayed-auto
Start-Service RemoteAccess

每条命令之后都要读状态，因为在某个账户下能启动、换个账户却起不来的服务，会告诉你缺的是哪项权限。

安装角色并证明它已安装

在服务运行的情况下重新添加角色，并勾上你真正打算使用的 VPN 子功能。只有通用角色并不能给你一个可用的 VPN 端点。

Install-WindowsFeature DirectAccess-VPN -IncludeManagementTools
Get-WindowsFeature RemoteAccess, DirectAccess-VPN, Routing
Get-Service RemoteAccess

确认子功能报告的是 Installed 而不是 Available，然后打开控制台，在别人碰这台机器之前完成初始配置。如果控制台仍声称服务未运行，就回到服务检查，而不是卸载角色。

把改动写下来

向导最初的选择决定了防火墙规则、地址分配，以及服务器是否期待 DHCP 中继。少量点到站点客户端并不需要站点到站点端点的形态。在点下一步之前，先定下角色、地址池、身份验证方法和证书来源。在这里靠猜，会得到一个装得干干净净、却从不接受连接的服务器。

把服务账户的偏差写进同一份记录。某次加固把默认账户改回去，可能在下一次重启时让故障复活，而那已是当初诊断它的人离开几个月之后。