It surprises me how few vendors use Active Directory Group Policy as a mechanism to centrally manage and deploy policy settings for their Windows based products, and instead build their own backend infrastructure for this purpose. I could rattle off a long list of benefits, including hierarchical management, a strong security model that includes delegated administration, built-in replication, stability and scalability, to name but a few.
Even if you could build your own deployment mechanism that matched or even surpassed the features in Active Directory Group Policy, there would still be one over-riding reason not to do so ... most organizations already have an Active Directory in place, and they have carefully designed and built an infrastructure that is suitable for their environment. So why provide them with a proprietary system for your product that requires additional servers and all of the dedicated training, management and support time that is required to set up and maintain this new infrastructure.
Dispelling the myths about AD Group Policy
First of all, it’s worth dispelling a common misunderstanding at this point. Active Directory Group Policy does not mean that your product is limited to the registry based policy settings provided by ADM and ADMX files. Group Policy is completely extensible, and you can develop a management console that plugs directly into the Group Policy Editor, which can save data in any format to the Group Policy Template (GPT) portion of a Group Policy Object (GPO). The GPT is stored on SYSVOL and therefore requires no change to the Active Directory schema. Put simply, your product can save a structured set of policies in an XML file, or any other format that takes your fancy, as opposed to being restricted to simple registry based policy settings.
Group Policy efficiency
Another common concern is the efficiency of using Group Policy. Understanding a little more about the inner workings of Group Policy, helps to dispel this concern too. Group Policy is a “pull” technology, and each product must implement a Client Side Extension (CSE), which resides ... yes, you guessed it, on the client computer. Each CSE is notified when there has been a change to one or more GPOs that are of interest to the client or logged on users. It is the CSE that is then responsible for downloading its policy settings from Active Directory, as GPOs are not just transferred in their entirety to the client computer. In other words, if a product’s CSE has not been installed on a client computer then the policy settings for that product will never be downloaded from Active Directory. It is an efficient mechanism, and the versioning of GPOs ensures that GPOs only need to be processed by a CSE when there has been a change to the policy settings or a change in the GPO precedence rules.
I should also point out that organizations who use Novell eDirectory need not feel left out either, as ZENworks supports Group Policy too, and for smaller companies with no directory services in place, there is always local Group Policy.
