I am installing the IBM License Metric Tool. The first thing I am doing, of course, is installing the BigFix server. The version of BigFix that comes with ILMT is 9.2.5.130 and I know that patch 6 is available.
A fixlet was available called something like “update installation folders with BigFix 9.2.6.94” which I ran successfully.
I was then expecting to see the fixlets to upgrade to patch 6 appear shortly thereafter, but they have not become relevant yet.
Are they supposed to become relevant right after I updated the installation folders, or am I just being impatient?
The server/console upgrade fixlet should be relevant, but relay and agent fixlets don’t become relevant until they checkin after the server is upgraded (incrementally over about 6 hrs).
First you have to upgrade the server. You can do that via fixlet if it becomes relevant or upgrade them manually via the installs. Note if you are using the fixlet you need to target it to everyone so it upgrades your consoles as well. Additionally you have to run BESAdmin on the server machine after you upgrade via fixlet.
Upgrades do cascade after the server is upgraded. More specifically the fixlets check their immediate parent, so the safest thing to do would just be to take all the relay upgrade fixlets as a baseline to upgrade all the relays as they become relevant, and take all the client upgrade fixlets as a baseline to upgrade those as they become relevant because either the server or the relay they talk to has upgraded.
A large deployment can take a while to do this, which is intentional as you don’t want everything reporting at the same time to the server.
Hi Steve … I will check the server tomorrow (it is at a customer location and I don’t have direct access to it). The server/console upgrade fixlet did not become relevant immediately after I upgraded the installation folders. This deployment has no relays or agents yet, other than the agents running on the server - I figured I’d upgrade BigFix first before deploying the clients.
Hi AlanM … thank you. This deployment, for the moment, has no relays or agents other than the agent that runs on the server - I figured I’d upgrade the server/console/agent on server forst and then deploy the rest of the infrastructure, I am aware that updates cascade but in this case (and I probably should have been clearer about this in my initial posting) this was seen on the server itself. I was just surprised that the relevance didn’t occur much sooner. I’ll check the server tomorrow as it is at a customer location and I don’t have direct access to it. Also thanks for the reminder about running BESAdmin.
The server upgrade is not dependent on the installation folders being updated, so there shouldn’t be a delay here. Note that there are two different fixlets for Server upgrade depending on whether your database is remote, and only one will report relevant. There are additional checks to make sure that the server does not currently need to be rebooted, and if ILMT is installed on the same system, that there are no port conflicts (primarily that ILMT and Web Reports aren’t both set to use port 80).
I’d expect a reboot is needed, if your not seeing it relevant yet.
The BigFix server was rebooted yet we still didn’t see the relevant BigFix fixlet to upgrade with a remote database. ILMT is not (and will not be) installed on the same system as BigFix. So I chose to run the BigFix server installer and skip the fixlet use altogether.
The installer ran fine until the very end where the upgrade seemed to expect the use of the “sa” userid for SQL Server Authentication. We originally chose to set up a separate id with the same access as “sa” but the upgrade process didn’t seem to pick this up. As a result, BigFix was installed but none of its services would start.
We ran the installer again, which prompted us to remove BigFix, which we did. We ran the installer a third time and then saw the same prompts as we did when we installed 9.2.5.130. We were able to re-establish the use of the SQL Server id created for database connectivity, the installation completed successfully, and all services were up and running according to the diagnostic tool. We then upgraded the console and client on this same computer successfully.
A little but round-about but the end result is what we wanted - BigFix at 9.2.6.94.
Next time, I’ll simply go to the patch6 page, download the code and the installation generator and start a fresh BigFix install with the patch 6 installation generator. I probably should have done that from the get-go but wasn’t sure if the code on the patch6 page was the full product installer or just upgrade code.
Ah, for remote db you have to do the upgrade manually anyway, though you should have seen fixlet 2281 “Updated Windows Server/Console Components - Manual Upgrade Required - IBM BigFix version 9.2.6” become relevant. So pulling down the installation generator manually and using its updated packages for each component upgrade is a good approach (on the patch download pages the installation generator is always a full product installer, but the components are only upgrade installers). You should be able to avoid the use of ‘sa’ user on future attempts by updating the enterprise_setup ODBC DSN to use Windows auth instead of SQL auth.