Check whether Windows Updates are being installed

Question

I have a powershell script that’s used by the IT support department for remotely installing software on workstations. The script supports the installation of multiple products (one after another)and therefore has the potential to take a long time to run.

Yesterday a technician used the script to remotely install multiple software products on a machine that had been switched off for a few days.

We have a Windows Update GPO targeted at all of our workstations, it is configured to install updates at 9pm every Wednesday. If a workstation misses this scheduled install date then the updates will install 60 minutes after the machine is next switched on.

Whilst the technician was installing the software against the remote workstation, the Windows Update reschedule kicked in. Therefore his installation and the Windows updates were now both installing at the same time. This caused the product that he was installing (SQL Server Management Studio) to crash.

I would like to modify my script to check whether Windows updates are currently installing. If yes, then warn the technician and abort the script. If no, then stop and disable the Window update service (wuauserv), this will prevent the possibility of it kicking in whilst the script is in use, then start and re-enable the service when the script reaches the end.

I cannot find a robust way of checking whether Windows updates are currently being installed.

Any suggestions welcome; I’m happy to use an object, command line tool, WMI, read the registry, etc...

UPDATE 1. 06/04/13: What I was hoping for is some way of querying the status of the Windows Update service. If updates are currently being installed, my preference would be to respect the fact that updates are installing and advise the Technician to come back later. I am currently conducting some tests to determine the effect of stopping the wuauserv service in the following scenarios:

1. Stop the service before the updates are due to install.
2. Stop the service whilst updates are being installed.

UPDATE 2. 06/04/13: I had a Windows 7 VM that had not been switched on for a good few days and I was therefore able to mimic the situation that the technician faced the other day. I was able to use snapshots to my advantage to conduct a number of different tests.

I should point out that I modifed the GPO responsible for our Windows Update settings, reducing the reschedule time from 60 mins to 10 mins after a workstation is switch on (to make testing a bit easier).

TEST 1) Stopped the wuauserv service before updates were due to install.

Updates were due to install at 12:40.

I Stop the wuauserv remotely using powershell. I was tailing the WindowsUpdate.log and the following appeared:

2013-04-06      12:36:00:287     984    e68     Service *********
2013-04-06      12:36:00:287     984    e68     Service **  END  **  Service: Service exit [Exit code = 0x240001]
2013-04-06      12:36:00:287     984    e68     Service *************

I waited until 12.40 just in case the service was able to start itself again by some magic. It did not.

I started the service and the following was written to the WindowsUpdate.log, confirming that the service had started again.

2013-04-06    12:42:07:571     984    e70    Misc    ===========  Logging initialized (build: 7.6.7600.256, tz: +0100)  ===========
2013-04-06    12:42:07:571     984    e70    Misc      = Process: C:\Windows\system32\svchost.exe
2013-04-06    12:42:07:571     984    e70    Misc      = Module: c:\windows\system32\wuaueng.dll
2013-04-06    12:42:07:571     984    e70    Service    *************
2013-04-06    12:42:07:571     984    e70    Service    ** START **  Service: Service startup
2013-04-06    12:42:07:571     984    e70    Service    *********

The log also confirmed that the 10 min reschedule had applied itself again:

Success    Content Install    Installation Ready: The following updates are downloaded and ready for installation. This computer is currently scheduled to install these updates on 06 April 2013 at 12:52

TEST 2) Stopped the wuauserv service during update installation

This is an extract of the WindowsUpdate.log just before I stopped the service:

2013-04-06      13:25:00:372    1004    4dc     DnldMgr Preparing update for install, updateId = {F13298D7-7EC1-4D33-9A57-A367F54BA4DA}.106.
2013-04-06      13:25:00:372    3472    790     Handler :::::::::::::
2013-04-06      13:25:00:372    3472    790     Handler :: START ::  Handler: CBS Install
2013-04-06      13:25:00:372    3472    790     Handler :::::::::
2013-04-06      13:25:00:372    3472    790     Handler Starting install of CBS update F13298D7-7EC1-4D33-9A57-A367F54BA4DA
2013-04-06      13:25:00:419    3472    790     Handler CBS package identity: Package_for_KB2698365~31bf3856ad364e35~amd64~~6.1.1.2
2013-04-06      13:25:00:434    3472    790     Handler Installing self-contained with source=C:\Windows\SoftwareDistribution\Download\8fff2597df465a2957121c20dbd4bcec\windows6.1-kb2698365-x64.cab, workingdir=C:\Windows\SoftwareDistribution\Download\8fff2597df465a2957121c20dbd4bcec\inst

This is what was recorded when I stopped the service:

2013-04-06      13:25:19:957    3472    3e4     Handler CUHCbsHandler::Cancel called with fReleaseThreadNow=0
2013-04-06      13:25:19:957    1004    ed0     AU      ###########  AU: Uninitializing Automatic Updates  ###########
2013-04-06      13:25:19:973    3472    3e4     Handler CUHCbsHandler::Cancel called with fReleaseThreadNow=1
2013-04-06      13:25:19:973    3472    790     Handler WARNING: CBS handler has been told to exit immediately.
2013-04-06      13:25:19:973    3472    790     Handler FATAL: Completed install of CBS update with type=2, requiresReboot=0, installerError=0, hr=0x80242008
2013-04-06      13:25:19:973    3472    790     Handler :::::::::
2013-04-06      13:25:19:973    3472    790     Handler ::  END  ::  Handler: CBS Install
2013-04-06      13:25:19:973    3472    790     Handler :::::::::::::
2013-04-06      13:25:19:988    1004    4dc     Agent     * WARNING: Exit code = 0x8024000B
2013-04-06      13:25:19:988    1004    4dc     Agent   *********
2013-04-06      13:25:19:988    1004    4dc     Agent   **  END  **  Agent: Installing updates [CallerId = AutomaticUpdates]
2013-04-06      13:25:19:988    1004    4dc     Agent   *************
2013-04-06      13:25:19:988    1004    4dc     Agent   WARNING: WU client failed installing updates with error 0x8024000b
2013-04-06      13:25:20:004    1004    ed0     Report  REPORT EVENT: {72199C19-359E-4D78-A075-4EAA44C368D9}    2013-04-06 13:25:19:973+0100  1186     101     {D5FD720E-0F2C-4363-AA87-6AD4A6D11B0E}  106     8024000b        AutomaticUpdates        Success Content Install User cancelled the installation.
2013-04-06      13:25:20:035    1004    ed0     Report  CWERReporter::HandleEvents - WER report upload completed with status 0x8
2013-04-06      13:25:20:035    1004    ed0     Report  WER Report sent: 7.6.7600.256 0x8024000b D5FD720E-0F2C-4363-AA87-6AD4A6D11B0E Install 101 Managed
2013-04-06      13:25:20:035    1004    ed0     Report  CWERReporter finishing event handling. (00000000)
2013-04-06      13:25:20:160    1004    ed0     Service *********
2013-04-06      13:25:20:160    1004    ed0     Service **  END  **  Service: Service exit [Exit code = 0x240001]
2013-04-06      13:25:20:160    1004    ed0     Service *************

As you can see, it documents the fact that theupdate that was currently being installed was cancelled.

I just hope that the installation that was taking place was cancelled in a graceful way? But I don't know really know the answer to that... As the majority of Windiws Updates use MSIs, I would hope that they use their ability to rollback file and registry changes and thus leave the workstation in a stable state.

Solution 1

I wouldn't recommend killing those processes in the middle of install, as you and AthomSfere have hashed out. However, seeing as how the main two install names in Windows to look for are msiexec.exe and setup.exe you can look for those in your powershell script, and if those processes are running then create a loop where the script sleeps until both of those are closed. Something like (pseudocode):

while($(get-process -like msiexec.exe).count -gt 1 -or $(get-process -like setup.exe).count -gt 1){
    sleep 300
}

I only partially recommend this solution because there's the possibility those updates that were installed may require a reboot, and if they do, and your script installed software won't install if there's a reboot pending, then that's the perfect storm for it to fail anyway.

Ideally if you had a big enough infrastructure to leverage something like sccm for software deployment and windows updates then that's what you would want, and that would ultimately prevent those conflicts (at least from my experience software and updates installed from sccm don't conflict, they are installed consecutively instead of concurrently).

Solution 2

net stop wuauserv

does not matter if it is running it won't be after this command completes.

When your script completes

net start wuauserv

Solution 3

I am not at a domain machine right now to verify the names, but the way I have handled this is:

Look for running processes:

1. msiexec.exe
2. Setup.exe
3. SCCM process - I forget the exact name, kill it.
4. SMS process - Name forgotten too, kill it

I check for the first two running (And one more which is CompanyNameSetup.exe) to see if there are current installs. If not, then kill SCCM and SMS processes so no new installs can be pushed.

Do your installs and then either reboot, or restart the SCCM and SMS processes / services.

After the comments below: I think this would be the route in psuedo:

while (msiexec.exe isRunning OR Setup.EXE isRunning)
{wait for completion}
net stop wuauserv  #Prevent installs
taskkill /im Wuauclt.exe /f  #Kill an empty Wuauclt.exe

Then you can call your scripts, after your installs are done, all you should have to do is call

net start wuauserv  #Start WSUS service

Comments

[Fitzroy]

This is something I had considered but my concerns were: A) If a technician runs the script before updates are due to install and the service is stopped, will Windows Update be intelligent enough to reschedule the install date/time when the service is started again? B) If a technician runs the script whilst updates are currently installing, is stopping the service 'heavy handed'? Will it gracefully stop the current installation or will it leave things in a bit of a mess? These are things I am currently testing.

[Fitzroy]

This is an approach I had considered. I used processexplorer and made a number of notes on the processes that appear whilst updates are being installed. On Windows XP, the majority of the time MSIEXEC has a handle on a file in 'Windows\Installer'. On Windows 7, the majority of the time, 'TrustedInstaller.exe' has a handle on a file in 'Windows\SoftwareDistribution'. To just kill a process doesnt strike me as the right thing to do, it doesnt sound particularly graceful. I would probably wait until the process closes rather than kill it. This is somethhing I'm giving some thought to.

[Austin T French]

Killing SCCM and SMS prevents new updates from installing midway through your install. I have had updates kick off in the middle of a script and cause problems. So killing processes (The ones I mentioned) are only to prevent installs from starting in the middle of your script, not to kill actual installs.

[Fitzroy]

So for example, if you have a queue of five updates to install, and update 1 of 5 is currently installing, does killing SMS and SCCM allow update 1 of 5 to complete but prevent the remaining four from installing? I don't actually use System Center Configuration Manager. I just have a WSUS server and use a group policy to point the workstations to the WSUS server. If what I've said is right, then I like your logic and wish I could find a way of applying it to my situation.

[Austin T French]

@Fitzroy, yes that's exactly the logic! Do you know what the WSUS client runs as? Service or exe? Or both?

[Fitzroy]

There is a windows service called 'wuauserv', in Windows XP the display name is 'Automatic Updates', in Windows 7 it is 'Windows Update'. If a user is logged into the workstation, a process called 'Wuauclt.exe' is spawned and runs under that users account. Whilst Windows updates are installing another instance of 'Wuauclt.exe' appears to open, this time under the SYSTEM account. Killing the users instance of 'Wuauclt.exe' seems to just cause the Windows Update GUI to disappear but closing the SYSTEM accounts instance seems to stop the installation of the updates.

[Fitzroy]

Have a look at the updates to my question to see the effect that closing the service has. I haven't properly studied the effect of closing the SYSTEM accounts instance of the 'Wuauclt.exe' process. From experience I just know it causes updates to stop installing - no idea if it allows the currently installing update to finish what its doing.

[cybernard]

Updates not fully installed will remain on the "todo" list. The current update is a separate process so it should finish correctly. Just do a quick check after stopping it to make sure msiexec.exe is not running.

[Community]

Your answer could be improved with additional supporting information. Please edit to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.