DZ's guide to Domino 6 Policies

Preface
I remember back in both R3, R4 and R5, the life of a non-policy Domino-environment. Setting up, configuring, administering and maintaining clients were, even if we didn't admit it, a living nightmare. Working as a Domino administrator, you probably wished that you could administer clients as your collegue, the M$-admin. Microsoft have for years been able to administer and maintain client settings using simple policy settings, but as a Domino administrator, you usually had to buy some 3rd party tool or have good developing knowledge and skills to do basic maintenance tasks. These could be to change some settings on a cilent computer, like the ECL, user preference settings, change notes.ini settings or let's not forget about the upgrade or client installation hassle. So, when Lotus finally announced that they were going to support policies in Domino 6, I experienced a kind of hallelujah atmosphere.

This article
This article assumes that the reader already knows some of the basics about policies. This article will cover some basic information, issues that I have discovered with policies and suggest workarounds for limitations that exist in the current implementation of policies in Domino 6. For more general and supplementary information, please refer to the Administraion Help Database.

Basics
Policies are a technology for "no-client-touch" maintenance. You will be able to install, upgrade, configure and maintain your clients without running around your office building. You should be able to do everything from one administrator client and change your current administration dramatically. Though, do not forget to read this article completely, as there are quite some gotchas and misunderstood features and areas of use.

There are 5 different types of policies:

• Archiving
  - let you control how archiving should work for your clients
• Desktop
  - let you control how the desktop and the client environment should work and look for your clients
• Registration
  - let you control how the registration process should work. This could be mailfile settings, certifier information, location of id-files, password options and other things.
• Security
  - let you control the user security settings. This includes password management (syncronization, change intervals, grace periods etc), ECLs and other things.
• Setup
  This policy is very similar to Desktop policies but does only apply for the first time setup of the client. Meaning, for existing clients and users, this policy will not apply, even if there is a change in the policy. Don't be confused if you see that this setting document have about the same settings as the desktop settings document. They are very similar but work in different ways.

To create a policy, you create set set of rules-document. These are called policy settings documents. A setting document alone has no effect on the environment - it has to be connected or included in a policy document. A policy document can consist of one settings document of each type, or less. Meaning, you can have a policy document consisting of only one registration setting, or you could have a policy document consisting of one setting document pr type (archiving, desktop, registration, security, setup). Each of the policy documents define a set of default values that will be applied to users or groups of users. When a policy has been deployed, one can easily change it and then get it automatically re-deployed to the same set of users, or addionals. Both policy and settings document are created and maintained in the Domino Directory, and can easily be accessed using your Administrator Client, People & Groups tab. For additional information about what the different settings document consist of - refer to the Administration Help Database.


Explicit and Organizational policies
Settings document are the basics and data documents for profile documents. Profile document are again devided into two types of documents, explicit and organizational policies.

Organizational policies (O-Policy)

An organizational policy will be applied to all users within an organizational unit. If one created a O-Policy with a name of "*/NE/Sales/ACME", all users certified within that organization would be effected. If a user is recertified to another organization unit, "Rune Carlsen/Marketing/ACME", the user will automatically have the corresponding O-Policy applied ("*/Marketing/ACME").

Explicit polices (X-Policy)

An explicit policy will apply to "explicit" users or group of users. These "explicit" users are not connected to a certifier in any way and will only be applied to the users the administrator manually selects. If the SALES department in ACME hires people from time to time (consultants or others), they might want to apply different policies for these people. If these users initially were certified with the "Sales/ACME" certifier, an explicit policy could overrule the settings in the O-Policy. X-Policies can be applied in 3 different ways; during registration of the user, changing the users person document or using the administrator client tool - assign policy (for the marked user(s)).