Task Scheduler能否以NT AUTHORITY\SYSTEM账户正常执行Windows服务？

可以完全实现和原独立进程Windows服务等价的运行效果，包括以NT AUTHORITY\SYSTEM身份、开机阶段自动拉起的核心行为。

匹配原服务行为的任务配置要点 #

• 任务「常规」页的安全配置区域，点击「更改用户或组」，手动输入NT AUTHORITY\SYSTEM后通过名称检查校验匹配
• 同时勾选两个关键选项：「不管用户是否登录都要运行」、「使用最高权限运行」——这两个选项漏选任何一个，都会导致进程的权限上下文和原服务出现偏差
• 触发器配置选择「启动时」，可根据原服务的实际启动时序，按需配置启动延迟、等待前置事件（如网络就绪、指定系统服务启动完成）的规则，灵活性比固定的服务启动类型更强
• 操作项直接映射原服务对应的可执行程序路径，同时把「起始于（可选）」配置为原服务对应的可执行程序工作目录，避免程序读取相对路径配置时出现文件找不到的问题
• 可对照原服务的恢复策略，配置任务的失败重试、超时终止规则，进一步缩小和原SCM托管服务的行为差异

和原服务模式的实际差异 #

• 原SERVICE_WIN32_OWN_PROCESS类型的服务由服务控制管理器（SCM）托管，进程崩溃后会由SCM按照预先配置的服务恢复策略自动拉起；任务计划托管的进程不会自动接入SCM的故障监控管道，需要手动在任务设置里配置失败重启规则，才能实现同等的崩溃拉起效果
• 权限上下文层面没有差异：按上述配置运行的SYSTEM账户任务，进程的访问令牌、权限集合、强制完整性级别，和原SCM托管的SYSTEM服务完全一致，不会出现权限不足的兼容问题
• 原服务的启动顺序受SCM的服务依赖关系管控，任务计划的触发时机由调度器独立判定，不会强制关联服务间的依赖逻辑，需要自行补充启动前置条件

容易踩的配置误区 #

• 不要勾选「只在用户登录时运行」选项，该配置会强制将进程绑定到当前交互用户的会话上下文，哪怕选择了SYSTEM账户也会出现权限偏移
• 不要随意启用任务的电源限制类选项，否则在笔记本电池供电、无活跃用户会话的场景下，任务可能被调度器自动跳过不执行

内容的提问来源于stack exchange，提问作者user13342561