Policy Issues… Again….

We have had some policy issues again.  This all started around November 14th when we starting having falures in our OSD environment.  The logs were showing:

Now, this was happening in one of our two primary sites.  The other site has more clients in it, but it ran without fail.  So, we got Microsoft involved.  To start off with, we wanted to get some more verbose logging so we went to the child primary site server and made some changes in the registry.  First, we changed HKLMSoftwareMicrosoftSMSTracing and set SqlEnabled from 0 to 1.  Then we went to HKLMSoftwareMicrosoftSMSTracingSMS_Policy_Providor and set DebugLogging from 0 to 1 and Logging level from 1 to 0.  We then bounced SMSExec service.

After recreating the issue and collecting the logs, Microsoft informed us:

I see you are hitting a distinct problem that is addressed in CU3. Please install CU3 to resolve this issue. There is an article scheduled to be written but has not been written yet, here is the article number for your reference: 2857452

The indicator is here:

And here:

The cause was expalined as :

Following the deployment of the image to an existing machine the client starts a number of DTS jobs to download updated policy. The policy begins to download and at some point a change is detected to the CCM_PolicyAgent_Configuration

At this point there is a possibility that some DTS jobs have completed but not yet processed. When the PolicyAgent_PostStartup task executes and attempts to check the progress of the DTS jobs for the pending policy downloads. The client fails to find the DTS job because it has already completed and concludes that the policy download should be invalidated.

To fix this, we installed CU3.  This solved the problem, but actually exposed another. Because of disk encryption, we actually use two task sequences when upgrading a PC.  And since we have various teams working this, we have two collections for each team to run those task sequences.  The first task sequence is used to backup the user data and get the apps mapped for the upgrade.  Once this is completed, the computer is moved to the second collection where the second task sequence is being deployed.  Once CU3 was installed, things started looking up, except for two of the groups.  They continued to get the error message.  After reading the logs further, we noticed they also got a message saying the package had expired.  Low and behold, the deployments for those two collections were expired!  This had been done apparently by some people to attempt to figure out what was going wrong before Microsoft got involved.  It would appear that CU3 also made it so the Install Package step in a task sequence would look at schedules!  Simply removing the expiration solved that little issue.
%d bloggers like this: