Migration from 3.0 to 3.5/4.0 version, Multiple Domain Controllers
This procedure allows to migrate a running Samba Active Directory database from a Zentyal 3.0 to a clean install of Zentyal 3.5 or 4.0. The database migration keeps all AD information, including users, groups, passwords, computers, etc. The main benefit of this migration is that you won't need to recreate users and groups, neither rejoin the domain for each of your workstations.
This scenario assumes we have 2 domain controllers, and we will migrate both of them. If you only have one DC, the procedure would be the same, applying the commands only for one node, check Migration from 3.0 to 3.5/4.0 version, Single Domain Controller
The procedure assumes we will be changing the IP addresses from:
- 192.168.15.1 old Zentyal 3.0 DC
- 192.168.15.10 old Zentyal 3.0 ADC
- 192.168.15.30 new Zentyal 3.5/4.0 DC
- 192.168.15.40 new Zentyal 3.5/4.0 ADC
So we will start from two DC's with Zentyal 3.0 :
First one
Second one
1. Perform a clean install of Zentyal 3.5/4.0. Use *exactly* the same hostname and domainname.
Note1: Active Directory is case insensitive, so don't worry about capitalization
Note2: In case that mail, mailfilter or Jabber were installed on 3.0, please keep in mind that its attributes were stored in OpenLDAP in Zentyal 3.0, so that information won't be migrated. In order to migrate this kind of data please review the documentation about DC environment procedure.
Note3: Zarafa is not available in Zentyal 3.5/4.0, we strongly recommend you to upgrade to Zentyal OpenChange.
2. Configure Samba modules in each Zentyal 3.5/4.0 in the same way they were configured in 3.0: create a new (temporal) Active Directory domain with the same name, configure the first node as "Standalone" and the second node as "Additional DC" joining the temporal domain.
Note4: While Administrator password was available in Zentyal 3.0 under /var/lib/zentyal/conf/samba.passwd, on 3.5/4.0 you will have to reset the password of the Administrator user to a known one using the Zentyal interface itself or RSAT tools.
First one
Second one
3. Stop DNS and Samba modules in the old (3.0) servers
4. Stop DNS and Samba modules in the new (3.5/4.0) servers
5. For each old (3.0) node, transfer the Samba private directory to the new corresponding node
Note5: We recommend using tar + scp as it maintains ownership, permissions and links.
6. For each new (3.5/4.0) server, uncompress the tarball in the Samba directory
Note6: The Samba database directory path has changed from /opt/samba4/private in Zentyal 3.0 to /var/lib/samba/private in Zentyal 3.5/4.0.
Note7: Make sure hardlinks are preserved between /var/lib/samba/private/sam.ldb.d/*DNS* and /var/lib/samba/private/dns/sam.ldb.d/*DNS* as explained here DNS_Backend_BIND
7. Now is time to check (and probably fix inconsistences) on the databases, so we will be running in each node
8. And we are ready to start stopped modules in the new (3.5/4.0) servers.
Note8: samba module will fail to start ('+' invalid group), don't worry about this for now, we will fix later on
9. As we changed the IP addresses, we need to check that information in Active Directory is correct on the first node (Zentyal 3.5/4.0 DC). We will run:
In case that you may need to change any , we will do it this way (just changing any appropriate field):
We will repeat this check on the second controller as well.
Note9: In the case you can't afford to change Domain Controllers IP addresses, you can always switch off the 3.0 ones, and change IP of new ones back to the original (using Zentyal GUI), and using this step to confirm that DNS information in samba is accurate.
10. Check on both nodes that replication is working properly with samba-tool drs showrepl
11. Some Unix attributes, like uidNumber for users and gidNumber for groups, in Zentyal 3.0 were stored in OpenLDAP so they are not present in the Samba database, we need these to be able to set shared folder permissions in the Linux system. We will use the following script to create these missing attributes:
Note10: As these attributes are replicated through the Active Directory, you just need to run the script in one node
12. To finish, we just need to restart again the samba module in each server and this time, it will finish gracefully:
13. In order to migrate sysvol data and any share that you might have configured , please refer to the single DC environment procedure.
Disclaimer
We would like to thank Sergio Pinto from Microblau, Zentyal Partners, for his collaboration in validating this procedure.