组策略配置服务启动类型必须使用“服务”扩展，即通过GPMC的「计算机配置→策略→Windows设置→安全设置→系统服务」节点设置，仅支持自动、手动、禁用三种类型，且须用内部服务名；直接修改注册表HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services{svcname}\Start无效，因SCM启动时会覆盖该值；策略需链接至目标计算机所在OU，确保Domain Computers有读取和应用权限，并执行gpupdate /force及重启生效；关键域控制器服务（如Netlogon、KDC）受AD DS角色保护，组策略无法干预，须通过角色安装/卸载管理。
组策略中配置服务启动类型必须用“服务”扩展，不能靠注册表策略硬改
域环境中直接修改注册表项 hkey_local_machine\system\currentcontrolset\services\{svcname}\start 看似能控制服务启停，但实际无效——windows 服务控制管理器（scm）在系统启动时会校验组策略定义的启动类型，并覆盖注册表值。真正生效的路径是组策略管理控制台（gpmc）中的「计算机配置 → 策略 → windows 设置 → 安全设置 → 系统服务」节点。
操作要点：
- 该策略仅支持设置
自动、手动、禁用三种启动类型，不支持“自动（延迟启动）”或“触发器启动” - 服务名称必须填 Windows 内部服务名（如
Spooler），不是显示名称（如“Print Spooler”） - 策略应用后需执行
gpupdate /force并重启服务或重启计算机（部分服务如Netlogon需重启才生效） - 若服务已被手动启动且设为“禁用”，SCM 不会强制停止它，但下次开机不会拉起
服务策略不生效？检查 GPO 链接位置和安全筛选是否正确
常见现象：策略已配置，但客户端运行 services.msc 查看服务状态仍为旧值，或 gpresult /h report.html 显示该 GPO 未应用。
根本原因通常是策略作用域错位：
- GPO 必须链接到包含目标计算机的
OU，不能只链接到用户 OU 或林根 - 默认情况下，计算机策略对所有计算机生效，但若启用了“安全筛选”，需确认
Domain Computers组或具体计算机账户有读取和应用组策略权限 - 检查 GPO 是否被更高层级（如父 OU 或域）的“阻止继承”或“强制”策略覆盖
- 运行
rsop.msc（结果集策略）可快速验证本地计算机实际生效的服务策略
批量配置多个服务时，避免逐条添加——用 PowerShell 导出/导入策略模板
手动在 GUI 中一条条配 20+ 个服务极易出错，且无法复用。推荐用 Get-GPOReport + Import-GPO 实现模板化部署。
实操建议：
- 先在一个测试 GPO 中配好全部服务项，导出为 XML：
Get-GPOReport -Guid "xxx-xxx" -ReportType Xml -Path "C:\svc-policy.xml" - 提取其中
<service></service>节点块，保存为独立模板文件，便于版本管理和 diff 对比 - 新环境部署时，用
Import-GPO -Path "C:\svc-policy.xml" -TargetName "Prod-Service-Policy" - 注意：导入会覆盖目标 GPO 全部现有服务策略，勿直接导入到生产 GPO；应新建 GPO 导入后再测试
某些关键服务（如 DNS、KDC、Netlogon）受域控制器角色保护，普通策略无效
在域控制器上尝试通过组策略禁用 Netlogon 或设为手动，策略会静默失败——因为这些服务由 Active Directory 域服务（AD DS）角色自身管控，其启动类型由 AD DS 安装过程固化，组策略中的“系统服务”扩展无权干预。
这类服务的管理方式完全不同：
- 必须通过
dcpromo或Install-WindowsFeature AD-Domain-Services流程控制角色启用/卸载 - 运行
sc query netlogon可看到其START_TYPE显示为0x20（即“系统启动”），这属于 AD DS 内部标记，不在组策略可写范围内 - 试图强行 stop/start 这类服务会导致域身份验证中断，甚至引发 USN 回滚风险
域控制器上的服务策略，只适用于非核心服务（如 W32Time、TapiSrv、SSDPSRV），核心 AD 相关服务得按角色生命周期管理，别硬套通用服务策略。
