Basically, a Server migration is moving your BigFix services (and optionally, database) to a new host. You use the existing masthead file, and the Backup & Restore procedure to migrate the files and/or database, usually followed by a DNS alias directing the masthead deployment name to the new server. To clients this is transparent.
An Infrastructure Migration is building a new BigFix deployment with a new masthead name, then moving clients from the old deployment to the new one. Action history and computer properties are not maintained, operator accounts must be recreated, etc. Optionally you can export your fixlets, baselines, computer groups, etc. from the old deployment and import them on the new one, but all fixlets get new fixlet IDs.
When your new Infrastructure is ready, you can use the old deployment to send an action to ‘masthead switch’ the clients, having them download the new deployment’s masthead file and migrate themselves to the new deployment.
You should probably open a Support Incident. The Licensing team can help make sure you have access to both of your accounts in the Licensing Center.
Usually not much trouble at all. Many of our largest deployments are anti-colocated. As long as the root server has low latency and high bandwidth to the database server, and the database server is properly scaled, it should be fine. There are certain operations like installation & upgrades that may require you to have the ‘serveradmin’ role in SQL, and normal operation should have the ‘db_owner’ role, but as long as you have good support from your SQL admins this works well.
This implies an Infrastructure Migration? Just be prepared to recreate everything in the deployment - LDAP connections, operator accounts, management rights, custom sites, content exports & imports. New Patch Policies, if you’re using them, and don’t forget about exporting & importing Software Distribution Packages or OS Deployment images & drivers, if you’re using them.
If you do a Server Migration instead, where you retain the original masthead name, the owners of the dept1.company.com DNS service should add an alias (DNS CNAME) directing server.dept1.company.com to the new BigFix host.
If you’re doing a Deployment Migration, I’d suggest creating a generic service name in DNS, like bigfix.company.com, use that as the masthead name when you create your new license, and alias that name to your real BigFix server’s hostname.
Carefully. If you’re doing a Deployment Migration, you don’t need to - just create a new license with a distinct masthead name (like bigfix-test.company.com) and test your content imports/exports/recreation there.
If you’re doing a Server Migration, what I prefer is to perform one or more ‘dry runs’. You can restore your existing production onto the new server, and no clients or relays would use it because DNS is still directing them to the old server. You can add HOSTS file entries on the new root server, new WebUI, new Web Reports, and your test Console machines, so only those systems connect to the new root.
You can expand as needed, adding HOSTS entries to whichever set of test clients and relays you want to use for testing.
You can restore your production database and files multiple times as needed to get comfortable with the process, and when you’re satisfied you can add the DNS alias to point all systems at the new server.
To make sure your test clients don’t connect to an old Relay and stray back to the original deployment, you may want to keep them on an isolated network (so they can’t reach the old deployment’s Relays), or delete the Relays from the console of the new server (so they are removed from the relay selection list on the clients).
I suppose it would probably work if you only had the newest versions of each site on the target server, but usually it’s more effort to separate the site versions. I usually use ‘robocopy’ for this, and once one copy has finished the subsequent copies are just deltas of changed files, which usually run pretty quickly. Since the server is frequently publishing new site versions, it can be tricky to keep the filesystem in sync with the database site versions.
It doesn’t hurt to pre-emptively open a Support Ticket, letting the team know you’re going to perform a migration, and let them collect the details of your deployment. It gives us an avenue to collaborate on your plan, and saves time if you do encounter any issues as we’ll have all the background information already.
