“Orphaned” Maintenance Windows for SCCM clients

Last week, in my SCCM test environment, I noticed there are several maintenance windows applied to clients that I had no idea where were they come from.

Symptoms:

When using SCCM Client Center, it shows this particular client (MGMT01) has 3 maintenance windows (service window) assigned to it:

PolicySpy from ConfigMgr 2007 Toolkit also shows the same:

The problem is, there should ONLY be 1 maintenance window for this client:

and actually, there is ONLY 1 maintenance window in total in my entire environment:

I ran “SELECT * from v_ServiceWindow” against the site database and there is only 1 row returned.

Background:

Sometime last year, I installed a new central site called “CEN” and set the existing primary site “TAO” as the child site.

The only legitimate maintenance window in my SCCM hierarchy should be the one showed above in the database, it is created for a collection I created called “All Windows Server 2008 R2 Systems (CEN0000E)” on central site “CEN”.

I suspect I might have created 2 maintenance windows for the 2 built-in collections “All Systems” (SMS00001)” and “All Windows Server Systems (SMS000DS)” on site “TAO” before I configured “TAO” as child primary under “CEN”. but it has been too long and I couldn’t remember it.

Troubleshooting:

1. I tried to reset SCCM clients policies using PolicySpy, it did not help. these maintenance windows came back after machine policy retrieval and evaluation and it is logged in PolicyEvaluator.log:

Updating policy CCM_Policy_Policy4.PolicyID=”SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}”,PolicySource=”SMS:TAO”,PolicyVersion=”1.00”    PolicyAgent_PolicyEvaluator    16/08/2011 8:23:41 AM    3624 (0x0E28)

Applying policy SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}    PolicyAgent_PolicyEvaluator    16/08/2011 8:23:41 AM    3624 (0x0E28)

1. Since I cannot modify the built-in collections from the child primary sites because they also exist in parent sites, and it is only a test environment, I removed parent-child relationship between CEN and TAO and waited overnight, then checked maintenance windows settings for SMS00001 and SMS000DS on TAO, there are no maintenance windows created for these 2 collections. So this step did not help me resolving the issue.

2. I then had a look at the policy table in both CEN and TAO site databases trying to find the policy for these orphaned maintenance windows using the policyID showed in PolicySpy:

I ran “SELECT * FROM Policy where PolicyID  LIKE ‘SMS%’” on both site databases, “CEN” database returned nothing and “TAO” has returned 2 rows and the policyIDs match the ones for orphaned maintenance windows:

I deleted these 2 rows from Policy table:

delete FROM Policy where PolicyID = 'SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}'
delete FROM Policy where PolicyID = 'SMS000DS-{4fe54281-f3f1-4b9f-9d9e-d1eb12b4a87e}'

and from PolicyAssignment table:

delete FROM PolicyAssignment where PolicyID = 'SMS00001-{bf9d2dba-eb0a-412f-9147-82f12b4f136a}'
delete FROM PolicyAssignment where PolicyID = 'SMS000DS-{4fe54281-f3f1-4b9f-9d9e-d1eb12b4a87e}'

Then restarted SMS_EXECUTIVE and SMS_SITE_COMPONENT_MANAGER services on TAO site server (also the MP). – Not sure if this is required, I did it anyway.

Finally, I reset SCCM client policy via PolicySpy and initiated “Machine Policy Retrieval and Evaluation Cycle”

Once evaluation is completed, SCCM Client Center is showing the correct maintenance windows setting:

Since I need to do this to all SCCM clients (because SMS00001 = “All Systems” collection), I’ll create a software package with a batch file as program:

WMIC /Namespace:\\root\ccm path SMS_Client CALL ResetPolicy 1 /NOINTERACTIVE
WMIC /Namespace:\\root\ccm path SMS_Client CALL RequestMachinePolicy 1 /NOINTERACTIVE

Disclaimer: The purpose of this post is only to document the steps I have taken to resolve this particular issue in my TEST environment. I did not consult with any other parties (including Microsoft) during troubleshooting. Even though I have not seen any negative impacts after I implemented this change in my test environment, I am not responsible for any damages it may cause in other SCCM environments.