BigFix announces the availability of BES 7.0.7. BES 7.0.7 provides several critical bug fixes to BES 7.0.1, including a security fix for Web Reports. BigFix highly recommends upgrading BES Servers, Relays, Web Reports, and Consoles to 7.0.7 to take advantage of the newest features, optimizations, and bug fixes.
The BES Server and all BES Consoles need to be upgraded to 7.0.7 at the same time. BES Clients and Relays may be upgraded at your convenience. Additional information about the update is available at http://support.bigfix.com/cgi-bin/kbdirect.pl?id=446 .
This upgrade is available to all BES customers at no charge. As with all BES upgrades, you can upgrade any component manually or by using Fixlet messages available on the BES Support Fixlet site.
Upgraded Unix/Linux agents for BES 7.0 are now available. Upgrade Fixlet messages are now available for clients running previous versions of Unix/Linux agents. Unix/Linux agents are also available from http://support.bigfix.com/bes/install/besclients-nonwindows.html
Not sure how many progress screens there were for the server upgrade…but it didn’t seem like very many. The upgrade sat for about a half hour at the computing space requirements screen but finished flawlessly.
I’m not sure if I didn’t see the progress screens as I was remoting in to do the upgrade.
Yes… there is a database upgrade component of the upgrade which cleans out many rows, re-builds some indexes, and transforms some data. For smaller deployments (less than a few thousand computers), then the upgrade should go quickly (just a few minutes)… for midsize deployments of 10,000-50,000 computers, probably you should expect 10-20 minutes, and for the big 100,000-200,000 computer deployments, it probably will be closer to 30-60 minutes…
Manually running the server installer is probably a good idea because it helps you keep good track of the status (the silent upgrade will work too, but you miss out on the feedback)
The upgrade (for any component) does not require a restart… However, if for some reason you have the files in-use during the upgrade (like for instance if you had the console open during the console upgrade), then you might need a restart to complete the upgrade. The agent, server, and relay upgraders try always to shut off the services and exit the processes before upgrading, but if something else is prevented the files from being replaced, they would be replaced on restart.
Is it normal to at this point only to have about 1/3 of my agents showing the relevance for the 7.07 update? I updated the server and all the relays the day the update was available. I have about 3800 agents and only around 1000 say they need the update. I have only updated about 100 over the last few weeks. The approx 1000 hasn’t changed in all this time. I know it can take a little time for the agents to report the relevance - but several weeks? Thanks.
You probably aren’t seeing the upgrade Fixlets because most of your agents are running the BES Client Logging Service that is used with BigFix AV, BigFix DLP, BigFix AntiPest, and BigFix Personal Firewall.
We need to deliver the updated agent and the updated logging service at the same time and we hit a small delay in releasing the Fixlet to do both updates. You should see it soon.
Why does the upgrade from 6.0.21.5 to 7.0.7.x try to set the SA password even though it is already set?
I’m not sure why you might see this happen, could you explain a little bit more? Do you have a local or remote database deployment? What was the exact message you saw and did the upgrade succeed or fail? Did you provide a password?
we created a 6X server with a remote DB and accessed it via a sql account with DBO privileges. Our DBAs upgraded the rights for our SQL user to SA prior to us proceeding with the install. When we attempted to run the upgrade manually because of the remote DB, the install indicated that the SA password was blank and to enter the password (dont have the exact verbage). We entered a password(not the SA pass) and hit OK and the install finished after that. We then tried to install the console, thinking it was successful, and got a versioning error when we connected to the DB.
Our DBA said the SQL side was in a loop polling for the version.
We then tried to re-run the install but had to uninstall the server because the repair/modify did not work so we had to uninstall the server. We then tried to install it with the SQL account and it worked fine.
By best guess would be that the installer didn’t recognize your remote database and thought it had to install MSDE locally, at that point it prompted for a password for the local SQL Server that got installed. I would check with our support department and verify your installation, you may need to clean out the local MSDE database and verify that everything is functioning correctly.
We have released a new patched version of the BES Client (version 7.0.7.92) that fixed a few issues. The most notable was the issue:
‘Fixed issue where multiple action groups would incorrectly report “Not Relevant” and not run the action for 7.0.7.82 agents. This will only occur if using “non-efficient-mime” (bug #17662).’
All the changes are documented at (scroll down on the page):
Is there a general release for 7.0.7.92 available yet? We are having the problem with multiple action groups coming back as “Not Relevant”. For new installs, we are install the 7.0.7.86 client and then using the fixlet to upgrade then to 7.0.0.92 and then patching. It would be nice to be able to install 7.0.7.92 from the client install folder directly.