The description of the fixlet does state the best pattern. If you target the Server Components fixlet at all endpoints it will upgrade all remote consoles (that have clients on them) and remote Web Reports servers after the root server has upgraded and the clients relay select again.
Kudos to the BigFix team! @steve, I upgraded our DEV environment this evening and was pleasantly surprised. Our BFENT and BESREPOR DB2 databases total about 15GB in DEV and we have a fair amount of BFI data reporting up through the server. Took 23 minutes and 18 seconds to backup the databases and 21 minutes and 31 seconds to apply the 9.2.6.94 software updates. Now comes the fun of regression testing and validation.
On to WebUI. I did have to airgap our DEV environment post platform upgrade to pickup “BES Support” site version 1234 to then install the LONG awaited WebUI. @AaronBauer, I’m really hoping that the next WebUI release will include support for CentOS and SLES endpoints.
@gearoid, for future BES platform releases I would very much like to see improved process/state reporting from BESAdmin (RFE#80161). It would be beneficial to be able to tail a BESAdmin.log during the upgrade to have better overall insight into the process/progress. Currently there’s not much detail from BESAdmin while the upgrade is processing.
Again, kudos to the BigFix team!
2 Likes
@mfuglem, you may need to airgap your environment to pick up the changed. You can tail the BESRealy.log and GatherDB.log on your root BES server to see why your environment may not be importing the latest version of an external site.
I am upgrading from 9.2.5 so they should be relevant. Looked after them this morning and found them. Site version is now 1234.
Looked after them this morning and found them. Could i ask how air gap would help. If i understand the term correctly it means the enviroment is not connected to internett or to a computer/server that is connected to internett. Thanks for the tips for looking at the log files. It seems that the site got updated to 1233 but i did not find them before it updated to 1234.
@mfuglem, if your environment is having issues updating external content sites to the latest versions, you can leverage the Airgap utility to resolve. For example, if you were to see “failed to pass sha1 hash value checks” errors in your BESRelay.log it indicates that something between your root server and the BigFix sync servers has in someway modified the site download. This could be content filtering and or proxy config in your environment. Running the Airgap process will allow you to mitigate these issues. Utilization of the Airgap utility does not mandate the BES environment not be connected to the Internet.
Have you checked the BESRelay.log and GatherDB.log on your root BES server to see if you’re getting errors when trying to import version 1234 of the “BES Support” external site?
3 Likes
In my Linux lab, the only computer that is relevant for the Server Components fixlet is my BigFix server, not the BigFix console on another Windows computer, so I can’t target my console with this fixlet. This is why I asked the question originally. I’m led to believe, as @gearoid has stated, that I have to upgrade my console manually.
–Mark
If you target using the dynamically target by property option what happens is that once the server has upgraded the fixlet becomes relevant on the console and then it will be upgrade by the fixlet.
1 Like
Correct. The fixlet is looking at the version of the server (which it gets when the client registers) so there can be a delay after the upgrade.
1 Like
Your console might have had a cache issue. It definitely should have been part of site 1233
1 Like
Ahhh, I see … I can use this to select both my server and console computer. Thanks for pointing this out. --Mark
1 Like
Checked the log files and there are no error on importing the new site versions of 1233 and 1234. Log says it imported both successfully. A bit weird that my upgrade fixlet came in site version 1234, but i will take a closer look.
I have 3 instances of BigFix I am upgrading.
Instance 1
Windows Server 2012 Standard - SQL Server 2012
Time to upgrade (from the time I hit the last OK till the last windows indicating success.
Version 9.0.876 to version 9.2.6.94
8 minutes 20 seconds
My BFEnterprise DB Size:
Pre Upgrade: 1.7 GB
Post Upgrade: 3.6 GB (an extra 2 GB???)
Pre-upgrade DB size
Post Upgrade DB size
+1 for the UI Upgrade
Instance 2:
Windows Server 2012R2 - SQL Server 2014
Version 9.0.876 to version 9.2.6.94
Time: 8 min 30 sec
My BFEnterprise DB Size:
Pre Upgrade: 3.2 GB
Post Upgrade: 6.2 GB (3 GB Larger)
Instance 3:
Windows Server 2012 R2 - SQL Server 2014
Version 9.2.5.130 to version 9.2.6.94
Time: 26 min 30 secs
My BFEnterprise DB Size:
Pre Upgrade: 42 GB
Post Upgrade:42 GB (unchanged)
2 Likes
Stacy, what versions of Windows Server and SQL Server are you using?
my post updated with OS and SQL versions
What are the usecases for the different instances?
DEV Instance
Server Instance
Endpoint Instance
Going from version 9.0.876 to 9.2.6.94 the upgrade fixlet for the console never becomes relevant. Upon futher inspection of fixlet ID 2255 the relevance shows
(exists regapp “BESConsole.exe” whose (version of it < “9.2.6.94” AND version of it >= “9.1”)
Since my consoles are 9.0 the fixlet will never show relevant to upgrade the console. Easy enough fix to change the integer but before I do, can anyone at BigFix tell my why I should not upgrade from 9.0 to 9.2 of the console?
I can install the console upgrade manually on a system and it did it usual uninstall the old version and install the new version.
thoughts…comments…?
1 Like
I think that may be a mistake in the relevance for the console upgrade, unless there is something odd that needs migrated in the console settings or ???
If the relevance is really there for a purpose, then it seems to suggest you need to install the 9.1 console and then install the latest console.
The content is reflecting that the server needed to be at 9.1 or greater to begin with so the upgrade to that version was expected. I can see how this is problematic in some cases so I’ll work on getting that changed going forward. Feel free to make a custom copy to fix it (for only the console alone portion)