I have started to use BigFix to perform the in place upgrade to 1709 and came across some similar results and I wasn’t able to pinpoint the cause of the issue. Now that I read your experience, I am going to try and set this to run when no user is logged on and see if this has any impact and success. I was able to successfully update some machines regardless of user but I cannot confirm if there was no user logged on. I deployed this task to 8 machines and only 3 updated successfully while the others failed.
I presented a restart required action at the end because I knew some users were logged on, I will try to deploy this when no user is logged on and perform the reboot automatic after completion to see if I have more completions.
I am surprised that the bigfix task doesn’t details any other specifics besides setting up a repository to pull this locally if the issue in fact is the user presence.
On the machines that failed, have you tried the GUI update outside of Bigfix? It seems that it runs a number of compatibility checks. We had some repeated failures and when run interactively, we find it complains about our version of antivirus product and requires and upgrade before the 1709 will install.
I will try and run the GUI update and see if there are any items that are flagged. The task that I created runs successfully and when the computer is applying changes, that is when I come across the issue. We generally has all of the same models in our environment and some machines have been imaged with 1709 manually when it was first released and had no issues with doing an in place upgrade. We do have a lot of different Win 10 versions that we want to consolidate to 1709 and was under the impressions that we could go from 1511, 1607, 1703 straight to 1709 but we are getting failures at times.
I will continue to dig into it and see if I can find anything in the logs. Although 1709 failed on some machines, I was able to get them from 1607 to 1703. I will try to perform the update version by version and see if there are any differences.
Thanks for the information (I was gone for a while so forgive my delayed response).
First note from my first post that I’m not using the ISO fixlet provided by BF as we had issues in the past. We’re just doing a simple SWD to an external directory; pretty straightforward. We deployed 1703 using this same method and had 99% success rates.
Last I was able to look at this, it was succesfully when we didn’t use our Preset. I later found that if I manually entered the restart message, it worked (as if the Preset was corrupt some how). I’ve updated my testing results earlier in this post. You should try deploying it as item #6.
The big mystery is why would a preset, post-message, or anything else have any affect on this?
BTW: Those “remove AV” from Microsoft are their standard troubleshooting response and do not reflect reality.
Thanks for the feedback, I am still getting different results with my testing. We don’t currently subscribe to the OS distribution site , is that how you are building your upgrade SWD?
I used its relevance, but that is it. I just uploaded the root of the ISO contents and have it move it to c:\tmp. Then run the setup command with those switches. Straight forward.
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.
