Issue with client upgrade from v9.0.835 to v9.2.1.48

Usage and Config Platform
1

This is definitely one of the worst types of problems to have. So far I am only aware of this happening with a single client.

I have a BESClient in a broken state after upgrading through the console from: v9.0.835 to v9.2.1.48

The service and files are present, but attempting to start the service gives the following error:

The newest client log shows it starting the upgrade before having an issue:

   Command started - wait __Local\Upgrade\BESClientUpgrade.exe /s /v"/l*voicewarmup \"C:\Program Files (x86)\BigFix Enterprise\BES Client\besclientupgrade.log\" REBOOT=ReallySuppress MSIRESTARTMANAGERCONTROL=Disable /qn" (group:1117679,action:1117680)
At 12:42:07 -0400 - actionsite (http://REMOVED/cgi-bin/bfgather.exe/actionsite)
   Command failed (Action ended while waiting for another process to complete) wait __Local\Upgrade\BESClientUpgrade.exe /s /v"/l*voicewarmup \"{location of client}\besclientupgrade.log\" REBOOT=ReallySuppress MSIRESTARTMANAGERCONTROL=Disable /qn" (group:1117679,action:1117680)
At 12:42:08 -0400 - 
   Client shutdown (Service manager stop request)
2

There’s no issue there in the log. That’s the normal log message when the client itself is being updated.

You’d need to look in the besclientupgrade.log to see what happened but the install didn’t complete for some reason.

1 Like
3

I didn’t see any issue in besclientupgrade.log either.

4

What is the actual machine its running on? We had some changes in minimum OS support levels and minimum hardware (processor) levels between those two but the fixlet should have not become relevant if it didn’t match

5

It is on a Windows 8 VM with 2 cores and 4gb of RAM.

6

So being a VM I doubt its less than a PIII hardware support :slight_smile:

1 Like
7

Not sure if this is applicable in your case but I’ve seen similar in the past while upgrading 7.2 and 8.x clients to 9.1.x on a server OS. The issue seemed to be that when the upgrade removed the previous installation, the service could not be deleted so it was marked for deletion on next reboot and left in a disabled state. The only way to clear this was a reboot which then deleted the service then repair/reinstall the client.

Regs
Rob

1 Like
8

I think you were on the right track.

The BESClient service would not start, but it existed. I had not rebooted since the upgrade, so I rebooted.

Now the BESClient service no longer exists, it has been deleted, but it was not recreated. The BESClientHelper is also on this system, and it tried to start it, deleted some stuff, and tried again, but never succeeded.

It would be interesting if the BESClientHelper could run a cached installer of the BES Client in these cases, instead of being dead in the water.

Also, it seems like the BESClientHelper should make an archive of the logs folder before attempting to delete the entire __Data folder as a debug step.

This is not the end of the world on a test machine, but if it happened on a chunk of production systems, it would be a big problem.

9

I ended up installing the client manually, so now it appears to be fixed.

10

That sounds very similar, service existed but could not start (ours were also set to disabled ). If it happens again, check for the “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BESClient\DeleteFlag”. If that exists then the service is marked for deletion.

1 Like
11

I don’t think mine was set to disabled, it just wouldn’t start.

12

I think there is some issue with sql server services because earlier I face similar issue when I am upgrading .At that time I tried almost all the thing and I have seen some services are not running in SQL server configuration manger and try to run any stopped service .
Try this and I am not sure whether it will work or not .
If it is working please let me know .

13

The issue I am talking about is with a client upgrade on a workstation / VM. This definitely has nothing to do with SQL.