Preventing a change to the main server replication formula

HCL Domino Domino Forum
1

Not an admin person, but was tasked with this. Asking for some help.

We have a main server, with numerous laptops set up as servers with local replicas and local replication formulas. The formulas are pretty simple "Select * where SubscriberId = “ADJ7L9999"”. This being the device name or server name of the individual laptop.

The main server has no replication formula, and should not have a replication formula. But we had an incident several years ago when someone manually setting up a laptop replica accidentally applied the replication formula to the server replica instead and ran the replication and, long story short, we ended up losing data.

So we automated the setting of the replication formula. The tech will create the local replica, upon opening the start form of the database, code in the onLoad runs. The code verifies that it is not on the main server, gets the laptop hardware name and creates the formula. This was set up to minimise the possibility of human error in where the formula is created.

A few days ago, a user reports a document that can’t be found. Sure enough, someone has somehow put a replication formula by accident on the server replica. The server replica was not replicated, only a couple of the laptops replicated, so no data was lost upon removal of the replication formula and subsequent laptop replications.

So my question is: Is there a simple and effective way to prevent a replication formula from being created and/or applied to a server database, while still being able to manage local replicas and their formulas?

Any ideas? Suggestions? Hope I’ve given enough info.

2

Subject: Preventing a change to the main server replication formula

It was likely one of our hardware techs who sets up the laptops and creates new replicas on those laptops. Part of the problem is that no one has owned up to it.

We want them to be able to create new replicas, but we don’t want them to be able to manually add a replication formula to the server replica. If that prevents them from adding a replication formula to the local replica, that’s fine too. They also need to be able to delete or overwrite databases.

The end users need to create and delete documents within those databases.

And these are stand alone databases/apps.

3

Subject: ok, but the Address Book can be special.

A domain-wide address book, you should be able to clamp its accesses down. Manager / Designer access is not normally needed for this database.

Y’can make local replicas, sure. And I wouldn’t even put it past people to need to change some things on the Address Book. But changing replication formulas, I’m pretty sure that’ll involve higher accesses, around Manager or Designer?

4

Subject: Find that someone and revoke their high access to the Address Book?

I don’t see a reason why the Address Book should grant deletion privileges to people who do this. I also don’t see why they should have Manager or Designer access to the source Address Book.