Priveon Labs Security Blog

Background

While working in an environment with TEM (IBM's Tivoli Endpoint Manager - formerly BigFix) and Cisco's NAC (Network Admission Control) technology, I ran into an issue with Windows 7 machines not being allowed to pass through NAC after a TEM client upgrade. In this environment NAC is configured to not allow a workstation access to the network unless the TEM client is installed and running. After upgrading to the latest version of TEM and pushing out the client upgrade, several Windows 7 users reported that they were failing a NAC check. After further investigation I found that the service startup for the "BESClient" (The service name is still BESClient as of version 8.2.1093.0 even though the product has been renamed from BigFix to Tivoli Endpoint Manager) service was set to "Automatic (Delayed Start)" instead of "Automatic." The service would eventually start and work fine but the NAC check was occurring before the machine got around to starting the BESClient service.

Delayed Automatic Start Info

Delayed Automatic Start is a feature that has been around for a while (since Vista) that allows non-critical services to load later in the boot process thereby allowing the computer to spend CPU cycles on critical services and improve the speed which the computer is available to be logged on. For more information on this feature, check out the following link from Microsoft's Performance Team blog - WS2008: Startup Processes and Delayed Automatic Start

In most environments there probably wouldn't be an issue with the TEM client service starting up a little later but in this case we need to make some changes so that users can go through NAC successfully.

Changing the Startup Type of the BESClient Service

The BESClient service is set to delayed start by the presence of a DWORD registry value named "DelayedAutoStart" with a decimal value of 1 in the key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient" of the registry. To disable Delayed Automatic Start and just have the service start type as Automatic the value of "DelayedAutoStart" should be set to 0.  You can test this out by opening up the services management console on a machine and changing the startup type between Automatic and Automatic (Delayed Start) and seeing the registry value change.

If you change the value through the registry, the services management console will not update the startup type until after a reboot (at least from my experience). The machine will use the new value on the next boot and since the value really doesn't come into play until boot time I didn't see the services console not updating as a big issue.

Deploying the Change Through a Fixlet

I created a fixlet to make the change across the environment as a whole and have posted the sample relevance and action scripts below. You can modify this for your environment or to improve the relevance as you wish.

Relevance

The relevance below will check for a machine running Windows Server 2008, Windows Server 2008 R2, or Windows 7 (If you have Vista in your environment then just add that in). Then it will check to see if the machine has the registry value named DelayedAutoStart with a value of 0. The relevance will evaluate to TRUE if the machine either does not have the value at all or it does not equal 0 (and the machine is one of the OS's listed).

(it = "Win2008" OR it = "Win2008R2" OR it = "Win7" ) of name of operating system AND (not exists key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient" whose (value "DelayedAutoStart" of it = 0) of registry)

Action

The action script is very simple and just makes the change in the registry to set the DelayedAutoStart value to 0. It does not matter if the value exists or not, the action script will set it to 0. You could put in "action requires restart" at the end but there's no reason to have the machine reboot since the change won't be processed until the machine boots anyway.

regset "[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\BESClient]" "DelayedAutoStart"=dword:00000000

Conclusion

You can use this information to build a fixlet to work with any service, not just the BESClient service. This also applies to any type of NAC, Network Admission Control or Network Access Control technology that checks for running processes/services before allowing access to the network. If you are using a different systems management application than TEM then the same methodology applies - you'll just have some different implementation steps.

When you deploy the action for the fixlet shown above I recommend that you make it a "policy" (no start or ending constraints, action reapplies when relevant again, no reboot, no messages) and target all hosts. That way when you perform the next TEM upgrade you won't have to go through all this again.

Further Resources

Link to the Fixlet Debugger that you can use to test out your relevance and action scripts before rolling them out. Also has other resources for writing fixlets.

• Fixlet Authoring

Release notes from BigFix on version 8.1 that mention changing the default startup behavior of the client. There is also mention of a command line parameter for the initial installation of the client that can change the default behavior but it does not change the behavior on upgrades.

• Changed the Windows Client service to have a delayed start. Added a command line option to control the behavior (DELAYAUTOSTART_AGENTSERVICE)

Microsoft's Performance Team blog

• WS2008: Startup Processes and Delayed Automatic Start