Overview

After a Domino Policy is created, the question is often asked, "When will it take effect?"  The short answer is, "It depends!"  The fact is that there are numerous factors that determine when a particular policy will take effect.  This article will cover the flow from policy creation to its application.  Care will be taken to call out the places where the particulars of your environment may affect this flow.  The goal of this article is provide ways for you to verify to see if the policy changes you have made are making their way throughout your system.

Step 1 - Making a change and an up to date Domino Directory

At first glance, the first step in the policy flow would seem simple.  You would either create or modify a policy or setting document in the Domino Directory.  But in 8.5 a user may get a new policy merely by being added to a new group.  So whether a policy or group document was modified, it then has to be reflected in an updated view index.  Normally, the Indexer task on the Domino server would update the view indexes once a minute.  Two INI variables can change this behavior.  The first is UPDATE_NAB_VIEWS_DISABLE.  If this is disabled then the automatic updating of the views will not occur.  But if the view update is not disabled, there is another INI variable, UPDATE_NAB_SUPPRESSION_TIME, which can be used to override the default interval of 1 minute.  Therefore, if policy changes aren't occurring as quickly as you think check to see if either of these two values are set in your server's INI file.  

Checkpoint 1: One way to confirm that the view is updated is to set the INI variable DEBUG_INDEXER=4.  This will generate output from the update process.  You'll see something like:
[168C:0004-01E4] 11/25/2008 02:07:48.27 PM NABIndexingThread> NAB suppress time now 30000
[168C:0004-01E4] 11/25/2008 02:07:54.27 PM NABIndexingThread> NAB suppress time now 25000
[168C:0004-01E4] 11/25/2008 02:08:00.27 PM NABIndexingThread> NAB suppress time now 20000
[168C:0004-01E4] 11/25/2008 02:08:06.38 PM NABIndexingThread> NAB suppress time now 15000
[168C:0004-01E4] 11/25/2008 02:08:12.38 PM NABIndexingThread> NAB suppress time now 10000
[168C:0004-01E4] 11/25/2008 02:08:18.38 PM NABIndexingThread> NAB suppress time now 5000
[168C:0004-01E4] 11/25/2008 02:08:24.38 PM NABIndexingThread> NAB suppress time now 0
[168C:0004-01E4] 11/25/2008 02:08:30.38 PM NABIndexingThread> Checking for NAB updates...
[168C:0004-01E4] 11/25/2008 02:08:30.38 PM CheckForNABUpdates> Updating open namespaces (update #2)

When you see the "(update #2)" message you know that the views have been updated.


Checkpoint 2: The best way to confirm from a client that a change you made is now reflected in the Directory is to use the Policy Synopsis tool of the administration client.  Right click on a Person document in the People & Groups tabs of the admin client and select Policy Synopsis.  If you just want to see if a new policy has been assigned to a user you can specify Summary and look for the "Derived from..." section:

The above example shows an Explicit policy, 3 organizational policies and one dynamic group policy.  If you want to see if a specific setting is correct, choose details and then the setting type, like Security, that you are interested in.  This would look like this:


The important thing to know is that if the policy or setting does not show up in the policy synopsis tool output, it definitely won't be applied to the user.  So this is the first place to verify the policy work flow.

Checkpoint 3: If the change is not showing up in the Policy Synopsis tool one way to force the issue is to rebuild the views directly using CONTROL-SHIFT-F9.

Step 2 - Which Directory?

The key thing here is that once the Indexer has run, you then have an up to date Directory on whatever server you made the change.  This is most likely the administrator server of your domain.  However, another thing to keep in mind is that a user's effective policy is updated when they login into their home mail server.  Clearly, this might not be the same machine as the administration server.  Therefore the time it takes for change to the Domino Directory to replicate throughout your domain must be taken into account.  That will depend on your replication schedule.  If you don't want to wait for scheduled replication, the server TELL commands can be used to pull/push the Directory changes to another server.  

Checkpoint 4: To see if a change has made it to a given server, the same checkpoints as above can be used, namely, using the Policy Synopsis tool.  If the change was not to a specific setting, but rather you added a new policy or setting or added a user to a group used in a policy you can simply look in the Directory and see if that is reflected in the local server's Directory.  

Step 3 - Location, Location

The next step is knowing when a policy change will be applied is knowing where the particular setting is consumed.  Some settings are consumed on the server and some are used on the client.  This Wiki articles describes what is consumed where: http://www-10.lotus.com/ldd/dominowiki.nsf/understanding-where-policy-settings-are-consumed.  For the purposes of this article, we'll cover one of each type: server and client.  So if you have a particular setting in which you are interested, then using these two articles together you can track it's application.

Policies applied on the Server

On the server side, let's take a Mail policy as an example.  Mail 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 command on the server console: "tell adminp process mailpolicy".  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.

One additional note to be made here is regarding dynamic policies.  Dynamic policies depend on resolving the group membership of each user.  Therefore when adminp processes the mail policies the end result will reflect the state of the groups at that time.  For performance reasons, a group cache is maintained on the server.  That cache is not updated immediately when a group is modified.  So if you add a person to a group that is used for mail policies, when can you expect that change to show up?  The first part is that the views have to be updated in the Directory.  The process here is the same that was listed in Step 1.  The second part is that the group cache then needs to read that view.  That only happens when a access is made to the cache, in this way updates are not being made unnecessarily.  One such access occurs during the process of the "tell adminp process mailpolicy".  So if you add a person to a group and then you see the view updated as in Checkpoint 1, then when you issue the "tell adminp process mailpolicy" you can be assured that the person will receive all policies assigned to that group.

Policies applied on the Client

On the client side, let's take a Desktop policy for example.  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.  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.

Checkpoint 5: You can see your locally cached policy documents by opening the hidden $Policies view (via Ctrl-Shift View\Go To).  So you can verify that the changes you have made to a Desktop policy is reflected there.

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.  Once again, note that on the Domino server, we rely on the Update task to update the views in the NAB.  If has not happened, 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.

Checkpoint 6: 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).

Conclusion

This article described how policy changes get reflected in the Directory, how those changes need to get to the home mail server of a user, and then how those changes can be used on the server or migrate to the client.  The six checkpoints listed can be used to track policy changes throughout your Domino environment.  In conjunction with the article on where policy settings are consumed, you should now have the tools to understand more completely how policies work in your environment.