I will have to give that a try and see if there is any difference. I am using a custom repository for the ISO so I think that I should be able to pull that down, copy to the tmp and then run the rest of the sequence but it may just be making more work vs the existing fixlet.
Have you come across any issue swith drivers not working properly after the update? I have seen a few machines have issues with the wireless adapter after the update
Since this is mainly in place upgrade versions, I don’t know what I can setup pre/post to avoid such issues.
I’m using a customized copy of the BigFix fixlet ID “1100992 - Windows 10 Multi-edition VL Version 1709 Available - Windows 10 (x64) (Portuguese (Brazil))”, which may differ the ID number according to your version, and changed the lines in bold as follow:
parameter “workISO” = "{pathname of client folder of current site & “__Download\Win10_1709_BrazilianPortuguese_x64.iso”}"
continue if {exists file (parameter “workISO”)}
The one issue is that after the upgrade is completed and the machine restarts, the computer name is changed and as a result, there has to be manual input to log into the machine with the local admin account and rename the computer back to its previous name so it can log into the domain. This is not practical if you’re planning to upgrade hundreds of machines.
Have you encountered that issue and how have you addressed it?
I’m not testing anymore. This should be straightforward so something is broken, which is why I have a PMR open. This process was pretty much flawless with the 1703 upgrade so something is different somewhere with the 1709.
The one way we have been testing this update ‘successfully’ up to now is to pre-cache the ISO on c:\temp (because when using the custom repository setting, it was taking too long to download to the local computer) and then using the bigfix upgrade fixlet, modify the parameter “workISO” to the iso location on c:\temp.
It’s been applying the update fine for now. Still testing
Yep. We’re pre-caching as well. It’s been a few weeks since I have heard back from IBM with regards to PMR TS000059000. They’ve supposedly duplicated the issue and I’m confident they’re working with Microsoft to find a resolution.
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.
