2.3 Policies 

Table of Contents

Have you looked into Domino policies yet? If not, then you have not yet seen how powerful policies can be. Since there are many reasons to use a policy and a number of policy types, you may wonder how you should get started with policies.

Introduction to Policies

The purpose of a policy document is to “assign” settings to users. There are a number of available setting types in Domino 8.5.x. including Registration, Setup, Desktop, Security and more. For a list and definition of each setting type refer to the Domino Infocenter Policies topic.

There are two types of policies:

• Explicit
• Organizational

An organizational policy is a policy that will be applied to the entire organization or organizational unit. For example, if you work for Fictional Software Company A, your user name may be User One/IT/Company A. In this example you could create an organizational policies for */IT/Company A or */Company A.



An explicit policy is a policy that is explicitly applied to a user. This could mean that the policy is defined in the user’s person document or is assigned to the user within the policy document itself. When assigning a policy to a user or group within the policy document itself, the policy is then considered to be a dynamic policy. For more information on dynamic policies, you can refer to the Domino wiki article How Dynamic Policies can reduce your administration workload. For more information on assigning policies, refer to the Domino Administrator help topic Planning and assigning policies.

Using Policies to Standardize Secure and Simplify Your Environment

Policies can be used to simply resolve a number of common problems.

Problem You Need to Solve	The Policy Answer
Enforce corporate security standards such as · Changing passwords every x days · Password minimum length	Organizational security policy
Security risk from having Notes.id files stored on a network drive with their default password	Organization security policy with an assigned ID Vault for secure ID file storage
Enable favorite calendaring features by default for users – for example: · Displaying new and unprocessed calendar and to documents in the calendar · Automatically showing cancelled meetings as cancelled in the calendar · Automatically checking for conflicts when adding appointments to the calendar	Organizational mail policy
Configure server side archiving for all users	Organizational archiving policy
Ensure all administrators use consistent settings when registering new users	Organizational registration policy
Get the new sales application replicated locally to your sales team.	A dynamic desktop policy assigned to the sales team.
Configure default settings for all new Lotus Notes Install	Organizational setup policy
Define default settings for mobile users	A dynamic Traveler policy assigned to users as they purchase a new mobile device supported by Traveler
Automatically upgrade mail file design when a client is upgraded.	Organizational desktop policy
Set a NOTES.INI parameter at the client for a remote user	Explicit desktop policy

The list could go on and on. Policies can be a Domino administrator’s best friend or biggest headache. Here are some definitions, hints and tips that will help you succeed with your policy roll out:

• Test first! Before rolling out a new organizational policy, create an explicit policy and assign it to a small set of users. If it goes well, then create your organizational or organizational unit policies for the rest of the employees.

• Create policies based on your organizational structure. A policy implementation of managers, employees and contractors will be too vague to work in most cases.

• Assign policies via groups or individually within the policy document, policy assignment tab rather than explicitly in the person document. Assigning policies in the person document is time consuming and difficult to manage.

• Create exception policies where needed for executives. Be sure to include a detailed description to help you identify the policy. It is also recommended to hide the group document from the general user population using a readers list. For more information on hiding group documents, refer to Limiting access to group documents section of the Mass mailings article.

• When learning policies for the first time, the language used can be confusing. For example, there is no option to create an “organizational security policy”. What does that really mean? A policy of type organizational where the policy name matches your organization, for example */organization, which has a security settings document applied as shown in figure 3.

• A “desktop policy” applies to all location documents. If you only want to apply a specific setting to a single location you should still make this change manually.

• There is no “undo” with policies. Once a policy has been applied, you can change the policy to push out a new value, but there is no way to choose “put it back to the original value”.

• When using policies to push replica databases or bookmarks to clients, never delete the database on the server without removing the database entry from the policy. As a safety net, always create database redirects when you delete a database or template to prevent a problem with a policy pointing to a non-existent database as shown in Figure 4.

• Know your environment. Policies will behave differently depending on the client version being used. This would be expected as many new functions have become available with the later client versions. Be sure your clients can support the function you want to roll out.

• A policy may be implemented by a number of processes. Archive policies are used when running compact –a or compact –A. Mail policy values are rolled out by the administration process (adminp) every 12 hours or immediately with the tell adminp process mailpolicy command. A setup policy is read and used during initial client setup. The remaining policy setting types are implemented by the Lotus Notes client’s dynamic client configuration (dcc). You can be certain dcc is running if you see the entry Notes configuration settings have been refreshed in the status bar of the client.

• Policies are stored within the user’s Contacts database (names.nsf). This database should be using the latest design to prevent problems when using policies.

• When using a desktop policy to control settings within iNotes you must also have a mail policy. This is due to the fact that it is the job of the adminp task to update the iNotes profile document from the desktop policy and adminp will only runs when that process when a mail policy is present.

• When using a How to apply value of Set initial value in a settings document, the value you are setting will be pushed to the client when the policy is first saved and any time the policy is modified or saved.

• Policy signatures are important. Policies will only be applied and used when signed by an administrator with proper authorities and a valid key. Thus, it is recommended that you sign your policies with a generic administration account or resign policies before the administration id can expire or when they administrator leaves the company. To see who is the signer of a policy and settings documents using the Policies and Settings views in the Domino Administrator client as seen in Figure 5. By placing the policy or settings document in edit mode and saving it the signature will be updated with your signature.

For a detailed description and an example of the different policy settings, refer to the policies self training modules or review the Domino Policy Blog.