KACE Agent Installation via Group Policy: Pilot

Based on some feedback I've received, I will being changing the format of these blog entries a little bit to display most pertinent information that may affect user experience on top, followed by any technical details below that.

SUMMARY:

Since disabling the swinstall from the login script, I've been working on implementing the same software packages using different means.  (currently Dameware and Nod32 implementations are being done via KACE, the information regarding those, can be found here for Dameware and here for Nod32) 

The KACE agent needs to be installed via different means. I chose to use GPO.  

For the time being, the GPO is enabled only on the technology OU. This will likely not affect anything in your user experience, as you all already have the KACE agent installed. There are some back end items that still happen on your machines regardless, so I would appreciate any feedback if you happen to see anything obvious or unexpected on your machine. For details about what's on the back end, please refer to the below technical details.

You can feel free to ignore the information below this point if you're not interested in the details.

• This GPO was put into pilot testing on 10/08/2012 at 1:45pm

Technical Explanation:

A little bit of background about GPO Software installation that pertain to our situation.

• GPO Software Installation Policies will only install a new software package if it's not installed on a workstation AND if the registry corresponding to the that GPO application is populated. The registry key can be found in: HKLM\Software\Microsoft\Windows\Current Version\Group Policy\appmgmt\ 
• GPO will always install the application, even if it's already installed on the workstation, if, the corresponding registry key doesn't exist. 

Based on the 2 points above, and what we know about our environment, currently, 100% of machines that have the KACE agent on them are not installed via GPO, and therefore don't contain the necessary registry entries to prevent a forced re-installation. Continuing without accounting for this variable, would cause a lot of unnecessary network traffic and CPU cycles; granted it will only be a one time deal. 

To mitigate this issue, 2 policies have been created:

1- The first policy is a Preference policy (PREF - SW - Fix Installed KACE Agent Registry) which targets computers that match a specific WMI query, as follows: 

select * from Win32_Product WHERE (IdentifyingNumber = '{C80E28A9-0620-48D7-A015-099636FA6FCB}' AND InstallState='5')

via "Item Level Targeting". That policy will only add the registry if the above WMI query returns TRUE. Effectively, it means that if the KACE agent is installed, tell the GPO Software Installation the same via adding that registry entry.

2- The second policy is the actual installation policy. (SW - KACE Agent Install). That policy is a simple Software Installation policy (Assigned, not Published), which runs the kace installation MSI:
"\\kbox\client\agent_provisioning\windows_platform\ampagent-x86_kbox.chino.k12.ca.us.msi"

Even though these 2 policies could have been potentially merged into one, there is one main reason why they are separated: Ordering.

In the GPO, this is one of the situations, where the ordering of the GPOs will actually matter. In a case where the KACE agent is in fact installed, but the registry entry doesn't exist, and the installation GPO is BEFORE the PREF GPO, then, the installation task will always trigger even if KACE is installed, because the PREF GPO didn't get a chance to run, and evaluate the existence of the agent.

By placing the PREF GPO on a higher priority than the KACE installer, it will take care of the registry entry, and will prevent the installation task from triggering if the KACE agent already exists.

PREF - SW - Fix Installed KACE Agent Registry

SW - KACE Agent Install