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).
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.
