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.

For Details Click Here

Thanks & Regards,
Haresh Hirani
Follow me: Twitter @hirravi1