I am using a baseline to perform a Windows 10 in-place upgrade. The baseline includes some prerequisites and then the IPU. Then at the end of the baseline I have a post action to restart the PC. I am finding that it can take over 20 minutes for the restart to take effect in some cases. The user then becomes impatient and then manually restarts the PC. Then in the last phase of the IPU, the Bigfix restart finally takes effect causing the IPU to rollback and the upgrade to fail.
Why does it take so long for the restart to happen? I have seen this before with our monthly Microsoft updates. Does it have something to do with the restart being at the end of a baseline?
.
Hi,
In-place-upgrade fixlets DO include the restart command at the end to let system boot in PE embedded into image and then upgrade system. Without the post action to reboot system, does it reboot automatically? If user manually does update, it may alter flow and it is not recommended.
What is the BigFix client version on the target machine?
Regards
We are running Bigfix version 9.2.9. Without the post action, the system would not reboot unless the user manually rebooted it. It may be a workaround to just display a message to tell the user to reboot the system, and not have Bigfix do the reboot.
After the user takes action on the first restart before going into WinPE, I have seen it take 28 minutes for the Bigfix restart to take effect. This is not good. The user has said restart the PC by clicking take action on the restart and then they have to wait 28 minutes before the restart actually happens. This is not right. Of course, they are going to become impatient.
Independently from poor reboot performance, if you are doing IPU toward Windows 10 (which release is your target release?), most recent releases of it require BigFix client 9.5.
About poor reboot performance, is it something that user can reproduce without BigFix client? What is the hardware target machine?
We are upgrading from Windows 10 1511 to 1703. We are using our own task to accomplish the upgrade since we use Symantec Encryption Desktop. The built in fixlet for in-place upgrade will not work for us. I don’t think there is much difference though.
I think I can reproduce the reboot performance on one of our older laptops. They are HP ProBook 640 G1.
Good morning,
if Symantec Encryption Desktop encrypts your disk, I’m expecting that IPU will fail because Windows setup can not decrypt the disk. I suggest you to read some Symantec documentation about this scenario: https://support.symantec.com/en_US/article.HOWTO125876.html
Some troubleshooting about our IPU fixlets are available here: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Managing%20Windows%2010%20in-place%20upgrade%20failures
About slow reboot, if it is occurs only when triggered by BigFix client, I suggest you to open a case against BigFix platform, providing BigFix client logs and machine details.
We are using Symantec scripts that inject the Symantec Encryption Desktop (PGP) drivers. That is all working perfectly.
The problem we have is with the Bigfix restart. I have a PMR opened. I will let you know how it turns out.