The “Migrating the BigFix root server” documentation mentions the concept of an “infrastructure migration” that can “be performed rather than a server migration”. However, I can find no further mention of the phrase or concept in the documentation. Anyone know what the difference is and where I can find some documentation on performing an “infrastructure migration”?
Since I know y’all are gonna ask We’re taking over management of BigFix from another group and migrating to new infrastructure. Our current environment is a colocated server with a 20-year-old masthead (“X-Fixlet-Site-Serial-Number: 192” ). The new environment is anti-colocated. The current X-Fixlet-Site-Gather-URL, etc., is in a domain that we have access to, but a subdomain that we do not manage (i.e. old server name is “server . dept1 . company . com” and we’re moving it to “server . dept2 . company . com” (spaces to prevent auto-link creation). We’d rather not have to be concerned about asking dept1 to make DNS modifications on our behalf (we’re in “dept2”) if we can avoid it. The original masthead also has a “From:” address of a user that retired a decade ago, so there’s that.
Anyway, other questions:
How much trouble are we inviting upon ourselves going from colocated to anti-colocated? (This is not optional… our organization wants all databases to be housed and managed by the database group. Our infrastructure is close enough and fast enough that having a remote database will not be a big deal.)
Am I making a big deal out of nothing wanting to refresh the masthead with a new server name (and email address and serial number). If a CNAME of the old address on the new server’s DNS is all that needs to be done to redirect communications, it’s starting to sound in my head like we should just keep the history around and I should get over myself.
How do you test a migration like this without putting the production masthead on your test root server? That doesn’t seem to make any sense.
When performing the “Server Backup” procedure, do we really need all of the files in the [BigFix Server folder]\wwwrootbes directory or just the most recent version of each subdirectory? For example, do we need to copy “actionsite_7_1383” through “…_1388” or just “actionsite_7_1388”? That’s a whole lot of data to move…
That’s it for now. More questions later, I’m sure…
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.
I’m interested to hear what hivemind has to say about the masthead age. Our masthead also contains an email address for a no-longer-present staff member.
Since it sounds like you’re moving physical and organizational infrastructures, IMO this is probably most easily digested not as one migration, but several.
Establish that this will be multi-phase process over an extended period. Make sure everyone is on board and congenial about the whole thing.
Migrate to new infrastructure, probably with newer Windows Server. Basic lift-and-shift, changing as little else as possible. Massive file copies over your preferred method for shipping bajillions of files. Rattle up a CNAME and move on to more complicated things. There are docs for this.
Make double-darn-sure you have all the realtime AV stuff dialed in on the new server.
Migrate the database to a remote database server.
4.1 We did this some years ago; it went without a hitch. (We went from a VM with colocated database to a server VM with remote DB VM; the two VMs are colocated on the same physical host via associations in the VM infrastructure.)
4.2. The DBA does their stuff, then you run through BES setup docs for the ODBC connections. There are docs for this.
Make double-darn-sure you have all the realtime AV stuff dialed in on the new DB server.
Check your FillDB stats. Tune as needed.
At this point, you’ve accomplished the major goals and have a long road of tuning and shaping. In no particular order:
Rejigger the firewalls, relays, DNS, affiliations, etc to match the organizations’ preferences. Allow plenty of time for changes to matriculate through the environment.
Implement whatever new IdM stuff you need – LDAP, SAML, etc.
Thank you, @JasonWalker and @atlauren! This is great information. We’ve already discussed changing some of our plans and will likely end up changing the rest.
We’re taking over management of BigFix from another group and migrating to new infrastructure. Our current environment is a colocated server with a 20-year-old masthead (“X-Fixlet-Site-Serial-Number: 192” 
). The new environment is anti-colocated. The current X-Fixlet-Site-Gather-URL, etc., is in a domain that we have access to, but a subdomain that we do not manage (i.e. old server name is “server . dept1 . company . com” and we’re moving it to “server . dept2 . company . com” (spaces to prevent auto-link creation). We’d rather not have to be concerned about asking dept1 to make DNS modifications on our behalf (we’re in “dept2”) if we can avoid it. The original masthead also has a “From:” address of a user that retired a decade ago, so there’s that.