New BES client install comes up "delayed start"

Do you guy know why all of a sudden some of our new images with the same BES client settings have the BES service come up “Automatic (Delayed start)” , instead of regular “automatic” ?
We certainly do not set that up in the cfg file… Not a deal breaker but in some cases it seems it does not start at all when setup that way (does manually)… Thanks !

(latest console and client version)

All new versions of the BES Client are set to delayed start by default. This is a good thing, and you should set all systems this way, even if they are older versions of the client.

The reason this is a good thing is for many reasons:

  • It minimizes any impact that the BES Client has on system boot up
  • It helps ensure that the network is up before the BES Client goes to work
  • There is a lot of disk activity on boot, it is nice to keep the client from contributing right away

Even though the client should always have minimal impact on the system, these are definitely good things.


If for some reason the BES Client service isn’t starting at all, then that is an entirely different issue, and you should probably file a PMR.

Does anything show up in the client logs?

If it doesn’t seem to start when set to delayed start, does it start automatically after a few minutes when the system is rebooted, or does it just never start, no matter what?

1 Like

Really ? since when ???

Wait, let me start over… 1) Thanks for the reply 2) Really ??? our environment is about 1/2 and 1/2 and AFAIK we never reset that to automatic. I’ve always seen it automatic, the delayed thing drew my attention… That’s not a new thing ?

i agree on investigating the non-starters, but was wondering if it might have been related to the delayed status. Apparently not !

I think delayed start has been the default since 9.0 or something like that. If some clients are 9+ and are not set to delayed start, then it might have to do with them being installed before 9 and the setting carrying over.

Delayed start has been the default since 8.1 actually (on OSes that support it). New Client installs/upgrades will override previous configurations for service start type if I’m not mistaken. This shouldn’t prevent Clients from starting up, and as @jgstew suggests, has many benefits.

That said, if you’d prefer to configure the Client service to simply start with type ‘automatic’, this would be doable currently with a custom Fixlet (either as a policy action to configure the desired start type, and/or a modification of the upgrade Fixlets to ensure the start type is ‘automatic’ post upgrade). If interested, I’ve prepared some examples that I’d be happy to share.

1 Like

I have an example here: https://bigfix.me/fixlet/details/2568

Hello
we use cisco NAC check on the besclient service, our clients are being blocked from accessing the network when NAC does not detect besclient service running.
is there any way to make the msi start the service right away during the installation?

thanks

As suggested above, this can be configured fairly easily with a custom Fixlet. That said, I would also suggest submitting an RFE to be able to configure this on Client installation and/or upgrade.

How your NAC is managed on those endpoints agentless or by agent??

I have no idea about the Cisco NAC, but I have seen similar behaviour with Forescout NAC, And post managing the endpoints through NAC agent, it’s not blocks/ quarantine the endpoints.