There are multiple reasons to migrate UEM servers, e.g. move to a private cloud, move from phyiscal to virtual appliance, installing fresh VMs etc. Have you every wondered how to migrate you favorite UEM solution without downtime, and with 100% confidence?
I am giving you some tips and tricks to achieve the following goals:
- Migration with zero downtime
- Full testing of your MDM configurations, policies before the production cutover
- Efficient rollback in case of downtime
- Migrate all the data (apps, configurations, policies, devices, users etc.)
Safe migration to a new environment – geese crossing the road with 100% confidence!
What UEM data should be migrated ?
The following data buckets should be considered:
- Devices and their logs
- Audit logs
- Configuration, policies
- Applications
- System configuration (IP routes, certificates etc.)
How shall to transfer the data from the old sever to the new server?
- Use the UEM Backup / restore utility
- Use the UEM High-Availability (HA) mode that will copy data from the Primary to the Secondary server.
Possible risky migration paths
- Setup new Servers with new internal IP addresses. Migrate the data with HA (High Availability) and change the NAT or load balancer configuration so that the new servers are being used
- New installation on the same server (the Firewall should block all incoming traffic during the maintenance window), then import a backup containing all EMM-data
- New installation on separate server, migrate the data, poweroff the old server and reuse the old IP addresses
All these paths prevent testing the new infrastructure without impacting the current production setup and testing is never done end-to-end on the end device.
Preferred solution
The best solution in my eyes is to install the new server in parallel to the existing infrastructure, providing a new set of internal and external IP addresses.
In order to test the migration on mobile devices, we shall inject a fake DNS record, resolving to the new MDM server. This technique is called DNS Masquerading.
Of course, the data has to be either synced or imported with the Backup/restore utility.
On iOS and Android it is possible to edit the WIFI settings and add a custom DNS server easily (don’t forget to remove this configuration after the testing phase!)
An Administrator can setup such a DNS server in the Amazon Cloud in minutes by using the dnsmasq utility (on Linux). The following article will give you more details about the procedure:
iOS DNS configuration
Add the DNS server on iOS
Android DNS configuration (choose a static IP first)
How To: DNS spoofing with a simple DNS server using Dnsmasq
Test cases
There are plenty of test cases to create, based on the enabled services. I would at least test the following:
- MDM communication
- App downloads and push
- Device registration and checkins
- System checks
- Activesync and backend-relevant traffic for your inhouse apps
Migration cutover
Start by performing a fresh HA sync or data import with the current production environment.
Once everything has been tested, you may simply change the external DNS record and resolve it to the new external IP address, or alternatively keep the same external IP and change the nating in your firewall or load-balancer settings.
After a “grace period” of about 1-2 weeks, you may decomission the old servers
Rollback
The rollback is very simple. Just rollback the old DNS record. If needed you might want to synchronize data from the new server to the old server, assuming of course that the data is not corrupted.
Possible drawbacks of this method
- Firewall rules for the new server are required
- Sometimes Amazon IPs are blocked in the WIFI zone, preventing devices to access the temporary DNS server
- You will need at least one free external IP address
Important checks
- The new UEM server must have the same version as the current server
- The TTL of the official DNS record should be reduced to some minutes a few weeks before the production cutover and reset back to normal after the migration. This will allow a fast propagation on all end devices. Setting a 5 Minutes Time-to-Live is a good practice during the migration window.
There exist other tools on the Market that may allow cross-UEM and per-device migrations, have a look for instance at the EBF onboarder
Single-Sign on has always been a challenge on mobile phones. Now that companies have to switch to Android Enterprise (Device Admin’ is being deprecated), the Android world is kind of lacking an important feature which used to work with EMM Proprietary solution: Native Kerberos SSO or Kerberos Constrained Delegation.