940 likes | 1.09k Views
10 Critical Policies and Other Tweaks to Boost Notes Performance. Andy Pedisich Technotics. In This Session. Policies make it easier to administer the users in your domain If you have never used policies, or if you have used them sparingly this is a great time to start
E N D
10 Critical Policies and Other Tweaks to Boost Notes Performance Andy Pedisich Technotics
In This Session ... • Policies make it easier to administer the users in your domain • If you have never used policies, or if you have used them sparingly this is a great time to start • There have been many improvements to deployment • Plus you missed some of the problems of early releases • This session will help bring you up to date by: • Doing a quick overview of the basicconfiguration concepts • Focusing on configuration best practicesand the most powerful tools in thepolicies system • Troubleshooting problems with policies
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 The two components of polices are: 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
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 The types of settings documents have increased since their introduction Five types of settings documents in ND6 Six types in ND7 Nine types in ND8.0.1 Ten types in ND8.5
The Role of the Policy 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 enough to handle many different requirements Let’s look at the policy settings documents
10 Types of Policy Settings Documents 1. Registration settings documents Used with the registration process in the Admin client Predefine all user registration options 2. Set up settings documents Occurs once — during Notes client setup Controls the initial Notes 6 client configuration You probably won’t use these because of changes in the Release 8 policy setting options 3. Desktop settings documents Applied by the dynamic configuration process on the client Controls settings in the user environment
10 Types of Policy Settings Documents (cont.) 4. Mail settings (new in ND7) Control user mail preferences in the mail profile document in each user’s mail file 5. Security settings Controls client Execution Control Lists (ECLs), password management, and ID Vault settings for the user Password management settings are applied by the dynamic configuration process on the client Settings for ECLs determine when the ECLs are applied 6. Archive settings Settings are applied to the server-based mail database by the dynamic configuration process Provides for both archiving and document retention
10 Types of Policy Settings Documents (cont.) 7. Traveler settings (new in 8) Configures mobile devices using Lotus Traveler 8. Activities settings (new in 8) Apply only to environments with 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
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
The Duplicates Made Policy Documents a Mess • Duplicates caused duplicate settings to appear in policy documents
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-Shit 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
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
Building Policy Settings Policy settings are configurations that will be applied to users Among other things, this desktop settings document configures the Notes client to display the sidebar and not hide any of the default sidebar components
There Are Hundreds of Policy Settings • 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
You Can Control How Each Setting Is Applied • Configuration settings in policy settings documents can be fine tuned in how they are applied • You can decide when to turn on inherit and enforce options • Let’s talk about these settings next • We’ll talk about “how to apply this setting” later
Inherit and/or Enforce the Configuration Settings These two checkboxes are the most misunderstoodby almost everyone who deploys them It’s critical that you understand them They change the way policy settings are applied
Let’s Clarify Inheritance vs. Enforce • Let’s try to cover some basics in policy application to help clarify the inheritance and enforce functions • Consider the following example organizational structure: • /Domlab • Is the root organizational level certifier for the enterprise • /EU/Domlab • Is the OU1 certifiers representing Europe • /Sales/EU/Domlab • Is the OU2 certifier representing the European Sales division
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
How Enforce Changes How Policies Are Applied • Enforce does not do what I thought it would do at first glance • I first thought it would force someone to have a certain setting and that they were unable to change it – I was totally wrong • Enforce actually means to take the setting from an upper 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 other OUs below /Domlab would set password strength to an 8 • This would include EU/Domlab and Sales/EU/Domlab
Summing Up Policy Hierarchy Inheritance and Enforce Each setting has inherit and enforce options 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 This can have a major affect on your domain because important settings such as password strength can be set consistently with very little effort using policies But if your Domino domain certification levels areflat, 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
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
Types of Policy Documents • There are several important 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 • An explicit policy that is applied to a group is known as a dynamic policy • The assignment of explicit policies requires a bit more explanation
Once Again, Organizational Policies • Let’s look at a very simple organization structure to see the power of organizational policies • Register users consistently in the EU/Domlab level by creating an organizational policy */EU/Domlab • And include a registration policy settings document • Those registration settings will be used automatically • But they can be changed at registration time
How About Desktop, Security, and Archiving Settings? • With all the policy settings documents to the right, settings are applied to all the members of the hierarchy • And if you move a user to a different hierarchy, these policy settings are re-set according to the policies setting document of the new hierarchy • The new policy settings become effective the first time users authenticate with their home server
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 rather than being assigned to a person, they are assigned to a group in the Domino Directory Since group membership changes over time and is flexible, 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
Applying Dynamic Policies As mentioned, if your servers are 8.5 and your clients are 8.0.1 or higher, then you can take advantage of group-based dynamic polices In many organizations these will take the place of explicit policies and may even take the place of organizational policies You may use these with the new auto-populated group feature in 8.5 that will generate groups based on home servers automatically But you can actually use them with any group
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 • But you really don’t want to, because this auto-populated group is going to be 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 to hold all of the members of the group • These are also auto-populated • The subgroup names have the following format: • auto-populated group name>-AP<#####> • ###### would be a number preceded by zeros • 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
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 granular process of keeping track of users who have been assigned an explicit policy
Dynamic Precedence Is Key In a few moments we’re going to talk about how effective policy is calculated 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 Which dynamic policy will “win” and be applied if there are several that are configured for the same person? • 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
Let’s Put It into Perspective Here’s an exact quote from the Release 8.5.1 Administrator’s help that will help you understand the nature of dynamic policies • The lower the precedence number, the higher the precedence, and the higher the precedence number, the lower the precedence • For example, a precedence of one (1) indicates the highest precedence, and a precedence of two (2) or any other number greater than one (1) indicates a lower precedence And here’s the kicker: • By default, when a new dynamic policy is created the policy is assigned to the end of the existing precedence order • Confused? Don’t be. It’s easy to change precedence!
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 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
What Kind of Policies Should I Use? Since users can have many settings documents apply to them 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, then use organizational policies If you are 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