3

Background:

Two Macs which are running the same Operation System: Mac OS X 10.11.6, OS X Server 5.1.

When I try to set up the second Mac as a replica server, it always shows an error as the following picture:

Picture with error

Then I tried to enter the following command in Terminal from the intended replica server:

sudo /usr/sbin/slapconfig -preflightreplica 192.168.8.107 <directoryadminuser>  

I always get this error message:

2016-08-13 07:20:58 +0000 NSMutableDictionary *_getRootDSE(const char *): rootDSE not found
2016-08-13 07:20:58 +0000 Error: Unable to determine the master's software version.

Both servers are set to be allowed to remote login via ssh as administrators.

Getting the version returns:

$:sudo slapconfig -ver
LDAP Setup Tool (slapconfig), Apple, Inc.,  Version 10.11

And I tried all the methods from these addresses, but none of them worked for me:

Anyone can share some advices with me? Really appreciated.

  • Thanks a lot, klanomath. Here is the correct address which I missed: walcott.com/blog/… – Vincent Aug 13 '16 at 14:59
  • Did you find a solution that worked for you? – Harv Sep 14 '17 at 22:18
  • @Harv Unfortunately not... – Vincent Sep 15 '17 at 13:34
1

Note that although I got the same error, I am on macOS 10.12.6 and Server 5.3.1.

I documented what I did, step-by-step. I'm not exactly sure which of these steps made the difference but my hope is that this will help someone.

In my case I have a server on the west-coast and another on the east-coast using a site-to-site VPN and two different /24 IP subnets, so communication can happen but replication obviously failed. Before starting I recommend having the same macOS version/build numbers as well as the same server.app version.

  1. Blow away OD on both sides. I used $ sudo slapconfig -destroyldapserver. Make sure to have a backup of your data first.

  2. Get DNS working perfectly. This involved going through Server.app's "edit hostname" process and (in my case) using a FQDN. When you change the hostname and you're asked to select whether the server is operating on LAN-only, LAN + VPN, or Internet, select either the LAN + VPN or Internet options. This is so that the server creates DNS zones that aren't ".local", which I think is one of the core issues that prevented replication working, because .local is for Bonjour and I think that messes things up.

    So I changed the computer name to "Company X Vancouver Server" and the hostname to vanserv.clientcompany.com. Restarted the server, checked things out with $ changeip -checkhostname and verified forwards and backwards DNS are working with the "host" tool, looking up both the IP and the hostname, and making sure it resolved both ways. Set the server to use 127.0.0.1 for DNS first, then its other IP (192.168.10.10), then local next-hop router, then public DNS. Restart.

    I did exactly the same thing on the east-coast server, calling it "Company X Toronto Server", and hostname "torserv.clientcompany.com".

    I made sure there were entries on both servers for the other server. So vanserv has vanserv.clientcompany.com (192.168.10.10) and torserv.clientcompany.com (192.168.20.10). Checked forward- and reverse- DNS lookups for the other server on both. And pinging torserv from vanserv would resolve and return packets, and vice-versa.

    I set both servers to "perform lookups for only some clients" - and I set that to the server itself, only. This is so that DNS lookups for the company's domain, clientcompany.com, don't go to the server and fail to resolve, such as a staff member at the office visiting the company's website.

  3. Create the primary OD, but leave it empty. Restart. Join the replica to it using the FQDN - in this case the OD was created on vanserv and I joined torserv to it as a replica. I used the FQDN vanserv.clientcompany.com instead of the IP address. Success!

  4. Populate the OD with data, make sure it replicates successfully. It did!

  5. Add in locales (optional) - I defined 192.168.20.0 as Toronto and set that server to torserv.clientcompany.com, and Vancouver as 192.168.10.0/24 and set that server to vanserv.clientcompany.com.

So my suspicion is that the "network problem" as well as the "different version of macOS" errors I was getting in the server.app GUI really were just a lack of good communication happening due to DNS being configured in a way that server.app didn't like.

0

Yes - this worked for me on Sierra with a brand new directory. https://support.apple.com/en-us/HT204880

  • Welcome to Ask Different. It's not advisable to provide a link only answer even though it answer the question. Links go stale, meaning the answer will no longer be useful. It's best to summarize the answer and provide the link as a citation or for more detail. – Allan Oct 30 '16 at 23:02
  • Thank you, sir. I did try this before, but no luck. – Vincent Oct 31 '16 at 14:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .