I am performing an in-place upgrade from 1511 to 1703, and I have found in some cases, another instance of the client is created in the console. It doesn’t happen in all cases. So far I have only found this issue on laptops, and not desktops. Has anyone experienced this?
Where is the content coming from?
The source for the in-place upgrade is cached locally in c:\programdata\windows10-IPU. I was running a test at my desk, and it took 28 minutes for the restart to occur after I click “Take Action” on the restart.
Were you clicking “Take Action” on a task to run the upgrade & restart, or had the upgrade already occurred and you were only doing “Take Action” on a restart?
Also, were you by chance using a tool to “tail” the BES Client Log? I’ve seen cases where the client gets very slow if you happen to be tail’ing the log when the log has grown large enough that the client is trying to rotate it.
The “Take Action” for a restart is issued at the end of the baseline (post-action) . At that point the upgrade is complete.
I usually use trace32 to read log files, but I wasn’t monitoring the log file in this case, or any other cases where the user became impatient and restarted manually.
Can you post the client log? I’m curious whether the preceding baseline component actually completed. I’ve seen some cases where the upgrade completed, but the powershell command to unmount the WIM was hanging.
This is what we see in the upgrade log file located in c:$WINDOWS.~BT\Sources\Rollback\evtlogs\system.evtx.
The process C:\Program Files (x86)\BigFix Enterprise\BES Client\BESClient.exe (XXXXXXXX) has initiated the restart of computer XXXXXXXX on behalf of user NT AUTHORITY\SYSTEM for the following reason: Other (Planned)
Reason Code: 0x80000000
Shutdown Type: restart
Comment: IBM BigFix Restart from ActionID 391940
There is a post for this problem where the restart was taking too long with a possible workaround, but to me it is a bug. If the user selects Take Action on a restart it should happen right away not 30 minutes latter.
Ihttps://forum.bigfix.com/t/restart-now-is-more-like-probably-restart-in-10-20-minutes/9185
I am not seeing how to attach a log file.
So how does the time of this event correspond? Is this event coming 30 minutes after you expect, or is the shutdown occurring 30 minutes after this event?
This event is triggered by Windows itself, after the BES Client triggers a shutdown. If the delay comes after this event, then there is a Windows process preventing the restart from occurring.
You need to determine where the delay is occurring. The BES Client logs could show delays in action processing / calling the shutdown command. Windows Event Logs may show delays between calling the shutdown API and the system actually restarting.
This is great information Jason. Bigfix must not be calling a shutdown with force close. When I issue a shutdown with a force close from a command-line, the shutdown happens right away. Maybe this is what Bigfix needs do when issuing a shutdown if it is not already.
I will run another test, and look at the log.
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 action the upgrade will fail.