必须先授予“作为服务登录”权限，否则服务必启动失败；错误1069本质是权限缺失而非密码错误，需通过secpol.msc/gpedit.msc或secedit命令显式授权，并同步更新服务账户凭据与NTFS/注册表等隐性依赖权限。
必须先给目标用户授予“作为服务登录”权限，否则服务一定启动失败；直接改服务属性里的账户只会卡在凭据验证或启动报错。
为什么服务切账户后总提示“拒绝访问”或“错误1069”
Windows默认禁止普通用户以服务身份运行，哪怕你已在服务属性里填了正确用户名密码，系统仍会拦截。错误1069本质是权限缺失，不是密码错——常见于域用户没加进“作为服务登录”，或本地用户没通过secpol.msc或gpedit.msc显式授权。
- 检查错误事件：在“事件查看器 → Windows 日志 → 系统”中搜索对应服务名，看是否有
Logon failure: the user has not been granted the requested logon type at this computer - 域用户必须用
DOMAIN\username格式添加，不能只输用户名；本地用户用.\username或COMPUTERNAME\username - 组策略修改后必须执行
gpupdate /force，不重启也能生效，但部分旧系统需重启策略服务（net stop gpsvc && net start gpsvc）
用命令行快速完成权限+服务配置（无GUI环境必备）
服务器核心、远程PowerShell、自动化部署时没法点services.msc，得靠sc和secedit组合操作。
- 加权限（本地策略）：
secedit /export /cfg policy.inf & echo [Privilege Rights] >> policy.inf & echo SeServiceLogonRight = svc_user >> policy.inf & secedit /configure /db secedit.sdb /cfg policy.inf /areas USER_RIGHTS - 改服务账户：
sc config "MyServiceName" obj= ".\svc_user" password= "P@ssw0rd"（注意obj=后有空格，password=不能带空格） - 立即生效：
sc failure "MyServiceName" reset= 0 actions= restart/60000+sc start "MyServiceName"
密码变更后服务自动停摆？这是最常被忽略的同步点
服务账户密码一变，services.msc里存的旧密码立刻失效，但系统不会主动提醒，只会静默失败。尤其域账户密码策略强制90天更换时，极易中招。
- 每次重置用户密码后，必须手动打开服务属性 → “登录”选项卡 → 重新输入新密码 → 点“应用”触发验证
- 不要依赖“记住密码”：服务管理器不会缓存密码，每次
sc config都得传新密码明文（生产环境建议用gMSA避开此问题） - 若服务依赖其他服务（如SQL Server依赖SQL Server Agent），检查所有相关服务是否用了同一套凭据，否则可能链式启动失败
真正麻烦的从来不是改账户那几步，而是NTFS权限、注册表键访问、网络资源认证这些隐性依赖——比如服务要读C:\ProgramData\MyApp\config.json，就得确保svc_user对该目录有读取权，否则连日志都写不了。
