Windows 10 1709 Update

Content Authoring
1

I had created my own Windows 10 1703 update last time as the IBM ISO mounted version was having issues at the time.

Real simple, it copies the contents of the ISO to C:\Win10-1703\tmp and runs:

C:\Win10-1703\tmp\setup.exe" /auto upgrade /Quiet /DynamicUpdate disable /noreboot

We had a very high success rate upgrading systems to 1703.

Then 1709 came out and my (foolish) expectation was that I would just replace the ISO and be on my way; having spent all the testing time with 1703. Wrong!

The install fails on the 3rd reboot (at 85%) all the time with the same fail messages (shown at the end). Running the EXACT same command logged on locally works.

Keeping in mind that the contents are outside of the BigFix directory structure and that setup command actually processes fully (I’ve baretailed the setupact.log during the install phase), I cannot understand why this wouldn’t work. Has Microsoft made another change to what should be a simple process; perhaps requiring that the install runs as a local user and not System?

I’m in total awe right now and would love to hear if anyone else if having this same issue. I’m using the same ISO that matches the SHA1 in the IBM supplied update (ID 1100964).

2017-11-10 09:56:34, Info                  SP     SetupPlatform: Global progress: 85, Phase progress: 40
2017-11-10 09:56:34, Info                  SP     SETUPPLATFORMEXE: Sending progress message: Phase: OOBE Boot, Operation: Migrate data, Percentage: 40%
2017-11-10 09:56:34, Info                  SP     SETUPPLATFORMCOMM: Progress message received: Phase: OOBE Boot, Operation: Migrate data, Percentage: 40%
2017-11-10 09:56:34, Error                 SP     Operation failed: OOBE boot apply. Error: 0x8007042B[gle=0x000000b7]
2017-11-10 09:56:34, Error                 SP     Operation execution failed: 13. hr = 0x8007042B
2017-11-10 09:56:34, Error                 SP     ExecuteOperations: Failed execution phase Pre OOBE Boot. Error: 0x8007042B
2017-11-10 09:56:34, Error                 SP     Operation execution failed.
2017-11-10 09:56:34, Error                 SP     CSetupPlatformPrivate::Execute: Failed to deserialize/execute pre-OOBEBoot operations. Error: 0x8007042B
2017-11-10 09:56:34, Info                         Persisting diagnostics data to C:\$WINDOWS.~BT\Sources\Diagnostics\diagnostics.dat
2017-11-10 09:56:34, Info                         Diagnostics data saved successfully
2017-11-10 09:56:34, Info                  SP     SETUPPLATFORMCOMM: Progress message received: Phase: OOBE Boot, Operation: Migrate data, Percentage: 40%
2017-11-10 09:56:34, Info                  SP     WINDEPLOY error code is 0x80004005. Will not attempt uninstall
2

I was able to get a success and wanted to share (I still need to run this several more times to ensure the results are stable). waitdetached seems to be the magic combo in the 1709 install.

waitdetached "C:\Win10-1709\tmp\setup.exe" /auto upgrade /Quiet /DynamicUpdate disable /noreboot

Hmmm. I failed to mention that I ran the above test using “Run only when no user is logged on”. I ran it again using the same command except with the “Run independently…” option. I was logged in and had a preset. It failed at 85% again.

I’ll try running running with no user logged in again.

1 Like
3

I must be the only one using BigFix to deploy in-place upgrades of 1709. :yum:

Running the action with “Run only when no user is logged on” worked a second time. What does that mean? That the Microsoft installer for 1709 will run but fail if someone is logged in?

4

Testing scenearios so far… Anything with a preset seems to fail. I have NO idea why.

  1. Run (A) with (Run only when there is no user logged on)(no preset) - Success
  2. Run (A) with (Run independently…users)(preset) - Failed
  3. Run standard job (ID 97154) with (Run only when there is no user logged on)(no preset) - Success
  4. Run standard job (ID 97154) with (Run only when there is no user logged on)(preset) - Failed
  5. Run (B) with default (Run independently…users)(no preset)(user logged on) - Success
  6. Run (B) with default (Run independently…users)(no preset; but set only Post-Action > Restart)(user logged on) - Success

A: waitdetached "C:\Win10-1709\tmp\setup.exe" /auto upgrade /Quiet /DynamicUpdate disable /noreboot
B: wait "C:\Win10-1709\tmp\setup.exe" /auto upgrade /Quiet /DynamicUpdate disable /noreboot

5

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.

6

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.

1 Like
7

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.

8

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.

9

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?

10

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.

11

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.

12

Hi AlexaVonTess, what is “preset”?
And have you verified if there is anything related to 9.5.7.94 client?

13

I’ve tried with 9.5.5 and 9.5.7.94. This is maddening.

14

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:

begin prefetch block
add prefetch item name =Win10_1709_BrazilianPortuguese_x64.iso sha1=8c763bf03d3293e03bfbab9a27ecfc508864df77 size=4462786560 url=SWDProtocol://127.0.0.1:52311/Uploads/8c763bf03d3293e03bfbab9a27ecfc508864df77/Win10_1709_BrazilianPortuguese_x64.iso sha256=b7582344c6f014a59b9532666e937cc8071ab821704cf8f345a64b660641fc37
end prefetch block

parameter “workISO” = "{pathname of client folder of current site & “__Download\Win10_1709_BrazilianPortuguese_x64.iso”}"
continue if {exists file (parameter “workISO”)}

15

PSExec, using the command below, manually, fails:

PSExec64.exe -accepteula -s “c:\temp\Win10\setup.exe” /auto upgrade /Quiet /DynamicUpdate disable /noreboot

PSExec64.exe -accepteula -h “c:\temp\Win10\setup.exe” /auto upgrade /Quiet /DynamicUpdate disable /noreboot

Running, manually without, succeeds:

c:\temp\Win10\setup.exe" /auto upgrade /Quiet /DynamicUpdate disable /noreboot

I would have to conclude that the setup.exe cannot run as System User (even though 1703 was able to).

16

I opened a PMR: TS000059000

NEW TESTING with new Task (Stage 1 / 2) all *:
1-1.Task (ID 99767)(Run independently…users)(preset)(user logged on) - Failed
1-2.Task (ID 99767)(Run independently…users)(preset)(G)(no user logged on) - Failed
2-1.Task (ID 99767)(K)(Run independently…users)(preset)(user logged on) - Failed
2-2.Task (ID 99767)(Run independently…users)(preset)(1703 setup.exe used) - Failed
3. Task (ID 99767)(K)(Run only when there is no user logged on)(no preset) - Success
4. Task (ID 99767)(Run only when there is no user logged on)(no preset) - Success
4-2.Task (ID 99767)(Run only when there is no user logged on)(no preset)(User Logged in, Waiting, User Logged Off, Running) - Success
4-3.Task (ID 99767)(Run only when there is no user logged on)(no preset)(Running, User Logs in) - Failed
5. Task (ID 99767)(Run independently…users)(no preset)(no user logged on) - Failed
6. Task (ID 99767)(Run only when there is no user logged on)(preset) - Failed
7. Manual ©(D)(E) - Failed
8. Debugger, Manual (F) - Success

KEY
A: waitdetached “C:\Win10-1709\tmp\setup.exe” /auto upgrade /Quiet /DynamicUpdate disable /noreboot
B: wait “C:\Win10-1709\tmp\setup.exe” /auto upgrade /Quiet /DynamicUpdate disable /noreboot
C: PSExec64.exe -accepteula -s “c:\temp\Win10\setup.exe” /auto upgrade /Quiet /DynamicUpdate disable /noreboot
D: PSExec64.exe -accepteula -h “c:\temp\Win10\setup.exe” /auto upgrade /Quiet /DynamicUpdate disable /noreboot
E: PSExec64.exe -accepteula “c:\temp\Win10\setup.exe” /auto upgrade /Quiet /DynamicUpdate disable /noreboot
F: From Debugger (Action): waithidden “C:\temp\win10\setup.exe” /auto upgrade /Quiet /DynamicUpdate disable /noreboot
G: waithidden “c:\temp\Win10\setup.exe” /auto upgrade /Quiet /DynamicUpdate enable /noreboot
*: BigFix Agent 9.5.7.94
K: KES Removed

17

Good morning Alexa,
I have successfully tested the in-place upgrade using the custome repository setting feature as pointed in this article: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Using%20the%20Custom%20Repository%20Setting%20feature

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?

18

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.

1 Like
19

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

20

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.

1 Like