About OD Replica

It does not copy the home directories. Open Directory replication only replicates the account's LDAP and password data, not files and folders (such as the home folder).

There are a number of options that may improve things; which is best will depend on how your users use their accounts.

If you have some users that just work in the 2nd department, a good option would be to move their home folders to the 2nd department server. A mini isn't really ideal as a home folder server, but it's probably going to be faster than mounting the home over the 2Mb link. Setting this up is fairly easy: connect to the mini with Server Admin, make sure the /Users folder is shared, and set it to automount in your network domain (with the options set to AFP and Use for user home folders...). Make sure the AFP service is running on the Mini. Then, in Workgroup manager, select the users you want to move, select the Home tab, and then select the mini server's Users folder from the list (if it's not there, something went wrong; don't try to add it with the "+" button). You will probably also want to move the users' data over (this procedure hasn't actually moved the home folder contents, just where the user will look for it). When moving home folders, be sure to preserve file&folder ownership.

Another option is to set up mobile accounts for your users. This keeps the user's home folder on the client computer, with an option to sync it with the one on the server. Depending on usage patterns, this may or may not be faster than accessing the home folder over the network. You set this up in Workgroup Manager -> Preferences -> Mobility.

If you think either or both of these options would help, I'd recommend picking one or two users to test on, and try various options (moving to the mini, trying with and without mobility, different sync policies, etc) to see what works best before rolling this out to everyone.

I would leave the 2nd department mini a replica; there's no problem at all setting up automounted share points, setting home folders, etc on a replica (or even a "connected" server that's neither master nor replica) -- when you define an automount it asks for your directory administrator name and password, and uses that to connect to the master and make the necessary changes there.

The advantage of this over two separate masters is that you don't have nearly as much work and complexity trying to keep your user setups in sync, syncing files, etc between the two locations; the disadvantage is that each user'd home folder is on one server or the other, so when users are visiting the "other" department, home folder access will be slow (although mobile accounts would mitigate this).

Using the same name & password on the two servers shouldn't be a problem unless it conflicts with the directory admin's name (by default this is diradmin/Directory Administrator). DNS is a much more likely source of trouble.

First, check the full hostnames of the two servers by running the "hostname" Terminal command on each of them. Then, make sure both servers can look themselves and the other, both forward (name -> IP address) and reverse (IP number -> name). I'm not sure I understood what you said about the names of the two servers, but assuming their names are sibeliusopisto.internal (IP address 10.0.0.1) and sibeliusopisto.janakkala (IP address 192.168.0.0.1), the test should look something like this:

$ host sibeliusopisto.internal
host sibeliusopisto.internal has address 10.0.0.1
$ host 10.0.0.1
1.0.0.10.in-addr.arpa domain name pointer sibeliusopisto.internal
$ host sibeliusopisto.janakkala
host sibeliusopisto.janakkala has address 192.168.0.0.1
$ host 192.168.0.0.1
1.0.168.192.in-addr.arpa domain name pointer sibeliusopisto.janakkala

Again, run this test on both servers (and probably a client in each department as well, to make sure everyone else can find both servers). You should be getting full, consistent information everywhere, or else you're likely to run into trouble.

Also, try running Workgroup Manager directly on the master server, and rather than putting anything into the Connect dialog, select Server > View Directories from the menu. Does that let you get into the server's directories?

I'll need some more info to make real recommendations here. First, Why are there two A records for sibeliusopisto.internal?

VincensoXFIN wrote:
; <<>> DiG 9.6.0-APPLE-P2 <<>> -x 172.17.6.90 +multiline +nocomments +nocmd +noquestion +nostats +search
;; global options: +cmd
90.6.17.172.in-addr.arpa. 10800 IN PTR sibeliusopisto.internal.
90.6.17.172.in-addr.arpa. 10800 IN NS sibeliusopisto.internal.
sibeliusopisto.internal. 10800 IN A 172.17.6.90
sibeliusopisto.internal. 10800 IN A 172.17.144.160

Is one of those really the address for sibeliusopisto.janakkala? The only time you should have multiple A records for the same DNS name is when that server has multiple IP addresses (i.e. several network interfaces), or you're doing something like DNS-based load balancing (which you to not want on an OD master).

Second, what normally provides DNS service at the two departments? Are there existing DNS servers, or is it just the OS X servers providing DNS? If there are multiple servers, you need to do some extra work to keep them all consistent, or you'll get weird results depending on which server happens to get queried...

Third, tell me about the network & routing setup between the two departments. Are they both using private (e.g. 172.16-31.x.x) addresses? What address ranges are used at each department? Can they reach each other's private addresses, e.g. by something like a VPN connection?

Finally, what're the IP addresses and configured hostnames (i.e. what does it print when you run the "hostname" command) of the two servers (so I can include them in recommendations)?

Thanks for the info; I'm still a little confused about the setup, but you've given me enough info to start making recommendations. Since there's another DNS in the 144 network (run by the other department), I'd try to get together with them and make sure you're both serving consistent information: either make the entries you need in their DNS and have all of your computers use their server, or if you want to run your own DNS server make sure they have all of your entries AND you have all of theirs. As long as the routing is set up properly, there should be no problem with computers in the .6 network using a DNS server in the .144 network.

As for what entries are needed, you need at least the forward and reverse entries for both servers:
sibeliusopisto.internal. A 172.17.6.90
sibeliusopisto.janakkala. A 172.17.6.95
90.6.17.172.in-addr.arpa. PTR sibeliusopisto.internal.
95.6.17.172.in-addr.arpa. PTR sibeliusopisto.janakkala.

(note: how these are organized into zones is actually somewhat arbitrary, as long as all of the right records are there.)

How does the main server come to have the 172.17.144.160 address -- is this the second ethernet port, or something like that? If so, I'm not sure of the best way to handle it. Adding more forward and reverse records is probably good, but I haven't tried running an OD master this way so I can't be sure it'll work right:
sibeliusopisto.internal. A 172.17.144.160
160.144.17.172.in-addr.arpa. PTR sibeliusopisto.internal.

Another thing I'm a little confused by is that the 172.17.6.x network seems to be split between your two two departments, even though they're connected by a WAN link -- normally, a link like that would be a routed connection, so the networks at the two ends would need separate network addresses. Do you know enough about the setup to clarify?

Now, as to how to straighten out the current mess: I'm pretty sure you'll need to switch the current replica back to standalone, but that may not entirely undo the mess it made when it replicated without proper DNS (note: do not simply shut the replica down, use Server Admin to explicitly change its role to "Standalone"). If the master doesn't start working after the replica is demoted, additional cleanup may be needed; one option would be to Server Admin to archive the master's data, then switch it to standalone (wiping out its network account database), re-promote it to master, and then restore the archive. If you haven't invested too much in the master's account setup yet, the best option might be to demote everything to standalone, then start over.

I'd also recommend rethinking your domain names; in general, you're better off using a consistent domain suffix with different prefixes for the various computers; having two computers with the same "first name" (sibeliusopisto) may actually be part of the problem. The master's name cannot be easily changes (unless you destroy the OD master and start over), but changing the mini's name is reasonably easy (as long as it's not set up as a replica at the time). Set up the DNS for its new name, then use the command "sudo changeip 172.17.6.95 172.17.6.95 sibeliusopisto.janakkala newname.internal" to switch the server's own idea of what its name is.