"BES Client" not listed as a Windows service after deploying a bare metal build via OSD

Usage and Config
1

(imported topic written by Don65)

We recently noticed that “BES Client” is not listed as a Windows service in services.msc after deploying a bare metal build via OSD. This is occuring on all of the hardware models we are deploying to. However, BESClient.exe is running as a process and I do see it listed in the services section of the registry. If I login to the workstation as administrator, open a command prompt, and execute a net stop besclient, I receive “error 5 has occurred. Access is denied”

Has anyone else experienced this problem and or know if this issue is resolved in the 3.5.x version of the MDT Bundle Creator? I’m in the process of opening a case with IBM support as well.

Our environment is as follows.

Deploying Win7SP1 x64 bare metal build using “OS Deployment Server (x64): 7.1.1.16 (240.27)”, “MDT Bundle Creator 3.4.13” and “BES client version 8.2.1373”.

Any assistance greatly appreciated.

2

(imported comment written by martinc)

Any chance someone has put some customization in to hide/lock the service? You can look at
http://www.pcclm.com/2013/07/prevent-tampering-with-bigfix-agents.html

There are also the fixlets to hide from the Add/Remove programs (listed in the link above)

Martin

3

(imported comment written by Don65)

Thanks Martin, that was helpful and pointed me in the right direction.

The problem appears to be with the besclient service security descriptor. Below is the process I used to identify where I believe problem is originating.

  1. I checked the following registry setting on a number of known properly working BES clients. All of the clients had the same hex value.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient\Security]

“Security”=hex:01,00,14,80,a0,00,00,00,ac,00,00,00,14,00,00,00,30,00,00,00

  1. The reference build for the OSD capture was created on a VM. I reverted the VM to the snapshot that was taken just prior to the OSD capture and checked the registry value mentioned above. The reference build had the same hex value.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient\Security]

“Security”=hex:01,00,14,80,a0,00,00,00,ac,00,00,00,14,00,00,00,30,00,00,00

  1. I reverted the reference build to the snapshot that was taken immediately after the sysprep / OSD capture completed. This is the hex value I found. It’s also the hex value that I’m seeing on all of the workstations built via an OSD bare metal build.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient\Security]

“Security”=hex:01,00,14,80,a4,00,00,00,b0,00,00,00,14,00,00,00,1c,00,00,00,02,\

00,08,00,00,00,00,00,02,00,88,00,04,00,00,00,00,00,24,00,ff,01,0f,00,01,05,\

00,00,00,00,00,05,15,00,00,00,53,c3,93,22,93,4c,6b,e6,53,cb,c3,9e,00,02,00,\

00,00,00,24,00,8d,01,02,00,01,05,00,00,00,00,00,05,15,00,00,00,53,c3,93,22,\

93,4c,6b,e6,53,cb,c3,9e,01,02,00,00,00,00,24,00,ff,01,0f,00,01,05,00,00,00,\

00,00,05,15,00,00,00,53,c3,93,22,93,4c,6b,e6,53,cb,c3,9e,28,46,00,00,00,00,\

14,00,ff,01,0f,00,01,01,00,00,00,00,00,05,12,00,00,00,01,01,00,00,00,00,00,\

05,12,00,00,00,01,01,00,00,00,00,00,05,12,00,00,00

  1. To summarize, it appears the sysprep / capture process altered the hex value which in turn is causing the issue we’re seeing. If I export the registry hex value from a known good BES client, next import the known good registry value onto an OSD bare metal built workstation, then reboot the workstation, the issue is then resolved. I’m thinking I can probably import the known good registry hex value into the registry after the OSD bare metal build process completes via a software distribution task. This will be a near term workaround unless someone sees an issue with this. I also have a case open with IBM support. Hoping to get a quick answer on this so I can move forward with the deployment.