Can’t be bothered to read – then watch the video instead… 🙂
One of the most common questions we get asked about our software – is how you deploy “en masse”. When our technology was developed, we knew didn’t want to build “Yet-Another-Single-Pain-of-Glass” management frontend – to go with the other 100+ management front-ends administrators contend with on a daily or weekly basis. So, our response to the questions is usually – how do would currently deploy a piece of software into your environment – and take it from there. Usually, once we thru the trial and UAT phase, I usually set up a workshop where I work as a facilitator to help the organization work out its preferred approach.
The workshop starts by explaining that everything we do is just a file. What we usually recommend is building the Droplet environment on a ‘reference’ machine and validating everything works. Before copying the files needed to the central location ready for deployment.
There are small metadata files that reside in the user’s profile – these are generic and can be pushed to the profile of the destination user(s).
C:\Users\%username%\AppData\Roaming which can be easily accessed using shell:appdata from the run dialog box.
The two critical files are apps.json and settings.json. Apps.json basically controls the name of the containerized app, description, and icon (imported to apps.json using the .ico format, but converted into base64 string in the .json) file. You can see the apps.json as the publishing end of Droplet as it controls what .exe the user can load from the container – and protected by the Droplet Administrator password.
On the left, we have the contents of the apps.json and on the right UI in the client…
The settings.json holds the core configuration of the application itself – this more or less equates to the Settings tab held behind the gear icon on the client. Notice how we don’t expose ALL the settings in the UI. That’s to inhibit casual changes – such as turning on a feature – without understanding the implications or the dependencies.
The other metadata files are important but very easy to explain. The “credentials” file stores the Droplet Admin’s password stored in an obfuscated format. That’s fancy talk to say the password isn’t stored in plain text but is scrambled in a non-human readable format. The droplet.lic is the per-user license file. The eula_accept is a logical file – its absence would cause our EULA dialog box to appear, its presence causes the dialog box to be suppressed.
Clearly, the jewel in the crown in the .droplet image file. One question is where to store it? The answer is really up to the customer and also what the model is in terms of delivering the user desktop. For uses sat a regular Windows PC or laptop, it makes sense to leverage the SSD drive on the endpoint which is also a requirement for our promise of true “offline” access to the apps. I tend to dump mine in C:\DropletImages.
Most customers zip up the .droplet file, and then extract it on the endpoint. Of course, compression algorithms vary and the size .droplet file is very much dependent on the disk payload of your apps – but we have seen 50% compression rates on our image format. So, the zip/unzip process can be beneficial in terms of reducing any network hit during a deployment. A smaller subset of customers has taken to storing the .droplet image on the end-users OneDrive or GoogleDrive and thus leverage the background synchronization threads these modern cloud storage systems provide.
If on the other hand the desktop is delivered remotely such as in a VDI, the .droplet file could be stored on C: Drive or D: Drive of the virtual desktop itself. Much depends on whether the desktop is personal and persistent, or compossible/disposable and destroyed a log off. If you don’t care about the persistence of the container it could remain in the C:/D: drive – but if you do care about persistence – some customers store the container with the user’s home directory. Thus, it is doesn’t matter which desktop the user connects to, and the container “follows” the user around on the network.
So, with everything just being a file. After the question is how to handle those files. Some customers opt to handle the metadata file using AD GPO’s as these can easily be associated with an OU/Group membership:
Others prefer to script the entire thing using PowerShell and a combination of msiexec, icacls, xcopy and 7zip – perhaps using the ‘if exists’ kind of logic in script to check for the presence of files – and aborting the script early if it’s found that the application and files are already there Whereas other customers will leverage something like Microsoft System Center Configuration Manager, now called Microsoft Endpoint Configuration Manager.
In this case, we created a Device Collection to target the endpoint, and the software is installed in a modular way. The core “Application” installs the software, and then a series of “programs” which call scripts each have their own function. So, one scripts downloads and unzips the .droplet image. Another program copies down the smaller metadata files – and other programs make sure droplet.exe is started at login – together with stopping any pop-ups. We do also have customers deploying our software with Microsoft inTune and also MobileIron. I’ve no experience of these platforms – but as inTune grows its a matter of time that will have to write a guide to that as well. So many management systems, and so little time… 🙂
So the main take-away – everything we do is a file. The same files can be used seamlessly across Windows 10 (physical or virtual), Windows 2016/2019 RDSH, Apple macOS, Chromebook, or Linux. Droplet Computing doesn’t introduce another single pain in the ass of management – after all, you have plenty of those already right?