Downgrading an Active Directory DC
In general, there are two ways to upgrade or downgrade Samba AD DC. The first way is to replace the packages or binaries 'in-place', which may require additional steps to operate correctly. The second way is to join (or re-join) a new domain controller and optionally demoting any unused controllers.
Reliability of the two methods
For the join method, this is intended to always work as newer versions should return more consistent results via replication and so the older version is more permissive. In practice, this method may be trickier due to needing orchestration, DNS record conflicts, naming and other topology related artifacts. It may take some additional time to stabilize across the network.
The 'in-place' method is described on the Updating Samba page as a standard method of updating. While updates tend to have code within the Samba daemon to auto-update underlying formats and discrepancies, or rely on the Samba AD DC database check tool, downgrades of certain versions may require additional tools to run (described on this page).
Downgrade compatibility (4.7 - 4.11)
Before downgrading a DC with an FSMO role, if you want to keep the database Samba is currently using, you have to run a database format downgrade tool. Depending on which version you're downgrading from and to, you need to run a different tool. This table shows you which:
|to \ from||4.11||4.10||4.9||4.8||4.7|
In 4.8 and 4.11, non-optional database format updates were introduced. When Samba encounters an older database version than the newest one it can operate with, it repacks and reconfigures the database for the newest version. Tools are provided to downgrade a database again, but they must be run manually before downgrading Samba. If a user upgrades, then runs Samba (triggering the database format upgrade), stops Samba, downgrades without running downgrade tool, then runs Samba again, Samba won't be able to read the database.
In versions 4.8, 4.9, and 4.10, a python tool called undoguididx is available to downgrade the database if the user is planning to downgrade to 4.7 or earlier. In versions 4.11 and later, the tool is called downgradedatabase and performs the same task for downgrading to 4.10 or earlier. Using any downgrade tool is always safe. If in doubt, just run it before downgrading and the earlier version of Samba will repack/reconfigure as appropriate if necessary.
This hassle is all avoided with a well maintained backup procedure.
These scripts change to database format to conform to Samba 4.7 and prior. Upon starting the downgraded code using Samba, an auto-upgrade to the appropriate format for the running version may occur. Re-indexing may also occur and so in general, the domain controller may be running but out of operation for a brief period of time (auto-upgrade should take a few minutes at most for even very large instances).
Incorrect binary packing format
The following error occurs when starting Samba with the wrong database formats. The error message which is currently present is:
ldb: Invalid data for index DN=@BASEINFO =============================================================== INTERNAL ERROR: Signal 11 in pid XXXX (4.9.XXX) Please read the Trouble-Shooting section of the Samba HOWTO ===============================================================
Make sure to run the downgradedatabase script before starting Samba with this version. In future, patched versions of older major releases may have slightly differing error messages.
Python 2 vs Python 3
Traceback (most recent call last): File "source4/scripting/bin/sambadowngradedatabase", line 10, in <module> import samba File "bin/python/samba/__init__.py", line 28, in <module> import ldb ImportError: dynamic module does not define module export function (PyInit_ldb)
If the following error occurs, try using a different version of Python than the one set by default.
Samba failed to prime database, error code 22
If this happens after downgrading Samba, it means your database was either provisioned with the version of Samba you downgraded from, or the database was upgraded by that version (or a higher one). Hopefully you made a backup of your database before upgrading, in which case you restore it. Otherwise, you can return to the version of Samba you downgraded from and run the sambadowngradedatabase script. You can provide it with either:
1. Path to target database, with: "-H /usr/local/samba/private/sam.ldb" (might be different path)
2. Your smb.conf file, with: "-s /usr/local/etc/smb.conf" (might be different path)
The script won't work on the version of Samba experiencing the error because it doesn't know how to read the new database format. You have to upgrade Samba, downgrade the database, then downgrade Samba. In the future, backup your database before upgrading to avoid this hassle.