why is that a problem Mike? As long as the non persistent message disappears and the persistent one is shown as you require does it matter?
The message says, âwhen this message disappears, restart your PC to complete the updateâ. If the non-persistent message appears and disappears, the user could take that as their queue to restart. The upgrade will continue after they restart, and then the persistent message will appear, but it could be confusing to the user.
In the end, after moving the task to set persistent messaging to the first position in the baseline, I have found that the non-persistent message only flashes by. So, I think it will work. Weâll see once we start rolling it out.
Iâm not following what the non-persistent message is vs the persistent message. When you configure a message for the baseline, that covers the entire baseline. But I would recommend configuring message persistence separately, not within the upgrade baseline.
Iâm still confused by what is being used to display the messages. Is it the baseline itself, or a component of the baseline? I donât think baseline components can display a message in a persistent way, only the baseline should be able to display messages using bigfix itself.
Can you provide screenshots of the settings of how you are deploying this in the console?
I donât see how to add a screen shot.
I have a baseline that does the follow:
- Set persistent messaging.
- Precaches 1803 source.
- Applies the upgrade.
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
delete clientRestart.bat
copy __appendfile clientRestart.bat
runhidden clientRestart.bat
I am calling it persistent message where the user cannot dismiss the message and non-persistent messaging where the user can dismiss a message.
_BESClient_ActionManager_PersistRunningMessage = 1 is persistent messaging.
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.
Development released a couple of new settings that will prevent Bigfix from causing a restart during an in-place upgrade.
- specifying exclusion list
_BESClient_ActionManager_PendingRestartExclusions = drivers;DRIVERS;
- specifying a delayed startup
_BESClient_Resource_StartupSleepSeconds = 300
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.
2 Likes
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.
Does the Besclient need to be restarted to make these settings effective?
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.
Yes, the semicolon at the end is required because it is used as separator and ending character.
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
delete clientRestart.bat
copy __appendfile clientRestart.bat
runhidden clientRestart.bat
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.