Domino Policies In the Notes/Domino environment, policies are a powerful feature allowing an administrator to control many user settings at once. They can be used to set purely administrative controls like enabling inbox maintenance. Or they can be used to enforce company practices by enabling e-mail message disclaimers. The great power and flexibility of policies; however, can be confusing and complicated particularly when multiple policies are used. Therefore this article will be used to call out and answer some of the frequently asked questions regarding policies so that you can take advantage of all that they can do for you. The questions will be grouped into categories to make it easier to find a particular question and answer.
This list is just a start so check back later!
General
What is the priority with respect to each other of the different types of policies? (Organizational, Explicit, and Dynamic) An upcoming Wiki entry will discuss this in great detail. But the general answer is that excluding Inherit/Enforce settings, the more specific policy takes precedence. So an explicit policy takes precedence over a dynamic group policy and a dynamic group policy takes precedence over an organizational policy.
Why can't I send down NOTES.INI settings or managed settings for plug-ins down to the client? In 8.5 you can! In a Desktop Settings document, look for the Custom Settings tab (far to the right on the list of tabs, use the arrows next to the tabs to get there) and you'll see sub-tabs for Notes.ini and Managed Settings.
What to be aware of when working with Policies in a mixed environment? First, when using pre- 8.0.1 Notes clients, be aware that desktop, setup, client archiving, and some security settings are actually calculated on the client, so when responding to an issue related to Policies, one will need to be aware of the client type to which the policies will be getting applied. Second, Mail Policies are applied and calculated by Adminp on the server; as a result, the policy version of mail will have dependency on the Domino version and potentially the MAILx.NTF in use. Third, when there's a higher version of the Domino Directory in use on the server, new settings and items will be present on older clients, but will not be used because the client code is not "aware" of these settings. Finally, and in a similar vein as the previous point, the "Set initial value" setting is a new feature to 8.0; that feature will not work against a lower the 8.0 version of the Notes client.
Also see: Do you have to have an 8.5 client to use Dynamic Policies?
How do policies get pulled and applied on the client? When the client authenticates with the users home server, it sends over a hashed value that indicates what policy information it thinks it has stored locally. The server calculates a similar hashed value for what it thinks the client should have. If those values do not match, then the server tells the client that it need to refresh it's policies. At this point, the client launches the dynamic configuration process, Dyncfg.exe, passing it flags on the command line that tell it to pull policies. Dyncfg uses the NAMEGetPolicy API, which asks the server to calculate the effective policy for the user, and then stores the effective policies locally in the clients NAMES.NSF database. You can see your locally cached policy documents by opening the hidden $Policies view (via Ctrl-Shift View\Go To). After pulling and applying the policies to the client, Dyncfg stores off the new hashed value that it got from the server, to be sent back to the server during the next authentication, which starts this whole process over again.
So what info is encoded in this hashed value? Previous to R8.5 and dynamic policies, it was simply the last modified time of the $Policies view in the server's NAB. With the introduction of dynamic policies, the hash was expanded to include any group or user names that caused a policy to be assigned to the user, as well as the last modified time of the $Policies view. So, if any policy info changes on the server, or the user is assigned to any new groups that cause a policy to be assigned to them, then the hash will change which will trigger the client to pull new policies. Note that on the Domino server, we rely on the Update task to update the views in the NAB once per minute. If this doesn't happen, then the $Policies view won't get updated, the code won't know anything has changed, and no policy changes will get pulled to the client. This is a very common cause of policy problems on test machines.
How to I force the client to pull policies?
Part of the hashed value is the last modified time of the $Policies view in the Domino Directory on the server. So modifying any policy or policy settings document (e.g., simple edit and save) and updating the $Policies view should cause the client to re-pull policies when it next authenticates with the server. To make that happen, you can disconnect the client by hitting Ctrl-F5 and then reconnect to the server in any way (e.g., open any database on that server). There have been some bugs where this process breaks down and policies do not get pulled. We've fixed them as we've found them, the most recent fixes going into R8.5 (as of 7/1/2008).
What tools are available for managing policies?
In the Domino Admin client, there are several tools on the Configuration tab.
Policy Viewers
In the left-hand pane, there are a couple of ways to view your policies:
The "By Settings" view allows you to easily see which policies a given Settings document is referenced from, so you can tell which users in your domain will be affected by a change to that Settings document.
The "By Hierarchy" view shows your policies based on their hierarchical names. The best feature of this view is the ability to select a particular user, a particular policy settings type (e.g., Desktop settings), and be shown the effective policy for that user. You select a user using these controls in the header of that tab:
Policy Synopsis
The Policy Synopsis tool is available from the toolbar on the right-hand side of the Configuration tab.
For the 'Report Type' one can get a summary report or a detailed report. In a summary report, the following information is provided:
Effective Policy for - this field provides a link back to the person record
Derived from the following policies: - shows which Policies entered into the calculation and provides links back to those Policy documents
One can chose to examine on or more Policies at a given time. In a detailed report, in addition to providng the "Effective Policy for " and "Derived from the following policies" fields, the document will also contain
a report with very detailed information describing every item on the effective policy note, its value, which policy it came from, etc. It's very handy when you have multiple policies assigned to a user and you want to know
why they are getting a particular value assigned to them. One can choose to append a record to the existing results database, or overwrite the database all together.
How often are Mail and Traveler settings applied?
Mail and Traveler settings are applied to the mail files on the server by the Administration Process (Adminp) every 12 hours by default. An administrator can also make Adminp process those settings by using the following TELL commands on the server console: "tell adminp process mailpolicy" or "tell adminp process traveler". Additionally, the server INI variable, ADMINP_POLL_INTERVAL, can be used to specify the time (in minutes) that Adminp should process those settings. However, since this will cause Adminp to go through every mail file on the server, this setting should not be set too low so as not to impact server performance.
8.5 Features
Do new groups have to be created to use the new Dynamic Policy feature?
No, your existing groups can be used. Just place them under the Policy Assignment tab in the policy document.
Are Home Server groups to be used only in Dynamic Policies?
No, a Home Server group is just a group that is auto-populated by those users that have the same home mail server. So while a Home Server group is populated differently than a regular group, it can be used wherever a regular group is used and that includes Dynamic Policies.
If a user is in two different groups and each of those groups are in a different dynamic policy, which one takes precedence?
The precedence question only comes into play if both policies specify the same setting, otherwise the various settings from each policy are just merged. If there is a conflict for a particular setting, the precedence setting specified in the Domino Directory in the People -> Policies -> Dynamic Policies view is used. There the group policies are listed in decreasing precedence. So the setting from policy with the highest precedence would be chosen.
Do you have to have an 8.5 client to use Dynamic Policies?
No, the server has to be 8.5 but the client can be 8.01 or greater. Note: that in a mixed environment you might have some servers which are 8.5 and some that are pre-8.5. For policy settings that are consumed by the server, clearly a pre-8.5 server won't be able to handle dynamic policies. So in that case you'd have to use explicit or organizational policies for users on that server. You could have an explicit and dynamic policy assigned to a user that accesses both 8.5 and pre-8.5 servers. Then when the pre-8.5 servers are upgraded you would then remove the explicit policy.
You changed group membership, now when will dynamic policies reflect that?
When you add/remove a member of a group, the Indexer thread will update the internal directory view which is then used to update the group cache. The Indexer thread will run every minute by default or you can specify the server INI variable UPDATE_NAB_SUPPRESSION_TIME with a value in minutes. Once the group cache is updated, dynamic policies will now correctly reflect a users group membership.
Dynamic Policy - Best Practice
When using Dynamic Policies you assign users to the policy via the Policy Assignment tab. It is better to use groups whenever possible instead of individual names. The reason being that all entries in the Policy Assignment tab get listed in a system view. If you list individual users, then there will be more entries in the view. The more entries present means more work to read those entries. So while it's not a problem to list individual users, it's much better performance wise to maximize the use of groups. After all, the whole point of dynamic policies was to avoid have to deal with individual users at all!