Policy Flow – The Details
The term ‘policy’ applies to many technical and non-technical discussions. Policy can have several meanings but for the ConfigMgr administrator the meaning is specific. Simply put, policy is that detail used to communicate work and configurations specific to each ConfigMgr client. Policy, for example, may instruct the client to enable or disable certain features, detail work that is to be performed by the client and communicate details about how to do that work.
In order for a client to make use of policy there must be some policy created for the client to retrieve. So how does all of this work? How does the policy get created and how does the client then learn about and implement the policy? A good starting point is a diagram to help understand the overall flow. The diagram shows detail for a primary site. This same flow applies to a hierarchy with a CAS and even if a secondary site is involved. For the CAS scenario bear in mind that no policy processing is done at the CAS. Full management can be done from the CAS but all policy creation and retrieval happens at the primary sites. For a secondary site the client would likely make use of a proxy management point but the policy would still ultimately come from the primary. Detailed discussion of secondary site flow is out of scope for this discussion.
With the diagram in mind let’s walk through this step by step.
A client instruction ultimately results in client policy being created. For this discussion the term policy will only be used after the instruction has been stored as policy in the database. Client instructions are typically targeted to collections which by definition means that not all instructions are destined for all clients. For the purposes of this example a package will be created and deployed to a collection containing a test client.
First, the package and program are created.
Package:
Program:
The package and program provide detail about what to install but not specific information about where to do the install and parameters for the install. The where and parameter information is provided in the deployment. The where information specifies the clients targeted by the deployment. This is vital information for policy creation. Accordingly, only after the deployment is created is policy created.
Deployment:
The activity of creating the package, program AND deployment first shows up in the distmgr.log (well, really the first place is in SMSProv and SMSDBMon). As mentioned previously, package and program creation does not cause policy to be created. Policy creation is tied directly to deployment creation. A review of processing in the logs will show this. The component that creates policy is policy provider but let’s follow the process from distribution manager onward to see how this works. There is a lot happening in the distmgr.log. Most activity is related to compressing and sending the content. This happens because selecting at least one distribution point is required when creating a deployment. The detail about distribution point selection is omitted from the log. There is actually only one line of interest related to policy creation and that is the only line shown. Note the package ID here matches the package just created.
DistMgr.log
Created policy provider trigger for ID CAS0007F
What does it mean that a policy provider trigger has been created? This one line might be a queue to immediately jump to the policy provider log. We will get there but not yet. The next component in line on the way to creating policy is offer manager. The line in distmgr.log indicating it has created a policy trigger actually means a flag file <offer ID>.OFN has been created for further processing. There is no detail in this file as it is just a trigger to wake up offer manager. Note the 0 KB size.
Note: You might look at your own site and try to follow these flag files but never see them. Capturing these files requires manipulating the site in a specific way that is not suitable for production purposes. Accordingly, I will not detail the process here.
Why offer manager you ask? Remember, the instruction for the deployment does not necessarily apply to every client. It is the job of offer manager to figure out what clients the instruction does actually apply to and then the process to create policy can continue. Note also in the offermgr.log we don’t see the package ID. Instead we see the offer ID which translates to the deployment ID column when added to the deployment view in the console shown earlier. The only place the package ID is seen is in the status message. Offermgr concludes processing by preparing policies. What is actually happening is that policy provider is being notified by a flag file what policies it needs to create.
OfferMgr.log
Processing New offer CAS2002A
STATMSG: ID=3900 SEV=I LEV=M SOURCE="SMS Server" COMP="SMS_OFFER_MANAGER" SYS=cm12prisql.tailspintoys.com SITE=PR1 PID=6692 TID=6584 GMTDATE=Sun Aug 24 17:17:35.478 2014 ISTR0="Richcopy_CAS0007F_AllSystems" ISTR1="" ISTR2="" ISTR3="" ISTR4="" ISTR5="" ISTR6="" ISTR7="" ISTR8="" ISTR9="" NUMATTRS=1 AID0=401 AVAL0="CAS2002A"
Examining collection: SMS00001 ßThis ID is for the ‘All Systems’ collection targeted by the deployment
Advanced client offer changes detected for collection SMS00001, 1 added and 0 deleted.
Prepared policies based on 2 offer(s) for 1 resources in collection SMS00001
And from here we move to policy provider where the actual policy is created. Offer manager forwards the .OFN file to policypv.box but this time notice there is information inside the file as the size is now 1 KB. If the file is opened in notepad or other text editor the file appears empty but there definitely is data in the file.
When policy provider processes the file the policypv.log shows the work that is done. The policy provider log is noisy so the snip shown is heavily edited to pull out the relevant lines. The policy assignment GUID and the policy ID are key pieces of information. Note in the policy ID the package ID and deployment ID are listed. Not all policy ID entries take this form as will be seen shortly.
PolicyPV.log
Looking for software policy and policy assignments that should be created...
Offer CAS2002A has been targeted to all systems.
Successfully created policy CAS2002A-CAS0007F-D67B0F82 and policy assignment {c6f6d475-3c19-4492-8d78-167f1f036220} based on package CAS0007F, program Rich copy and offer CAS2002A
Processing 1 OfferID notifications
Finished checking for deployment CAS2002A
At this stage policy has been created. But where is it stored? Though not obvious from the logs all policy is stored in the database. There are several database tables related to policy as shown.
This discussion will not attempt to explore all of the tables where policy is stored. While it is good to know how policy is stored the information about policy is encrypted in these tables. In addition, there are other tables and relationships that can be in place when trying to back track policy. For an example see my blog post on OSD variable troubleshooting here.
In brief, there are two tables of interest. The first is the Policy table itself. This is where all policy is stored by ID. The policy that was just created is also stored here. Note that not all policy ID’s are the same format. Note also that for each policy ID there is an associated policy body. The policy body is where the policy instructions are stored but as can be seen this policy body is encrypted and not readable in the database.
The policy being created is not enough. The policy must be assigned to specific clients. Assignments are detailed in the policyassignment table.
For discussion of the database tables we will stop here. There are other policy tables but this is enough to understand that the policy is created in the database. As shown in the diagram the next step is for clients to retrieve the policy so focus will now shift there.
A ConfigMgr client by default will check in for policy every hour. The client initiates a policy request through a client component called policyagent. The policy logs on the client side can be busy as multiple policies are requested, handled and updated. The log sections below focus specifically on the policy that was created earlier.
When the client requests policy it sends it’s GUID, NetBIOS name and FQDN to the management point. When reviewing the client logs note that there will be places in the logs where processing is handed off either to other components on the client or to the management point. The log flow below shows this in order but if a single log was reviewed it may not immediately be obvious where handoffs take place. This comes with experience. As mentioned, the snips below are edited. Don’t forget to review the entire log sections as the detail is helpful to fully understand processing that takes place.
PolicyAgent.log
Requesting Machine policy assignments
Requesting Machine policy from authority 'SMS:PR1' ß This is an indication of policy being requested
from the management point.Requesting assignments:
<RequestAssignments SchemaVersion="1.00" RequestType="OnUpdate" Ack="False" ValidationRequested="None"><PolicySource>SMS:PR1</PolicySource><Identification><Machine><ClientID>GUID:B0D3AD49-DBA2-4F74-900C-B7EA5F73B6E3</ClientID><NetBIOSName>WINDOWS8</NetBIOSName><FQDN>windows8.tailspintoys.com</FQDN><SID></SID></Machine></Identification><ServerCookie>2014-08-23 21:19:21.163</ServerCookie><Resource ResourceType="Machine"/></RequestAssignments>
At this stage the client is requesting policies from the management point and processing shifts to the management point. There are two policy related logs on the management point – MP_GetPolicy and MP_Policy. The MP_GetPolicy log records the client request for policy and reply. The MP_Policy log comes into play when the specific policy is actually requested and downloaded by the client.
MP_GetPolicy
MP GP: Initializing anonymous request.
MP GP: GetPolicySendResponseHeaders: Sending response 200 OK
MP GP: GetPolicyDoneWithSession: ServerSupportFunction() returned 0x0
MP GP: HttpExtensionProc:GetPolicyProcessRequest() returned 1
Policy body request from ::1 using Anonymous auth as Anonymous user
Encountered validation failure 87D00239 for Unknown client for policy body download.
MP GP: Query String Before Decode : CAS2002A-CAS0007F-D67B0F82.1_00
MP GP: Query String After Decode : CAS2002A-CAS0007F-D67B0F82.1_00
MP GP: ID : CAS2002A-CAS0007F-D67B0F82
MP GP: Version : 1.00 MP_GetPolicy_
MP GP: Compression : <none>
MP_Policy
CHandlePolicyAssignmentRequest::CHandlePolicyAssignmentRequest(0x00000000014CFF78)
MP PAR --------------------------------------------------
MP PAR Message ReplyTo : direct:WINDOWS8:PolicyAgent_ReplyAssignments
MP PAR Message Timeout : 3900
MP PAR Message Body :
<RequestAssignments SchemaVersion="1.00" RequestType="OnUpdate" Ack="False" ValidationRequested="None"><PolicySource>SMS:PR1</PolicySource><Identification><Machine><ClientID>GUID:B0D3AD49-DBA2-4F74-900C-B7EA5F73B6E3</ClientID><NetBIOSName>WINDOWS8</NetBIOSName><FQDN>windows8.tailspintoys.com</FQDN><SID></SID></Machine></Identification><ServerCookie>2014-08-23 21:19:21.163</ServerCookie><Resource ResourceType="Machine"/></RequestAssignments>
CHandlePolicyAssignmentRequest::ParseRequestBody(): Input server cookie is 2014-08-23 21:19:21.163
MP PAR Request Type : OnUpdate
MP PAR Ack : False
MP PAR Resource : <Resource ResourceType="Machine"/>
CHandlePolicyAssignmentRequest::ParseRequestBody(): ResourceType is Machine
CHandlePolicyAssignmentRequest::ParseRequestBody(): CRC Type is None
MP PAR Identification : <Identification><Machine><ClientID>GUID:B0D3AD49-DBA2-4F74-900C-B7EA5F73B6E3</ClientID><NetBIOSName>WINDOWS8</NetBIOSName><FQDN>windows8.tailspintoys.com</FQDN><SID></SID></Machine></Identification>
MP PAR PolicySource : <PolicySource>SMS:PR1</PolicySource>
CHandlePolicyAssignmentRequest::ParseRequestBody(): MachineID of the Resource : GUID:B0D3AD49-DBA2-4F74-900C-B7EA5F73B6E3
CHandlePolicyAssignmentRequest::Execute(): No Policy Access Check performed. MP is in mixed mode.
MP PAR Output cookie is 2014-08-24 17:39:41.843
MP PAR ----------------------------------------
MP PAR Field value PolicyAssignmentID is {c6f6d475-3c19-4492-8d78-167f1f036220} ß The policy ID being requested.
MP PAR Field value Version is 1.00
MP PAR Field value IsTombstoned is 0 ßIndicates policy is still an active policy
MP PAR ----------------------------------------
MP PAR Field value Body is
<PolicyAssignment PolicyAssignmentID="{c6f6d475-3c19-4492-8d78-167f1f036220}">
<Policy PolicyID="CAS2002A-CAS0007F-D67B0F82" PolicyVersion="1.00" PolicyType="Machine" PolicyCategory="SoftwareDistribution" PolicyFlags="16">
<PolicyLocation PolicyHash = "SHA256:74A48FCB38EEFDCAA1170D4ED80C5222DB9C5B5E8701A5EBC4F31AF4C686A7FD" PolicyHashEx = "SHA1:0A7F51169C9A1A2DC315E68BFD6DD69C61C3DC3A"><![CDATA[https://<mp>/SMS_MP/.sms_pol?CAS2002A-CAS0007F-D67B0F82.1_00]]></PolicyLocation></Policy></PolicyAssignment>
MP PAR Field value BodySignature is E1410CE7B1D11FA05635D6D1E07EE3A848A5D672521EDC23478A73776245D7C5F4DD9728CB50E35DB23297DB995268F9F87118C01DAA23E0238F26C62EBED84DB8C35CFF8257A54CB14F2B592F17FB1A3AB4C28781DB123AEA38984F4DD015A7BE1DB0E95CD7794D490D4652CDCBA938C0B6A3354F1C8ADA14D18E2BD0FE808EFD0B7E1BA4C4AA89DE8BA563A1F43367435A443E2B0763C3D0D932544DC19B15F551BE9E83FDB14513771E343B1FFAD5475A74353B49DA8B27C0048C8CE4B719E618EB698405A54E00FE85A3E7424DFA09731268ECA6A492EF3B614E7C1DABF20C037B64CB3CFE1A182F90A1E0270DA28AE9AEEE9AB9B5C11CE1798687939993
MP PAR Field value HashAlgId is 32780
MP PAR Field value HashAlgOID is 1.2.840.113549.1.1.11
MP PAR ----------------------------------------
CHandlePolicyAssignmentRequest::CreateReply(): 6 rows. ßPolicy reply is created and sent
MP PAR --------------------------------------------------
CHandlePolicyAssignmentRequest::Execute() completed successfully
CPolicyManagerHandler::HandleMessage(): ExecuteTask() succeeded
The management point work has completed and the response is sent back to the client for further processing.
PolicyAgent.log
Processing Machine assignments from 'SMS:PR1'. The new cookie is '2014-08-24 17:39:41.843'.
Raising event:
instance of CCM_PolicyAgent_AssignmentsReceived
{
AuthorityName = "SMS:PR1";
ClientID = "GUID:B0D3AD49-DBA2-4F74-900C-B7EA5F73B6E3";
DateTime = "20140824180349.587000+000";
ProcessID = 2484;
ReplyType = "Delta";
ResourceName = "WINDOWS8";
ResourceType = "Machine";
ThreadID = 2272;
};
Successfully submitted event to the Status Agent.
Schema Version is '1.00'.
Total 6 PolicyAssignment(s) found. ßIn this check 6 policies were found. We are only tracing one of them here.
Compiling Policy CAS2002A-CAS0007F-D67B0F82:1.00:SMS:PR1
Policy 'CCM_Policy_Policy5.PolicyID="CAS2002A-CAS0007F-D67B0F82",PolicyVersion="1.00",PolicySource="SMS:PR1"' successfully compiled ßPolicy is compiled at this stage but not yet active.
Policyevaluator.log
Policy state event signaled
Policy state for [CCM_Policy_Policy5.PolicyID="CAS2002A-CAS0007F-D67B0F82",PolicyVersion="1.00",PolicySource="SMS:PR1"] is currently [DownloadStarted;{CDE010CC-A78F-4A47-896B-F027A2379A21}]
Policy namespace \\.\ROOT\ccm\policy\Machine\ActualConfig will be updated in 120 seconds ß Notice that the namespace for policy that is active is called ActualConfig. The staging namespace is called RequestedConfig. Those namespaces are shown below.
Updating policy CCM_Policy_Policy5.PolicyID="CAS2002A-CAS0007F-D67B0F82",PolicySource="SMS:PR1",PolicyVersion="1.00"
Locked RequestedConfig successfully
Applying policy CAS2002A-CAS0007F-D67B0F82 ßHere the policy is being applied.
A good way to review the settings in WMI is to use a tool called WMI Explorer. This is a tool written by Vinay Pamnani who is a colleague at Microsoft. Before WMI Explorer WBEMTest was the tool of choice. With WMI Explorer I’m sold – great tool. You can find the tool here.
Think of the RequestedConfig namespace as a sort of staging area where policy can be checked prior to putting it into production. Very similar to how a transaction log works in SQL.
The ActualConfig namespace shows those policies that are active on the client.
And there you have it. Policy processing is complete and the policy is now active on our client. Once the policy is active there are other components that will notice it and begin to implement.
This article describes the process of policy processing and while the raw details are shown in most cases it will not be necessary to review detail at this level. If in depth review of the policy processing namespaces in WMI on the server and/or client is needed be sure to review the various policy tools in the ConfigMgr 2012 resource kit. Such tools include Client Spy and Policy Spy.
Policy Tracking/Client Health
One other small tidbit. In ConfigMgr 2012 policy requests from each client are tracked as part of client health. When a client requests policy a .POL file is created in polreq.box. This file is processed by the client health manager (chmgr.log) and the time of the request stored with the machine record. The polreq.box with a .POL file in it is shown along with the sample contents of this file. The policy portion of client health data for the test system is also shown.
Comments
Anonymous
August 25, 2014
thanks Steve.would like to see more internals (technical Deep Dive) like this ;)Anonymous
August 25, 2014
Awesome Post Steve!! Thank you for sharing :) -Satyam SrivastavaAnonymous
August 26, 2014
Very Nice and detailed information Steve, thanks a lot for sharing.Anonymous
September 10, 2014
Excellent blog...great information. Thanks :)