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

Anybody who installed Kb2509470 last week and happened to have Outlook 2007 may have run into a rather bizarre issue trying to print from Outlook. When attempting to print or generate a print preview from within Outlook, the user would get the error message "There is a problem with the selected printer.  You might need to reinstall this printer.  Try again, or use a different printer." No doubt that countless hours have been spent attempting to resolve the problem from the printer/print driver side of things but the resolution is to remove the update and the problems will immediately cease.

There are several posts on the TechNet forums about this issue, where critical mass from the user community seemed to build up over the weekend. Microsoft has pulled the update and as of this morning has updated the KB article page stating they will re-release a corrected security update (http://support.microsoft.com/kb/2509470).

I recently ran into a situation where certain users in Active Directory were just not showing up for some administrators while other admins could see them just fine. Upon further investigation it became evident that if the Advanced Mode of Active Directory Users and Computers was not enabled, the user accounts were hidden. Using the Attribute Editor tab of the user's account I took a look at the attribute "showinAdvancedViewOnly" and sure enough the setting was enabled.

Cisco Unity was installed in this environment and the users that were not showing up in AD also happened to have the setting "Show subscriber in email server address book" unchecked in Unity. Unity was not only making the change that was intended for removing the user from the address book but was also setting the attribute "showinAdvancedViewOnly" as well.

If you experience the same issue the workaround is simple. Edit the attribute "showinAdvancedViewOnly" on the user's account with either the built-in Attribute Editor tab of the user account page (if you have AD 2008) or use a tool like ADSIedit or LDP.exe to perform the change.

VMWare now includes Powershell integration into their VI Toolkit releases. This allows us the ability to run cmdlets and scripts from Powershell to control your VMWare environment, making manual and time-consuming tasks much quicker and easier.

You can get the latest VI Toolkit here: http://communities.vmware.com/community/vmtn/vsphere/automationtools/powercli

The toolkit itself is regularly updated with new commands, so you'll want to make sure you keep it up to date. Once the toolkit is installed, it creates a shortcut to a new Powershell. This will launch Powershell with the VMWare cmdlets loaded. If you attempt to launch the old Powershell link and run any VMWare supported commands, they would fail because PowerShell would not be aware of them.

HP's universal Print driver can help ease managing drivers for printers in a big way. It can help keep the server's driver repository cleaner, it helps to make setting a Print server up much easier, and it gives more management options.

That being said, there is one option, the "Status Notification Pop-up" which some IT professionals would prefer their users not be bothered with. This is a pop-up that shows up on any client's PC which uses the printer when they print, or if the printer has an issue like low toner, out of paper, etc.

In the printer's settings itself there is an option to disable the notifications. However once you change the setting, apply it, and close the properties page, the setting is not saved. There is a way to not only disable this option (on all existing and future printers,) but also grey it out so it cannot be changed.

This will work whether you have already installed and configured all of your printers or not. If you have already set them up, don't worry, any settings inside the printer's driver that you've changed will not be reverted back to defaults.

First you need the UPD (Universal Print Drivers',) Install.exe file. Open command prompt and get to the directory you have the install.exe file in. We'll just go with "folder" as our example for now:

C:\Folder

Now you can type install.exe /gdssnp /ni

The /gdssnp will make a registry change to disable the SNP, while the /ni will make it so the actual printer install doesn't happen but the other steps along the way will.

Running this command will also make it so any new printers created will not use it.

The whole process can take upwards of 45 minutes. There is a point to where you will think it's locked up, but just give it time. It should finish.

If you run the installer with the /gdssnp switch like we've discussed, it will make the following registry change to every existing printer using the driver:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Printers\<PrinterName>\PrinterDriverData

If you prefer, you can go through and manually change the registry entry for every printer. But that could be a tedius and long process if you have a lot of printers.

There are several other switches you can run the UPD installer with, making managing and setting up the print server much easier, including (but definitely not limited to,):

• /q         Quite mode, no prompts
• /nd        Does not set the printer as default
• /dst        Disables the Services tab
• /dos        Disables the Online Support option
• /dssnp        Disables the Status Notification Pop-up for the printer you are currently installing.

The full list and other options can be found easily in HP's support documents. Just go to HP's website and search for Universal Print Driver.