MFA Server Migration Information & Process

Answers & Notes To Migration FAQ's

• An Identity Automation Support Engineer will assist in the migration process.
• There is no downtime. The current server will remain online during the setup and testing of the new MFA server. Downtime will be minimally affected depending if the servers will be renamed and re-IP'd or if new server name(s) and IPs are used. Downtime is especially minimized through our use of cached credentials.
• If you have an older version of the MFA server, it will be easier to install your current version of the MFA server onto the new server and incrementally upgrade after the migration.
• The process takes approximately 2 hours, give or take.

What's Needed for a Successful Migration

• A fully stood up Windows server according to our requirements.
• Any and all MFA software related passwords (this includes the one_sys_admin account, the sa or dedicated SQL account used to connect to the SQL MFA database or a DBA to be available for the call if those passwords cannot be made available or shared for the call).
• The installer of your current MFA server version.
  • Note: If you no longer have it, or it is no longer available for public download from our Downloads, please let us know and we will get that for you.
• A test client for checking the new server's connection after the migration

Generic Migration Steps

1. Create a backup of the SQL MFA database and restore it to the new server (if migrating the SQL database), remaking 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 from Step 2.
   a. Connect the new MFA server installation to the newly restored database from Step 1.

   
   

4. Create a test connection to the server with a test client to verify the new server is working.

   • Note: If we will be re-IPing or reusing 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.*
   
   

5. 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 rename or re-IP of the new server is necessary, it would happen at this point.

Updating the Server Sync URL

When using a new name/IP address for the new MFA server, there are 2 options for updating the sync URL for the MFA clients.

Update the old MFA server policy to point to the new server

Clients automatically sync with the server every 2 hours (starting from when they're turned ON), unless specified otherwise. This is more automatic and hands-off, but can take longer than a GPO push.

With the MFA policy method of redirection, we generally suggest a grace period of a few days before shutting down the old server.

Update the ServiceURL registry value through Group Policy

The client registry value HKLM\Software\Foray\ServiceURL can be updated and pushed to the clients.

Since the migration maintains the original database and settings, nothing will change for the clients or 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%'))