Command-line options when using Windows 10 Update Assistant

Question

_{Tuesday, January 23, 2018 5:53 AM | 1 vote}

We've been using command-line switches, -ReflectDrivers specifically, with both Windows 10 Update (via setupconfig.ini) and Installation USB (setup.exe + command-line options). 

However, I can't seem to figure out an elegant way to use command line switches with Windows 10 Update Assistant https://www.microsoft.com/en-us/software-download/windows10 (the option to update local PC). The process starts download process and then just runs setup automatically, seemingly ignoring setupconfig.ini 

The only workaround I could think of was after the process fails once, go to C:/$GetCurrent/Media where Assistant downloads the files and then run Setup.exe from there with the necessary switches. 

Is there a more elegant solution to make Assistant read setupconfig.ini or command-line switches otherwise?

Thank you in advance

All replies (2)

_{Wednesday, January 24, 2018 2:50 AM}

Hi Jetico,

As far as I know, there is no way. Based on official information, IT pros can use the setupconfig file to add parameters to Windows Setup from Windows Update and Windows Server Update Services. It's not included the Windows Update assistant.

Here is the official reference:

Windows Setup Automation Overview

/en-us/windows-hardware/manufacture/desktop/windows-setup-automation-overview

Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].

_{Saturday, August 25, 2018 1:06 PM}

You should fix this.  Please!

What's the point in providing "ReflectDrivers" command line option for windows feature updates to be delivered by Windows updates, allowing "setupconfig.ini" to be set in the WSUS folder and then windows update assistant trying to install it instead, completely ignoring this ?

Your developer people really do seem to appear to be a bit dim at times.

If Windows Update Assistant automatically tries to install a feature update, (instead of the normal "Windows Update" mechanism) on an third party encrypted drive, the update will fail. Perhaps it might even occasionally destroy the OS and their data thus making life harder for the user.

You provided this "ReflectDrivers" option for this purpose so you should make sure it works in ALL cases when the computer wants to upgrade by itself, applied along with ALL OTHER command parameters supported by Windows update, placed in the setupconfig.ini file.

If the Update Assistant is automatically downloaded by itself, please get it to look in the documented WSUS folder and apply setupconfig.ini to the update setup command.

We have no trouble in blaming you for this silliness I can tell you.

I am trying this today, I wanted the test computer (1607, which has 3rd party OS encryption appled) to feature update by the normal Windows update. It downloaded update assistant instead and this does NOT work in this case.

PS: I even uninstalled Windows Update Assistant on this 1607 machine, in the hope it would feature update normally with Windows Update,  BUT it immediately installed itself about 10 minutes later (after a restart) and started to update itself, by downloading windows 10 1803. Please either use the normal Windows update service to apply the feature update (where WSUS setupconfig.ini is supported) or add  the support to the automatically downloaded update assistant. If you can't do this, at least check for setupconfig.ini in the WSUS folder and stop the update assistant from doing anything.

If setupconfig.ini is currently present in the WSUS folder, then  doubtless SOMEONE had a GOOD REASON to put it there, and I am certain they didn't want it to be ignored when a feature update was going to be automatically applied to the machine, by some other means such as Windows Update Assistant.

Faced with cases like this I have a motto in mind for Microsoft which I always think about:

"Why make it easy, when you can make it terribly terribly hard?"

Thanks for reading this and I do hope you take what I say in good humor.  But things like this are a real problem for us, and we have to take the blame when really it lies elsewhere, perhaps somewhere in Redmond in the USA.