Working with a client recently on some policy setting updates and we ran into an issue where the new policy wasn’t taking effect on his client. We made the change to the policy (in this case an Archive policy) and could see that it had been processed and applied to the mail file. Checking the user’s Notes client, the link to the Archive was not showing up.
I opened up the ($Policies) view in the user’s local names.nsf to check the policy documents there and noticed that it had been a couple of months since the last update. Something was not right. We cleared the policy docs out of the view and restarted Notes. No policy documents at all were getting pulled down to the client.
This is a remote client and he had emailed me this update. I couldn’t work with him immediately, so I asked him to send me the output from Help - Support - Collect Support Data in his Notes client. This is a very useful tool for pulling out all configuration and diagnostic data from the Notes client (Standard client only, I believe). This grabs the notes.ini, Eclipse related config files, etc and dumps them into a ZIP file in the same folder structure as the client. Very easy for a person to use and then send the resulting ZIP file.
Looking through the ZIP file I received, I went to the notes.ini to see what might be there. Scrolling through I find the MailServer= entry and an IP address listed instead of the Notes name of the server. I contact the user and have him open his location document and behold, the IP address. We change it to the correct name and restart the client. Now the policies are downloading and the link to the archive is present in his mail file.
Apparently, he had changed the setting during a problem with network routing. This was a good time to show him how to setup a connection document in case the routing issue ever comes back.
To recap, we discovered:
1 - The Collect Support Data tool in the Notes client is very helpful
2 - IP addresses in certain Location doc fields are not very helpful