Just a heads up on a new ConfigMgr 2007 Knowledge Base article we published this morning. If you’re pushing out Software Updates to Windows 7 or Windows Server 2008 R2 based clients then you’ll want to be aware of this potential issue:
System Center Configuration Manager 2007 clients running Windows 7 or Windows Server 2008 may reboot even though the Configuration Manager 2007 Software Updates deployment management settings are configured to suppress reboots on all clients. By default the reboot will be scheduled for 3:00am but can occur at other times as well.
This can occur if the Configuration Manager clients have Automatic Updates enabled for the Windows Update client. If an update is delivered to a client that has Automatic Updates enabled, the Windows Update agent may ultimately manage the reboot of that client depending on the schedule used. By default, the Windows Update agent schedules updates to be installed daily at 3:00am.
To resolve this issue disable the Automatic Updates policy on the Configuration Manager client computers. To do this, apply a Group Policy to disable Automatic Updates. This setting is located in the following location:
Computer configuration>Administrative Templates>Windows Components> Windows update> Configure Automatic updates
Note that this policy does not prevent the Windows Update service from functioning, it merely disables the Windows Update agent behavior described above. This will allow only the Configuration Manager Client to manage updates and thus the reboot schedule.
It is also recommended that you disable the Action Center so that the user will not be prompted to configure Automatic Updates. For information on configuring the Action Center see the following:
When Automatic Updates for the Windows Update agent and the Configuration Manager client are enabled on the same machine, both can manage the reboot for the client. This assumes that the Windows Update agent is configured with the default install behavior and schedule.
When both the Configuration Manager client and the Windows Update agent are enabled you will see entries similar to the following in the Windowsupdate.log file:
2010-11-22 13:09:09:916 296 1ffc Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates] windows update agent
2010-11-22 13:09:09:916 296 1ffc Agent *************
In the same log:
2010-11-22 14:03:46:064 2720 b84 COMAPI <<– SUBMITTED — COMAPI: Search [ClientId = CcmExec]
2010-11-22 14:03:46:064 296 23d4 Agent ** START ** Agent: Finding updates [CallerId = CcmExec] Configuration Manager Client
2010-11-22 14:03:46:064 296 23d4 Agent *********
In this situation, if for example the Configuration Manager client installs an update that requires a reboot and it was suppressed, the update installation creates a registry setting in HKEY_LOCAL_MACHINE\System\Current Control Set\Control\Session Manager\FileRenameOperations with the name of the file that needs to be replaced on the following reboot. The Windows Update agent uses that registry key to define the OS status that will trigger the agent to be in a reboot pending condition.
In a case like this, if the Configuration Manager client is set to reboot the machine after a few days but the Windows Update agent is scheduled to install updates every day at 3:00am, the condition that is applied first after installing the update will be the behavior the OS will have.
The Configuration Manager client installs updates by Windows Update agent API but if machine has the Windows update agent enabled the agent itself will follow its own configuration settings.
Also note that if you sysprep a client machine to use as your base image, and Automatic Updates are enabled when the image is taken, all clients based on that image will retain the Windows Update configuration in the following location:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Windows Update\Auto Update\
The relevant values here are scheduleinstallday and scheduleinstalltime.
For the latest version of this article see the link below:
J.C. Hornbeck | System Center Knowledge Engineer
The App-V Team blog: http://blogs.technet.com/appv/
The WSUS Support Team blog: http://blogs.technet.com/sus/
The SCMDM Support Team blog: http://blogs.technet.com/mdm/
The ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
The SCOM 2007 Support Team blog: http://blogs.technet.com/operationsmgr/
The SCVMM Team blog: http://blogs.technet.com/scvmm/
The MED-V Team blog: http://blogs.technet.com/medv/
The DPM Team blog: http://blogs.technet.com/dpm/
The OOB Support Team blog: http://blogs.technet.com/oob/
The Opalis Team blog: http://blogs.technet.com/opalis