I have another approach that you may want to try. It’s not very intuitive. Try Issuing the shutdown command yourself.
Some time back I had a problem where the BES Client wouldn’t restart the system when there was a disconnected RDP session still logged on, because the BES ClientUI could not display the shutdown message window. This was resolved in a later version, but while I was experiencing the problem I would use the
shutdown.exe /r /t 3600 command to restart the computer in one hour, in addition to the Action’s post-restart configuration.
What I found, though, was that once Windows had a shutdown scheduled, the BESClient could not shut down windows. The Client UI would be displayed for a logged-on user, but when they click “Take Action” to begin the restart, nothing happened. Windows would refuse the client’s restart call because there was already a restart in progress (granted it was scheduled to wait an hour, but still it was in progress).
I don’t know whether that’s still the case, this was some years back, but you might be able to prevent the BESClient from prematurely restarting the system by explicitly using shutdown.exe to schedule a delayed shutdown.
If you want to clear the scheduled restart (say, you’ve detected that the Windows upgrade is finished and reboots are OK to proceed), you can abort the pending restart with
I think the behavior is illustrated in this screenshot. Once I send the command
shutdown /r /t 3600 a restart is scheduled; when I send another restart command via
shutdown /r /t 900 the second instance is refused as a shutdown is in progress.