Failing software updates in SCCM / WSUS

I recently was troubleshooting an issue with some failing software update installations being deployed via SCCM / WSUS, and finally found out what was affecting them. All of the failed updates were related to Microsoft Office, so that kind of tells you something right there. It turns out, the root cause of the installation failure was that the “Office Source Engine” (short name ‘ose’) was disabled.

A quick, easy way to re-enable the service remotely is to use Windows PowerShell. Here is a command you can issue to set the start mode to manual:

(Get-WmiObject -Query “select * from win32_service where name = ‘ose'” -ComputerName RemoteMachine).ChangeStartMode(“Manual”)

The error messages I was getting in the UpdatesHandler.log are below:

WSUS update (32cd1fb9-5401-4025-b8dc-22a3b41060cc) installation result = 0x80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (880f4592-a57e-4af6-ae6c-c2988519df4e) installation result = 0x80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (8fe60694-94c6-4568-8094-17e2e92045ea) installation result = 0x80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (938d8bbf-f928-4dac-baef-b66005583409) installation result = 0x80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (ae97d343-7c0d-4c06-9a62-67eff01890a9) installation result = 0x80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (bf20a84c-6662-4755-b60d-7fe3a090eb01) installation result = 0x80070652, Reboot State = NoReboot
Update execution failed.
WSUS update (e33db88f-49ab-4cce-aa24-16d952526b6b) installation result = 0x80070643, Reboot State = NoReboot
Update execution failed.
WSUS update (f6e3e036-eaf1-4423-9eab-9359a23fcb9e) installation result = 0x80070643, Reboot State = NoReboot
Update execution failed.
WSUS update (f75401a0-0419-48fc-8011-bb0b30c061f8) installation result = 0x80070643, Reboot State = NoReboot
Update execution failed.

Update (2009-10-29): I thought I had posted this somewhere, but I guess not. While the suggested PowerShell code above would work for a one-off fix, a better way to manage this configuration would probably be to use the Microsoft Group Policy Preferences Client Side Extensions (CSE). You can use these GPO extensions to enforce service configurations for systems with the CSE installed, thus reducing helpdesk tickets resulting from improper configurations (whether done maliciously or non-maliciously).