I was wondering if you guys could provide me any help related to migration.
What we need is the following: We have an environment with about 2500 computers, 5 relays, 1 Database. Our Server runs version 10.0.3.66 which is fairly old, as we were not using our environment due to a significant Cyber Attack a year ago, so we are rebuilding our entire infrastructure, patch management.
We were able to backup our entire BigFix Environment, but we would like to update our entire system. We will migrate BigFix for SQL 2019 as well as another operational system probably Windows Server 2016 or 2019. We’re running BigFix and all of its components in machines running Windows Server 2012 R2.
We will migrate the server to an environment using the same FQDN, only the Operational System will change.
What should we do?
The masthead is where the server knows how to communicate and propagate to clients, so we’re gonna need that.
We were also thinking of making a “clean” installation, that being… We would install server on the new machine of same FQDN and we would ignore the old database creating a new. Is it possible?
Database migration can be tricky, so I would like to know any advice on how to do that.
If your infrastructure is modest, there isn’t much to worry about with migration, but if your custom content is small, it’s best to rebuild it from start if the server was previously compromised.
If you are planning a migration, you can either upgrade your existing infrastructure with the latest version or establish a similar BigFix infrastructure on new hardware and operating systems, after which you can upgrade the BigFix version from old to whatever you like.
But during DB migration BigFix version must be same in both side else there will be N numbers of issues.
However, if you want to go with migration, it is not a major issue; you can start an HCL case for migration, and they would assist you; however, we did it in our infrastructure, so I don’t see much of an issue there.
Back up existing DBs and move them to the new server
Install BigFix using same masthead file on the new system
Restore DBs after installation
Copy all sha1 values from the old server to new server so that your custom content works fine.
If you are seeing something unusual after logging into console-
A. Gather reset Master server
B. Re-sign Security data
If you have Custom Fixlets, Tasks, and Analysis - you can export from the old environment using the bigfix console and export … it will save it out in flat file for import into your new environment.
I export and import to move things between my Bigfix lab system and Bigfix Prod system.
Do you know if the database has to remain with the same name as well?
We got a new license for another computer and SQL Server 2019 (we were using 2012).
As I mentioned it will be a clean install, even the database will be new. Since we have some other few services on the current database, we won’t be able to shut it down.
Maybe we can repoint to the new database? Do I have to edit the masthead? Will it generate a new masthead?
There are…a lot of options. I’d highly recommend reaching out to your Tech Advisor to run through your specific options. I think an hour worth of conversation would help a lot, and it’s what they’re there for. If you don’t know your TA, reach out to me (Jason.Walker at hcl.com) and we’ll find out.
I personally prefer migrations (reinstall on new host with same masthead, keys, and a restored copy of the database), but certainly you could do a clean install (new license, new keys, new masthead) and then perform a 'masthead switch" to migrate clients from the old deployment to the new one. In that second case, you’ll need a new DNS name for the root, and carefully schedule migration of the clients and relays to avoid orphaning clients or relays.
It is already set that we will perform a clean install, you see, BigFix is not being used for a year already in our environment and it has to be updated, so we decided to move on with that. Nothing will be backed up. Only the masthead, keys, license, etc.
We’ll also uninstall all the relays.
It will be fresh new and we are capable of keeping the same FQDN for the server and relays, but not for the database.
The relays will be the same computers, we will reinstall once we get the server working.
Now, I don’t even know who our Tech Advisor is, and it’s being difficult to get support, since our security head is not on the company anymore and everything is under his credentials since he was responsible for that.
He does not have access to that, because it was on the corporate e-mail, but the new one is having some trouble finding out.