Bigfix Restart Causing Windows 10 1803 Upgrade to Fail

[mbartosh]

When I run the Windows 10 1803 in-place upgrade, it fails because Bigfix sends an unexpected restart. The restart appears to be from the upgrade action itself. I took the action and the machine restarted, but then it restarted again in the last phase of the upgrade which causes the upgrade to roll back.

In the Windows upgrade log, there is a roll back folder with event logs. The system event log shows that the Bigfix task for the upgrade causes the restart at the time the upgrade log stopped recording.

[AlexaVonTess]

We’ve talked about this quite a bit in this forum. Bottom line: You need to remove the /NORESTART from the command line and not use any BigFix Post-Action.

[mbartosh]

Thanks. I will look at the other posts. I am curious to find out how removing the /NORESTART could possibly work. It seems like the machine is going to restart on the user when they are in the middle of their work, unless the upgrade displays some messages. Since we are running in silent mode, I would not think that messages would be displayed.

[AlexaVonTess]

That’s where your verbiage comes into play in your Message.

Here is what ours says:

READ CAREFULLY: Your system is running an older version of Windows 10 and this update will bring it up to Version 1803. Upon Taking Action, the update will start, run about 25 minutes, and REBOOT WITHOUT ANY FURTHER NOTICE. You may want to only Take Action when you will not need your computer for about 60 minutes. For example, before going to lunch.

[mbartosh]

That is a very good clear message. The problem I have is that the restart time could very from 10 minutes to 3 hours on the machines in my environment. I’m not sure your message would work in that case. But, I may not have another choice.

I saw your post earlier regarding the restart bug. I think it is unacceptable for IBM to say it is a Microsoft problem and not do anything about it. IBM needs to work with Microsoft or create a work around for the problem. Bigfix strength is supposed to be deploying updates which is very difficult with this restart bug.

Regarding the misplaced restart, I have noticed that the upgrade works the second time after failing because of the Bigfix restart the first time. Was that your experience?

[mbartosh]

There needs to be something built into Bigfix to check for a running Windows upgrade, and not execute any actions during an upgrade. I also have a problem with other actions running that will cause the in-place upgrade to fail. For example, the September Microsoft updates. In the third phase of the upgrade, Windows is on the network, but the upgrade is not complete. Bigfix can an does send updates during that third phase. If there is a restart in one of those actions, the upgrade will fail.

[steve]

We are still working with MS to find a solution to this problem, and looking at different approaches to Feature Updates that might avoid the problem, but haven’t found a solution yet.

For the messaging approach, it might help if you add a running message so the user knows that it is still running. There was a setting added around 9.5.7 timeframe that allows you to make running messages persistent (not dismissible by the user).

[AlexaVonTess]

If you look on BigFix.me, you’ll see my Stage1/2/3 approach. This process will make your deployment times more

1. Stage 1 copies the ISO to the C:\Temp\Win10 directory.
2. Stage 2 Run the install if the ISO exists (presents the user with the message). This is a Policy.
3. Stage 3 will remove the ISO IF the upgrade works, otherwise it leaves it there for next time. This is a Policy.

I generally run Stage 1 in waves and stop/start Stage 2 once a month or so. Stage 3 generally never needs to be stopped and it a good indicator of your success rate.

[AlexaVonTess]

There was a setting added around 9.5.7 timeframe that allows you to make running messages persistent (not dismissible by the user)

I remember reading that in one of the change logs and was looking forward to it. When I finally upgraded to 9.5.8, I looked for it (perhaps not hard enough), could find no reference, and figured it never made it in the release. I guess I was thinking that it would have been a checkbox on the Messages tab, sub option to “Display message while running action”; perhaps “Disallow Dismiss option”.

[steve]

It was in 9.5.5, actually. Here are the two client settings:

_BESClient_ActionManager_PersistRunningMessage
Type: Boolean
Version: 9.5.5
Platform: All
Default: 0
Requires Client Restart: YES
Description: Blocks the user from dismissing the “while action is running” message dialog. The system menu on Windows and Mac is disabled, blocking minimize and maximize as well. Only the close functionality is blocked on Unix/Linux. The user can still minimize or maximize the message box on those platforms.

_BESClient_ActionManager_UIActionRunningTopmost
Type: Boolean
Version: 9.5.5
Platform: All
Default: 0
Requires Client Restart: NO
Description: set to 1 to cause “while action running” message dialog (when configured to display) to stay topmost. Note: On Unix and Linux platforms, this functionality requires a window manager that supports the “Extended Window Manager Hints” specification.

[mbartosh]

Do you think it would work to have a policy running whose only purpose is to display a message letting the user know they need to restart the PC, then after 24 hours persist the message in the foreground? The relevance would be:

pending restart “Win10InPlaceUpgrade”

At the end of the action, I set the following:

action requires restart “Win10InPlaceUpgrade”

[mbartosh]

The only problem with the messaging approach is that it depends on the user being there. We would like to complete most of our updates overnight without disrupting the user. We would instruct the user to log off their PC before they left at night, and the upgrade would run from beginning to end. For any users who had forgotten to log off, we would send a logoff task, and then the machine would restart and complete the update.

[AlexaVonTess]

I see. It’s a client setting, so an “all” or “none”. I was thinking per Action. Thanks for the info!

[mbartosh]

I plan to have two different baselines.

1. Baseline that will run the upgrade with NORESTART, but a persistent message will be displayed while the upgrade is running that informs the user they need to manually restart when the persistent message goes away. In addition, there will also be a task at the end of the baseline that will display a persistent message informing the user they will need to manually restart in order to complete the upgrade. The relevance for this task will be “pending restart Win10InPlaceUpgrade” which is set at the end of the upgrade. The action has one line which is pause while “pending restart Win10InPlaceUpgrade”.

2. Baseline that will not have NORESTART on the command-line. When we run this baseline, it will have a time window to limit when it runs. The intent is to have a job that will complete the upgrade from beginning to end overnight without disrupting the end user.

[mbartosh]

Apparently, the _BESClient_ActionManager_PersistRunningMessage does not work for a baseline.

[jgstew]

does not work for a baseline

The baseline itself would need to be the thing to display the message, not the components.

there will also be a task at the end of the baseline that will display a persistent message informing the user they will need to manually restart in order to complete the upgrade

The only way to do that with bigfix is to use the restart post action dialog, which would cause the problem. You can’t use BigFix to display a persistent message to the user unless it is a task that never ends, and if you did it that way, then bigfix would not be able to do anything on that computer at all until the message is handled, which is less than ideal.

[jgstew]

You need to remove the /NORESTART from the command line and not use any BigFix Post-Action.

I wonder if there is something that could be triggered in actionscript that would be the equivalent of hitting “restart now” on the windows update dialog / windows upgrade install.

I’m guessing this issue is that bigfix triggering a restart when the feature update restart is pending overrides that pending restart and causes issues.

[steve]

Works fine for me with a baseline. Make sure you restart the agent after changing the setting.

[mbartosh]

Thanks Steve. Good to know.

[mbartosh]

Steve,

There is an issue when I put the persist message setting in the upgrade baseline. The problem is that the non-persistent message will appear initially, then it disappears, and then the persistent message will appear. Is there a way to get around this within the same baseline, or am I going to have to have an upgrade preparation baseline and then run the upgrade task independently?

Here are the baseline components in order.

1. Set client setting _BESClient_ActionManager_PersistRunningMessage and restart besclient.
2. Cache the upgrade source locally.
3. Run the upgrade.