There is a message defined for the baseline telling them to restart when they no longer see the persistent message. This is working. The key is: after setting persistent messaging restart besclient.
//Set client to persist messages displayed
setting “_BESClient_ActionManager_PersistRunningMessage”=“1” on “{now}” for client
//Restart Besclient
delete __appendfile
appendfile @echo off
appendfile net stop BESClient
appendfile net start BESClient
For some reason the persistent message in the baseline goes away as it is supposed to. Then I have a policy running that is relevant for any machine that has pending restart “Win10InplaceUpgrade1803” which I set at the end of the upgrade. The problem is that this message appears and then the original message appears at the same time leaving two messages.
I found that when I get double messages there are two instances of the same machine in Bigfix. The Windows 10 1803 upgrade was successful. I have not seen this behavior on all machines, but at least 25% so far. But, why would this cause two messages. The first message was for the 1803 upgrade which completed. It should have gone away.
The first setting forces BESClient to ignore the registry entries added by Microsoft during the upgrade and that trigger the second reboot of BESClient. The second one forces BESClient to start after Microsoft update procedure completes its update.
The first setting is straight forward, but I do not understand the second setting regarding StartupSleepSeconds. What is the timing involved? The in-place upgrade takes a lot longer than 5 minutes.
It’s good that a solution is in the works or perhaps even here. So long as the work around, and this is what it is, doesn’t cause issues elsewhere. I’ll probably stick to my method for now, but this is somewhat encouraging.
The setting _BESClient_Resource_StartupSleepSeconds allows to make the BESClient to sleep for some seconds (until 300, that is 5 minutes), after starting the BESClient service.
This way, the service will start but won’t perform any processing for the number of seconds set with _BESClient_Resource_StartupSleepSeconds.
During the Win10 upgrade, the delayed start will allow the OS to complete the post-reboot steps in the first minutes after rebooting and will prevent a second reboot forced by BESClient (and triggered by the registry settings configured by the OS at the first restart).
Based on that, the suggestion is to configure the setting (_BESClient_Resource_StartupSleepSeconds = 300) before applying the Win10 upgrade fixlet and run the fixlet as is, without changing anything in its actionscript.
Do you think that 300 seconds is long enough? I am assuming that 300 seconds would be the time needed to get through the last phase of the upgrade. In other words the amount of time it takes to complete the last phase of the update plus a little extra time. For newer faster machines with SSDs, they would complete the last phase of the update in just under 300 seconds, but I doubt some of the older machines with spindle drives would. So, should the time be increased to account for the lowest common denominator?
That worked in all cases we tested, however we are still verifying with Microsoft support.
Take into account that 300 seconds is the maximum allowed value for the setting.
Is the syntax correct for the setting to ignore registry entries added by Microsoft during the upgrade that trigger the second reboot of BESClient? Is the semicolon and the end of “drivers;DRIVERS;” correct?
setting “_BESClient_ActionManager_PendingRestartExclusions”=“drivers;DRIVERS;” on “{now}” for client
_BESClient_Resource_StartupSleepSeconds only affects the BESClient behavior at the agent start, so it will be applied by BESClient from the first service restart after you set it.
How about the “_BESClient_ActionManager_PendingRestartExclusions”=“drivers;DRIVERS;” does it require a restart of the BESClient?
This is how I have the fixlet now, but I am going to remove the restart portion.
//Set client to prevent a premature restart before the Windows Upgrade is complete.
setting “_BESClient_ActionManager_PendingRestartExclusions”=“drivers;DRIVERS;” on “{now}” for client
setting “_BESClient_Resource_StartupSleepSeconds”=“300” on “{now}” for client
delete __appendfile
appendfile @echo off
appendfile net stop BESClient
appendfile net start BESClient
I’d suggest to use just one of the two settings: either _BESClient_ActionManager_PendingRestartExclusions or _BESClient_Resource_StartupSleepSeconds, not the two at the same time.
About _BESClient_ActionManager_PendingRestartExclusions, it will act as soon as it is set and it doesn’t require a restart of BESClient.
One may suggest that these settings be included within the actions script (optional perhaps but certainly there with nomenclature) of the IBM provided Fixlet.
If you guys can help us validate that these settings address the issue, we can make the change to the content, but we’d like some more confirmation first.
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.
