How do I configure Windows Update programmatically?

First of all, normal programs shouldn't be messing with Windows Update configuration. That's something the user (or the user's administrator) decides. If you're an IT administrator, then you can use Group Policy to configure Windows Update on your network.

But maybe you're a special case where the above remarks don't apply. Say you're a data center and all the systems are running inside of virtual machines and you don't want them installing updates or rebooting without your permission, so you want to run a script when you set up the image to disable updates.

You can use the Microsoft.Update.Auto­Update object, known to native code as IAutomatic­Updates. Here's a script that prints your current update settings:

var AU = new ActiveXObject("Microsoft.Update.AutoUpdate");
var Settings = AU.Settings;

The notification levels are documented as Automatic­Updates­Notification­Level. If you want to change the notification level, you can update the level in the Settings object, and then save it.

var AU = new ActiveXObject("Microsoft.Update.AutoUpdate");
var Settings = AU.Settings;
Settings.NotificationLevel = 1; // aunlDisabled

All the various settings are documented in MSDN, though you have to dig through IAutomatic­Updates­Settings, IAutomatic­Updates­Settings2, and IAutomatic­Updates­Settings3 to find them all.

Comments (20)
  1. Joshua says:

    This would have been more useful about twenty years ago when we were looking at a case where windows updates didn't work right. We had got so far as managing to take apart MSBA to find out how it works. Basically we would have ended up with a duplicate of WSUS installed on a laptop.

  2. Dan Bugglin says:

    Eh, the example use case doesn't really work since you could make that part of the image, right?  But whatever.

    Links to the various interfaces Raymond mentioned but didn't link:…/aa385822(v=vs.85).aspx…/aa826442(v=vs.85).aspx…/ee694834(v=vs.85).aspx

    Huh.  All of them have the same OS requirements.  I kinda wonder now why they were split into multiple interfaces.

    [Right, this goes into the image. So when you need to create 50 new images… -Raymond]
  3. Katie says:

    The Windows Update Agent API can be very useful as well.…/aa387099(v=vs.85).aspx

    I had to use it once to implement a copy of the Windows Update wizard for a Windows 7 Embedded industrial controller – the existing Wizard didn't work with the specific look and feel of the controller.

  4. Adam Rosenfield says:

    @The MAZZTer: I seem to recall an older post by Raymond (though I'm unable to find it at the moment) saying that at some point, Microsoft updated the documentation to remove references to older versions of Windows in the "Minimum Supported Client" / "Minimum Supported Server" version documentation.  If the versions listed were older than some particular versions, then the minimum versions would be bumped up.

    Right now, that minimum minimum version looks like Windows XP / Windows Server 2003.  So all of the functions that really first became available in Windows 3.1, 95, 2000, etc. are documented as first being available in XP / Server 2003.  For example, CreateFile has clearly been around for a very long time, but MSDN says its minimum supported versions are XP / Server 2003.

  5. Bryan Porter says:

    @Adam Rosenfield – the important part is the word "supported". That statement is meant to describe what versions of the operating system you can call Microsoft support and expected to receive assistance with, not a historical timeline of the functions introduction.

  6. StefanH says:

    @Bryan Porter – I don't think that's what "supported" refers to. Because the minimum supported client version from the IAutomaticUpdatesSettings interface documentation is listed as "Windows 2000 Professional with SP3 [desktop apps only]" here:…/aa385822%28v=vs.85%29.aspx

    And Windows 2000 has been unsupported for a while according to the Support Lifecycle Product Database:…/default.aspx

  7. Anon says:


    a) That's what it refers to.

    b) They are not going to update every single article across the entire site simultaneously, and some articles may never be updated at all. There's no reason to touch them if no other information has changed.

  8. Anon says:


    Err.. clarification:

    a) It refers to the minimum supported operating system for that function. When the article is updated, only supported operating systems are included in the section.

  9. Henry says:

    Hey, how useful and timely!

    Just had to dig into this topic because a newly installed Win 7 wouldn't let me active Microsoft Updates (as opposed to only Windows Updates) through the link on the CPL.

  10. L. says:

    Nitpick: at install time, unattend.xml files can be used to do this with no scripting.

    OTOH, this could be handy if you are using Powershell to remotely (re)configure a computer.

  11. Malcolm says:

    Nitpick on the nitpick: While you can indeed set this at install time, scripting it can have its uses.

    For instance, you could image your server with updates enabled, allow it to update automatically and then, once up to date (Is there an API to check that?) turn off automatic updates …

  12. mfah says:

    @Malcolm: Nitpick on the nitpick on the nitpick.  If you have Active Directory you can have two OUs for servers with a different GPO on each.  One for build with updates enabled, the other for production with updates disabled, and just include "move to production OU" as the last step in your build documentation.

  13. Kirby FC says:

    @Bryan Porter – "the important part is the word "supported". That statement is meant to describe what versions of the operating system you can call Microsoft support and expected to receive assistance with, not a historical timeline of the functions introduction."

    The word "supported" is ambiguous.  "Supports" is commonly used to indicated that something works with or is used by something else, e.g., "Product X supports unicode".  If you say "Minimum supported version is Windows XP" it could be interpreted as "Does not work with versions prior to XP" which may or may not be true.

  14. It has been widely accepted that the meaning of "supported" for the MSDN is really really unlucky. When you need to work with an really old, officially unsupported version of Windows you cannot deduce which functions are available and which aren't.

    Shouldn't be too difficult to use a different method to mark support and unsupported Windows' ?

    On topic: Anyone messing with Windows Update usually ends up breaking it (local company IT, I'm looking at you, and it ain't with pretty blue eyes)

    [Even if the marking is left at "Windows 2000", the rest of the documentation won't be. For example, VirtualLock changed behavior and the docs were updated with "On Windows NT 3.1, this API behaves like X. Starting in Windows NT 4, it behaves like Y.". Once Windows NT 3.1 fell out of support, the first sentence was eligible for deletion to avoid cluttering up the documentation with information that is obsolete. -Raymond]
  15. slab says:


    'Remarks: The IAutomaticUpdatesSettings2 interface may require you to update the Windows Update Agent (WUA). For more information, see Updating Windows Update Agent.'

    They're different interfaces because it's functionality added in new versions of Windows Update, but even older OSes got newer versions of Windows Update over time.

  16. Jimmy says:

    Would it be possible to provide a modification history for MSDN articles, like in a wiki? That way the documentation would be uncluttered by default but one could look up documentation for obsolete Windows versions if really needed.

  17. Malcolm says:

    @mfah: Good point, but how do you still know when updates are up to date?

  18. Marc K says:

    Good thing I saved all those old MSDN Library CDs for when I want to develop something new for Windows 95!

  19. Chris Crowther says:

    If you're a data centre and you wanted to turn off updates in all the VMs wouldn't still just use Group Policy to do it?

Comments are closed.

Skip to main content