Removing computers from a collection in System Center Configuration Manager 2007 may cause an unexpected reboot

Removing computers from a collection in System Center Configuration Manager 2007 may cause an unexpected reboot

  • Comments 1
  • Likes

hotfixJust a quick heads up on a new KB article we published today:

=====

Symptoms

Some computers may reboot unexpectedly after they are removed from a collection in System Center Configuration Manager 2007
(ConfigMgr 2007) when that collection has a maintenance window. From looking at a sample log we can see the following:

1. The maintenance window was deleted at about 8/23/2011 12:12:46 AM:

CServiceWindowManager::OnPolicyChange- Policy __InstanceDeletionEvent notification received ServiceWindowManager 8/23/2011 12:12:46 AM 10356 (0x2874)
Service Window Policy Deletion notification received. ServiceWindowManager 8/23/2011 12:12:46 AM 10356 (0x2874)
A Policy Change has occurred. Policy has been deleted. ServiceWindowManager 8/23/2011 12:12:46 AM 10356 (0x2874)
The service window being deleted is not active. Just Deleting... ServiceWindowManager 8/23/2011 12:12:46 AM 10356 (0x2874)
The Next event was found to be either the start/end of the service window just deleted. Recalculating next event... ServiceWindowManager 8/23/2011 12:12:46 AM 10356 (0x2874)
No Service Windows Left. There is no next event.... ServiceWindowManager 8/23/2011 12:12:46 AM 10356 (0x2874)
Sending Message SERVICEWINDOWEVENT:DELETE event ServiceWindowManager 8/23/2011 12:12:46 AM 10356 (0x2874)
Inactive Service Windows List has 0 windows ServiceWindowManager 8/23/2011 12:12:46 AM 10356 (0x2874)

2. The assignment {0A650EE8-0DE5-4D82-AED6-947BD72425D4} was downloaded successfully at about 8/22/2011 11:10:30 PM:

DownloadCIContents Job ({39B93D1E-6868-4E2A-B271-BA721753019D}) started for assignment ({0A650EE8-0DE5-4D82-AED6-947BD72425D4}) UpdatesDeploymentAgent 8/22/2011 11:10:16 PM 11888 (0x2E70)
Progress received for assignment ({0A650EE8-0DE5-4D82-AED6-947BD72425D4}) UpdatesDeploymentAgent 8/22/2011 11:10:29 PM 14120 (0x3728)
Progress received for assignment ({0A650EE8-0DE5-4D82-AED6-947BD72425D4}) UpdatesDeploymentAgent 8/22/2011 11:10:30 PM 14120 (0x3728)
Update (Site_C20CCE23-F877-4170-89AB-ED6F54566E97/SUM_ff0863f8-1e9d-4c0b-91a2-7ef1e2faf357) Progress: Status = ciStateDownloading, PercentComplete = 0, Result = 0x0 UpdatesDeploymentAgent 8/22/2011 11:10:30 PM 14120 (0x3728)
Update (Site_C20CCE23-F877-4170-89AB-ED6F54566E97/SUM_ca765565-04fb-4ece-b64b-5625983c69d7) Progress: Status = ciStateDownloading, PercentComplete = 0, Result = 0x0 UpdatesDeploymentAgent 8/22/2011 11:10:30 PM 14120 (0x3728)
Update (Site_C20CCE23-F877-4170-89AB-ED6F54566E97/SUM_8be5dea6-87f2-461b-aabb-22a14de30efb) Progress: Status = ciStateDownloading, PercentComplete = 0, Result = 0x0 UpdatesDeploymentAgent 8/22/2011 11:10:30 PM 14120 (0x3728)
Update (Site_C20CCE23-F877-4170-89AB-ED6F54566E97/SUM_43742f2a-7256-4fd1-9985-859b3aab0bad) Progress: Status = ciStateDownloading, PercentComplete = 0, Result = 0x0 UpdatesDeploymentAgent 8/22/2011 11:10:30 PM 14120 (0x3728)
Update (Site_C20CCE23-F877-4170-89AB-ED6F54566E97/SUM_457a20a6-3ae0-4ffc-8e2f-677199d22fdd) Progress: Status = ciStateDownloading, PercentComplete = 0, Result = 0x0 UpdatesDeploymentAgent 8/22/2011 11:10:30 PM 14120 (0x3728)

3. The assignment {0A650EE8-0DE5-4D82-AED6-947BD72425D4} was started triggering installation at about 8/22/2011 11:11:18 PM, however, it failed and will be retried once the service windows is available:

Starting install for assignment ({0A650EE8-0DE5-4D82-AED6-947BD72425D4}) UpdatesDeploymentAgent 8/22/2011 11:11:18 PM 6676 (0x1A14)
This assignment ({0A650EE8-0DE5-4D82-AED6-947BD72425D4}) will be retried once the service window is available. UpdatesDeploymentAgent 8/22/2011 11:11:27 PM 6676 (0x1A14)

4. The policy for the assignment {0A650EE8-0DE5-4D82-AED6-947BD72425D4} was deleted at about 8/23/2011 12:14:51 AM, however, this time the assignment {0A650EE8-0DE5-4D82-AED6-947BD72425D4} has already been triggered. Please refer to 3.

OnPolicyDelete for assignment ({0A650EE8-0DE5-4D82-AED6-947BD72425D4})... UpdatesDeploymentAgent 8/23/2011 12:14:51 AM 10356 (0x2874)

5. Once the maintenance delete event was received in the client side at about 8/23/2011 12:12:46 AM (please refer to 1.), for the assignment {0A650EE8-0DE5-4D82-AED6-947BD72425D4} was finished downloading (please refer to 2.) and it has been triggered installation (please refer to 3.), the assignment will be installed immediately once the maintenance window was removed at about 8/23/2011 12:12:50 for the policy for the assignment was deleted at about 8/23/2011 12:14:51 AM (please refer to 4.).

Starting install for assignment ({0A650EE8-0DE5-4D82-AED6-947BD72425D4}) UpdatesDeploymentAgent 8/23/2011 12:12:50 AM 7276 (0x1C6C)
Policy object for assignment ({0A650EE8-0DE5-4D82-AED6-947BD72425D4}) not found. UpdatesDeploymentAgent 8/23/2011 12:12:51 AM 7276 (0x1C6C)
Policy object for assignment ({0A650EE8-0DE5-4D82-AED6-947BD72425D4}) not found. UpdatesDeploymentAgent 8/23/2011 12:12:51 AM 7276 (0x1C6C)
Policy object for assignment ({0A650EE8-0DE5-4D82-AED6-947BD72425D4}) not found. UpdatesDeploymentAgent 8/23/2011 12:12:51 AM 7276 (0x1C6C)
Cause

The problem occurs because the maintenance window is removed after the computers are removed from the collection.

If the assignment was downloaded successfully and was triggered, then once the maintenance window was removed before the policy of assignment was deleted, the assignment will still be installed. It means that there were 2 important policies that arrived at the ConfigMgr 2007 client in this issue after removing the computers from the collection:

(1) Maintenance Window delete

(2) Assignment policy delete

The reason why the issue occurred is that the policy 1 arrived before policy 2. Based on current ConfigMgr 2007 design, the program policy deletion is not prioritized over maintenance window policy deletion because the policies were evaluated and applied one by one and there is no priority flag in the policies.

Resolution

This is by design behavior in ConfigMgr 2007.

More Information

In the current version of ConfigMgr 2007, we need to pay attention when moving computers between collections that have a maintenance window setting because the maintenance window setting means that the computers cannot perform change outside of the maintenance window.

It is recommended that administrators follow the best practice of naming the collections in a specific manner (such as "MW-<window name>"), then the administrator know the collections that have a maintenance window and thus will not remove operations outside of the Maintenance window.

http://technet.microsoft.com/en-us/library/bb694295.aspx

================================================

Best Practice Recommendations

Maintenance windows are not intended to function as a primary scheduling method for programs. Instead, they are designed to limit the interference of software deployments or changes with critical system functions. For example, one likely use of a maintenance window would be to specifically restrict system changes on a collection of client computers to the period between midnight and 2:00 a.m., when network traffic is at a minimum or when those computers are not engaged in other activities.

It is recommended that if you use maintenance windows to restrict system changes, you should create specific collections for this purpose rather than use the default collections. Additionally, naming these new collections in a specific manner (such as "MW-<window name>") can be helpful. One or both of these methods will help you manage your collections more easily and effectively.

=====

For the most current version of this article please see the following:

2612955: Removing computers from a collection in System Center Configuration Manager 2007 may cause an unexpected reboot

J.C. Hornbeck | System Center Knowledge Engineer

App-V Team blog: http://blogs.technet.com/appv/
AVIcode Team blog: http://blogs.technet.com/b/avicode
ConfigMgr Support Team blog: http://blogs.technet.com/configurationmgr/
DPM Team blog: http://blogs.technet.com/dpm/
MED-V Team blog: http://blogs.technet.com/medv/
OOB Support Team blog: http://blogs.technet.com/oob/
Opalis Team blog: http://blogs.technet.com/opalis
Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
OpsMgr Support Team blog: http://blogs.technet.com/operationsmgr/
SCMDM Support Team blog: http://blogs.technet.com/mdm/
SCVMM Team blog: http://blogs.technet.com/scvmm
Server App-V Team blog: http://blogs.technet.com/b/serverappv
Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center Essentials Team blog: http://blogs.technet.com/b/systemcenteressentials
WSUS Support Team blog: http://blogs.technet.com/sus/

clip_image001 clip_image002

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • i find one of the issues with relying too much on maintenance windows is the possibility that the system will fall out of the collection for reasons that are not user related. for example, say a client stops working and stops working long enough that its related object is removed from the database -- thus the collection. later, an administrator discovers the problem and resets the agent in some way that it reports back in.

    assuming things are queued up, when the agent starts to work and receives policies, it is possible that the agent will operate as outlined in this article, causing a potential reboot. so while the mw naming convention is useful and recommended (i use it) -- it's very possible that things will do exactly as noted in this article -- without anyone moving anything.