Provide an automated way for BigFix Clients to be automatically lifecycled/upgraded. The feature would contain abilities to:
have “canary” release of random computers to get upgraded.
Have a way to upgrade to different computer groups (upgrade to latest version N on development computers, upgrade to N-1 on nonprod computers, upgrade to N-2 on production computers).
Define a maintenance window when these upgrades occur and if they are on a daily/weekly/monthly schedule.
Something similar could be created manually via Baselines but it requires some BigFix admin management which is not ideal.
In the WebUI patch policy configuration, selecting External Content doesn’t give an option for which site (like BES Support), and the OS is specific ( I can’t select Windows and Red Hat for example).
Custom Content is less restrictive but it would require duplicating all BES Support Client Upgrade fixlets which is not desirable.
In general i keep a policy open which will bring clients forward.
Each time i upgrade the Bigfix Server, i republish the policy to the latest and let it run with no end date, and schedule to run off hours when not expecting to patch. aka weekend days.
Would this even work even if delivered I wonder? Every time we upgrade clients on server (once an year exercise) we do see significant number of failures because the installer is trying to access some bes client Compliance folder under AppData folder that is not even being used or exist, which causes the installer to fail and leaves the machine without a client… We have to redeploy it via Client Deploy tool to fix it but it is painful! If we are to activate some kind of policy that will face similar issues and break agents it will just cause more of an issue than it would solve…
Maybe it’s just on our side cause we are servers-only and AppData is locked out pretty good for security purposes but just thought I’d mention it…
My environment is over a thousand servers, we bake a version of the BES client in the image and run cleanup on it before issuing the sysprep. Once the new system is powered up since it has a client it immediately checks in and registers itself and starts a process of updating to current for things that have changed since the original image build.
For systems which are not from our image, we built a custom BES client msi package (bake in the masthead, and some client settings) to allow things to follow the same process. Except for support of new OS’s, the package doesnt have to change often, as the BES Server will bring it current after initial updates based on our policies (open ended actions)
We use some custom client settings in the new image to put the new builds into a ‘new build’ dynamic group which has a few policies targeted against it, along with autopatch jobs which run after hours.
We have a two stage new build process, first stage does things that is very custom, and could not be scheduled easily through AutoPatch (like disabling IPv6, making sure Page File is correct, TLS, Print Service, and even VMtools are updated, install monitoring client, along with updating the BES client, and enable BES Client encryption) and the Second stage moves the builds to a group which autopatch targets nightly to basically through the ‘kitchen sink’ at it for security updates.
Even though we have the BES client update in the new build process, we still run general action on weekends to update clients to current - just because there is always that odd restore, or system build that didnt follow expected processes.
