Reasons for ProxyOriginatingRequestUNID to change during user move
Tags: adminp notes
I'm currently working on a script that will assist a customer in moving about 16k users to a new central environment, and during testing I ran into a strange issue where the ProxyOriginatingRequestUNID and ProxyOriginatingTimeDate field values change once the client has picked up the changes.
In the current environment there's about 20 servers spread across a number of sites, and because there is no mail file name uniqueness, they cannot just use the user move process from the administration client, besides they don't want to have to manually deal with all those approve mail file deletion requests.
I've build an app that generated a unique file name for all user mail databases, and where one could assign the intended new servers to the users, and initiate the user moves.
It also contains an agent that monitors the administration requests that are generated in admin4.nsf, approving the 'Approval for Mailfile Deletion' requests that are generated once the user's client has picked up the new home server/mail database information from the server.
I'm currently working on a script that will assist a customer in moving about 16k users to a new central environment, and during testing I ran into a strange issue where the ProxyOriginatingRequestUNID and ProxyOriginatingTimeDate field values change once the client has picked up the changes.
In the current environment there's about 20 servers spread across a number of sites, and because there is no mail file name uniqueness, they cannot just use the user move process from the administration client, besides they don't want to have to manually deal with all those approve mail file deletion requests.
I've build an app that generated a unique file name for all user mail databases, and where one could assign the intended new servers to the users, and initiate the user moves.
It also contains an agent that monitors the administration requests that are generated in admin4.nsf, approving the 'Approval for Mailfile Deletion' requests that are generated once the user's client has picked up the new home server/mail database information from the server.
Because there are users for which the mail database location and file name changes as part of the move to the new environment, I could not simply use the NotesAdministration class to initiate the Move User process (you can only indicate the directory on the new server, not the database file name), instead I create the administration requests myself by creating documents in admin4.nsf. ('Check Mail Server's Access').
This request will be followed by a number of additional administration requests (like 'Add New Mail File Fields', 'Monitor New Mail File Fields', etc.).
Initially I had initiated a number of user moves from the administration client to see which kind of requests would be generated and to find out how to generate them myself. During those tests I noticed that throughout the whole procedure, from the 'Check Mail Server's Access' to the 'Delete Mail File' requests (after approving it) once the process was completed, the ProxyOriginatingRequestUNID field (contains the unique id of the initial request) and the ProxyOriginatingTimeDate field (contains the date time of the initial request) remain the same.
ProxyOriginatingRequestUNID: "FE507710A:AC9EF33B-NC1257515:00457C15"
(datatype: text)
ProxyOriginatingTimeDate: 04-12-2008 13:39:13 CET (datatype: time date)
in the following requests (this is the unid of the first request):
Check Mail Server's Access
Create New Mailfile Replica
Maintain Trends Database Record
Add New Mailfile Fields
Monitor New Mailfile Fields
Replace Mailfile Fields
So I used that knowledge to make sure I would only approve 'Approve Mail file Deletion' requests that actually belonged to the current user move and not some left-over requests from the past that had never been processed.
But when I started testing I noticed that for one test user the 'Push Changes to New Mail Server' request (and the requests that followed) contained different values for the two fields. ProxyOriginatingRequestUNID pointed to a document unique id that did not exist in admin4.nsf, and ProxyOriginatingTimeDate contained a value from the past.
The following requests have a different values for
ProxyOriginatingRequestUNID: F7BAE0A46:38153682-NC125750C:00377B2B
(datatype: response reference list)
ProxyOriginatingTimeDate: 25-11-2008 11:05:58 CET (datatype: time date)
Push Changes to New Mail Server
Get Mail File Information for Deletion
Approve Mail File Deletion
Eventually I figured out that the person document for this test account contained a hidden (and totally not documented) field called MailMoveCscdInfo, a text list field that contained the document unique id referenced by the administration requests, and the timestamp.
MailMoveCscdInfo: "38153682 7BAE0A46:00377B2B C125750C"
"CN=Corus Template Signer/O=CorusGroup"
"CN=Corus Template Signer/O=CorusGroup"
"25/11/2008 11:05:58 CET" (datatype: text list)
The document unique id is recorded in the MailMoveCscdInfo field in the following way:
- If the document unique id in ProxyOriginatingRequestUNID is Faaaaaaaa:bbbbbbbb-Ncccccccc:dddddddd
- The first element of the MailMoveCscdInfo text list contains the id like this: bbbbbbbb aaaaaaaa:dddddddd cccccccc
However, this turned out to be only part of my problem.
Did you spot the difference in data type between the initial ProxyOriginatingRequestUNID value and the second one? (text vs response reference list)
I've used Steven Tomaselli's excellent code sample (from the R6/R7 forum) below, to generate the ProxyOriginatingRequestUNID field, with the proper data type this time, in the initial request in the user move process
Sub CreateProxyUNID(refdoc As NotesDocument, refdb As NotesDatabase)
Dim tempdoc As NotesDocument
Set tempdoc = New NotesDocument(refdb)
Call tempdoc.MakeResponse(refdoc)
Dim refItem As NotesItem
Set refItem = tempdoc.GetFirstItem("$REF")
Call refdoc.CopyItem(refItem,"ProxyOriginatingRequestUNID")
End Sub
This fixed the problem except for users that have this hidden MailMoveCscdInfo field in their person documents, which amounts to approximately 2.5% of the users in the customer's Domino Directory.
P.S. as a little side note, if you still have R5 servers in your environment, you really should get rid of them or take them out of your main environment or disable adminp because they will happily process administration requests intended for the domino directory's administration server, causing multiple replication/save conflicts in person documents for every user that you initiate a user move for.
