A couple of weeks ago I wrote about how we can now run a Droplet container as Windows Service. At that time, I just wanted to explain the use cases around that, and didn’t peel back the lid to explain how it’s done and what the setup process is like. It’s actually very simple.
Just to refresh the little grey cells – we have two modes of operation per-user or per-computer. In the per-user model, the end-user starts the container and waits a short while for it to load (30-40s on physical), and then they get their “Droplet Seamless App”. The start of the container can be invoked by loading droplet.exe and hitting the big orange “Start Container” button (no prizes for guessing what does)
This client can also be started when clicking a droplet shortcut backed by our “launch” syntax for example:
“C:\Program Files\Droplet\Droplet.exe” launch “C:\WINDOWS\NOTEPAD.EXE”
This model works well for containerized applications typically used only occasionally such as once a week, month, quarter, or on a completely ad-hoc as-needed basis. The per-user mode is also handy for administrators as it gives the admin an easy way to build, monitor and switch contains during the time where you install software and checking everything works as expected.
With the per-computer model, if on the other hand the containerized apps are being used all day and every day, it makes sense to automatically start the container when the Windows PC or Windows 2016/2019 server first starts. This means no need to wait for the container to load, and containerized applications are available immediately after login.
To set up the service I need a copy of the setting.json this per-user ]file can be found in the current user’s profile at:
C:\Users\%username%\AppData\Roaming\Droplet
And copied to:
C:\ProgramData\Droplet
Next, we can open a command prompt with administrator rights, and navigate to this location:
C:\Program Files\Droplet\resources\container\service
In this location is a droplet-service.exe utility that can be used to install, start and remove the service with the command:
“C:\Program Files\Droplet\resources\container\service\droplet-service.exe” install
Once the service is started it appears in the Windows Service MMC like so:
For the client-side configuration, I use a shortcut in located in shell:common startup using our flags to make sure the client-end is always loaded, but minimised to the System Tray like so – this means any changes to the entitlement is always updated at logon when the user “apps.json” is read. We can use the syntax:
“C:\Program Files\Droplet\droplet.exe” launch –minimised
* That’s minimised with a S not Z…. :-p
With everything in place, the client loads silently in the System Tray and connects to the Droplet container service.
As you can see with this model the client-side app merely becomes a “broker” to the applications running inside the container. We believe that as time goes by the per-computer model will become the de-facto way most of our customers will run Droplet software. Increasingly, we will become invisible to the user who shouldn’t have to worry or concern themselves with how applications are being delivered – all they do is double-click a shortcut, without any real awareness that their software has been dropletised (and that’s with a S, not a Z…)
:p