How does a multi-server installation replication work?
By leveraging the functionalities of Active Directory and AD LDS technology, Mi-Token provides the possibility of having two or more servers running the software and sharing the tokens database. Each server will hold a copy of the tokens database and it will be replicated in an N-to-N fashion using the AD LDS replication mechanism.
In a replication scheme, one server will be the Master and the rest will be labeled (and installed) as replicas of the master. As AD LDS is a subset of AD, an LDS database will run and expose the services using a port number (5000 by default) and each subsequent replica will run a copy of its own in the same port number. The Mi-Token tokens database will have a Schema Master and a Naming Master role defined, usually the first server installed. For instance, if we have servers A, B, and C, assuming A is the master (also the Schema and Naming master), the replication mechanism will have each replica server replicate between each other, as shown below:
What to do if the master server fails?
If the master server fails, the secondary (third, and so on) servers can continue working, but just as it happens with an AD DC, the Mi-Token authentication server must point to a working server, usually the next in line.
In the following example, we have two servers MTMaster and MTSec (master and secondary, correspondingly). The Master server is set to manage the tokens database, the secondary server is also pointing to MTMaster:
If the server MTMaster fails or loses network connection or is unable to serve requests over port 5000, the Authentication clients will fail and will continue failing if they point automatically to the secondary server without switching the working server to point to another LDS instance.
When the primary server fails, open the Active Directory Users and Computers Window. For demonstration purposes, MTMaster has been turned off. When we browse the Users and Computers Window in the secondary server, we find the tokens node showing an error:
In the screenshot above, we can see that there is an LDAP connection error to MTMaster, therefore the tokens data is not available. To fix this, click the "Connect manually..." button. This will bring a configuration dialog as follows (please be patient, it make take a few minutes):
This dialog will show potential servers that may become the current tokens manager. In the case above only MTSEC can do the job, as is the only one showing a configuration set. When we select it, we notice the nostname text field updates automatically to the selected server:
Click "Connect". This will set the connection to the selected server's tokens database and the program will bring the Users and Computers Window back, refreshing it as well.
Notice the Tokens node shows mtsec next to the Tokens label, stating that it is connected to that instance. If you use more than one server at a time, usually there is no need to manually configure one by one all of them, as this configuration will replicate as well to the rest of the servers, however, make sure it has been replicated if one of your servers is not working properly.
What to do if the master server cannot be recovered?
By following the instructions from the previous section, you changed what server is the current tokens manager, however in terms of the AD LDS scheme, the master and FSMO roles holder is still the failing server. If the non-working server is no longer functional and cannot be brought back, you may decommission it according to your Organization's policies and procedures, and then follow the instructions of the article below (from our FAQ) to manually remove the server from the replication scheme and promote any other working server as the master (and FSMO holder).
Remove a failed AD/LDS server from an Instance Set
What to do if the failing server is on again?
If the failing server comes back online and it is still the master and FSMO roles holder, follow the next steps to select it as the primary server (tokens manager):
Right-click the tokens node and select Properties
In the properties auxiliary window, navigate to the Domain Settings tab:
Right-click the domain where the primary server must be reset and select "Configure Mi-Token..."
Select the desired server from the servers combobox in the Settings Dialog:
Click Apply, this will close the Dialog and update the domain Settings. You should see the primary server reset to the master:
Click OK to close the Properties Auxiliary Window. This is done only once, as the setting will replicate to all the servers.
The master server is now the primary (manager) server once more.