The settings seemed like it was working, but when I tried the upgrade on a slow machine, I found the same problem. Bigfix caused the upgrade to fail by issuing a restart before the upgrade was complete. Is it because 300 seconds is not enough?
Here is the setting that was set prior to running the upgrade.
setting “_BESClient_Resource_StartupSleepSeconds”=“300” on “{now}” for client
Sounds like it isn’t long enough for a slow machine. Unfortunately, 300 seconds is the max value for the setting. Can you try setting “_BESClient_ActionManager_PendingRestartExclusions”=“drivers;DRIVERS;” instead?
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 shutdown.exe /a
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.
Yes, I will try right away. The only reason I did not set PendingRestartExclusions is because L3 told me not to.
According to Emiliano, “_BESClient_ActionManager_PendingRestartExclusions”=“drivers;DRIVERS;” setting would prevent the reboot from occurring even when it is required. This is the problem that they have discovered (blocking the reboot from happening even if it is required). I am not completely sure what that means.
Unfortunately, the last time I tested on the slow system that was consistently failing, it worked. We did have to stop one of our security baselines. Although, yesterday, it was failing on the upgrade baseline.
BTW, the slow system took about 7 minutes to complete the last phase of the upgrade when the system has network connectivity, and the BES client is active.
The setting “_BESClient_ActionManager_PendingRestartExclusions”=“drivers;DRIVERS;” worked on the one test I did. We will continue using both settings as part of our Windows 10 in-place upgrade baseline unless we find a problem.
I have created a fixlet that will delete both of the settings after the upgrade is complete. I plan to set a policy the will remove the settings based on a system being successfully upgraded. I will check for the OS version being 1809, and the non existence of the folder c:\Windows$.~bt.
I am setting both client settings, and I am still getting a restart. However, the restart is not from the in-place upgrade action which is an improvement. The restart appears to be from the December Microsoft updates. I thought that all Bigfix actions would be prevented from causing a restart. We have stopped the December Updates baseline and will try again. Being able to set the timer to greater than 5 minutes would be the fix. You really don’t want any Bigfix actions running during the in-place upgrade anyway. OR, is there a way that the Bigfix client could detect that an in-place upgrade is running and suspend all activity until IPU is complete?
setting “_BESClient_ActionManager_PendingRestartExclusions”=“drivers;DRIVERS;” on “{now}” for client
setting “_BESClient_Resource_StartupSleepSeconds”=“300” on “{now}” for client
I’ve been following your process with these new settings, Mike. Thank you for posting your efforts to the community. As it stands now, I’m still feeling that it is hit-or-miss enough where I’m going to stick with my existing process for 1809 that we used for 1803. It seems to be solid enough.
For those still struggling with the feature upgrade process using our content, we did include a change to our reboot detection logic in 9.5.12 that should prevent a duplicate reboot from being triggered by BigFix. This has made the upgrade successful for some specific scenarios we were able to pinpoint. The fix is for APAR IJ13194 - THE ACTION TO UPGRADE WINDOWS 10 VERSION MAY FAIL AFTER THE REBOOT. BigFix 9.5 Patch 12 is now available
If you’re able to test out this version in your environment, please let us know if it fixes things for you.
Can we get away with just a client upgrade or does everything have to be brought up to 9.5.12 to get this benefit?
@jonbisch
From what I understand, I believe a client upgrade would suffice.
Exactly like you said.
I came across this thread which says this has been covered in the patch earlier to 18894.
In addition, you should also look for
_BESClient_Resource_StartupSleepSeconds value, and set it to 300
This issue (aka the “bug”) has not been apparent in Win10 1903. You should be able to deploy “normally” using the /NORESTART switch.
Does the switch need to be in a certain place in the command line?
Not to my knowledge. I guess what I meant was that the native supplied Fixlets that BigFix provides, which does contain the /norestart switch, should now work well with Win10 (1903). Note that as of this writing, the 1903 fixlet has not been released.