restore names.nsf on cluster domino

(sorry for my english by google translate)
i have accidentally rename de "domino admin" security group and now
I am no more domino administrator.
I have such a backup of names.nsf file but there is another problem:
my domino farm is a cluster of 4 server 8.5.3.
if I restore the file and let the servers to replicate, they will overwrite the restored names.nsf with what for them is the most current and back to have the original problem.
After thinking about how I think of all the servers shut down and restore the names of one of these then?
sorelleramondaAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

cohalexCommented:
Indeed, if you will simply restore the names.nsf on your current server, it will be updated through replication from the other servers in the cluster.

You could:
1. disable replication and cluster replication on your problem server
2. replace the names.nsf from backup (while domino is down)
3. start domino, edit & save the admin group to have new timestamp
4. enable again replication and cluster replication

To disable standard replication, edit the notes.ini file and find the SERVERTASKS parameter, it will be something like this:
SERVERTASKS=Update,Replica,Router,AMgr,AdminP,CalConn,Sched,HTTP,RnRMgr
-> remove Replica from the list

To disable cluster replication (different task) - edit the notes.ini file and add entries:
DISABLE_CLUSTER_REPLICATOR=1


sorelleramondaAuthor Commented:
console log:
bla bla
starting replication with server ****  
bla bla
......replication is initiated, however, and has aligned the file to that of the other servers.
sorelleramondaAuthor Commented:
DISABLE_CLUSTER_REPLICATOR=1
 remove Replica from the list
is not enough
Learn SQL Server Core 2016

This course will introduce you to SQL Server Core 2016, as well as teach you about SSMS, data tools, installation, server configuration, using Management Studio, and writing and executing queries.

cohalexCommented:
You are correct, the replication was initiated from the other cluster or domain servers and unfortunately this can't be stopped.

As this article explains, there is no way to fully disable replication:
https://www-304.ibm.com/support/docview.wss?uid=swg21199669
larsberntropCommented:
1st option:

You should have an Administrator ID (if you first setup the Domain, this is generated alogside with the first certifer and the first server ID)

Use that to recreate the domino admin group you accidentally deleted.

2nd option:
Bring down one of the servers.  ater it has stopped, copy the names.nsf to a local notes install with the same version as the stopped server. Put it in a subdirectory so as not to overwrite another names.nsf.  Copy the server id to the same location.  create a zip file so you have a backup. Start the Notes client, and switch to the server ID.  open the copied names .nsf, and recreate the group you accidentally deleted.  Close the notes client, and use the windows task manager to verify it has completely finished (no notes*.exe or nlnotes.exe in the process list)

Copy the names.nsf back to the server data directory, and start the Domino server.

Note: by recreating I mean that you should create a new document, and populate it just how the old one was populated. dont copy and pste from a backup.
cohalexCommented:
One more possibility would be to change the ReplicaID of the restored names.nsf.
The tool should allow you to change back the ReplicaID to a desired value, so you can restore it back after the problem is fixed.

This tool should do it - ANTRID:
http://www.rprsystems.com/index.html
doninjaCommented:
Another quick possibility if you just want to restore a group is to open the old names.nsf in a notes client, and make a copy of the group using the same name. This will create a new document with a different universal id so it will not be associated with the deletion stub.
You should have 2 group documents with the same name.

now just place onto one of the cluster servers and start up.
It will initially see two groups but will then remove one as part of replication.

You should then only have one Domain Admin group left and can access the server

All serevr documents access the group by name not the universalID.
You may need to restart servers once more once back down to a single group as some server security is cached at server start.
cohalexCommented:
@doninja
It might not work if the ACL of the local restored names.nsf does not list him explicitly with sufficient privileges.
Worth trying though.
doninjaCommented:
@cohalex
Agree but usually it's possible to find some ones ID that has enough local access to create a group document.
Depends if addressbook has enforce consistent ACL.

Also if using a local admin client you can enable full access control which sometimes works on a local database.
Finally although not recommended you can try a servers ID as it may not be listed in ACL explicitly as a server but in a mixed group.

Finaly on what some others have suggested about stopping replication after replacing the names.nsf, but do this on server disconnected from the network with a local client installed so you can copy the group document.
Or if not possible, on one cluster server, temporarily change DNS or routing so it cannot contact the other servers but your client can still connect to copy the group document.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
larsberntropCommented:
@cohalex:  BRR.  fiddling with replica ID on the names.nsf of the Domain is seriusly suspect voodoo.

I'd try my steps first.
cohalexCommented:
@larsberntrop
That's right, it's tricky and should be used with care and pre-testing.

We are regularly manipulating the ReplicaID for restored user mail files, before putting them under the Data directory, and we never had issues.
Never did it with names.nsf though.
sorelleramondaAuthor Commented:
yes, the marker has names.nsf "enforce consistent ACL addressbook has" active
 and yes, to isolate the server from the domain "trust networks" and connect it to a "remote network" is the correct solution to avoid repeats.
 Isolated on the server I have available certified ID, Lotus Domino Administrator client and Names.nsf restored from backup.
 Once you make the change that interests me in line I put the server and all replicated the Names.nsf correct.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Lotus IBM

From novice to tech pro — start learning today.