ZfD Group Policies HowTo

One of the most important things to remember when working with Windows Group Policies in Zenworks is to remember that it is Microsoft technology you are dealing with, not Novell technology. Zenworks only gives you the ability to deploy Group Policies to workstation with out a Windows Domain. It is also important to be able to tell the difference between a Zenworks Policy and a Group Policy. They arn't the same thing, so don't confuse them.

For workstations to obtain a policy from the network, it requires the Group Policy files to be available in a network directory available to the users who will require to download it. The Group Policy is NOT stored in eDirectory like previous versions of Windows policies were (Extensible and Win9x based policies were stored in eDir). In Windows Active Directory, the Group Policy is stored in the directory, but this is only because it is Microsoft Technology. Novell was not given the proper API's to do the same thing, so to accomplish the goal of deploying Group Policies in Zenworks, the actual policy files need to be stored in a common location.

The way the policy creation works is when you specify the network location for the Group Policy files, and click the edit button. ConsoleOne will make a backup copy of your workstations local policy then it will bring up the Microsoft Management Console to edit your current local policy. As you make changes to the policy you will see those settings take affect on your local PC. When you are done editing the policy and close the MMC, ConsoleOne will copy the current local policy to the specified Group Policy location and then restore the backup policy created when editing was initiated. This will clear out any Group Policy settings made during the edit session.

[small]Note: It has been observed on a few occasions when the backup of the local policy does not recover properly, leaving the Group Policy that was just edited on the local PC. It is because of this possibility it is recommended to NOT use a production PC to edit policies. It is recommended to use either a test PC that you can restore an image to if this happens, or to utilize VMWare to edit policies. If an issue occurs in restoring the local policy in a VMWare guest PC, then an administrator can utilize the snapshot / revert functions to recover from this type of issue.[/small]


Creating your policy:

[ol]
[li]Plan your policy design; choose what kind of policies you want to create and how many you will need to create. It is common to create three levels of a policy.
[blue]Level 1 û Restricted user / workstation[/blue], this policy is the most restrictive and has many features of the OS locked down.
[blue]Level 2 û Common user / workstation[/blue], this only has system configuration lock downs, no limiting lock downs on application usage and network usage.
[blue]Level 3 û Admin user / workstation[/blue], this policy has no lock downs and will unlock any PC it is used on.[/li]

[li]Create a directory structure to store your policy files into. If you use the above example, you will create three directories for XP and three for 2000. Develop a naming convention to use for these directories to minimize administrative confusion if others need to edit your policy. Ensure users have read / file scan rights to these directories.[/li]

[li]Create your most restrictive policy first, enabling all lock down you desire to have on a restricted user or workstation. Once done, you will need to follow a chaining process to ensure continuity across your policies.[/li]

[li]On the Common user policy, go as far as editing the policy in MMC, but as soon as you open the MMC to edit the policy, close MMC. Once closed, browse to your restricted policy directory and copy all files from the restricted policy directory to the common policy directory, over write all files doing this.[/li]

[li]Go back into your Common policy properties in ConsoleOne and edit the Common policy again, you should now see all the settings you did in the restricted policy now in the common policy.[/li]

[li]Go through the common policy and reverse any settings you wish a common user to be able to perform. Doing his will ensure if a user is in restricted, then moved to common that all restrictions are removed.[/li]

[li]Repeat steps 4 through 6 for your admin policy, only this time, use the Common policy files as your base.[/li]
[/ol]

Following this will guarantee proper flow of your policies and ensure proper unlock are applied to the user or workstation when the policy is downloaded.


Tips

[ol]
[li]Each policy requires it's own directory. Do not try to store policies from different policy objects into the same directory. They will over write each other.[/li]

[li]Make your life easier, use UNC mappings only. When you first set this up and you browse for policy locations, you more than likely will get done through a drive mapping. Change this to UNC before you ever deploy it. You never know (or might know) that not everyone in your network has the same drive mappings[/li]

[li]Create the policy from a workstation running the same version and service pack level of the OS the policy will be deployed to. If you want to deploy policies to XP SP1 workstations, use an XP SP1 admin PC. If you want to deploy policies to 2000 SP3 workstations, use a 2000 SP3 admin PC. This may seem to be a small thing to worry about, what problem could you face if you used an XP SP2 admin pc to make a policy for XP SP1? Many of the function will not work. Microsoft made some big changes to the Grop Policy in XP SP2, so there are setting that XP SP1 does not support. SO you will set them and wonder why they arn't taking affect, this could be why.[/li]

[li]Documentation options for policies suck. No one has taken the time to write a decent tool to document these things into somthing a person can hold onto, or even compare. There are some great GroupPolicy managment tools out there, but from my research, the documentation just isn't there (plus if your using ZfD to deploy GPO's then you more than likely do not have a domain, so any GPO tool you find may end up being useless). There is a tool called GPRESULT that comes with Windows. By properly executing this on a PC that has the policy you built applied to it, you can document the applied policy [/li]
[/ol]