The IBM BigFix team is releasing 9.2 Patch 5 (9.2.5.130) of the IBM BigFix Platform. The main features of this release are APAR fixes, security vulnerability fixes, agent support for Windows 10, and general bug fixes. Relay support for CentOS 5/6/7 and agent support for CentOS 7 is also being announced for all 9.2 versions (9.2.0 and above).
The 9.2.5 upgrade will likely take longer than previous IEM/BigFix upgrades
The duration is proportional to the amount of subscribed external content, number of client uploads on the server and speed of server hardware; and could take multiple hours for some deployments
Deployments actively using SUA or ILMT are expected to have higher numbers of client uploads and will be more impacted
The UI does not display the progress of the upgrade and will be unresponsive while the upgrade is occurring
For those of you that install QnA everywhere, this catches the Windows client up to all other platforms by installing it with every client, and this version is a Console application so it will run on Core server platforms as well. The command line interface is the same as every other platform as well now.
Fixlet Debugger didn’t change and is still a Windowed application.
NB: Take heed of the retroactively added (updated) “Important Notes” section re the extra length of time required and no feedback - even on a small instance. Ugh. Please fix the feedback part going forward. Here’s some strong text:
Just before the end of the upgrade a Window popped up asking for the proxy password. I entered a password. It appeared to be wrong and then the Window closed. I do not need to set proxy settings and I do no have proxy settings set. Does anyone know why the proxy Window appeared? According to support it should not have.
This is normal behaviour. The consoles and servers need to remain able to talk the same language and when a schema or interface changes they need to be the same.
For the releases we currently have, the server and console should always be the same version
Have requirements for the IEM Console changed somehow in patch 3?
All the previous version worked before but its not possible to install latest version on Win 7 Enterprise 32-bit anymore.
Windows Server Components (Server, Console, Web Reports, FillDB, and BESAdmin) are now 64-bit Windows applications.
…
=====================================
= Changes between 9.1 and 9.2.0.363 =
…
OS Support
Linux Server, Relay and Agent components can now be installed on RHEL 7
MS Windows 2003 R2 is no longer supported for the IEM Server, Web Reports and Console
Windows Server and WebReports components can now be installed on 64-bit platforms only (MS Windows Server 2008 and higher)
The IEM Server installer prevents deployment on 32-bit operating systems.
The IEM Console installer will allow a manual installation on 32-bit platforms. Future Console installer releases will not support this mode of installation.
Yes, we used the version 9.2.2.21 of a Console without a problem. Now I see in the release notes that since 9.2.3 it is a 64-bit application. It was just confusing as in IEM Console requirements, it is listed as 64-Tolerate app for x86-64 hardware.
Does it mean there are no plans to support it on 32-bit systems in the future? Unfortunately, all the workstations used in our company are 32-bits, even in year 2015. In that case we might need to downgrade IEM or find some “workaround”.
I upgraded the server/relay/clients this week and noticed that the start type of service “X” is no longer working. I am guessing it is something with the new client but I opened up a ticket for support as we were using this for a few different tasks. the result was usually manual/demand/disabled based on the start type of the service
example:
q: exists service "SepMasterService"
A: True
T: 0.019 ms
q: start type of service “SepMasterService” | "Not Installed"
A: Not Installed
T: 0.025 ms
Yeah, it looks like this is a bug in the 9.2.5 agent. You’ll likely have to downgrade these agents until we can release a fix, or use a workaround like:
value "Start" of key "HKLM\SYSTEM\CurrentControlSet\Services\BESClient" of native registry
Can you easily downgrade the clients by taking the 9.2.1 job and removing the relevance for version of client < “9.2.1.48” and version of client >= “7.2”? Just wondering the effort for 20000+ endpoints versus just recreating the properties using the relevance you provided (which results in 2/3/4 which correlates to Automatic/Manual/Disabled in Services).
No, the installer only works if the existing client is at an older version, so you’d have to do a custom action to remove and then reinstall. Or do an uninstall action, and then use the client deploy tool or AD login script to re-install the older version.
I would definitely recommend the option of uninstalling and then reinstalling with a BAT file deployed through BigFix if you need to downgrade.
I wouldn’t recommend just uninstalling and then trying to get another mechanism to work to get it back… I would only recommend that if there are failures.
You’ll likely have to downgrade these agents until we can release a fix, or use a workaround like: