Problem with old Person Documents Replicating Back In
Friday 20th March, 2009I was talking to a customer recently who had an issue where old person documents kept replicating back into the Directory. In our conversation to find a way to stop this from happening, the following ideas came up as possible solutions. Just wanted to share our thoughts with everyone in case you find yourself with the same issue.
Option 1:
Set up Deny Access List for Servers:
Everyone has a Terminations Group for users as they are removed from the Domino Directory. This prevents someone from using the terminated user's ID and connecting to a Domino Server. In this same principle, create a Terminations Group for Decommissioned Servers. One of the root causes that was identified for old person documents replicating back in was someone found an older server and decided to boot it up to see what was on it. By chance, they plugged the server up to the network and Domino loaded automatically and immediately started replicating with the Hub Server. If a Terminations Group for decommissioned servers existed, the server would not have had rights to connect and replicate.
Option 2:
Remove "Replicate or Copy Documents" Rights for users in the ACL:
Another possibility for old person documents replicating back in could be the fact an end user has decided to create a local replica of the Domino Directory. This is very rare in large environments due to the size of the Directory; however, in smaller environments, the Domino Directory could be used locally to look-up people's phone numbers, addresses or even as a Mobile Directory Catalog. If an end user allowed a local replica to sit and not replica for more than 30 days, typically at this point you have passed the 30 day purge interval for Deletion Stubs so the end user would then start replicating old person documents back to the Domino Directory the next time they replicate. In this scenario, the idea was to first ensure "Enforce Consistent ACL" was enabled on the Directory and then remove the check box to allow users to "Replicate or Copy Documents" from the ACL. This would break the functionality of end users maintaining local replicas of the Domino Directory and force them to use Mobile Directory Catalogs. The only problem with this is users are unable to copy any data from the Directory even when trying to copy data to the clipboard to paste somewhere else.
These were just some ideas that came from a meeting. These suggestions are not necessarily recommended by IBM as best practices since these methods have not been thoroughly tested. If you choose to implement these suggestions, please test them thoroughly in your environment first. Especially the idea to remove the "replicate or copy documents" option from the ACL.
Option 1:
Set up Deny Access List for Servers:
Everyone has a Terminations Group for users as they are removed from the Domino Directory. This prevents someone from using the terminated user's ID and connecting to a Domino Server. In this same principle, create a Terminations Group for Decommissioned Servers. One of the root causes that was identified for old person documents replicating back in was someone found an older server and decided to boot it up to see what was on it. By chance, they plugged the server up to the network and Domino loaded automatically and immediately started replicating with the Hub Server. If a Terminations Group for decommissioned servers existed, the server would not have had rights to connect and replicate.
Option 2:
Remove "Replicate or Copy Documents" Rights for users in the ACL:
Another possibility for old person documents replicating back in could be the fact an end user has decided to create a local replica of the Domino Directory. This is very rare in large environments due to the size of the Directory; however, in smaller environments, the Domino Directory could be used locally to look-up people's phone numbers, addresses or even as a Mobile Directory Catalog. If an end user allowed a local replica to sit and not replica for more than 30 days, typically at this point you have passed the 30 day purge interval for Deletion Stubs so the end user would then start replicating old person documents back to the Domino Directory the next time they replicate. In this scenario, the idea was to first ensure "Enforce Consistent ACL" was enabled on the Directory and then remove the check box to allow users to "Replicate or Copy Documents" from the ACL. This would break the functionality of end users maintaining local replicas of the Domino Directory and force them to use Mobile Directory Catalogs. The only problem with this is users are unable to copy any data from the Directory even when trying to copy data to the clipboard to paste somewhere else.
These were just some ideas that came from a meeting. These suggestions are not necessarily recommended by IBM as best practices since these methods have not been thoroughly tested. If you choose to implement these suggestions, please test them thoroughly in your environment first. Especially the idea to remove the "replicate or copy documents" option from the ACL.
email:Peter Smith | website:
I find that the worst offenders for taking local NAB replicas that stagnate and rep old docs back to the servers are the Notes Administrators!
email:Andre H | website: http://www.ytria.com
Hi Michael,
whilst I agree with you that it is better to find a solution to prevent this issue from happening.
Ytria's scanEZ gives you the ability to at least identify the "resurrected documents" if the problem happened so that you can quickly fix it. See here one of the Tips that our Technician has written about this topic: https://www.ytria.com/WebSite.nsf/WebPageRequest/Tip53_~D?OpenDocument&Lang=en
email:Andre H | website: https://www.ytria.com/WebSite.nsf/WebPageRequest/Tip53_~D?OpenDocument&Lang=en
link did not format correctly - will try again here if it does not work the link next to my name is now also the one to the Ytria Tip. { Link }
email:JYR | website: http://jyriver.blogspot.com/
Yes, a major problem in large environment
{ Link }
email:Bob Warth | website:
I'm curious what organizations allow Create access to their nab? Most admins I know don't. If an end user can't Create then they can't replicate in oboslete docs. I agree with Peter that we admins do it to ourselves by firing up an old server with a valid server id on it, an old test client with our ID on it, etc.
email:Kevin Pettitt | website: http://www.lotusguru.com
Re: Option 1
Adding a server to a decommissioned server group assumes you *know* said server is no longer in use, in which case a more sensible approach would seem to be to remove the server from "LocalDomainServers" and probably delete the server document and connection documents as well. My point is that this problem would only seem to occur because the server was never consciously decommissioned, but rather was just "forgotten" - a circumstance that precludes this option.
I can imagine this happening with development servers or even "laptop servers" that some admin/developer might use for portable demos (e.g. speakers at conferences). I would suggest that if you're going to have such servers in the environment that you create a separate domain with an independent Directory, and perhaps cross certify your "prod" ids to your "dev" domain. Oh, and don't replicate your production Directory to your dev servers :-).
That said, I'm glad you wrote this as one of my "laptop servers" currently resides on a near dead machine that I haven't had time to fix yet and which has been off for several weeks. When/if I do, I will remember to avoid loading Domino until I copy over a recent names.nsf.
email:Keith Brooks | website: http://www.vanessabrooks.com
The solution in #1 is more practical.As kevin said, if you as an admin are lazy or a server you do not "know" gets decommissioned and no one tells you or follows proper procedures (you do have procedures on this right?) then this can happen.
like Peter said, usually it is an admins pc or personal server which suddenly starts doing it.
BUT, if old users, which have more recently been deleted, are suddenly coming through then you might have a different problem.
Perhaps someone inadvertently, maybe using a 3rd party admin tool or even a jr admin, restored all the denied people, instead of just the one they needed. This has also happened.
ideally you want to lock down your NAB, in R* you have some more restrictions and 8.5 the ID vault where you can manage some of this exact issue, perhaps in a better way.
But if you have an older server domain you need to be vigilante. Always have a replica of yesterday's NAB local just in case.
email:Keith Taylor | website:
What's the best method for understanding who or what put these old docs back in the directory? We've looked at "user detail" for a high number of writes.
email:Pete | website:
How about the KISS method?
1. Decomission server....it works
2. Un-Install Domino from same
We all know there's often more to the story, but simple can be the best method.
Cheers....
email:hortert | website: http://rapid4me.com
Personally I had no problems with option 1. Thanks a lot!
email:Stephen Bailey | website: http://www.converteam.com
I reported this issue on the notes.net forum a while back. My issue was trying to identify the rogue documents that had appeared in the address book.
A very kind soul took pity on me and posted an agent which worked first time for me!
My entry:
{ Link }
The agent:
{ Link }
email:saç ekimi | website: http://www.sacekimmerkezi.org/index.php/category/sacekimmerkezi
Hi;
Unfortunately, although I realize I could not read the topic defalrca to help me in this regard would be glad if the mail.
mary lou
marylou23@gmail.com
{ Link }
email:placement argent | website: http://placementargent.org
Thanks for informative post. I am pleased sure this post has helped me save many hours of browsing other similar posts just to find what I was looking for. I bookmarked this blog a while ago because of the useful content and I am never being disappointed. Keep up the good work Just I want to say: Thank you!
email:injury lawyer | website: http://theaccidentlawyers.org/injury-lawyer/
Thanks for informative post. I am pleased sure this post has helped me save many hours of browsing other similar posts just to find what I was looking for. I bookmarked this blog a while ago because of the useful content and I am never being disappointed. Keep up the good work Just I want to say: Thank you!
email:mikroenjeksiyon | website: http://www.tupbebekgebelik.com/mikroenjeksiyon.html
was an article I liked. Thanks for sharing.
...
email:online casino | website: http://casinobonuszone.com/casinos/
There's a lots good data in this blog,i’m from london i found this on google i found this blog very interesting good luck with it i will return to this blog soon. Do you mind if I reference to this blog from my newsletter?
email:robseller81 | website: http://americanfinancesolutions.com
Your suggestions are extremely distinctive, I help you. I think you should always be described as a clever man. So i prefer to know you.
email:Phoenix Pool Companies | website: http://www.aquavidapools.com
Thank for your advice. That is exactly what I want
email:Adjustable bed frame | website: http://adjustablebedsprices.org
I like this post,And I guess that they having fun to read this post,they shall take a good site to make a information,thanks for sharing it to me.
<a href="{ Link } bed frame</a>
email:Photography Canberra | website: http://chriscanham.com
You see that all comments say that your post isvery good, Congratulations, I get many good knowledge from your. Hope that you will have others . Looking forwards to get more. Thanks
email:Ben 10 Games | website: http://www.kingofgames.net/ben-10-games
If an end user can't Create then they can't replicate in oboslete docs. I agree with Peter that we admins do it to ourselves by firing up an old server with a valid server id on it, an old test client with our ID on it, etc.