/build/static/layout/Breadcrumb_cap_w.png
02/12/2019 110 views

Our Hardwired lab computers have DeepFreeze on them and are configured to go into a maintenance state early in the morning.

I've encountered a fair amount of challenges with Managed and Offline Scripts via the K1000 due to Deepfreeze and the systems having performed an inventory, caching the dependencies while they were in a frozen state but did not do an inventory update or re-download the dependencies during their maintenance window.

I'm aware of many SysAdmins who have DeepFreeze and SCCM that exclude the CCMCACHE directory from Deepfreeze which allows dependency packages, patches, inventory data, ETC to be retained even if a machine is frozen.


Does anyone have any recommended practices or experience doing something similar to this for KACE? My hypothesis is that excluding C:\ProgramData\Quest\KACE from Deepfreeze should more or less do what I want, the main problem I'm thinking would occur is that the agent could become corrupted were the KACE agent itself to update while a machine was frozen.

0 Comments   [ + ] Show comments

Comments


All Answers

0

Things will not get corrupted they just never will really update so the next time a machine boots it just goes back to the old software including the client.

We use deepfreeze on all the academic machines.  We have gone to only using online kscripts for fixes and installs (even to update the client).  For patching we thaw rooms and use the DF console to run windows updates.  Then we add that rooms label to the patch schedule and do a run now on for that group to get all 3rd party products.

If you already have not, I recommend you put your DF machines in a separate ORG from non-DF machines

You can exclude the one directory, turn off auto provisioning and scheduled patching, only run online scripts and other items as run nows (no scheduled tasks at all).  This will allow inventory to run and the local files will update including the logs.  But you still do not want to run stuff while frozen since that stuff is going to add/remove/change files in places other then that directory.

Answered 02/13/2019 by: SMal.tmcc
Red Belt

  • With chained tasks you can now create a thaw kscipt and run that first then run all your other tasks and then finally run a freeze kscript.
    • Is the thaw action part of a chained task? E.G. a chain that has Thaw, Install something, Install another thing, freeze. Does task chaining gracefully handle resuming execution when a reboot occurs mid-chain or do they have to be split into separate chains?
  • Interesting, this sounds significantly different then our current layout. Could you please expand a bit on the benefits of using having the systems in separate ORGs? My concern about agent corruption is that if the agent were to update while a machine is frozen, the agent configuration that resides in C:\Programdata would be retained during reboots but the actual agent would roll back. I worry that the agent could become corrupted if there a formatting change with one of the agent's files that occurred after an upgrade which the older agent couldn't read upon rollback.