We have just upgraded to BigFix 9.2.6.94 and we standardize on deploying the besclient/agent via a software GPO for Windows machines. We are seeing errors in the event logs and basically the client is not being installed by our software GPO. We are not seeing any issues with our previous build of 9.0.1117.0.MSI installer.
There appears to be something wrong with the installer that was generated as part of the upgrade process. All I did was copy the “BigFixAgent.msi” to a file share and rename to “BigFix-BESClient_MSI-9.2.6.94.msi”. When I use the previous installer mentioned above, there is no issues with deploying the agent.
No, I am not interested in deploying the client using the .exe, especially, since the .MSI has always worked before with no issues and our previous build works just fine. In addition, it would require for us to develop a script, which quite frankly we should not have to build out, since we have a .MSI package.
I ran a test by manually running the .MSI package and the installation is successful.
Lastly, I tried deploying the .MSI by copying the file, but not renaming, still no luck.
We have the following GPOs to optimize policies in our system:
System-DelayStartupPolicyProcessing: Set to 30 seconds.
WaitForNetworkAtStartup:Always wait for the network at computer startup and logon
Using gpresult /r I have verified all necessary policies are being applied to the machine.
Any help would greatly be appreciated. We are a University with over 6000 endpoints deployed, so the sooner we can update our automated deployments via a GPO the better, since we have technicians constantly adding new machines.
For new machines, the BigFix agent is usually installed at image time.
GPO is primarily for machines that have no alternative for management on them other than AD and did not have BigFix installed at image time, so it usually is just older machines pre-BigFix roll out.
It isn’t a bad idea to have BigFix deployed on machines that are missing it through GPO, but it isn’t really necessary for it to be the latest version of the client unless there are some compatibility issues with new OSes like Windows 10.
You can have an older version of the client install, then upgrade it through BigFix itself. It isn’t a bad idea to have the GPO deploy a newer version from time to time, but it isn’t something you should have to switch out regularly.
Thanks for the reply jgstew, I actually don’t disagree with any of your logic, although, I don’t have control over several areas across campus. We are a 5 division campus with IT segmentation across all divisions and departments. I don’t control how often other campus technicians update the client on their images, but I do control which client gets installed once they join a machine to the central AD.
Thus, if I can keep an updated .MSI, I have a higher adoption rate, since I am neither managing or coordinated with other departments with respect to the imaging process itself. I do encourage others to include an updated BESClient agent in their images, but several factors prevent this from actually occurring:
The imaging process is both cyclic and occurs at different intervals across campus, so sometimes there is a several month gap, before certain areas would include the latest agent in their areas. Sure, I have a non-expiring baseline to update clients to the latest version, but if I deploy the agent via an .MSI, then we make more progress in making sure that systems have the latest build, since several areas have outdated images and I cannot be guaranteed they will update it anytime soon. The .MSI helps me guarantee that. Using the .MSI reduces the need for clients to process the update fixlet, which means less BigFix processing required by the client.
Plus, images are static builds until someone actually makes an update to their image. Meanwhile the .MSI automatically upgrades the system once I deploy a new package. So, if a particular machine for whatever reason never updates its BESClient agent in the image, no worries, our .MSI catches it once the system is joined to the central AD.
So, in short, it helps us improve adoption rates, since we are not completely reliant on others making sure to have the latest agent in every single one of their images, which would probably take longer than me just deploying a new .MSI. Why? We have over 27+ departments across campus, coordinating who has done what and when, my opinion, too much of an overhead right now. I am hopeful that this will change in the future though.
For now, the .MSI does the trick on the Windows side.
Thanks again for your help and all of your posts! I am a big fan, thanks again for all of your contributions! Hopefully, my scenario spells out more reasoning a little more, if you still disagree, no worries, I understand.
My situation is similar in my experiences in education.
My general point is that once a system has BigFix on it, it would be best to update BigFix with BigFix itself by deploying the update fixlets, not by using GPO. Ideally they would be deployed centrally to all machines to keep BigFix updated.
I feel like BigFix should only be deployed through GPO to machines that do not have BigFix installed at all, not those that already have it installed.
As long as the client in their image is functional, then BigFix can self update. No need to update through GPO.
Not having a client update to process wouldn’t save much.
Also, with BigFix updating itself, you can control how that update happens. You can have it only happen after the machine has had BigFix installed for a day or so, which allows the machine to complete any policy actions, configuration, provisioning, etc… before updating the client which could interrupt the client’s initial processing of sites and slow things down.
We had policy actions for both updating BigFix agents and configuring them (Cache, relays, etc). Anytime a client or a relay came online with an old version we would have BigFix automatically upgrade the agent.
This will give you a much more consistent environment that will be a lot easier to support.