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:
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.
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:
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
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
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).
User contributions licensed under CC BY-SA 3.0