What is a policy architecture?

Policy architecture is a collection of policy documents, with associated settings documents, that are applied to a group of users. In order to create a policy document, you first need to create the settings to be applied to a particular policy. Next you need to understand there are two types of policy documents; explicit and organizational.

What is a Policy Architecture? A policy architecture is a collection of policy documents, with associated settings documents, that are applied to a group of users. In order to create a policy document, you first need to create the settings to be applied to a particular policy. Next you need to understand there are two types of policy documents -- explicit and organizational.

What is an Organizational Policy? An organizational policy is one in which all settings are applied, or inherited, by all members of a specific organization. Using this approach allows you to automatically apply settings based on the organization unit in which users are a member.

For example, let's say your company -- called ABC -- retains both permanent employees and part-time interns, and that all registered users belong to either the /employee or the /intern organization unit. You could then create an organizational policy where all users in */employee/ ABC automatically inherit its settings. You could then apply a second policy that would apply to all users in the */intern/ABC organizational policy.

By creating separate policies, you allow employees to have greater flexibility and control over their Notes client environment and, conversely, restrict the ability of part-time interns to modify their environment settings. Thus all employees are governed by a common set of configuration settings based entirely on the organizational unit (which is defined when the user created or registered in the Domino Directory).

The organization-based policy is generally considered to be the easiest method for managing client workstation settings. Furthermore, this approach provides flexibility to accommodate changes to organization structure. So, if a part-time intern graduates from college and subsequently becomes a permanent full-time employee, all you need to do is update the user's organization unit. The user will then automatically inherit the new policy settings the next time she authenticates with her Domino server (following the status change to the organization unit value).

Figure 15 depicts a sample organizational policy for full-time employees. You'll notice that the settings documents all start with emp_ to help identify the settings that are specific to employees.

logging tab
Figure 15. A sample organizational policy for all full-time employees

An organizational policy for the intern employees would look similar to this form except the policy name would be */intern/ABC and a different set of settings documents would be defined and selected. Using this same approach, you could prefix all intern settings documents with intern_ to distinguish them from the employee settings.

WARNING: Do not include spaces in the policy name. Domino will interpret the space as a separate policy. In other words, Domino will consider the space to be one policy name and the characters immediately following to be a second policy name. As a best practice, the policy name should contain characters and no spaces. Also note that all policy names must be unique. Duplicate policy names can cause Domino implementation problems. For additional information, you can view the technical bulletin posted on the IBM Web site.

What is an Explicit Policy? An explicit policy, on the other hand, is one in which the policy applies only to specified users or user groups. Using this approach you must explicitly define the users who are associated with the policy. While it's true this approach does require more time and effort to administer, the policy does have advantages. To be specific, this type of policy is frequently used for users who require custom configuration settings. It can also be used for groups that encompass multiple organization units.

Similarly to the organization policy, an explicit policy will contain a collection of settings documents. However, using the explicit policy, you must perform additional setup in order to implement it. Users automatically inherit the settings as members of an organizational policy. However, when creating an explicit policy you must take an additional step and update users' Person document with the assigned policy. For those of you familiar with "Setup Profiles" in version 5, this process is similar to that one; however, only one explicit policy can be assigned in the Person document.

For example, let's revisit company ABC. We've already learned it has both full-time employees and part-time interns. Continuing with this example, the company also employs a number of subcontract employees. These specialty employees typically come onsite for a short duration as technical experts in a certain field. The contract employees may reside in multiple organizations. Using the explicit policy you could manage the contractors and customize their settings

Tip: Using an explicit policy you can create a custom welcome page when users first launch the Lotus Notes client. To learn more about this feature and for step-by-step instructions, you can read the article "Rolling out a Corporate Web Welcome Page" by Cara Haagenson. This article is available at the DeveloperWorks Web site.

Most companies will utilize a combination of both organizational and explicit policies. Organizational policies are automatically applied settings based on the organizational unit. Explicit policies, on the other hand, are created in advance and assigned as part of the user registration. The combination of these policies provides a centralized approach to managing and controlling Lotus Notes client settings.

As discussed earlier, there are six primary settings documents that you can define for a policy. These settings include Setup, Registration, Desktop, Mail, Archive, and Security. The Setup and Registration settings are applied one time. The remaining are dynamically applied.

Did you know? Policy documents are hierarchical in nature. This means that some settings trump other settings based on the Inherit and Enforce options and the parent-child relationship.

Survival guide for Lotus Notes and Domino Administrators

 Home: Introduction
 Part 1: What are policies?
 Part 2: How are policies implemented?
 Part 3: What are settings documents?
 Part 4: What is a policy architecture?
 Part 5: Creating settings and policy documents
 Part 6: Creating policy documents
 Part 7: Registering a new user using an explicit policy
 Part 8: Assigning an explicit policy to an existing user
 Part 9: Using exception policies
 Part 10: Viewing your policy settings

Survival Guide for Lotus Notes/Domino Administrators This chapter is an excerpt from the book, Survival Guide for Lotus Notes and Domino Administrators, authored by Mark Elliott, published by IBM Press, March 2009, ISBN 0137153317, Copyright 2009 by International Business Machines Corporation. All rights reserved. For more info, please visit the publisher site. Safari Books Online subscribers can also access the book at safari.com.

Click here for the chapter download.

Dig Deeper on Lotus Notes Domino Administration Tools

  • Favorite iSeries cheat sheets

    Here you'll find a collection of valuable cheat sheets gathered from across the iSeries/Search400.com community. These cheat ...