11.0 - Windows Server

Hey! I am looking at building a new Bigfix infrastructure and moving my clients over to it. I am looking at 11 patch 3 and curious about a few things.

  • Any issue with using Server 2022 for the OS and MSSQL?
  • Would I need to backup/restore to a 10.x server (current version) on the new environment then do upgrades after to accommodate for SQL changes?
  • For licensing, I was planning on switching mastheads. Old PC name may change. How does that look from a seat count perspective? So say I got 10k licenses and I make a new license for the new environment… and this migration could take a month to complete. How does that look?

No issue, that should be fine. Ref Knowledge Article View HCL - Customer Support

That’s often the easiest way, if you want to preserve your action history, computer IDs, and custom content. You can restore as long as your previous version is at 10.0.4 or higher (for Win2022 support). But if you’re planning to switch mastheads, you won’t be able to use your restored data anyway.

Again, it’s usually easiest to not switch mastheads and instead just restore-and-upgrade from the old deployment. But if you want to switch, you’d

  • Use the License Center to create a new license. Move some client count from your old license to the new one. Doesn’t have to be the whole client count all at once.
  • Use the new License to install a new Server, generating a new Masthead.
  • On the old deployment, use the Task 1516 Switch BES Client Action Site Masthead - BES >= 9.0 from the BES Support site to ‘masthead-switch’ your clients. Follow the instructions in the Description - you have to copy the new deployment’s masthead to a directory on the old server.

That’s the basics. Obviously there are a lot of minutae to go through so be sure you’ve planned for your custom sites hiearchy, custom content, computer subscriptions, operator accounts & passwords & rights assignments, and Roles. On the network & client side, make sure whatever firewall rules and proxy configs you have for your server and relays are valid for the new deployment. Plan how to migrate Relays - are you adding new relays for the new deployment at every site, are you migrating whole sites at once, etc.

Thank you, I think :frowning: LOL!

Yeah, the masthead thing I think will have to happen unfortunately. The team before me redid the architecture that was in place so that all of Bigfix is running on a single server. The name of the server has SQL in the FQDN - which made it to the masthead. I didn’t want to just get by using DNS or having SQL1 (root) / SQL2 (actual SQL) - as that just seems lazy and like it would become a thing down the road.

I was actually planning on setting the old and new up side by said, adding the new firewall rules for the new servers, and porting content over. I think automatic groups and custom sites can be migrated easily enough - it’ll just be time consuming. Wont be migrating relays if I can help it… I am wanting to just move everything to TLS1.3 across the board, and I believe that affects hashes used in previous tasks and fixlets - and it will all need to repull that data anyways. I think.

1 Like

Understood.
But TLS 1.3 should not affect the hashes used in previous fixlets; only concern there is whether your custom downloads include both ‘sha1’ and ‘sha256’ hashes for the download statements.

Unfortunately that’s the exact concern I have - we have some fixlets that were made that included both. :confused:

Including both is good.
Fixlets that only have sha1 hash defined in the download is where you can get some issues.

Requiring sha256 hashes on downloads is recommended but (I think - will check this later) is still optional.

I think you can still require TLS 1.3 on network, and SHA256 signatures on Actions, without requiring sha256 on downloads (again I need to check that to be sure).

Changing the deployment name is definitely a good reason to masthead-switch and it sounds like you have a good plan. Pro Services is here if you’re interested in contracting us to run the upgrade for you; and if you don’t have the budget or just want to do it yourself, I’d recommend opening a support ticket ahead of time. The team can look over your plan and let you know if they see any problems, and if you do have to call for help on the night of migration, we could already have your config details available to get right into helping.