Faronics and KACE integration: Improvement and Problems.

Recently, I attended a webinar which suggested a great idea: use KACE to control DeepFreeze freezing and thawing for labs, without using the Deep Freeze console, thereby centralizing the management of both Deep Freeze and KACE patching. In theory, this sounded like a great idea. So, I decided to follow a white paper that KACE wrote to do this integration. (download below) 

After getting everything in order following the instructions, I found at least one thing that was missing for my case. Due to the variations of versions, I decided to add a new field to the Deep Freeze Status, which would also include the version number of the Deep Freeze Config agent on each machine.

To do this, you need to add another Software Item in KACE, in the same manner that you added the “Deep Freeze Enterprise Status”, but this time, query for the “DF Version” instead of the “DF Status” and name the software item: “Deep Freeze Enterprise Version”. For a clearer idea regarding this, please refer to page 8 of the white paper.

Once the Custom Inventory Rule is added, now, all that is needed is to modify the MySQL code in the report, to include the version column. Below is the code needed, you can just take that, and replace the code that you currently have:

SELECT
MACHINE.NAME AS SYSTEM_NAME,
IP,
MACHINE.DOMAIN,
LAST_REBOOT,
LAST_SHUTDOWN,
(SELECT MACHINE_CUSTOM_INVENTORY.STR_FIELD_VALUE
FROM MACHINE_CUSTOM_INVENTORY
JOIN SOFTWARE
ON SOFTWARE.ID=MACHINE_CUSTOM_INVENTORY.SOFTWARE_ID
WHERE MACHINE_CUSTOM_INVENTORY.ID=MACHINE.ID
and (SOFTWARE.DISPLAY_NAME = 'Deep Freeze Enterprise Status' OR
SOFTWARE.DISPLAY_NAME='Deep Freeze Mac Status')) AS DEEP_FREEZE_STATUS,
(SELECT MACHINE_CUSTOM_INVENTORY.STR_FIELD_VALUE
FROM MACHINE_CUSTOM_INVENTORY
JOIN SOFTWARE
ON SOFTWARE.ID=MACHINE_CUSTOM_INVENTORY.SOFTWARE_ID
WHERE MACHINE_CUSTOM_INVENTORY.ID=MACHINE.ID
AND (SOFTWARE.DISPLAY_NAME = 'Deep Freeze Enterprise Version')) AS DEEP_FREEZE_VERSION
FROM MACHINE
WHERE ((1  in
(select 1 from MACHINE_CUSTOM_INVENTORY
join SOFTWARE
on SOFTWARE.ID=MACHINE_CUSTOM_INVENTORY.SOFTWARE_ID
where MACHINE.ID = MACHINE_CUSTOM_INVENTORY.ID
and (SOFTWARE.DISPLAY_NAME = 'Deep Freeze Enterprise Status' OR
SOFTWARE.DISPLAY_NAME='Deep Freeze Mac Status')
and MACHINE_CUSTOM_INVENTORY.STR_FIELD_VALUE is not null)) )
ORDER BY DEEP_FREEZE_STATUS, SYSTEM_NAME

Now that we covered the good thing, I will go through some of the problematic items with this process:

1. Since the processes are separated in KACE, meaning, a separate script is required for freezing, thawing, pushing patches, turning off, and turning on, this means that for every group of machines, 5 different pieces need to be coordinated. If you have 20 labs (Which is quite normal for any district), that’s about 100 additional schedules scripts that would need to be added. That said, given a concise naming convention, it would be possible to take control of this, and allow it to function correctly.
2. Even though I haven’t done too many tests yet, but, running the boot thawed, or boot frozen script on a lab label, doesn’t seem to always hit 100% of the machines. which means, the script would have to be run again. The problem with this, is that if I don’t target only the machines that have not succeeded in their reboot, then the whole lab will reboot again. Either that, or I would have to manually remove the lab label, and re-add machines that need the script re-run, which, for one lab is ok, but for 30, is quite cumbersome. A possible work around for this, is to modify the Deep Freeze reboot script to check for the uptime of machines, and based on that, reboot them, if they haven’t been in rebooted in x amount of minutes. It’s not a sure way to avoid re-rebooting, but it could mitigate against some of these cases.
3. Integrating KACE and Deep Freeze still doesn’t remove the need to create separate scripts for shutting down the machines after they are done. Ideally, the patching process would have a check mark to allow machine shutdown after the patching process has completed. If KACE is serious about their partnership with Faronics, they could even add a checkmark to freeze machines after patching is done. One or both of those, would make the process much simple, and avoid requiring multiple scripts before and after patching, and having to match the schedules of the patching and the scripts. All this, of course, assuming the schedules work as one would expect, and not +/- 15  to 20 minutes because there is still  a patching process still in progress.

These are only my first observations as I was testing the process. I will be updating this article as I work more with this, and perhaps suggest solutions if and when I find some. As a first impression though, this process of integration doesn’t seem to create a whole lot of benefit to justify re-setting up and scheduling the maintenance schedules already setup in Deep Freeze administrator.

Has anyone had any real life experience with this? if so, what was the solution to the above problems? Have you done anything creative to benefit more from this process? All sounded really snazzy in the webinar, and on paper, but in reality, it’s much less practical than one would want.

Related posts: