We have had a few customers reporting issues running BES on computers with Faronics (http://www.faronics.com) Deep Freeze installed.
The reported symptom is that the BES Console will show multiple computers with the same name.
Here is a short description of Deep Freeze:
“Deep Freeze protects and original computer configurations, eliminating routine IT maintenance while allowing complete unrestricted access to a workstation. Regardless of the changes made to a workstation, simply restart to reset the computer to its original state. The result is a protected, parallel network, free of viruses and unwanted programs. Deep Freeze is available for both Mac and Windows platforms.”
In the process of doing its job, Deep Freeze will prevent registry changes to be modified, thereby causing the BES Client to re-register with the BES Server as if a computer has been added to the network.
Faronics has published a step-by-step guide use BES to deploy and install Deep Freeze:
I’ve followed the above linked Faronics document and managed to resolve our problems with Deep Freeze (non-enterprise edition)
However, the documented solution requires you to set the BigFix client service startup type to Manual and then run a batch file via login script to test if the PC is frozen or not (using a Faronics commandline utility). If detected as thawed, the BESClient service is started thus allowing you to patch/update the PCs ok. If frozen, no action is taken thus the BESClient is not started.
However, I found that this didn’t quite work out ideally for us since the Dep Freeze PCs were on an automatic thawtime schedule of 1am to 6am when no-one would actually be at the machine to log on.
To get around this I used the Autoexnt utility from the
Windows 2003 Server Resource Kit
to install the batch file as a service which would then run on automatic startup, thus allowing the BESClient service to start whether the PC was logged on or not. Sorted.
I believe I finally have a viable workaround for the issues everyone has had with BigFix and Deep Freeze interacting with one another causing multiple entries in the console. We had a customer that was having this issue and didn’t like any of the proposed solutions that are currently available. The solution I’ve come up with still allows full functionality of the BES Client (eg: it’s running all the time and reporting) and should avoid issues with running out of licenses due to tons of duplicate computer entries. The “trick” that I use is saving and restoring the client registry entries when a frozen system is restarted. I will be posting a document to the TrendEdge website http://trendedge.trendmicro.com/ within the next week on how to make this all work.
Sounds exciting… We kept asking Faronics how we could accomplish exactly what you are asking about, but we never heard a viable solution… We look forward to seeing what you come up with…
The trick is to preserve the HKLM\SOFTWARE\BigFix registry key between reboots while a machine is frozen. There are a couple of ways to do it.
My first solution was just to:
Set the BES Client and (optionally) BES Client Helper services to manual startup.
Use Group Policy to define shutdown script that stops both services and saves the state of the HKLM\SOFTWARE\Bigfix registry key to a “thawed” location - either a local ThawSpace or potentially a network share. The network location has some serious security issues, though.
Define a startup script that restores the registry and starts the services.
The only issue with this approach is trying to configure the Group Policy on workstations that are not part of the domain. It’s definitely do-able but can be a bit of a pain as you have to manipulate the GPT.INI and SCRIPTS.INI files on the local machines. If Microsoft decides to change something in the future, it could potentially break the process.
What I’ve decided is a better and more robust solution is to just create a “BES Deep Freeze Compatibility Service” that will basically do the same thing as the startup and shutdown scripts when the service starts up and shuts down. Yeah, it’s another service that gets installed but it won’t use much memory at all and won’t use any CPU as it doesn’t really do anything except on startup and shutdown. It’s a lot easier to manage in the long run as well.
I’m in the process of coding the service EXE and have already written a few tasks and fixlets to manage things. I will post the link to the final document as well as the EXE and fixlet/task code once it is all up on our site.
Its great to see that you figured out a work around. But my question is have you found a way to get around the idle restart?
The reason I ask is because we tried something similar earlier this year. I wrote a startup and shutdown script to export and import the BES registry files onto a thawed partition we use for the App-V cache. Pushed it out with GPO.
It works like a charm, until the idle restart kicks in. Its a problem because the DF idle restart doesn’t shutdown the machine nicely, it simply kills it. (And by kill I mean that you can be looking at the login screen and the next thing you know you’re looking at the bios and the windows boot sequence)
For security and privacy purposes, we have to have an idle restart on our machines, so does anybody have any ideas on how to get around this?
I don’t know much about Deep Freeze itself, so I’m assuming “idle restart” means that the machine automatically reboots after it has been idle after a specific period of time?
Originally I had planned on just updating the “cache” on the thawed partition whenever my helper service was started/shutdown. However, knowing this little “gotcha” with DF, I can change the code to simply watch for changes under the BES registry keys and write them to the cache as they happen. So, in theory, it wouldn’t matter if the machine just dies without a clean shutdown. As long as it comes back up and starts the service, we would restore the settings.
I
think
that would fix this issue as well, yes?
Sorry for the delay in releasing the code, but I’ve been sidetracked with the flu and some other more pressing issues. I do hope to have something ready for everyone VERY soon, though!
Sounds like a great idea. Having the service update every time the registry is changed SHOULD work, in theory. But in this line of work I’ve had a lot of theories go up in smoke in practice.
If it comes to it, I can disable the idle restart and just handle it manually, but I’m hoping your idea works. Good luck!
Sorry it’s taken a LOT longer than I thought to get this finished, but I’m almost finished with the code and hope to have it posted along with docs early next week. I think I’ve managed to make the service so that it will also fix any potential issues with similar software like Microsoft Steady State. I’ll need folks to test it in the real world after I get done testing it in my virtual lab. The targeted OSes will be Windows 2000, XP, 2003, Vista, 2008, and Windows 7. It should run on both 32-bit and 64-bit. I have the code compiled for a native 64-bit service, but I won’t be releasing that until BigFix releases a native 64-bit client. Microsoft does funny things with registry reflection that will cause confusion otherwise.
If you need someone to test it, I’ll gladly volunteer. I’m running XP in my environment, but testing windows 7 for rollout Q1 2010 so I can test both platforms.
Okay - I have the code and documentation ready. I have one engineer in the field who’s going to test it at a customer site over the next week or two. If there are other folks out there who would like to test it and provide feedback, please drop me an email. I’ll send you a ZIP file containing the content as well as the install/admin guide.
Once I officially release it on our TrendEdge website, I will post the link here.
Completely forgot about this thread. I Managed to use Josh’s method for a little while, but Faronics released the data igloo in April and it does EXACTLY what we’ve been trying to do for years. I’ve been using it and it works perfectly.
I’ve had feedback that things are working with this service, so it should be stable. It works not only with Deep Freeze but any drive lockdown utility such as SteadyState. I will be updating a few things. I forgot to add in a check for the MSVCRT (MS Visual C++ Runtime Library), so if that is not installed on the endpoint, the service will not start. You can download the documentation and the files from our TrendEdge website:
I believe I have a issue with MSVCRT (MS Visual C++ Runtime Library), either not being installed or at a old 5 version. When I run the task to install the persistant cache service the action appear to run but the cache folder is not created nad the service does not start. The log sshows everything has completed but BigFix reports a failure. Checking the endpoints the PCSBES file and dll are there as expected.
What version of the MSVCRT (MS Visual C++ Runtime Library), and where can I download it from?
