Debbie Lynd and Ted Niblett

reprinted from THE VIEW, November/December 2002. www.eVIEW.com
©2002 THE VIEW. All rights reserved. No portion of this publication may be reproduced without written consent.

Explicit Policies

There are times when a group of settings should be customized for different users across organizational boundaries. This is precisely when explicit policies come in handy. Explicit policies are a little more work to maintain than are organizational policies, because they are not automatically assigned based on the organizational hierarchy. Instead, administrators must assign them in a user’s Person document, just as they did for setup profiles in R5. However, unlike setup profiles, you can assign only one explicit policy to a user.

Explicit policies can also have a parent/child relationship. You can create one explicit Policy document (the parent) to handle the majority of users within a certain group and another explicit Policy document (a child) to impose some different settings for other users in the group. The child explicit policy would inherit most settings from the parent. The ABC Corporation, for example, has contractors who span organizational boundaries. The contractors should have an ID that expires in 6 months as opposed to the rest of the organization, which defaults to 2 years. To register the contractors using policies, the administrator must create a new explicit policy for those users.

Note!
Settings are applied in order of increasing specificity, beginning with the most general root ('*'), then organizational policies for O, OU1, OU2, and so forth, in that order, followed by explicit policies. That suggests — correctly, as it turns out — that the highest-level explicit policy is considered a child of, and can inherit settings from, the lowest-level organizational policy in a user's policy tree.

To create an explicit policy for the contractors mentioned in the previous example, begin by creating a new Registration Settings document, naming it “Contractors,” and defining the certificate expiration for 6 months. The mail server setting and the group settingwill be inherited. Then, open a Policy document just as you did when creating an organizational policy. Name this document “Contractors” and select “Explicit” as the Policy Type.

Registering a New User with the Explicit Policy

Because an explicit policy is not related to a certifier, the explicit policy type must be selected from the Register Person screen, as shown in Figure 25 . Select “Contractors” under the Explicit Policy’s drop-down list to have the settings for a contractor come from the Contractors policy; all other settings will be inherited or enforced from the parent policies (organizational).

Figure 25 -- Selecting the “/Contractors” Explicit Policy for a User

Assigning an Explicit Policy to an Existing User or Group

You can assign explicit policies to multiple users or groups by using the Assign Policy tool in the People & Groups tab in the Domino Administrator client. By selecting multiple Person documents or a Group document in the People or Groups view, and choosing “Assign Policy” from the task list on the right, you can choose from any existing explicit policy as displayed in Figure 26.

Figure 26 -- Assign an Existing Explicit Policy

Exception Policies

Here there be dragons! (5) An exception policy is a policy document that ignores all settings from any ancestor policies . Proceed with care! If you create too many exception policies, it can become impossible to manage all those exceptions.

Why would you use an exception policy? Keep in mind that organizational policies will be automatically assigned to users. There may be users who have completely different settings than have been defined within the organizational boundaries. For instance, there could be a group of users who are being created for testing purposes, or a group of users who are created for use in a classroom environment in which the organizational settings may not apply. In this case, an exception policy may be the way to go. Just remember that exception policies are not something to use on a regular basis.

5 As medieval European maps used to say of unexplored regions. For more information, see www.maphist.nl.

To create an exception policy, open the Administration tab of the Policy document and check “Ignore settings from ancestor policies” in the Exception Policy field, as shown in Figure 27.

Figure 27 -- Create an Exception Policy

The Effective Policy and How to View It

An effective policy is a compilation of all the settings in each of the policies assigned to a user. It is an aggregate of the organizational policies (that are implicitly assigned to users) and the explicit policy (if one is assigned).

An exception policy is a policy document that ignores all settings from any ancestor policies. Proceed with care! If you create too many exception policies, it can become impossible to manage all those exceptions.

Note!
It's possible for a user's effective policy to be a composite of settings defined at all different levels of a policy hierarchy, receiving the benefits of inheritance and enforcement. For example, even though a user may be assigned only one explicit policy, such as /Temp/IT/ABCCorp, the user may receive a collage of settings from the three policies in the hierarchy: /ABCCorp /Pace/ ABCCorp, and /Temp/IT/ABCCorp.

From the People & Groups tab, select a person, then select “Policy Synopsis.” The Policy Synopsis dialog box (Figure 28 ) provides options for creating a synopsis document that shows either summary or detailed information. The Summary Only report displays only the policies that are assigned to a user; the Detailed report shows all of the assigned settings. The database in which the document is stored can reside locally or on a server. By default, the filename is policysyn.nsf. You can see a sample policy synopsis in Figure 29.

Figure 28 -- The Policy Synopsis Dialog Box

Figure 29 -- Sample Policy Synopsis

You can also generate the policy synopsis from the Configuration tab, as shown in Figure 30 . This tab provides an additional field for selecting the user name. (From the Configuration tab of the DominoAdministrator client, you can display policies “by Hierarchy” or “by Settings.” From the hierarchy view, you can also display the policy hierarchy by domain or by user.)

Figure 30 -- Viewing Policies from the Configuration Tab

Planning for Policies in Notes/Domino 6

Implementing policy-based management requires a structured approach to create a maintainable set of policies. Before you create your first policy settings document, create a planning document. This document should start with the organizational hierarchy and apply the settings for each of the categories (Registration, Setup, Desktop, Security, and Archiving) to the organizational levels.

Follow these guidelines:

1. Start at the top. Determine which settings apply to everyone within your organization and apply those settings to an organizational policy with Enforcement enabled.
2. Create a map of all the variable settings and the groups to which they apply.
3. Where possible, apply those settings using the organizational structure — create a policy for the organization “O” that includes all the settings that apply to everyone and follow that with policies for the OUs within the organization.
4. Create explicit policies for the groups that cross organizational boundaries.
5. Most importantly, remember to keep it simple. The more complexity that you add to your policy implementation, the more maintenance work you make for yourself down the road. And one of the main goals of policy-based management is to reduce the number of administrative tasks, and therefore improve the administration and performance of Domino.
6. Think about when settings are applied. Registration settings apply only to the registration task of the Domino Administrator client. Setup settings apply to the initial client setup; they are applied prior to bookmarks being added to the desktop. Archive, security, and desktop settings are applied by dynamic configuration, when a client connects to the home server for the first time during a session. Archiving is invoked by the command Compact –a (or Compact -A for server archiving), and it is automatic for scheduled client-based archiving.

FAQs about Timing

Q: When should I begin planning my user- management policies?

Now would not be too soon. Getting it right will take time, and you want to be prepared to implement your policies when you upgrade.

Q: At what point in the upgrade process should I implement policies?

As soon as you upgrade your first server! Policies won’t be applied to existing users until they have upgraded to Notes 6 clients, but you’ll be ready to go as soon as they are.

Caution! Don't forget to disable setup profiles in Person documents when you upgrade your clients. Make this a step in your upgrade plan!

Tips and Tricks

You can implement policies for archiving mail databases to servers as soon as servers are upgraded.

Remember: mail archiving is not just for Notes clients! It will work on any mail database that is being archived on a server. You should also consider adding an archive server to offload all those huge mail archives from your production servers. Don’t forget to create a program document on the mail server to invoke archiving with Compact –a (or Compact –A for server archiving).

You can implement registration and setup settings as soon as the server is upgraded. Any new users can then be registered and installed using the new settings. Keep in mind that even though registration settings simplify the registration process by providing defaults, an administrator can still change settings on the fly during the registration process.

For company-wide settings that should never be changed, enable “ Enforcement” at the organizational (“O”) level.

When implementing desktop settings, remember that users can modify any of those settings in their user preferences after you have seamlessly “pushed” ; them to their client. The only time that a desktop setting will change again is if you modify the Desktop Settings document.

Conclusion

Touring the settings that can be managed with policies, as we have done here, is an eye-opening experience. The scope of just how much centralized control administrators have over users’ client settings in Notes 6 is impressive.

We think that the ability to centrally manage ECLs is reason enough to implement policies. And being able to set standards for registration and client setup means that you don’t have to remember all the settings for the different groups that you are certifying. But by far, the best thing about policies is that you can use them to set up Smart Upgrades and Mail Upgrades, which means that you never have to touch another desktop again!

Ted Niblett abandoned an entry-level accounting job for the software industry, joining Lotus Technical Support shortly after the release of 1-2-3 3.0. After ten years in Support and Consulting, he’s now Product Manager for the Lotus Domino Server. In his spare time, Ted is learning how to use the heart-rate monitor his wife gave him as a birthday present.

Debbie Lynd is Content Director for THE VIEW's conferences and seminars and has been working with Notes and Domino for the past ten years. She is a Certified Lotus Instructor (CLI) and a Principal Certified Lotus Professional (PCLP) in System Administration and Application Development. Debbie is also co-author of the book “Lotus Notes and Domino R5 Development Unleashed (SAMS),” which is currently being revised for release 6. She will soon be on the road presenting at THE VIEW's Lotus Notes & Domino 6 Upgrade Seminar, which should be arriving in a city near you soon! You can reach Debbie at Debbie@eview.com

Want to learn a lot more about ND6 Policy administration?
Debbie Lynd, co-author of the above article on Policy-Based User Management, is also a top-rated VIEW speaker and she's presenting a session titled Improve Client Management with Policies in ND6 at THE VIEW Notes/Domino 6 Upgrade Seminar. This session is just one of the real-world technical training sessions at this 3-day seminar that's guaranteed to shorten your learning curve and prepare you to roll out Release 6 across your enterprise, implement key features, and train your users. This event is being held this Spring in 6 cities worldwide: New York City London Copenhagen Chicago Washington DC Sydney March 31-April 2 April 14-16 May 12-14 June 16-18 July 14-16 August 11-13 Click here for more information! “I gained valuable knowledge that will save me a wealth of time and stress in developing a project plan, identifying critical system and environment preparations, and creating detailed testing requirements.” — Gary Wade, Lotus Notes Administrator, City of Orlando				Both authors of the above article on Policies will be diving further into the subject at ADMIN2003, THE VIEW Notes/Domino Administration Conference. Their sessions include The Building Blocks of Policies in Domino 6 and Leveraging Policies to Manage Users, plus a hands-on Policy Implementation Lab. Las Vegas, April 30- May 2, 2003 These Policy sessions are part of the End User Management Track, just one of 7 tracks offering more than 60 technical sessions. Other tracks dive deep into: Messaging Performance Security Collaboration Server and Database Admin Web & Wireless topics Plus there's on-site certification testing, ask-the-experts sessions, networking opportuinities and much more. ADMIN2003 is guaranteed to improve your skills and increase your company's Notes/Domino ROI, or your money back! Click here to learn more about ADMIN2003!