10 Critical Policies and Other Tweaks to Boost Notes Performance

10 Critical Policies and Other Tweaks to Boost Notes Performance Andy Pedisich Technotics

What We’ll Cover … • Taking a run through types of policy settings documents • Inheriting and enforcing policy settings • Applying policies to users and groups • Nailing down the 10 policies every domain should use • Troubleshooting policies • Wrap-up

There Are Two Important Components of Policies • Policy settings documents • They define the configuration of what you are managing • Policy documents • Policy documents control how the policy settings are applied throughout your user population • Organizationally to all or part of a certificate hierarchy • To individual users explicitly • Dynamically to members of a group • They can specify only a single policy settings document per category

A Policy Document with Policy Settings Specified

Components of Policy-Based Management in Lotus Notes • Policy settings are configurations you want to apply to your users • These settings are organized by functionality • For example, all registration settings are in one settings document, while archive settings are in another document • Policy documents connect the settings documents to users and determine who gets what settings • They can follow the organizational hierarchy • They can be applied to specific users or groups • So that you can apply settings across organizational boundaries • This makes them flexible

10 Types of Policy Settings Documents • 1. Registration settings documents • Predefine defaults to all user registration options • 2. Set up settings documents • You probably won’t use these • 3. Desktop settings documents • Controls settings in the user environment • 4. Mail settings (new in ND7) • Control user mail preferences • 5. Security settings • Controls client Execution Control Lists (ECLs), password management, and ID Vault settings and more

10 Types of Policy Settings Documents (cont.) • 6. Archive settings • Applied to the server-based mail database • 7. Traveler settings (new in 8) • 8. Activities settings (new in 8) • Apply only to Lotus Connections server running Activities • 9. Productivity Tool settings (new in 8) • Controls the availability and behavior of the Symphony Productivity Tools within the Notes environment • 10. Roaming settings (new in 8.5) • Controls roaming configuration for users who keep their roaming files on a file share

Policy Settings You Will Use Often or Rarely Use at All

An Issue You Might Be Experiencing • During some upgrades of the Domino directory design, we’ve seen instances where the “newer” Release 8 policy settings document were missing • Or there were duplicates listed • The missing ones prevented you from taking advantage of these new policies

Caused by Extra Docs in the $PoliciesExt View • As it turns out these “extra” or “missing” policy settings were caused by duplicate or missing documents in the $PoliciesExt view • Access this view using Ctrl-Shift as you click the Go To… menu option

IBM Keeps the Newer Policy Specs $PoliciesExt • If you have duplicates, remove one of each type of document • If you have no Release 8 settings available, copy the four from the $PoliciesExt view in PUBNAMES.NTF into this view and the policy settings will appear in your menu system • I think IBM took this approach so they could dynamically add more settings rather than hard-code them into the client • Sometimes it breaks during the redesign

Building Policy Settings • Policy settings are configurations that will be applied to users • This settings document configures the Notes client to display the sidebar and not hide any default sidebar components • Policy settings documents hold dozens of configuration settings • Some are fields that hold values you must provide • Some have drop-down boxes, some are check boxes

Inherit and/or Enforce the Configuration Settings • These two checkboxes are the most misunderstood by almost everyone who deploys them • It’s critical that you understand them • They change the way policy settings are applied

How Enforce Changes How Policies Are Applied • Enforce does not do what I thought it would do at first glance • I thought it would force someone to have a certain setting and that they were unable to change it • Enforce actually means – take the setting from an upper org level and make it the same all the way down the organizational branch • For example, if the /Domlab policy indicated that passwords had to be a strength of 8 and enforce was turned on: • All OUs below /Domlab would set password strength to an 8 • This would include EU/Domlab and Sales/EU/Domlab

Organization Levels and Policies • Each level can have their own unique policies and policy settings • Create three different organizational policy documents, each with its own unique policy settings documents for: • */Domlab • */EU/Domlab • */Sales/EU/Domlab • This is a very simple structure • But if any of the settings are the same for these three levels, you can take advantage of the power of inherit and enforce

Looking at Policy Settings Without Inherit or Enforce • Let’s register Joe User/EU/Domlab • The /Domlab organization registration policy settings documents sets 2GB quota • EU/Domlab OU1 registration policy settings document doesn’t set a quota for mail files • Joe User’s mail file will be configured with no quota /Domlab EU/Domlab

How Inherit Affects a Policy Setting • Inherit means to take the setting from a higher level in the hierarchy; for example: • /Domlab user registration policy sets a database quota of 2GB • And there is also an EU/Domlab registration policy setting • Which inherits the setting from a parent policy • Joe User/EU/Domlab’s mail file will inherit the setting and will have a 2GB quota /Domlab EU/Domlab

Summing Up Policy Hierarchy Inheritance and Enforce • Inherit and enforce only have meaning where there are multiple layers of organizational or dynamic policies • Setting with inherit will apply the setting from the level above • But will not apply to the levels below unless enforced • Setting with enforce will always be obeyed at all lower levels • EU/Domlab could be configured to inherit from /Domlab and enforce to all organizations below • Settings would be forced on Sales/EU/Domlab

The Power of Inherit and Enforce • Inheritance and enforcement of policies can be used to push enterprise standards through your entire organization • Has a major affect because important settings like password strength can be set consistently with very little effort • But if your Domino domain certification levels are flat, with just one level like /MyCompany, then forget about inherit and enforce • You can’t use them • There is no mechanism to inherit from or enforce downward through the hierarchy if you don’t have a hierarchy

Types of Policy Documents • Organizational policy • Follows the certifier structure, such as Sales/EU/Domlab • Explicit policy can be applied to: • Individual person documents • People in groups • Not directly to groups, but to the people in groups • Groups • Explicit policy applied to a group is known as dynamic policy • The assignment of explicit policies requires a bit more explanation

Explicit Policies • An explicit policy applies to a collection of users that cross organizational boundaries • Before Release 8, explicit policies could be assigned only to individuals in their person documents

Assigning Policies to Groups Was Limited • It was possible to assign explicit policies to groups • But all that happened was that the “current” members of the group had the policy assigned in their person document • If new members were added to the group, the policy was not applied to them • This major shortcoming was corrected in Release 8 • You can now apply policies to groups, and when the group changes, the policies are re-applied to the new members

Using the Policy Assignment Tool for Explicit Policies • As a general rule with 8.5, using the policy assignment tool to assign an explicit policy to selected users or a group would not be the optimal way to do it • If you try to assign policies that way, Notes will display this screen reminding you of new functionality in Release 8.5 • Be sure to read this very carefully

Moving to the Next Step in Assigning Explicit Policies • If you continue to try to assign an explicit policy in Release 8, you are asked whether you want to assign it the old way • Which means iterating through the list of names (or the selected names) and changing person documents • Or the newer way of changing the policy documents themselves

Creating a Dynamic Policy • Release 8 policy documents can be directly assigned to multiple users and groups • You can even use an auto-populated group • We’ll talk about those special groups in a moment

New in Release 8.5 — Dynamic Policies • Dynamic policies are created as explicit policies • But are assigned to a group in the Domino Directory • Group membership changes over time • The dynamic policy that a user is assigned can potentially change day by day • This feature is new with ND8.5, but will work as long as your servers are 8.5 or higher and your clients are 8.0.1 or higher

Auto-Populated Groups • Auto-populated groups are new in Notes and can be used with policies • So far, the auto-population is strictly based on the members having a particular home server • Perhaps this will be expanded in a future release

Working with Auto-Populated Groups • Auto-populated groups can be used anywhere you’d use a group • You can nest them in other groups • Use them on ACLs • Use them as a mailing list • Members are added and maintained by the Domino server’s update task • The default update interval is 30 minutes • You can modify it in the Domino directory profile

Selecting User Home Mail Server Has Helpful Options • Specify the home server designated as mail server for the users • You can specifically include additional users by entering them manually • And you can exclude members manually, as well • Changes to the “Members” field are automatically performed by the Domino update task

Update Task Fills in the Details on Members • The update task completes the adding of group members • You cannot modify the group members • This auto-populated group is controlled by the user’s home server entry Members are automatically added based on mail server assignment

Auto-Populated Groups Automatically Create Subgroups • When an auto-populated group becomes too large (beyond the 32KB limit for a text field), subgroups are automatically created • These are also auto-populated • The subgroup names have the following format: • Auto-populated group name>-AP<#####> • ###### would be a number preceded by zeros • For example: • If the auto-populated group name is USMailMembers, the first subgroup for that group would be called • USMailMembers-AP00001 • This would be nested into the original USMailMembers group automatically

Dynamic Policies Are Another Kind of Explicit Policy • When creating a policy document, selecting an organizational policy hides the tab for the policy assignment and precedence • Selecting an explicit policy lets you access the policy assignment configuration tabs • Use these dynamic policies in place of assigning an explicit policy to individual users where appropriate • It will eliminate the need of keeping track of user documents where an explicit policy has been assigned

Dynamic Precedence Is Key • The precedence of dynamic policies will affect how they are applied to a user • Which dynamic policy will “win” and be applied if there are several that are configured for the same person?

The Importance of Precedence • Answer: If there are two dynamic policies with different options for the same setting, the user will receive the setting of the policy with the highest precedence • A policy with a precedence of 1 beats a policy with a precedence of 2 or 3

Change Precedence in the Notes Administrator Client • Use this procedure to manually set policy precedence: • From the Domino Administrator, click People and Groups  Policies  Dynamic Policies • Select the policy for which you are increasing or decreasing precedence • Click the Increase Precedence or Decrease Precedence buttons accordingly • Repeat for any other policy precedence changes you need to make

What Kind of Policies Should I, a Smart Person, Use? • Because of multiple levels of hierarchical policies, explicit policies and dynamic policies, simplicity of design is critical • Tailor your policies’ use to your environment • If your organizational structure matches your functional needs: • Use organizational policies • If using ND8.5, and can take advantage of dynamic policies: • Then use them! • Lastly, if you have users with specific needs that don’t fall into the above categories, then use explicit policies

Simplicity in Policy Strategy • In a perfect world, you could use a single Organizational Policy applied to your ORG level; all policy settings documents apply to everyone in your Org • The more layers of policies you add, the more complex your administration becomes and the more likely you are to have unintended consequences

A Safe, Low-Risk Methodology When Implementing Policies • When introducing policies, think in three stages • Proof of concept • Introduce the settings using an explicit policy on just a few • Make sure you can back out of any policy • Piloting the policy • Expand the policy to affect a group • Then expand the group to 50 to 100 users • Make sure you get plenty of feedback on the effects from a number of participants • Full policy implementation • While it depends on the policy, this generally involves a change to an organizational policy and affects large numbers

#1 – Registration Settings • Registration settings are probably the first and easiest set you should implement • Active only during the process of registration • Standardize your new user creation process • The registration process is dramatically sped up • Because almost every field is pre-populated with the correct values for the user • Registration policy settings documents have zero impact on existing users • They only affect the creation of new user default settings

Simplified User Registration With Policies • Admins can predefine all user registration options • Password quality • Internet address format • Mail file creation • Template/server • Certificate expiration • And more! • In theory, you could register user without checking the“Advanced” box!

Mail Settings • Lets you control the values in a user’s mail profile document • Every value in the preferences document is configurable • Extremely valuable in lowering support costs • There are many support calls from people about the configuration choices in their calendar profile • Mail settings use a different update process than set-up and desktop settings • They are acting on the mail file that resides on the server

Mail Settings Update Process • Mail settings are updated via AdminP • Every 12 hours, AdminP evaluates person docs and policy docs to see if it needs to update a users’ calendar profiles • You can trigger an update with the “Tell AdminP Process MailPolicy” console command • When you implement the mail settings, it will apply to ND6 mail files as long as your servers are at least R7 • This may be a very good thing or a bad thing • That is why we test, test, test

Critical Settings in Mail Policy Settings Documents • The majority of settings in the mail settings form indicate preferences • But the following two have a significant impact on support calls • #2 – Allow Users to Change Mailfile Ownership • Don’t allow this, it only leads to trouble • #3 – Displaying Calendar Entries in Mail Views • It’s important to set corporate standards here, though you aren’t required tolock these down • These settings always cause confusion for users when they are changed

Critical Settings in Mail Settings • #4 – Default Reservation Settings for choosing Site • Resolves an issue that most users, including myself, hate — when an organization has many sites • Be aware that this setting is only effective if your organizational hierarchy or explicit policies match up with your resource reservation design

#5 – Critical Settings in Mail Settings • Message Disclaimer • Since the disclaimer is defined within a policy, you can apply different disclaimers to different populations • Based on Org level or group membership

#6 – Mail Disclaimer – Client or Server? • Reduce burden on servers, enable client for adding disclaimers • This will also allow for the addition of disclaimers to Secure/MIME (S/MIME) and encrypted messages • You can have the server add the disclaimer to encrypted messages, but this tends to result in corrupted signatures and corrupted encryption

#7 – Cancelling Message Recall • You can craft your policies so that only certain users are permitted to recall messages • But if you’ve decided not to roll out message recall, it’s important to remove the button from sent folder that says “recall message” • If you don’t, you’ll get help desk calls asking why you’re message recall is not working • This valuable mail policy setting will actually remove the button from the sent view

10 Critical Policies and Other Tweaks to Boost Notes Performance