As we all know 2012 R2 OS EOL is coming soon, so we are planning to do upgrade the Bigfix environment (Root servers, Web report servers, Console servers, Relay servers, etc.,) to the 2016 or 2019 OS level.
Could you please guide us and share pros\Cons? How the procedure will be to plan for the upgrade.?
is it an in-place upgrade possible for the bigfix Root server and others.?
If so, what’s the order to perform the upgrade?
what are the things that need to take into consideration to plan for this upgrade?
During upgrade clients will report or not…?
is there any impact for SQL Database where Bigfix DB has existed.?
@Chandu, when discussing major OS upgrades to your core BES infrastructure best practice is to stand-up Net-New hardware/VMs for your replacement infrastructure and then migrate the implementation. There is documentation for this for Microsoft Windows/MSSQL installations. If your organization needs further assistance, you can engage the BigFix Professional Services team for paid, hands-on assistance with your migration/upgrade.
I have migrated Bigfix installations on a number of occasions using the processes @cmcannady linked to, each with no issue. Most recent was in Nov last year migration from Server 2012 R2 and SQL 2012 to Server 2019 and SQL 2017. One important factor is do not have 2 servers using the same masthead live in your environment. If you are using an alias for your current server, it makes it easier for switching over and then it just a DNS update.
My top recommendation is test test and test again.
If you don’t already have a backup, establish the backup process so you can backup your existing server.
If you use an alias, reduce the TTL on your CNAME to 15mins ahead of your actual migration date. This makes the switch to the new server much quicker for the endpoints.
Install the OS and SQL on the new server(s)
Edit your local hosts file on the new Bigfix server so the new server resolves to the loopback address for the fqdn of used in your masthead. Eg. 127.0.0.1 bigfixserver.domain.com
This avoids it reporting to your current production server and potential issues that would incur and you can now run the new server without any impact to the live production environment (if you can isolate the VLAN then that is also an option)
Install the same Bigfix version as you have on your live server onto the new server.
Backup your new server so you have a clean setup to revert back to.
Complete the restore process of your existing live server to the new server
Verify you can see your current systems in the console on the new server.
Optional – Edit your hosts file on a client to resolve to the new server and verify you see it reporting into the new server.
Optional – restore the backup of the new server and run the process again.
I always like to run several test migrations and script the various steps so the migration is a consistently repeatable process. When I have the backup and restore processes scripted where they and complete each time I run them, I then know I’m ready for a live migration and can schedule the outage of the production server. If you have a small environment and both server on the same LAN then the overall process should be relatively quick. I did our environment of > 100k endpoints, a DB in excess of 100GB and with the new server in a different physical location to the existing server in under 4 hrs, with much of that time being the copying of the applications folders and DB backup over the WAN to the new server. Having the scripted backup and restore processes meant it all went as smoothly as possible.
This is all great advice and is exactly the process I use in customer migrations or disaster recovery.
Since you’re doing this on a regular basis I’d just add a couple of tips on performance.
If you’re using Robocopy to sync the root server directories between servers, it can go dramatically faster with the multithread option ( /MT: ). By default robocopy uses 8 threads at a time, but /MT:16 or /MT:32 can be dramatically faster as it must copy millions of very small files. This doesn’t help though with copying the SQL databse backups (that are just a few very large files).
If you use the Task Scheduler to run your Robocopy on a regular basis, the Task Scheduler runs the copy in a lower priority that can take much longer. The only way I’ve found to make the Task Scheduler run in a normal priority is to create the copy task, export it to XML, edit the XML directly, and re-import the XML as a new task. There’s a bit of description to this at https://stackoverflow.com/questions/47197821/how-to-change-default-scheduled-task-process-priority-in-windows
Also, check that SQL Server is configured to compress your database backups. I’ve seen cases where the database backup is 800 GB but with compression goes down to about 150 GB, for a much faster copy between the servers. Even at that size, compressing the backup only adds 10-15 minutes to the backup time but can save hours in copy-over-the-WAN time.
One additional tip I’d give, is to open a Support Incident on your migration ahead of time. You don’t have to wait for a problem, you can open an incident to ask for assistance in reviewing your plan. It’s good to validate that you know your support contact info, allows you to gather your basic deployment info without the pressure of a break/fix needed, and ensures we have someone standing-by when you start your migration.
To be a more effective way to understand, can you please share the personal document (When you had done it) if you have it handy to me. I will go through it and understand the process and plan for the same. It helps me.
I don’t have any documents or scripts I can share for this as its company private data. All I do is refer to the links already shared earlier for backing up and restoring then build a simple batch script to do what I am having to run on the command line. Your process will need to be specific to your environment and installation.
Thanks. one more question is we have primary and DSA servers…when we need to plan for OS migration, can we start with primary and then DSA or both same time…?
