In trying to implement ID Vault I am finding a number of my users (5%?) have corrupt policy documents in their local names.nsf (in the hidden $policies view).
I’ve tried deleting policies in the client, both manually and programatically, but these errant policies don’t delete. What I have to do is make a file>database>copy, then rename the file to names.nsf and then I can delete the docs and good ones download from the server. Any better way? How common is this problem? Often it seems to affect archive documents such that the user has no archive link and cannot manually archive either.
Subject: Yes ($Policies) can be an issue, and here’s how to fix
We’re seeing it in an upgrade from 6.5. Lots of bad internal reasons why this can be the case (not necessarily any of them IBM code).
Here’s what we found as a solution. Some of those docs in ($Policies) are not valid docs. Open Doc Properties and scroll through the view. One of them is likely to report a bad unid.
Refresh the view (F9). That seems to clear up the bad unid, and that may be enough to get the Policies to work. Of course if it doesn’t, then delete all the docs in the Policies view and restart the notes client. Of course, if the client uses local mail files…wait till server replicates to local to look for actual enablement of policies at local replica level.
If you’d like a database on open script for this (shove into mail file for example), I’ve got it.
I’ve found and fixed an issue with regards to Archive policy links that come and go. It’s been fixed in 8.5.1 and it is being backported to 8.02FP4.
The way to verify this issue is to do the following:
Rename ndynconfig.exe to something else so that it can’t run.
Delete the directory: \Notes\Data\workspace.metadata.plugins\com.ibm.rcp.managedsettings
Start the client
The archive link should disappear.
Stop the client
Rename ndynconfig.exe back.
Start the client
After Dynconfig runs, the link should be back.
The issue is with the two sides of the client, Java and C, stomping on each other. When the Java side runs it is wiping out the ability of the C side to see the Archive policy. The policy is still there, the C side just can’t see it. But when the C side eventually runs dynconfig again, it can see the policy again. When the Java side eventually updates its settings again (every 12 hours) it’ll hide the settings again. Thus why the settings appear to come and go.
Subject: Could this be the reason why Shared Loging Fail
I’ve just been reading this topic of conversation and as part of some early adoption testing found a few of the users who I’ve upgraded to 8.5 from 6.5.4 have dynamic policies applied for both archiving and security in that shared login enabled. All seems fine for a few days then randomly even though no policy documents have been modified the client appears to be reset and they also loose links to the archive. Do you believe the fix mentioned here would also resolve this issue as well.
I have just recently heard of a similar situation regarding archive criteria documents. But the resolution was much simpler than what you seem to have to do.
What was done was that with the $Policies view open, F9 was used to refresh the view and the invalid documents were removed from the view and then the archive criteria links worked correctly. Note: a shift-F9 was not done, just a simple view refresh. You might have aleady tried that and thus tried to delete the document, but can you confirm one way or another whether this works for you?
Unfortunately, we have not been able to reproduce this issue in house. So I’d like to gather more information on your situation so that we can do so. So I have a few questions:
Do the users experiencing the problem have replica of their personal names.nsf on the server?
Do the users experiencing the problem have replica of their mail files locally as well as on the server?
Have you recently upgraded these users from another release? If so, which one?
Were these users recently moved to a new server via adminp?
How are the policies being assigned to the users? Explicit, organizational, or dynamic?
Are only documents of the form ArchiveCriteria the ones being corrupted or are other policies being affected?
I tried the F9 and it didn’t help. In fact, I find that I cannot delete all the policy docs using Ctrl + A then DEL. When I F9, the corrupt docs are still there. If I do a File>New Database copy, I then can remove the errant docs and repopulate the policies.
Q. Do the users experiencing the problem have replica of their personal names.nsf on the server?
A. None of them do…we don’t do this.
Q. Do the users experiencing the problem have replica of their mail files locally as well as on the server?
A. None of them.
Q. Have you recently upgraded these users from another release? If so, which one?
A. Its been a mix. Some upgrade from 8.0.1 and 8.0.2. Another was a fresh install.
Q. Were these users recently moved to a new server via adminp?
A. None
Q. How are the policies being assigned to the users? Explicit, organizational, or dynamic?
A. All three.
Q. Are only documents of the form ArchiveCriteria the ones being corrupted or are other policies being affected?
A. It seems primarily the archive docs. But I didn’t check every one. This was the issue.
Here’s some more info. This also seems to affect people I am trying to upgrade to use the ID Vault. 80% of the users get their ID uploaded to the vault. Some just won’t upload. But this could be unrelated of course.
Thank you for the information. So far, your issue seems to be unique except for the possibility that the corrupted docs may be limited to archive criteria documents. There is a current issue being investigated with them. So could confirm that the corrupted documents are ONLY archive criteria documents? That would at least let us narrow down the problem to possible with one type of docment versus potentially being a broader issue.
When you say,“In fact, I find that I cannot delete all the policy docs using Ctrl + A then DEL. When I F9, the corrupt docs are still there.” do you get an error? What exactly happens?
Subject: Yes, the corrupt docs are all Archive Critieria.
Here’s the step by step Mark:
(1) Go to user’s Workstation who is not able to archive manually or open their archive. These same users don’t seem to be uploading their ID to the ID Vault Either.
(2) Open local names.nsf to the $policies view
(3) Ctrl + A to select all policies docs and DEL
(4) F9. Notice that the archive criteria docs are not gone.
(5) make a new replica of names.nsf locally called new_names.nsf.
(6) Exit Notes and remove old names.nsf and rename the new one to names.nsf
(7) Restart Notes and repeat steps 2-4 and notice that I can delete all policy docs now.
(8) Restart Notes once or twice and note that polices are repopulated.
After this, things seem to work properly, but I’ve had some reoccurances of corruption.
OK, it is good to know that the issue is limited to the archive criteria documents. When you say ‘corrupt’ how are you determining that? Problem archive criteria documents that I’ve seen have the behavior that if right click on the document properties I get “Invalid or non-existent document”, is that what you see?
What's been reported by others that have problems is that if you right click on an archive criteria document to bring up the document properties, you get the error "Invalid or non-existent document". Could you try that and see if you get that error?
Now when people have this situation, they end up having two documents for the same archive criteria. The first one being invalid. This has been shown to cause the one issue you reported: (1) loss of the the archive link on the mail navigator. This is because the mail navigator thinks there is an archive criteria document but when it goes to get it the invalid one is returned and thus it is not displayed. In effect, the invalid one masks the presence of the good one.
I strongly suspect that this is the same reason for your other issue: (2) loss of the ability to manually archive. When you go to manually archive, it too will see the invalid document and not the good one.
So that behavior is consistent so far. Where what you are seeing diverges is the (3) inability to delete these archive policy documents from $policies. But if I make a new copy of names.nsf (replica or new copy) I can delete them.
The first two issues were the result of a stale view and thus F9 was enough to bring the view up to date, remove the invalid document, and then items 1 & 2 would work. But not for you. So I need to first confirm if you are getting the "Invalid or non-existent document" error to see if you really are seeing the same thing. In addition, we then need to figure out why you can delete the notes and/or why F9 does not work for you. Can you describe exactly what happens when you try to delete the notes? Do you get an error? Can you select the documents?
Regards,
Mark
I had the same issue with the archive link not appearing at one of my customers. I solved the issue with the suggestion of using F9 after I deleted all documents (which left 2 non-existing docs in the view). I also deleted the documents from the Trash folder and then restarted Notes. After the policies were applied (docs in $policies), the archive link was available.
… if you haven’t already done so, turn on debuging output via debug_outfile= on the client. Also try turning on debug_policy=1 in your client’s notes.ini. If it reoccurs send my the data at: mskurla@us.ibm.com
