Windows 10 1803 Update

They will be available soon.

1 Like

Hi there was a BES announcement last night (my time) on the fixlet release;

[Major] Windows 10 Business Editions Version 1803 Available - Windows 10 (English (United States)) (ID: 1111102)
[Major] Windows 10 Business Editions Version 1803 Available - Windows 10 (Japanese) (ID: 1111104)
[Major] Windows 10 Business Editions Version 1803 Available - Windows 10 (x64) (English (United States)) (ID: 1110004)
[Major] Windows 10 Business Editions Version 1803 Available - Windows 10 (x64) (Japanese) (ID: 1110006)

I still do not have this working in our environment. We have 24 sites and relays defined in each site. I’d like the 1803 update to function like other updates where it is copied once to that site and then all other machines update locally. Is anyone doing this successfully?

Using the Stage 1/2/3 process that we’ve already talked about I have upgraded close to 1,000 endpoints globally. Why don’t we start with which Stage isn’t working?

1 Like

got stage one to work copying file on local LAN but that seems like 1 to 1 instead of actually using the relays. When i tried to run stage 2 i get error that action success criteria relevance contains a syntax error. Expression could not be parsed.

Stage1 copies the ISO and will use your BigFix infrastructure to place the ISO on each endpoint.

Stage2 - I’m unsure where the error is being seen. After downloading it and when trying to import it? If you’re copying/pasting the code, you need to make sure its plain text; straight quotes being replaced with smart quotes is a good example where relevance will error.

Anyway, I probably can’t help you with the little info being provided. The Stages seem to work for others. Sorry.

As far as you know, does the /norestart bug still exist? When i deploy via BigFix it fails, but when i do it manually and restart from start->reboot it seems to work ok.

Also, is there a reason you changed it so setupcomplete.cmd does not un-mount the iso? Is there even a reason to run setupcomplete.cmd any more, it doesn’t look like it does anything?

Yes, the “bug” is still there. You CANNOT use the /norestart switch and you CANNOT restart using post Action. So you’ll need to ensure your verbiage in your initial message makes all that clear to the user.

There is no need to unmount after installation.

For my 1803 Install powershell script via Bigfix, I am allowing setup.exe to reboot the system as needed and not trying to control the reboot via Bigfix.
So far so good.
We have 3rd party encryption so have to modify fixlet for reflect drivers and we are also using the BigFix custom repository to pull the ISO from (not worried about it going away from cache :))
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint%20Manager/page/Using%20the%20Custom%20Repository%20Setting%20feature

For Posterity and people finding this in the future: I received the same error about being unable to parse the Success Criteria. When I go into the tab, the radio button is set to “the following relevance clause evaluates to false” but there is nothing in the relevance box.

I switched the radio button to “All lines of the action script have been completes Successfully”

For myself: the Script then failed on the wait setupcomplete.cmd >"{parameter “workPath”}\setupcomplete.log" line. I’m trying it again without that line and will report my results.

You may be better off getting the code from BigFix.me. Just search for Stage1.

hello Alex
i am getting challenge in upgrade the windows 10 build version In Stage 2

move __appendfile mount.and.install.bat

on this stage action was stuck with Running status

Yes, the “bug” is still there. You CANNOT use the /norestart switch and you CANNOT restart using post Action. So you’ll need to ensure your verbiage in your initial message makes all that clear to the user.

Is this still an issue with 1809 or 1903? Is there a link somewhere to MS’s forums discussing this issue? I’ve only ever been able to find your comments on this forum referencing this bug.

BigFix attempted to come up with a work around which starts here.

After reading about it, I chose not to test or implement it as my process was solid enough.

I’ve deployed 1809 using my same process and I’m willing to bet the issue is there. However, 1903, which I have not yet deployed with BigFix may not have the issue. I’m only guessing at this, but based on my manual install tests of 1903, the process has changed (hopefully for the better).

The change that I have seen is that much of the upgrade seems to take place during the execution of the setup.exe from the media (close to an hour). Then the first reboot goes to about 68%, followed by a second reboot which completes the installation. So that is about 2 reboots less than previous versions.

Based on that, I’m taking a leap of faith that the 1903 native fixlet when it is release will work well. :face_with_monocle:

2 Likes

It’s only a single device, but I just pushed 1903 to a laptop via BigFix with the /noreboot flag and I manually rebooted it after a period of time, everything worked fine.

Next, you’ll want to kick off a reboot via the BigFix Post-Action options and see if that works.

Worked great. I pushed it with a 30 minute reboot timer and left for the day. Came in today and it’s 1903 and all is well.

2 Likes

If your device is compatible, the new version will be downloaded automatically through Windows Update. You can also install the update using the Media Creation Tool to perform a clean or on-site upgrade, the Upgrade Wizard, or download the ISO file to create a USB boot device. .

Just to follow up, I did a few of my coworkers computers on Friday, also with a reboot timer and they both worked great.

1 Like