问题现象：Weekly定时一周多天某个时刻重启机器的计划任务要么如期执行重启了但显示了错的执行时间，要么没有如期执行重启且显示了错的执行时间。报错信息：The operator or administrator has refused the request. 操作员或系统管理员拒绝了请求（0x800710E0）。
针对这个问题，网上主要2个方案：试了没有用
①fix组策略、fix系统（sfc /scannow并无报错，清理组策略后问题依然）
https://answers.microsoft.com/zh-hans/windows/forum/all/操作员或系/3c814345-f8fa-43ae-9a90-3954af3e8383
恢复组策略默认设置的cmd命令：
代码语言：txt复制secedit /configure /cfg c:windowsinfdefltbase.inf /db defltbase.sdb /verbose
rd /s /q "c:windowsSystem32GroupPolicyUsers"
rd /s /q "c:windowsSystem32GroupPolicy"
gpupdate /force执行完命令后重启机器
②取消计划任务条件中电源配置前面的√
https://www.geeksforgeeks.org/operator-refused-request-error-in-win/
https://www.minitool.com/news/the-operator-or-administrator-has-refused-the-request.html
经研究，是系统bug，跟是否勾选条件页签中"只有在计算机使用交流电源时才启动此任务"前面的√没有关系。
我甚至尝试过使用ISO放在数据盘（系统盘从50G扩容到100G留够50G剩余空间）就地升级，发现这个问题并不会因为升级系统而消失。
为啥说是bug？因为"上次运行时间"并没有真正执行Weekly计划任务，Weekly计划任务首次到点执行显示0x0，过了一段时间显示了错的最后一次执行时间，从系统日志核实重启的时间就是设定的时间，首次执行重启后，后面确实没有按预期时间执行重启，正因为没有按预期时间执行才报的0x800710E0，显示的那个错的时间就是系统判定计划任务已错过、做那个判断时的时间点，自然那个时间点没有执行计划任务。为什么首次执行成功了，一开始也显示0x0了，但机器重启后过了段时间刷新成错的时间且显示了标题的报错，是同一原因，是开机的系统时间异常导致计划任务的执行状态判断出现异常。
代码语言：txt复制机器重启前后的时间可以通过下面的powershell过滤判断
#ps1
$bufferSize = $Host.UI.RawUI.BufferSize
$bufferSize.Width = 1024
$Host.UI.RawUI.BufferSize = $bufferSize
Get-WinEvent -FilterHashtable @{logname='System';id=@(6006,13);StartTime=(Get-Date).AddDays(-1) } | Where-Object {$_.ProviderName -eq "Microsoft-Windows-Kernel-General" -or $_.ProviderName -eq "User32" -or $_.ProviderName -eq "EventLog" } |Sort-Object -Property TimeCreated
Get-WinEvent -FilterHashtable @{logname='System';id=@(6005,12);StartTime=(Get-Date).AddDays(-1) } | Where-Object {$_.ProviderName -eq "Microsoft-Windows-Kernel-General" -or $_.ProviderName -eq "User32" -or $_.ProviderName -eq "EventLog" } |Sort-Object -Property TimeCreated
下图是重启前后时间连贯的举例：
下图是重启前后时间不连贯的举例：
reg query "HKEY_LOCAL_MACHINESystemCurrentControlSetControlTimeZoneInformation" /v RealTimeIsUniversal这个注册表键值的含义是什么，都有哪些取值，分别什么意思？
经过对比发现：
1、删掉RealTimeIsUniversal的话，重启机器起来后到windows time服务未就绪期间的系统时间是北京时间，东八区的情况下，不会触发这个bug，非东八区会触发这个bug。
2、如果不删RealTimeIsUniversal的话，重启机器起来后到windows time服务未就绪期间的系统时间为当前时区时间，前提是底层传了对的UTC时间。
老的S1机器：会传宿主机的localtime时间给cmos
1、删掉RealTimeIsUniversal，即0值：表示硬件时钟设置为本地时间。这是 Windows 的默认设置。在这种情况下，当您更改时区或启用/禁用夏令时时，Windows 会自动调整硬件时钟。给硬件时钟传了linux宿主机的localtime（东八区），重启后就是传的linux宿主机的localtime时间，即utc 8，如果Windows子机是西八区时区，那就跟utc 8差16个小时。
2、不删RealTimeIsUniversal的话，即1值：表示硬件时钟设置为 UTC，即系统根据CMOS时间和设置的时区来确定当前系统的时间。给硬件时钟传了linux宿主机的localtime（东八区）作为utc 0时间，那重启后就是(utc 8)-8，即utc 0，如果Windows子机是西八区时区，那就跟utc 0差8个小时。
这2种情况都会影响Weekly计划任务状态。
最终解决方案：基于当前环境做自定义镜像，开utc白名单（Windows_SysConfigClock_UTC）后等半个小时白名单生效，用刚做的自定义镜像重装系统应用白名单，重装成功后重启2遍机器，用前面的powershell命令查看时间，确保重启前后的时间是连贯的就行。
