2
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:
- Stop the service before the updates are due to install.
- 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.
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. – Fitzroy – 2013-04-06T13:23:58.477
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. – Austin T French – 2013-04-06T16:07:53.237
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. – Fitzroy – 2013-04-06T17:37:05.523
@Fitzroy, yes that's exactly the logic! Do you know what the WSUS client runs as? Service or exe? Or both? – Austin T French – 2013-04-06T18:00:26.517
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 – 2013-04-06T18:30:29.143
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. – Fitzroy – 2013-04-06T18:34:15.783
I've done some more testing with ProcessExplorer to see which processes open whilst Windows Updates are installing on Windows 7. Typically, the LOCAL SYSTEM accounts instance of 'Wuauclt.exe' creates a child process, the child process creates another child process which is either 'setup.exe' or 'msiexec.exe'. I might be wrong about this,but it appears that there are some updates that dont follow this trend - after some playing with ProcessExplorer it looks as though the updates use 'TrustedInstaller.exe'. Unfortunately it appears that TrustedInstaller.exe is open quite often on Windows7. – Fitzroy – 2013-04-06T23:22:40.713