Two BigFix Installs? Test and Prod?

Usage and Config
1

HI,

We’re brand new to BigFix, but I was told today that our company wants to have two separate installs of BigFix. A ‘Test’ install that would be managing a couple Test servers, but would be mainly for testing upgrades to BigFix itself to make sure that an upgrade doesn’t break any functionality. We’d then also have a Prod install of BigFIx that would be the one we actually use for Patching and whatever else we do with it.

Does anyone else have a setup like this? Is this really necessary? I don’t like the idea of having to do everything twice, but if the Test install was really just for testing new BF versions, I guess it would just sit there 99% of the time unless an upgrade came out.

Anyway, just want to know, is this a good idea? Is it overkill? Could an upgrade to BigFix be rolled back if we found that something breaks?

Thanks.

2

Read my response in your other thread.

3

We have this, but not really for testing upgrades. I carved out a few license for testing new features. We have Patch and Inventory but I wanted too play with IVR and some other stuff related to Lifecycle, so we stood up a test environment and I have a half dozen or so Lifecycle licenses for it. Remediate was announced right after I did this and once I get the Justification written for Remediate we’ll probably buy it. Now that it is setup, I’ll probably leave the test environment in place just for occasional testing, especially with the upgrade to 11.

1 Like
4

We have similar Setup and it makes sense in my opinion. We test new BF Versions as well as new content like new hardening checklists, custom content etc.
And definetly I like it.

5

I think it depends on lot on how you plan to use BigFix.
I would always advocate for have some kind of lab/test system, but how to scale it depends on your individual needs.

At the very least, you should have the ability to stand up some virtual servers to test your backup & recovery ability. Like any product that uses databases and has many interconnected data feeds, backup & recovery can be complex. You should have the same kinds of recovery testing for any of your other complex or critical infrastructure too, by the way, such as AD, DNS, DHCP, Certificate Services, Firewalls, Web Services, HR systems, and anything else the business relies upon.

These can be temporary installs on VMs if the deployment is small or underfunded. In larger companies, ideally you’d have dedicated test resources for all that critical infra, and having a test BigFix to go alongside it is a natural fit.

If you’re only using a small subset of BigFix - maybe only Patch, or only Inventory, and your deployment won’t be critical or frequently changed - then maybe all you need is the capacity to stand up some VMs and periodically test your disaster recovery backups, and practice upgrades periodically.

Honestly though I rarely see BigFix used in such small deployments, and once you get comfortable with the power of BigFix I think you’ll find yourself relying upon it so much that even a day or two of outage will become unbearable. If you don’t build some kind of test lab you may find yourself wishing you had later.

If you do have a large deployment, or plan to use complex features like Server Automation plans, REST API automations, correlating data with ServiceNow, bulk OS upgrades or bare-metal deployments with OS Deployment…then you’ll probably really want to have an environment where you can test those things, confident that you aren’t going to accidentally upgrade the whole company to the latest beta of Windows 15 or something next weekend because you clicked on the wrong target group.

1 Like