I have a couple customer servers that have Intel® Smart Connect software installed which are populating the registry key PendingFileRenameOperations with the following:
I know i can exclude with the “_BESClient_ActionManager_PendingRestartExclusions” client setting i’m just not certain what the format should be. Is this correct?
??\c:\Windows\SysWOW64\WPRO_41_2001woem.tmp;??\c:\Windows\SysWOW64\WPRO_41_2001woem_nm.tmp;
I’d like to confirm before asking our customer to reboot servers.
We found that problem as well and believed it was causing our systems to show a status of “Pending Restart” even after the endpoint was restarted. We believe that it was the cause for “some”. We also made the call that the software is kind of bloatware, so we just uninstalled it.
I’m speaking client OS’s here not servers, so we’re also dealing with:
Microsoft Office 365 Updates
Printer drivers
Windows 10 Fast Startup
All these great things that M$ throws at you to make sure your computer never is in a clean reboot condition.
Can we exclude the “PendingFileRenameOperation” all together or at least at a directory level? We have so many that keep us from reporting a status of Complete after a reboot.
In our environment we found that specifying “Symantec;\spool;.tmp;” fixed 95% of the problems. I’m not sure if you can specify more than 3 values but it’s fairly flexible.
When determining if a restart is needed by examining the windows restart pending list, all items in this ';' delimited list plus hpqwmi.events are ignored. The matching is done by a case sensitive string match on the entries from the delimited list.
I’m working to find a better / more reliable way to determine when a machine needs to be rebooted specifically as a result of a patching activity. None of the built in properties are reliable for this purpose. I’m considering using this language and looking for other feedback / ideas on whether this is the right approach:
exists key “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired” of native registry
Support has concerns about the reliability of this key, but they don’t have other suggestions for more accurate information. Does anybody in the community have a better approach?
Are you using any kind of Maintenance Window settings? I’m experimenting (with good results so far) using
boot time of operating system < effective date of setting "MaintenanceWindow" of client
I toggle the MaintenanceWindow setting to start patching on my clients, and this part is relevant until the machine reboots after the window closes.
Edit: this is just one part of my relevance, I have other checks that the maintenance window has run & closed & a reboot was needed in the first place.
Thanks for the reply. No, we’re not using maintenance windows. I just need to know whether a machine needs a reboot related to patching, and only patching.
Yeah, I agree with Support’s skepticism then. It’s going to be difficult to tell the difference between “a reboot is needed due to patching” versus “a reboot is needed for something else”.
Really I think the only reason we’re flagging a “non-patch” as a reboot needed, is that some software vendors either don’t understand or are intentionally abusing keys like PendingFileRenameOperations. That lists files to swap during reboot that are always locked/in-use and cannot be replaced while Windows is fully running, and is meant for patching/servicing, but some vendors seem to rewrite their values on every reboot just to do some kind of automatic reinstall/repair during each boot (looking at you, HP Print Monitor! )
Separating out “expected” versus “spurious” PendingFileRenameOperations is going to be specific to each deployment. We can whitelist specific values but the list would be different for everyone.
We have struggled with this in the past and ended up setting up exclusions for the PendingRestartExclusions setting"
“_BESClient_ActionManager_PendingRestartExclusions”=“Symantec;\spool;.tmp;” on “{now}” for client
Our primary culprit was symantec with a lot of pending rename operations, or the spooler for disconnected rdp printers. With this we can reliably still use the “pending restart” relevance. It was creating issues mainly for Server Automation, as the “Restart Endpoint and Wait for Restart to Complete” would just hang, because after a reboot the server would still be pending restart.
We created a separate reboot task specifically for SEP, since it often times wants another reboot after a client update. For that I have it set to trigger on “not pending restart” and (exists keys “Session Manager” whose ( value “PendingFileRenameOperations” of it as string contains “Symantec”) of keys “HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control” of ( x32 registry; (if exists x64 registry then x64 registry else nothing)))
I think the best effort is really finding what is triggering the “pending restart” and figuring out how to deal with that. Even after patches are installed, small changes within the OS can trigger windows to want to restart.
