We are performing the in-place upgrade to 1703. This is the first IPU we have done. I was just wondering if you found it necessary to put a lock on the computer at the end of the upgrade action so that no other Bigfix actions could come in during the second boot phase of the in-place upgrade? We have found that some of our updates are failing because of other actions causing a restart. Or, maybe you just stopped all actions that could have caused a restart. Please let me know your experience in this area.
We found that the IBM supplied fixlet didnāt work well; irregularities in mounting the ISO.
We built our own using SWD, nothing special, where we just compressed the contents of the ISO instead of mounting it, and then copied it to c:\temp\win10 for execution.
We then had a preset that ran the setup with no notification until after it was completed. Then we prompted the user about the pending upgrade which would take place upon reboot. This way the user wasnāt waiting for the copy of the large file and the initial install to take place. This process had a very high success rate. Upon a successful upgrade, we then had a post action that removed the temp folder.
We are doing exactly the same thing as you are. We also used SWD to create the script but I added the code below at the end of the script because we found in some cases a Bigfix action was running at the end of the upgrade (the part from 70% to 100%) and forcing a restart before the upgrade was completed. The upgrade would then roll back. The odd thing is that the lock did not seem to work. The Bigfix action still caused a premature restart. We have identified the problematic action and stopped it, but it seems like the lock should make the upgrade fool proof.
action requires restart āWin10InPlaceUpgradeā
action lock indefinite ā{parameter āaction issue dateā of action}ā
That seems like the issue Iām having with 1709, which Iām actively working with IBM on. What confuses me is that once the endpoint performs its initial reboot, BigFix is out of the picture until it either completes or rolls back. Thatās the 70% to 100% your speaking about?
Iāve even monitored the c$$WINDOWS.~BT\Sources\Panther\setupact.log directory in Baretail to ensure that first part of the install completes before BigFix triggers a reboot.
There are some actions that can ignore the Action Lock state on the client. It depends on which site contains the source fixlet for the action.
By default any fixlets from the āBES Supportā site (which includes the default āRebootā tasks) can ignore the Action Lock state. This is needed as this site also contains the āUnlock Clientā tasks.
You may also specify one Custom Site for which fixlets/tasks will ignore the action lock state. That is managed using the BESAdmin tool and the selected site will be called out in your masthead file.
If your action is based on a task from the BES Support site, or a designated Custom Site, that would explain why the action is running even with the client locked.
I havenāt had a problem with this yet but have only done a few in-place upgrades (1607 to 1709). Iād suggest that if youāre working through a PMR or building your own custom installers, you might try actually disabling and stopping the BESClient service after initiating the upgrade; and use the Windows Setup scripts āsetupcomplete.cmdā and āsetuperror.cmdā to enable and restart the BESClient when the upgrade succeeds or fails.
Great information Jason. The action that was causing the restart, was actually a Microsoft Security updates baseline. These are from the site patches for Windows. After testing, it looks like these patches cannot run during the lock, but somehow they did.
I do notice when this premature restart happens, there is another instance of the client created in Bigfix. I donāt know if the premature restart is causing the new client, or the new client is not locked which allows the unwanted action to run.
FYI: I have had a PMR on this open for a few months and it has recently been escalated (this is regarding 1709 only; my 1703 was near perfect). The fixlets are a two stage approach; one to copy the ISO to c:\temp\win10, the second to run the install (and potentially a 3rd to remove the ISO after a success). Iāll certainly post any info I learn.
We have a preset restart for the in-place upgrade task, and it seems if the user does not wait for Bigfix to restart the PC, and they get impatient and restart it themselves, the Bigfix restart will take effect in the final phase of the in-place upgrade. It is understandable that users would become impatient since it can take minutes for the Bigfix restart to take effect. I wish there was a way to make the Bigfix restart happen faster.
Did you ever receive any feedback from BF in regards to your PMR? We are still performing some upgrades to 1709 via the windows update assistant as most of the attempts that I made kept returning different results and issues. I understand that the approach is to copy the iso to the local temp and then run the setup from that directory for each device but perhaps y environment is at the root cause of the issues that I experienced.
Our gpo does not currently allow wuauser service to run, and windows update is disabled. So I have had to add a few lines to every update that requires that service to be running to have a successful outcome.
What versions of Win10 are you upgrading from? Weāve done about 30 clients so far, upgrading from Win10 Enterprise 1607, and havenāt had a problem with the default fixlets.
Has this issue been resolved? I am looking for the best way to deploy in place upgrades of 1709 to my machines and wanted to pick your brain on how to do so
This is the latestā¦ If you are having this same issue, please try and go through the process below.
BigFix customers that are having issues should raise a case with Microsoft Premier support. When they do so, they should make sure to tell the support engineer that BigFix has directed them to raise the issue with Microsoft. Opening a support case with Microsoft will help us make progress much faster.
Once a case has been opened with Microsoft, send the contents of the Panther directory.
When you are running setup /noreboot all the logs related to the current upgrade session are at c:$Windows.~bt\sources\panther folder.
BigFix/IBM will be working with Microsoft in in the background and hopefully this will help us all to get to a good resolution.
We are in the middle of a utilizing BigFix for the Win 10 upgrade and it seems that may have ran into the same issue. Weāve been having some other issues as well.
Though the bug still exists, the work around we have is pretty solid. There are posts on 1803 from myself as well as a Three Stage Fixlet approach which you can find on bigfix.me.