Short Description: Preventing the Notes client from generating multiple 'Update Client Information in Person Record' Adminp requests
|With each launch, the Lotus Notes® 6.x client checks the Notes Client License, machine name, platform version, and Notes version build. This collected information is stored in two places:
1. In the notes.ini parameter DYNINFOCR_xxx=yyy as a hashed value, with hashes replacing the placeholders before and after the equal sign (=). Therefore, the parameter is unique to each computer.
2. In the Person document in the Domino Directory
If the value calculated during launch differs from that in DYNINFOCR_xxx=yyy of the notes.ini, then Notes submits an AdminP request to update the Domino Directory Person document for the user.
In a MultiWin server farm or terminal environment, the Notes data directory resides at a single location. Due to the workbalance facility of clustered Windows Terminal Servers, the terminal sessions can be launched each time on a different machine. When the Notes client recognizes a different machine name (of the WTS server), it calculates a new hashed DYNINFOCR_xxx=yyy value and creates a new AdminP request.
A large amount of "update client" AdminP requests could delay other AdminP requests and produce a high volume for replication of the Domino Directory. And the multiple AdminP requests could fill the Person document with obsolete information.
How can you prevent this client check and avoid the AdminP request?
|Notes 6.x client :
To prevent the recalculation of the DYNINFOCR_xxx=yyy parameter. Refer to "How to programmatically add a parameter to Notes.ini" (1210786) for one method to add that notes.ini parameter for all users.
A disadvantage of DisableDynConfigClient is described in "Roaming users are not being prompted to upgrade" (1162429). However, in a terminal services or Citrix environment, program upgrades are performed by the operating system administrator, not by the individual user, so the disadvantage does not apply.
Also, by implementing the ini parameter DisableDynConfigClient=1, the Dynamic Client Configuration will not execute, which means that both organizational and explicit policies assigned to the Notes user will not be pushed down to the Notes client. If policies are in use, you should not use this notes.ini parameter. You may want to consider an alternate solution to the AdminP requests, such as running an agent in the Administration Requests database that will delete the Administration Requests after they are created.
Notes 7.x client:
The parameter DisableDynConfigClient=1 is no longer used or applied in Notes 7.
Notes 8.x client:
Note: The notes.ini parameter DISABLE_CLIENTRECORD=1 prevents the creation of the admin4.nsf document.
Disable_ClientRecord=0 / 1
There is no kown UI setting for this notes.ini variable. But you can specify this setting in the notes.ini settings tab of the configuration settings document.