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.
