One important feature of Droplet containers is our non-persistent mode – or what’s referred to in our configuration file as “non-persistent mode”. By default, Droplet containers are stateful and changes are held in a single in an image file format called .droplet.
Non-persistent mode essentially makes the container stateless such that any changes that occur after the container is started are discarded at shutdown or reboot of the host device. It’s especially useful for kiosks – where a dedicated machine is the access point for a single application that is in a public arena. If something goes wrong with the application or device, staff can merely reboot the system – and it will go back to its “known good” state.
That principle also extended to the shared computer model – where a single PC is used by multiple staff over the day or week. Classic examples would be shift workers in a healthcare context, or call-center staff. They may be sharing the same physical PC and sharing the same container on that PC. It’s unlikely you’d want changes to accrue in the application between shifts. So, a combination of say mandatory profiles and droplet containers in a non-persistent mode – essentially makes the environment read-only, and super easy to reset. That works in another context such as lab environments in education where students jump on any terminal to carry out their work. This is especially true in environments where students deliberately delight in making changes – you know the type!
There is also a security angle to non-persistent mode. A significant number of our customers use Droplet to run legacy applications that could be vulnerable and subject to attack. Alongside our current security which creates a secure bubble around these applications – by making the container itself easy to reset to a clean state. For our customers taking advantage of this approach – they often run as Windows service – and schedule a rolling stop/start of the core Droplet service.
Finally, our old friend “bloatware”. As you will have observed in virtualization environments – Windows still creates temporary files, which even if deleted still tattoo the file system with dirty/stale blocks. Generally, the more modern the Windows kernel the fast and quicker the image can grow. By first using the persistent mode to install and configure the software – and then deploying it with non-persistent mode enabled you can guarantee the container image file stays the same.
Enabling non-persistent mode is simple as editing the settings.json which is in the user profile in the per-user model, or C:\ProgramData\Droplet when running as Windows service – and turning it on with a true statement. In my case, I did this on my Apple Mac using nano as the text editor.
I use non-persistent mode on my Mac mainly because it’s usually from there I show modern Windows apps running natively, and therefore I tend to use a modern container image type for that, so I’m keen to make sure it doesn’t grow unexpectedly
So, caveats…
There are two main caveats. First the obvious one. You should not store persistent data inside the container. This is something we recommend as a matter of course for the majority of customers. By using mapped network drives or our drive redirection feature you can make sure that data is store outside the context of the container. I would also recommend imposing either a local or GPO policy to hide access to the C: drive inside the container such that only remote storage is accessible. Another common mistake is making changes such as installing software into the container and being horrified that after a restart – it has disappeared. If you are doing this quickly whilst doing other tasks and distracted you begin to wonder if you’re losing your marbles. Non-persistent mode ALWAYS discards changes, and never asks – it just does it. The setting is seamless to the UI so no big red traffic lights are warning you of this fact. Have me and my developers being caught out by this fact? To quote Ludwig Wittgenstein Tractatus Logico-Philosophicus
“That which we cannot speak of, we must pass over in silence…
😉
The other caveat concerns the subject of my next blog post – “enableDomainLogon”. We do support joining the container to an Active Directory Domain. This primarily for containerized applications that mandate a full Windows Authentication. As you know any domain-joined device wants to update its trust password every 30-days. Effectively, the non-persistent mode would discard those password changes, and the container would end up “orphaned” from the domain. This is akin to having a laptop off the domain for several weeks, and then bringing it back into the corporate network, and discovering its trust relationship was broken.
So non-persistent mode is a great way to keep the container fresh and ensure no unauthorized changes are made to it – just make sure you don’t lose your marbles…