MFA Server Migration Information & Process

Server migrations for the MFA server software can be an easy process. Below are a few of the answer to some of our most frequently asked questions about migrations, followed by the basic steps we take to perform a migration.

Generic Migration Steps

1. Create a backup of the SQL MFA database and restore it to the new server (if migrating SQL), re-making the SQL database accounts as necessary.
2. Create a backup of the MFA Server Encryption key and transfer it to the new server.
3. Install the current version of the MFA server to the new Windows server (it's easier to migrate to the same version) and restore the transferred key.
4. Connect the new MFA server installation to the newly restored database from Step 1.
5. Create a test connection to the server with a client, if we are able, to verify the new server is working, among other health checks performed along the way.

Note: If we will be re-IPing or re-using the old server's FQDN, that's more than possible, we'll just need to wait until the end, after the final upgrade to the latest MFA server version.

6. Create new backups of the new MFA installation and incrementally upgrade through MFA server versions if yours is older than the latest.

After The Migration

Once the server migration is complete, we'll perform a quick health check with a test computer to verify that it's working and can connect with the new server properly.

Following the connection test, if a re-naming or re-IP of the new server is necessary, it would happen at this point.

If we are not changing the new server name and redirecting the clients to the new server instead, that can be done either through GPO or the MFA policies to update the ServiceURL registry key. Once received, the clients will begin synchronizing with the new server. When this is done through the MFA policy, its time to take effect varies. Clients automatically sync with the server every 2 hours (when they're ON), unless specified otherwise. This can take longer than a GPO push, but it's more hands-off. With the MFA policy method of redirection, we generally suggest an allowance of a few days before shutting down the old server.

Since the migration maintains the original database and settings, nothing will change for the clients and end user experience.

How To Tell If The Clients Are Syncing

Unfortunately, the portal does not have a dedicated function for us to explicitly view this. Below is a SQL query that can help give a close estimation of how many out of your total clients have synchronized with the server within the last 7 days. This number can be changed to any whole number in the (getDate()-7) condition.

Additionally, the following query excludes mobile devices (to the best of its ability) from the results as phones do not synchronize with the server and can skew the numbers.

USE [ONE]
SELECT
	COUNT(
		case
		when (app_version NOT LIKE '2.%') or (os_name NOT LIKE '%mobile%')
		then 1
		else null
		end	
	) AS 'Total Clients'
	
	, COUNT(
		case 
		when lastPolicySyncDate <= (GetDate()-7) 
			and ((app_version NOT LIKE '2.%') or (os_name NOT LIKE '%mobile%'))
		then 1 
		else null 
		end
	) AS 'Clients Synchronized'
	
	, COUNT(
		case 
		when (lastPolicySyncDate <= (GetDate()-365)) 
			and ((app_version NOT LIKE '2.%') or (os_name NOT LIKE '%mobile%'))
		then 1 
		else null 
		end
	) AS 'Clients NOT synced in 1+ years'
	
FROM Workstations

You'll notice a third column is displayed from the query above. This will help differentiate the client computers that have not synchronized in a year (365 days) or more's time. The query below will list those machines. Mobile devices are also excluded from these results.

USE [ONE]
SELECT '' AS 'CLIENTS NOT SYNCED IN 1+ YEARS'
	, workstation_id
	, fqdn
	, computerDN 
	FROM Workstations
	WHERE lastPolicySyncDate <= (GetDate()-365) 
		AND ((app_version NOT LIKE '2.%') or (os_name NOT LIKE '%mobile%'))