Testing BigFix on Windows 10, version 1709, Fall Creators Update

My whole process is explained here.

But to answer your question, I used SWD. I did not try without AV installed because that is not realistic and won’t do my any good (I can’t very well uninstall/reinstall AV on 100’s of endpoints). Plus this works manually. Plus this worked with 1703. So something is going on. I’ll try more testing with the 9.5.7.94 agent (I only tried one).

The AV question is just because it was the main villain here in the update process. I manage 5000 endpoints and there’s really no point in uninstall AV, upgrade and reinstall AV. However, trying in just 2 endpoints with same specs and softwares but no AV everything went fine. Then I looked for information and saw that I would need to update my AV (in my case Trend OfficeScan) from version 11 to 12. I didn’t change anything in my fixlet, just updated the AV version and things ran smoothly regardless user preset I select.

That’s good information just the same and I understand the logic. Do you recall if you tried manual installs with AV 11 and what those results were? If it was AV, I would suspect it would fail even when doing it manually. If however, they were successful, as mine have been, then certainly AV is worth a closer look.

Manual seemed to work fine in the beginning, but shortly after the 1709 version installed it started to give blue screen after a few restarts.

I’ve posted here what is been working for me so far if you wanna take a look.

So I think it is safe to say that it isn’t AV in my case. And these facts are pretty substantial I think:

  1. Manually always works
  2. BigFix fails on 3rd reboot at 85%

What I have experienced so far from BigFix+Win10 is that, for some reason, BigFix isn’t able to implement a command in Windows 10 as you would do locally. I had exactly the same problem when tried to install some browsers certificates via BigFix in Windows 10. The same command line worked as a charm in Win7 computers but not in the Win10 ones. However, performing the exactly same command line locally it worked perfectly in both OS.

The 9.5.7.94 client creates an IBM BigFix Support Center icon on the the start menu which, if deleted, gets recreated when the BigFix client service is restarted. How can this be permanently deleted ?

Can any one suggest for Win10 fall creator update for 1709 build from BigFix console.

Is it from OSD in system lifecycle. ( in-place upgrade).

Thanks in Advance

@SysAdmin3,
I didn’t understand your request but if that’s what you’re asking I’m using the Windows 10 Multi-edition VL Version 1709 - Windows 10 (x64) (Portuguese Brazil) available fixlet, just replacing the prefetch block code area with the informations of the ISO that I uploaded to the BigFix server, as in a software distribution.

No, FCU means win10 fall creator update.
suppose we have win 10 1703 and want to upgrade to win10 1709 … that is Fall creator update.

That’s not happening. Need help. Many blogs says it’s getting fail and still solution did not come around.

If you have an existing system to upgrade, you can do that via fixlet from the “Patches for Windows” site.
Yes, results are mixed. Many people have had problems, but so far these seem to be Microsoft issues and not BigFix content issues (that I’ve been able to identify, anyway). Some of us, myself included, seem to have better results if we run tge upgrade only when there are no users logged on and reboot immediately after running the upgrade fixlet.
I haven’t checked into the methods on the OSD site, but if there are methods in OSD they would involve an OS Migration, where the machine is reimaged using a previously-captured, sysprepped image uploaded into the OSD Image Library. I upgraded from Win7 to Win10 using that method, but haven’t tried it for upgrading one build of Win10 to another.

The main problems we face was about antivirus programs.
It seems that some antivirus programs prevent Windows from being updated correctly by preventing some changes in the process.
In my case, for testing purposes, after uninstalling the antivirus program, the Windows update from 1703 to 1709 fixlet from “Patches for Windows” worked fine. After this, instead of uninstalling the AV in all computers just look for an update to the AV program that fixed this incompatibility.

Good point, prior to my deployment I had to upgrade Symantec from 12 to 14.

Exactly, same with the Trend Micro.

Where that patch found in OSD module or in system life cycle
Let me know so that I can check.

It would be within the “Patches for Windows” site.

Fixlet IDs listed here

1 Like

ok. thank you, I know these patches and I thought you were talking about from in place upgrade in OSD of life cycle module.
Well. don’t know this will resolve the issue which is happening every where for 1703 to 1709 upgrade task sequence. if it will success while disabling AV then I will update here.

Thanks again guys.

I suggest uninstalling the AV program of a selected computer before take the upgrade action test instead of just disabling it.

1 Like

I second the suggestion to uninstall (or upgrade to latest version) the antivirus product. It wasn’t just a matter of AV interfering, the Windows Setup program itself runs a compatibility check and will block itself when it encounters a known-incompatible antivirus.

When we ran the upgrade interactively, it popped up a window that Symantec 12 was incompatible and would not allow setup to run.

1 Like