• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 2763
  • Last Modified:

How to move databases to a server in another domain using adminp

Hello fellow-experts,
I've got a bit of a problem and I can't seem to find where I went wrong righ away and I'm feeling lazy today, so here's the question:

I have two servers:

As you can see they are not in the same notes domain, there is however a cross-certificate present in both directions and server/pbet is in the group OtherDomainServers of server/pbc and vice versa.

The group OtherDomainServers is always in a database's ACL with Manager access.

I've setup a connection document to server/pbc in the address book of server/pbet, with the schedule being disabled, since I don't want automatic replicating, only when I request it.

Now, in the administration client I open server/pbet and go to the Files tab. I select a database to move and specify the destination server: server/pbc.

The move is initiated through adminp, I can see in the administration log the following entries appearing:
- server/pbet performed action "Check access for Non-cluster Move Replica"
- server/pbet performed action "Non Cluster Move Replica".

The first one is okay, but the second one returns an error:
Title: pbet's Address Book
File name: names.nsf; Name: server/pbc; Error: User or server not found in Name and Address Book

I've check against the documentation the following:
1. source and destination server are running adminp
2. the user performing the action has create database rights on the destination server and manager access with delete on the databases on the source server (it's actually an administrator with full rights on both servers)
3. The source server has create replica access in the ACL of the server. (I suppose, if I put the group OtherDomainServers in the section 'Create replica databases' of the server documents, this should be okay)
4. The destination server has at least reader access in the ACL of the replica on the source server. The group OtherDomainServers has manager access to the database and the server belongs to this group, so this should be okay.

Looks like adminp is looking for the name of the destination server in the address book of the source server and of course it doesn't find that name in there, except in the group OtherDomainServers.
What am I forgetting ????
Jean Marie Geeraerts
Jean Marie Geeraerts
  • 12
  • 8
  • 3
1 Solution
you forget to tell us what is the source server and what is the destination :-)

Ok, entering group alone as manager is not enough. To be able to check whether server/pbc is allowed to access server/pbet is not enough to have the cross-cert betwean pbet and pbc. You need the publich key of server/pbc in pbet domains address book.

So my recomandation is to temporary cut'n paste server document of server/pbc from pbc domain address book to the address book of pbet domain.

Also check ACL of admin4.nsf on destination server server/pbet. But this seems to be right, because basic AccessCheck went well.

of course I mean copy&paste of server document and not CUT (huh... :-)

Doesn't Adminp works only in its own domain ???

Check this link for, troubleshooting points http://www-1.ibm.com/support/manager.wss?rs=475&rt=0&org=sims&doc=2A0EE65D8D3217CC802563F10030D4D6

Why don't you replicate the database and delete the original one ?

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Jean Marie GeeraertsApplication EngineerAuthor Commented:
Replicating gives similar problems, I'll try the copy/paste tomorrow and see how far that gets me.

Source server is server/pbet.
Destination server is server/pbc.


According to the documentation this should work across domains, if all necessary requirements are met as stated in the documentation (and repeated in my comment).
Ok, let us wait for the results.
Hello JM,

Please forget this server document copy. This would be too simple :-)
You need Cross-domain Configuration document on the request destination domain side ( pbc )

For the complete list of required tasks look please here:

Good luck,

PS: the reason why I proposed server document copy was, that I had good experience with doing so when this dammed option "CheckPublicKeys" was turned on in our domain. After a while with similar dirty tricks we turned this option again off :-)

Jean Marie GeeraertsApplication EngineerAuthor Commented:
Okay, so I have just added the Administrators group to the "List of administrators who are allowed to create Cross Domain Configuration documents in the Administration Process database:" of the Domino Directory Profile of the address books on both servers.
I've also added the same group to have manager access to the Administration Requests database.

I created an Outbound Cross Domain Configuration document on the source server, server/pbet with the following :
- Domains to submit AdminP requests to: PBC
- List of AdminP requests to submit: Create Replica
- Only submit Create Replica Requests to the domains listed above if the destination server is one of the following: server/pbc (Server Name) - PBC (Domain name)
- List of approved signers: I specified the members of the admin group's fully qualified names here.

I created an Inbound Cross Domain Configuration document on the destination server, server/pbc with the following:
- Receive AdminP requests from domains: pbet
- List of AdminP requests allowed from other domains: Create Replica
- Only allow Create Replica requests if intended for one of the following servers: server/pbc
- List of approved signers : the members of the admin group with their fully distinguished name.

I even copied the server document from the directory of server/pbc to the directory of server/pbet, but I still get exactly the same error.

I can also notice on the server console of the destination server, that a session is opened by the source server, but nothing appears in the administration log.

Any ideas what's still going wrong?
OK, here it comes :-)

fetch binary the server.id from server/pbc to your Notes client. Switch to this server.it on your client and try to open some of the concerned databases on . Observ whole the time live console of ... STOP!

Your destination server name is not found in source request domain address book. You see?

From my point of view was the AdminP request never replicated to admin4.nsf replica on pbc. Or are facts there showing you progress of the request on pbc side?

Jean Marie GeeraertsApplication EngineerAuthor Commented:
That's exactly what's happening, but why?
in the link from Heman are six question from Lotus support. Can you answer all six questions (to you :-)?

My I call you on the phone to discuss this all: not to give you a recomandation, but only in the hope when you explain the problem to me you are geting your answer yourself. May I?

Jean Marie GeeraertsApplication EngineerAuthor Commented:
Let me look at the six questions first and then I'll send you a little mail if you can call me. (The weekend is getting close and I'm working on some other stuff too, so it may have to wait until Monday)
Jean Marie GeeraertsApplication EngineerAuthor Commented:
Okay, so here's an answer to the questions from the troubleshooting link Hemanth sent:

1. Are hierarchical certifiers being used?
-> No
2. How many servers are running ADMINP?
-> There is one server in each domain and they all run AdminP
3. Do all servers have a replica copy of NAMES.NSF, ADMIN4.NSF and CERTLOG.NSF?
-> They are in different domains, so the databases are all there, but they are not replica's of each other.
4. Is replication of these databases working OK. (MUST have current/updated databases).
-> Doesn't matter for this question, imho.
5. What problems are being encountered and with which databases?
-> See problem description.
6. Which server is specified as the Administration server for their NAB? (check Advanced panel under File, Database, Access Control).
-> server/pbet is the administration server for domain pbet and server/pbc is the administration server for domain pbc

Does this help in any way?
Jean Marie GeeraertsApplication EngineerAuthor Commented:
P.S.: Zvonko: you can call me, if I don't answer withing 4 rings, that means I have left the office ;-)
Jean Marie GeeraertsApplication EngineerAuthor Commented:
Okay, so following our phone call I looked into the cross-certification.
From the domino administrator I did the following:
1. With the ID of an administrator for /pbet domain
  - cross-certify on domain level /pbc
  - create a cross-certificate for server/pbc
2. With the ID of an administrator for /pbc domain
  - cross-certify on domain level /pbet
  - create a cross-certificate for server/pbet

The cross-certificate on the server shouldn't be necessary, but when I switched to the server ID and tried to open a database on the other server, it asked me to create a cross-certificate, so apparently it still wasn't locating the server.
I then added the cross-certificates specifically for the servers and tried to open a database using one server's id on the other server, but still no luck.

Am I doing something wrong with the cross-certification procedure?
- In Administration client go to the Configuration tab
- Select Tools, Certification, Cross Certify...
- Select the certifier ID for the current domain as certifier
- Enter the password for the certifier
- Select the certifier ID for the other domain as "ID to be Cross-certified"
- Set the current domain's server as Server to perform the action
- Set the expiration date
- Click Cross Certify

I've also checked the ACL of certlog.nsf to be sure that administrators have manager access to the database.

This way the cross certificate is created in the domino directory and appears under Miscellaneous, Certificates, Notes Cross Certificates.

What's going wrong here ?

Well, I guess I'll read all about it on Monday. I'm of for the weekend now, so I'll see you on Monday...
The procedure is correct, but once you have certified the cert.id of dest server, you have to recertify the dest server.id, etc., with dest cert.id !

Follow the same procedure for other server too.


JM, goto those two domain address books.
Look for Server\Certificates

On pbet domain you have to have this NotesCrossCertificate:

On pbc address book the oposite:

My error on the phone was that when switched to server.id, then this NotesCrossCertificates are not valid for this server common name in your local names.nsf :-)

Anyway, if the upper two NotesCrossCertificates are pressent in both domain address books, then no server recertication is needed. Otherwise would be two domains with hundred server on each side endless recerticated :-)
Also cross certificate on the fly for dialog user would not work without user.id recertification. That can not be true.

Still this error "server/pbc not found in names.nsf" make no sense to me...

Do you have AdjacentDomain documents on both domains?

Good luck,

Jean Marie GeeraertsApplication EngineerAuthor Commented:
Both certifiates were present, but I forgot to define the adjacent domains. -- It's been way too long since I had to do any serious administration, so I'm a bit rusty...
Anyway, I created the adjacent domain documents, but the error still stays the same.

I thought maybe, he's looking in the wrong address book, because I was doing all this with an administator from a third domain, who has administration rights on all domains, so I added the administrator of the source domain to the administration group of the destination domain and tried with this user. Switched to a location where the home server is the source server and used the ID-file of the administrator of the source domain, but all stays the same.

I'm starting to run out of ideas here (maybe I need to take the refresher course in administration).

Do you still have ideas of what could be wrong?
Check this please:
1.) Open on pbet side the names.nsf
2.) Choose Action: EditDirectoryProfile
3.) In the field ListOfAdminsForCrossDomainConfig enter local and remote admin
4.) Do the same on pbc side
5.) Open on pbet side the ADMIN4.NSF
6.) Open view CrossDomainConfiguration
7.) If neither Inbound nor Outbound document is present then select menu: Create->CrossDomainConfiguration
8.) For the content of the fields look here:
9.) Give both sides the same privileges regardless whether Inbound or Outbound is required.
10.) Look on both server documents for the field: Security->WhoIsAllowedToCreateReplicas. I suppose you have your Admin group there. Check the chain of members for this groups.

Good luck,

Jean Marie GeeraertsApplication EngineerAuthor Commented:
Checked all of the above and still come up with the same error. Is this a lost cause ???

Here's my configuration in detail:

Domain pbet:
server document
- Create replica databases : Administrators, OtherDomainServers
- Administrators : contains all administrators, local and from other domains
- OtherDomainServers : contains the servernames of all other servers
- connection document to server in domain pbc
- Adjacent domain PBC, without restrictions
Directory Profile:
- Domain defined : pbet
- List of administrators.... : Administrators
Cross certification:
- to domain pbc

Exactly the same is valid for pbc.
Have I left anything out ?
Jean Marie GeeraertsApplication EngineerAuthor Commented:
Yes, I forgot to mention the cross domain configuration in admin4.nsf:
- Inbound:
      . Receive AdminP request from domains: pbc
      . List of AdminP requests allowed : Create Replica
      . Only allow Create Replica ... : server/pbet
      . List of approved signers : Administrators, OtherDomainServers
- Outbound:
      . Domains to submit AdminP requests to : pbc
      . List of AdminP requests to submit : Create Replica
      . Only submit ... : Server server/pbc, domain pbc
      . List of approved signers : Administrators, OtherDomainServers

The same two documents exist in pbc (with mirrored values of course).
Jean Marie GeeraertsApplication EngineerAuthor Commented:
We didn't really solve my problem here, but I will still award points for the effort taken to help me here.
Thanks zvonko !!

FYI: I bypassed the problem by having the NT adminstrator create a temporary trust between the NT domains and copied the files through the operating system.
Then shutdown the old server and had the temporary trusts removed.

Thank you JM for this :-)

At the moment I have very little time, so I am happy at least this is no more a question. It is a pity because there will not be as soon a requirement to test this adminp requests between domains.
Still I keep in mind your question with elegant mounting of shared drives on Domino running as service. I have an idea but no time to test :(

Jean Marie GeeraertsApplication EngineerAuthor Commented:
So maybe, I can move up the ladder in EE in the meantime :-) (Getting close to the #5 spot)
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 12
  • 8
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now