Prevent address book to replicate with another one it has not seen in xTime 
Use this IdeaSpace to post ideas about Domino Administrator.

: 12
: 19
: 7
: Domino Administrator / Directory
: adress book, replication
: Jacques Page617 29 Jan 2009
: / Email
I would like an option to prevent the address book from replicating with another one (same replica ID)  if it has not seen in a while.
I would set mine to 2 months.  If my address book as not seen you since then, there would be no replications (automatic anyway as it would be nice if it could be manually allowed.)
This would prevent any rogue address book from dumping documents and settings that have either been modified or deleted.
This would be especially good for administrators who take over domains as there is no realy way of knowing how many rogue servers exist in the environment and what practice the old administrators had to decomission servers.  This could also be useful with other databases
Thinking more about it, it would be nice to prevent replication of the Names.nsf with ANY replica that is not officially on a server (such as a local replica on an admin desktop).  This would help prevent an administrator from replicating the NAB locally, deleting half of it and have the changes replicated up..(don't laugh, I seen it happen...))

1) Gregg Eldred8655 (29 Jan 2009)
I demoted this solely on the basis of your last paragraph. You had my vote for a better method of protecting your Domino Directory, but limiting it to only servers makes it difficult to fix problems that could be corrected by a local replica (the opposite of what you describe).
2) Jacques Page617 (02 Feb 2009)
HI Gregg

I am not sure about the last one too but I have seen it happen. Perhaps I am more scared than I should be here. Maybe we could have a switch to let that happen.. Maybe it would defeat the purpose...

I am not sure if all should be included but I am very sure I would like to have a lock option. As a consultant, the first thing I would do when I get to a new client is set the Names.nsf not to replicate with ANY server or replicat it has not seen in 2 months or more.

I have only 18 servers here and I am having fun running around rogue systems.. I can only imagine what a 200 server farm looks like....

Thank you for your comments!

3) David Hablewitz15116 (13 Feb 2009)
I think this idea has either been misinterpreted by the 6 developers who voted against it or those voters all work for Microsoft.

Just ask any administrator who has had to deal with cleaning up a database after someone replicated their local replica for the first time in a year and added thousands of previously deleted documents back would clearly see the value. I have heard many admins make this same complaint. In one case I encountered in a domain of over 90,000 users and servers all around the world, someone at a remote site turned on a server that had been decomissioned 2 years prior. This created hundreds of replication/save conflicts and restored tens of thousands of previously deleted documents. The massive replication storm alone as those changes replicated to hundreds of servers brought server replication to it's knees. But the worst part was that it restored some connection documents that resulted in replicating several mission-critical databases that were not supposed to. Recovery from both of this catastrophic event was painful and took over a week.

So can any of those uncommented demotions give a better reason AGAINST this feature?

FWIW, I have submitted this as an SPR directly to IBM support before even.
4) Ninke Westra2116 (17 Feb 2009)
Actually I would like to see this for all types of databases, not just the Domino directory.

In the scenario where the client's configured with a local replica and a user has been away for more than 3 months (sabatical/sick leave) and they launch their client again old stuff will replicate back into their mailfile.

Another example I encountered last year at customer was where users would create local 'archives' by creating creating local replicas which in itself was not a problem until the clients were reconfigured for local but connected mode with scheduled replicatioin where some of these old replicas started to replicate stuff back to the server.

5) David Hablewitz15116 (17 Feb 2009)
6) Alan Dalziel1450 (26 Feb 2009)
Given that in most cases purged deletion stubs are the root cause of many documents reappearing in DBs in situations like this, perhaps an option could be added to space savers in Replication Settings to permit/prohibit replication when the gap to the last replication is greater than the deletion stub purge interval?
7) David Hablewitz15116 (27 Feb 2009)
Nice idea. There might be other details for the developers to consider related to when the interval is changed, but you're dead on.
8) Jean-Yves Riverin458 (01 May 2009)
I promote but like Gregg, you should let the NAB replicate locally

9) Jacques Page617 (27 May 2009)
I think letting the NAB replicate locally is not a good Idea in any case. I would rather leave the Copy option.

I know, used wisely, it should not be a problem. But beside the Roge info, I had to deal with the results of an admin who replicated locally, deleted half the address book and .. well, you know the rest.

13 hours later we had it back on the line but all this could have been avoided by simply preventing Local Replication of the NAB..

Maybe I am over cautious. Then again, should we not consider the number of administrators who sometimes are more dangerous for their systems than viruses?
10) Jacques Page617 (27 May 2009)
PS: I like Alan's Idea. Prohibit passed the purge interval.

Perhaps we can add that to all the DB's
11) Patrick Polette219 (18 Jan 2010)
I like Alan's Idea. Prohibit passed the purge interval... as long as one can bypass this denial. It is often useful to be able to replicate documents after deletion stub have been purged (manually or automatically)

I dislike the interdiction of local replica of the NAB, this could be very useful on a normal usage. When an "admin" do such a mistake you described, there is nothing that can prevent it. He could have done it directly on the server that would not have changed anything.
12) Jacques Page617 (10 Feb 2011)
This has been done in 8.5.3! Thank you! Also applicable on all databases. I love it!


Welcome to IdeaJam

You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.

Use IdeaJam to:

  • Collect ideas from employees
  • Solicit feedback and suggestions from employees and customers
  • Run innovation contests and competitions
  • Validate concepts
  • Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top

IdeaJam™ works with:

  • IBM Connections
  • IBM Lotus Quickr
  • Blogs and Wikis
  • Websphere Portal
  • Microsoft Sharepoint
  • and other applications.

IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.

Learn more about IdeaJam >>

IdeaJam developed by

Elguji Software Logo