The old out-of-office agent comes in for some stick now and again. Its been vastly improved in nd8 (good news), but there's still some really cool ways to break it. For instance, if you have users who set their out of office agent, but it just never works - whats happened ?
One issue I found this week was if the user only has editor access to their mail file (a good thing), then the out of office activation creates an AdminP request, which then enables the agent in their mail file. For this to work, the users have to have author access to AdminP - something that might not be set up if you'vre environment pre-dated nd6. Something to check.
Another interesting point is if the users have successfully created adminP requests but they never get executed. What is going on ? Well, in the admin4.nsf database, check the transactions by user name, and then look for the user having the issue. If they have adminP entries listed, but they never get executed, check to see if the server that this is to be executed on has a full notes name (server/myCompany) or just the server common name (server). If its the latter - just the server common name, well, I might have a solution for you.
In the case of an adminp entry with just a server common name, AdminP on that server never processes that request - its looking for the full server name. So where is this coming from ? If you check out the users' location document, on the mail tab, you see what the user thinks is their home server. If thats' just been set to the server common name, you have an issue. The Lotus Notes client 'Dynamic Client Config' agent updates that server name from the person document in the public domino directory. And sure enough, in the case of our user, the user only had the Lotus Notes common name in their person document home server field. Ouch.
The nice thing is that this user has been happily receiving mail (so router.exe doesnt have an issue with just the server common name) - it just appears to be user generated AdminP requests. Such as Out of Office, or Deletegate Mail file. The other nice thing is that its easy to identify all the users with malformed server names in their person documents by looking in the Domino Directory view 'Messaging, Mail Users' view, which lists all users categorised on their home server name. At that point, its easy to update all the malformed server names in the domino Directory, and next time the user authenticates, Dynamic Client Config will fix their location documents. After a day or so, the user should be able to run out of office, or deletegate mail file access, even if they only have Editor access to their mail file.
And how did this start ? It transpired that in 'File Preferences, Admin Preferences' on the registration tab, the administrator had set the default home server that they registered users on to just the server common name, and didnt pick the name out of the directory (and therefore get the full notes name for the server).
Phew. A simple fix in the end, but a good hour worth of digging through the chain of events to figure this out. Hence the reason its here - hopefully someone else can benefit from this work.