The issue with Win 10 upgrade was related to a second reboot triggered by BESClient, after the first restart following the Post-Action condition.
Once the Win 10 setup completes the upgrade and the machine is restarted the first time by the Post-Action restart triggered by BESClient, the OS still has to run some finalization steps to successfully complete the upgrade.
However, while the OS is finalizing the upgrade, BESClient finds registry settings in PendingRenameFileOperations in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager] and evaluates them as condition for launching a new reboot.
Unfortunately, the second reboot occurs too early, while the OS is still working to finish the post restart steps,
and it causes the OS rollback to the previous version and the related BigFix action failure.
Iâd really like some more detail on how the PendingFileRenameOperations check is altered and whether that is/could be applied to other situations. I.E. is the client making a new check against HKLM\System\Setup for âSetupTypeâ or âSystemSetupInProgessâ or something else?
Actually, the fix doesnât change the way BESClient checks the PendingFileRenameOperations settings.
It, instead, modifies the internal logic BESClient uses to detect if the restart has been triggered by an action and to clear the related keys.
In details, when an action creates a pending restart situation, the Windows BESClient creates a global Atom, and the global Atom persists until a machine restart: it allows BESClient to detect if the machine has been restarted since the Atom was created.
Before implementing the fix for APAR IJ13194, BESClient was checking for the global Atom unless the PendingFileRenameOperations test showed no remaining items.
For this reason, it did not clear the existing restart flags in actions.
With the fix, BESClient examines the global Atom even when the PendingFileRenameOperations are present, and used the Atom information to clear the existing restart flags in actions (and preventing any further unexpected reboot).
Thanks for clarifyingâŚand wow, that sounds big. There are lot of other queries in the forum about âpending restartâ action statuses not getting cleared, that often trace back to PendingFileRenameOperations getting updated by misbehaving software, and the need to blacklist particular keys. Sounds like this change could help in those situations?
Well, the fix address the scenario where the post action restart setting initiates unwanted reboot, but it doesnât change the behavior regarding the existence of PendingFileRenameOperations: if items still exist under PendingFileRenameOperations, BESClient wonât restart the machine additional times but the state stays in âPending Restartâ until the items are deleted by the OS/software.