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?
Two videos – one using a Microsoft RDSH host running on VMware vSphere… and the other demoing the “Switch User” feature for kiosks in environments like health care.
Note: In the video, I’m running our software in vSphere VM because it made it super easy to show the “Switch User” feature – it’s also a great illustration of how Droplet containers run on physical or virtual environments in equal measure.
Okay, I’d admit that was a complete tease as a title, design purely to grab your attention and suck you in. Please forgive me. It should really be Droplet-as-a-Windows-Service (DaaWS)
One new thing about the 2.0 release is to “modes” of operation. You can run the Droplet container as our standard per-user application or as a Windows computer service. If the per-user application the user starts the Droplet container manually or else the administrator sets the software to run using the flags droplet.exe launch –minimised.
(Yes, that’s minimised with s, not a z! Just like virtualisation is spelt with is S not a Z :p)
This per-user mode of operation works best for containerised (with S!) apps that the user only needs occasionally such as once a day, or every other day or once a week/month – and where you want to maintain the “each user gets their personal container” model. From a resource perspective, the droplet.exe only consumes memory and CPU allocations when needed, and when the user is finished, they can shut down both the application and container. This model is commonly used by customers who want to deliver a containerized (okay with a zed this time just to keep the Yanks happy :p) app on an as-needed basis for a subset of users. The start-up time of the container is very good (around 30-the 40s mark) and so for many users, that’s acceptable.
Alternatively, our software can be configured to run a Windows computer service – which means the container is started when the Windows PC is started and is always running silently in the background. In the is case one Droplet container file services the needs of many end-users. It means the container is ready and waiting to serve up containerized apps as soon as the user logins to the Windows PC. In this model, our “client” application becomes just that – an “agent” that sits in the System Tray waiting for the user to run the Droplet Seamless App.
This was the first model I developed for Droplet Seamless Apps back when it wasn’t a product, but an in-house skunkworks. So, it’s been around in our labs for more than a year as we tested and validated the approach with our core customers.
So, there are a couple of core use cases.
Firstly, for customers who want to run their containerized app most of the time. In this case, whether the app is legacy or modern, it’s a key line-of-business app that is used by the vast majority of users, the vast majority of the time.
Secondly, we have many customers who are using the “Switch User” feature in Windows 10 PCs. A good example of that is health care (or own heroic NHS for example) wherein a given shift 4-6 different members of staff use the same physical machine and want to quickly toggle between different uses in the same kind of kiosk-style mode. Our container in this model allows for multiple users to access the same Droplet container on the same Windows PC.
Finally, the service-mode is ideal for Microsoft Remote Desktop Session Hosts (RDSH) on its own, or augmented by VMware Application Pools or Citrix Virtual Apps. This means one container can service many contexts on the server. For this model, we leverage our 64-bit container which allows 1-4 CPU cores to be allocated. It also supports allocating as little as 2GB memory up to a maximum of 192GB. This means the System Administrator can allocate a subset of resources to the container based on resources need to support the concurrency needed. This is a much more efficient model for running the container – it’s more efficient from a storage, CPU, and memory allocation perspective – than multiple users running multiple containers in the context of their remote user-session
In my last blog post, I talked about our 2.0 release and support for Droplet Seamless Apps, and the story is similar on Chromebook/Linux. We now have a brand-new way of presenting applications to the end-user that we call “Droplet Chelle”. Now I will fess up that the naming is a total vanity project on my behalf (Michelle/Chelle, geddit?) as well as a pun on the commonly used term of “shell” to describe any operating environment that provides an interface to the user.
All this running under Google’s ChromeOS Project Crostini. In case you don’t know that’s Google’s code name to allow Linux apps to run natively on Chromebooks, and thus extend the useability and usefulness of the ChromeOS – known as Linux (Beta) on the Chromebook. So essentially, we are running a modified and tuned version of our Linux-based product under ChromeOS. Of course, you do need a good Chromebook to run this stuff – so Intel Celeron with 2-4GB of RAM won’t cut the mustard. Fortunately, there are a whole raft of modern Chromebook’s out there that easily rival a Windows PC or Apple Mac for durability and performance. My personal favorite is the ASUS C436 Flip 14in i5 8GB 256GB 2-in-1 Chromebook which was doing the rounds last year at the £799 price mark.
So below I have the latest version of Microsoft Office 365 running natively on the Chromebook. I’m actually running Neverware CloudReady (a commercially and community-based open-source version of ChromeOS) who was recently acquired by Google. CloudReady is a great way to repurpose Windows PCs and turn them into ChromeOS devices.
In the next example, I switched containers to show legacy applications. The Droplet Chelle allows direct access to the Google Drive and Local Storage of the container which allows users to store the files in da cloud or locally without needing to set up or install Google Drive in the container itself.
So, I’m going to dispense with my usual blogging approach – long rambling blog posts with excessive amounts of detail :-p – and instead, opt for the more frequent bitesize approach complemented by a quick demo video – posted to the top of the page.
Very soon we will be officially releasing the 2.0 version of Droplet. Existing customers have been running on this release for some time, and we have been introducing our new version to organic opportunities since the end of last year. So, it’s been some time in the making and testing – and it’s now possible to do the reveal on much of the work of the last 18 months in terms of product development.
Firstly, I’d like to think our hard-working team of developers, not least my colleague Fabian Hemmer, without him and the team none of this would have been possible. I first got the idea for how to do seamless apps in late 2019. And initially discounted the idea at the conceptual level without even trying it. During that Xmas 2019 and early New Year 2020 I came back to the idea – and put together a skunkworks demo that was enough like a completed user experience that I could present back to my management. Moral of the story. If you have a wacky idea – try out – what have got to lose except time – and parts of your Xmas break. :-p
One of the big new features of 2.0 is our all-new “Droplet Seamless App”. Our goal in this release was to get out of the way of the user’s view, and just serve up Droplet Apps out of the container. In this way whatever the app might be it looks as feels as if it is running natively in the OS to the degree that they really have no idea that the application had been containerized. The level of this “seamlessness” varies depending on whether the application is legacy or modern. If it’s a legacy application, it’s like not support the Aeroglass style UI that Microsoft introduced in Windows 8 and onwards.
Here the Droplet Seamless App is a legacy version of Microsoft Excel 2003. To the left is our core application which would be normally minimized to being a system tray icon like so:
If on the other hand, it’s a modern application where Aeroglass is the standard – the user simply cannot tell that the application has been containerized. To the degree that we have a fun game with partners – called “Guess The App” where I run the same app twice – once on physical and once in the container – and they have to guess which is the Droplet App. Occasionally, I cheat by opening the same app twice in the container.
So here on my Windows 10 PC, you can see Command Prompts and two Control Panels. One is coming out from the container and the other is native to Windows 10. The only way you can really tell the difference is if I type “hostname” into the command prompts. You can see one returns “Michelle-PC” and the other returns “Droplet-PC”
The good news is this seamless experience is something we have extended to Apple macOS. That’s great news for our customers who have to support Windows and Apple devices – especially those in educational establishments where Apple MacOS use has been historically much higher.
So here I have the full Windows version of Microsoft Office 365 running on the Apple macOS (not the native Apple Mac version which has a different look and feels). This support for modern Windows applications on the Apple macOS is useful when there is no Apple equivalent or where the web-based SaaS version isn’t as good as the native Windows version. With a Droplet Container Image (DCI) just being a file. I can copy the image containing the software and use it on my Windows PCs and my Chromebooks (more about Chromebook in future posts!)
And all this is done without needing any backend server infrastructure (unless you want/need to run Droplet Seamless Apps in the context of VMware, Citrix, Microsoft WVD, or Amazon Workspaces/AppStream) completely offline using the compute power of the endpoint.
My last blog here was in April of this year. And what a year it’s been. They say hindsight is 2020, and who would have thought it would be in the year of 2020 that saying would be made true. I take the view that if you are still working, healthy, and haven’t lost a loved one to COVID, then you are blessed. I’m pleased to say I’m one of that group – and my love & best wishes go out to anyone affected by the events of the last 12 months.
One thing I didn’t realize is how bizzy I would in my first full year here at Droplet Computing – and it’s not just with doing 101 with new prospective customers or jumping on Zoom to assist with trials of software – or cranking out interoperability guides and KBs. What makes my job so enjoyable is the hours I get to spend testing, playing, and creating skunkworks in my lab, which I try to turn into products or product features. It’s probably the most creative part of what I do – and often driven by customers bringing challenges to us that you would only encounter in the real world. So one thing that is deeply rewarding is watching your technology become battle-hardened out there in the world of the production environment – forged in the fire of real-world use. One thing learned in the last 18 months or so with being at “Droplet” is how flexible you need to be, and able to turn your hand to any technology – which suits my character down to the ground. If variety is the spice of life, then working here is like a particularly hot vindaloo!
Anyway, I was inspired today to write a blog about my experiences of using an Intel NUC in my vSphere lab – a topic that would seem seaming unrelated to run running legacy or modern Windows apps in containerized format – but stick with me and you’ll see where I’m going.
So in my time of being a VMware Instructor and then an employee of the mighty VMW – I’ve largely kept away from the NUC style form factor. The resources always seemed so limited (volume of memory/number of NICs), and also because back in my ESX 2.x.x days I got burned by the HCL. I kid you not I once tried to install ESX 2.x.x to Dell Optiplex PC – and I’m proud to say that I’m one of a small number of people who ran ESX 2.x.x on Pentium III PowerEdge Pizza boxes connect to SCSI (yes SCISI!) JBOD! Home labs have come along way since 2004. But I decided the time had come to take a punt on an Intel NUC especially as I hard so many good and trusted people in the VMware Community speak highly of them (That’s you William Lam, if you’re reading this 🙂 )
So this is what I added to my basket on Black Friday, with a plan to buy the gear – do some tests – do a demo to my management – and then claim it back through company expenses. In that “act now, and ask for forgiveness” kind of way [I’m happy to say my sneaky plot worked like a charm – thanks Barry…]
Parts wise I played safe consulting Intel’s site for the NUC10i7FNH and only buying RAM and the NVMe card that was on that list. I probably could have found cheaper RAM/Storage from no-name brands coming off the same factory somewhere in deepest darkest China – but I figured that was pointless considering I’d only save a couple of bucks (or pounds) here or there. I took the decision to just fill one bank on the memory slots – in case this approach didn’t fly – but I’ve been so pleased with the experience, I will buy the other 32GB SODIMM. The only question is how to sneak that thru my expenses claim without the big boss man noticing (Sorry, Barry…)
I won’t bore you with a 4hr unboxing video (WTF!) where I marvel at the quality packing materials (FFS!). Needless to say – fours screws at the base and your in – slot in your RAM. Unscrew the mounting screw on the NVMe, which is sprung loaded, and once the NVMe is in place – screw the mounting screw back. Pop the lid back on and your good to go. I did the whole thing on the living room carpet whilst watching Bing Crosby in High Society. Not quite taking ESD precautions there, but hey – you only live once – right?
Gotchas – none really except:
- I had to go into the BIOS/EFI (F2) and disable the on-board Thunderbolt port when installing ESXi 7
- You get a weird TPM warning – apparently, there’s a BIOS update for that… and then you have to apply a Firmware update – then disable Secure Boot – AND if that doesn’t work – clear the TPM keys by installing Windows before installing ESXi. I did the Firmware Update (F7 and provide a USB stick with the .cap file on it) – but it still didn’t clear the warning. I decided to live with the warning – and turned the Secure Boot back on… Life too short too worry about a false-positive warning in a homelab…
- vSphere 6.7 wouldn’t install – and I got a weird EFI firmware message – apparently fixed by flash update – it didn’t work for me – I’m not bothered, who wants 6.7 when you can run 7 in your lab (but it would have been nice to have…)
- Being old skool I burned a CD (how quaint) and plugged in a USB CD/DVD I have. I guess I could have put ESXi7 on a USB thumb drive but I couldn’t be bothered – I got ESX7i on the box which is the main thing. The build I used was ESX 7.0.1 (1685050804) this apparently has the NIC drivers built-in to the build so need to faff about with VIBs and Image Builder, blah, blah, blah.
So overall I really rate the NUC. It’s a great little ESXi home lab server for those who are operating so far up the stack that you really don’t care about features – you just need a cheap & cheerful bundle of CPU/Memory/Disk to run the high-level stuff without burning precious hours trying to get some custom shop thing working, and tearing your hair out to get network drivers going.
I’ve half a mind to sell on my aging HP ML350e – and use the money to replace them with NUCs. If I did that I could sell on the half-height rack I have in the garage, and being the home lab back indoors which is quite nice considering it’s Winter. That said, I do rather like having the HP ILOs for videos. My plan had been to just keep on adding RAM to the HP ML350e’s and sweat that asset – which I still could do. It turned out that in the end, it wasn’t a memory I ran out so much – more than my CPUs were getting so old that they lack the horsepower/feature set I needed to do my testing. That’s a bit of a bummer because you can always add more RAM, but I rather balk at the idea of ripping out CPUs. Server-class hardware is always more pricey than PC class – and I spent a pretty penny upgrading the HP ML350e for the bare-bones (2nd CPU, Add DIMMS, and GPUs….). I guess that’s another trade-off with the NUCs, no chance of adding a GPU. So, having discussed this thru the medium of a blog, I think I will stick with the HP’s ML350e for now… add RAM as I run out, and use them increasingly more for management systems – and stick anything that needs performance to the NUC. The day the ML350s just won’t install whatever version of ESXi I’m running on is the day I put them on eBay.
Now for the Droplet part. For some time I’ve been concerned that some of my performance experiences weren’t very realistic in virtual platforms. My old home lab was based on some Gen8 ML350e which are some 4 years old (maybe more…). Although they have 2xSOCKETS they are only 8 cores of Xeon, and whilst they work fine for workhorse VMs (AD, Citrix, RDS, VMware View, and management nodes like SCCM and so on) it became clear I couldn’t use them to benchmark or get a feel for what our technology would do under the context of more modern hardware. So much so I abandoned that altogether this year – a took to testing our technology on cloud-based environments provided by our partners such as Amazon WorkSpace/AppStream and Microsoft WVD (big shout and thank you to Toby & Co at Foundation-IT for standing up that environment for me!)
The downside (for me) of these cloud environments is as a rule they don’t expose to their instances the Intel-VT attribute (Disclaimer: some Azure Linux instances, do have Intel-VT exposed) I assume mainly due to concerns about security and multi-tenancy. On physical Windows 10, Apple Mac and Linux/Chromebook Droplet Computing use a whole range of difficult hardware accelerators based on the container type, customer need and how is easy it is to get change management things approved (you know the score!)
So for me one question always was – if I expose hardware assistance to the vSphere VM running Windows 10, could I use a hardware accelerator to make our container “go faster”. I’d always failed to achieve this with my older hardware (BSODS and freezes ago-ago), and figured with a new chipset I might get a different outcome. Also wanted to see what ducks in a row might be needed to make this work – what combination of CPU/vSphere/Windows 10 Version – would be necessary. I’m pleased to say I was successful in getting to work on the Intel NUC. In fact, it flies – and I figure with a proper enterprise-class server – the result would most likely be even better.
Firstly, I needed to enable X Expose hardware-assisted virtualization to the guest OS. You might find this is already in place if you’re in the habit of enabling Microsoft Virtualization-Based Security (VBS) as MS VBS requires access to Intel-VT as well as other attributes such as Secure Boot and TPM in the BIOS.
Secondly, I need the right version of Windows 10. As you might know, there are two channels for Windows 10 – the semi-annual which is updated twice a year, and the Long Service channel (LSTC). Whilst the LTSC still languishes on version 1809 of Windows 10 – there have been at least 4 major releases on semi-annual, and we are currently on 20H2.
I started my tests using 20H2, but I have successfully made this configuration work with 1909 and 2004.
Aside: BTW there appears to be a bug in Windows 10 1809. I suspect the bug is “well known” and the fix will be “upgrade your version of Window 10” rather than an individual hotfix.
Thirdly, before installing our software I enabled a hardware accelerator in the side of the guest operating system
And that’s it… our software automatically picks up the hardware enablement inside the VM, and our container is nice and nippy. This particular benefits our 32-bit container which we use a LOT with legacy applications. We do have a 64-bit container (for customers who have legacy apps, which only shipped as 64-bit and for whom there was no 32-bit version). With our modern container (which needs more grunt to run) for modern applications, the hardware acceleration makes all the difference. So the break thru for us – is being able to run all our container types in a Windows 10 VDI VM without concerns about performance.
As a side benefit, it should also mean myself and our partners can use our vSphere labs more flexibly for tests and demos.
My next step is to QA this with our partners on a wide range of hardware – before we consider giving the green light on this configuration and officially supporting it – and I also need to test RDSH guest running Windows Server 2016 and Windows Server 2019 for platforms like Citrix VirtualApps, VMware Horizon View and Microsoft RDS.
It’s been some time since I blogged about things Droplet Computing. The main reason is we have been so busy with customers and product development (and documentation work!) I’ve had to focus purely on supporting new and existing customers. We have seen a spike in activity and engagements before the whole Coronavirus thing, mainly caused by the EOL of Windows 7, and folks being forced to decommission and get those apps into either Windows 10, Apple Mac, Linux, Chromebook or environments like VMware View, Citrix Virtual Apps or Amazon WorkSpaces. We are experiencing another spike of interest because of the Coronavirus, as customers look towards their nascent Work From Home (WFH) capabilities, and try to scale them to unprecedented demand, that few if any could have envisaged even a couple of weeks ago. I suspect when this is all over (and it will eventually be over) folks are going to have to think again about their WFH capacity.
So, in this blog post, I want to talk about what’s been happening in product development…
Droplet Computing DCA v1.2.3
The first bit of news is we recently GA’d a new version of our software that through a co-incidence of versioning has the number 1.2.3. Back in the early 1990’s Lotus 123 was the first application I taught as a fledging IT trainer fresh out of university. Back then Windows 3.1 had just gone mainstream and folks were being ported off their old DOS PC programs to this new-fangled thing that needed a “mouse”. I recall one delegate left a course because the creepiness of moving a pointer on the screen freaked them out, although they had no issue with moving the cursor on the screen!
I suggested our new DCA release and the Droplet Container Image (DCI) should not include Notepad as our default sample app but a DOS version of Lotus 1-2-3 as a nod to the past, and a little tongue in cheek joke – ostensibly to show how Droplet Computing Containers can run all sorts of apps, not just modern ones but Jurassic ones too! So here’s a screengrab of Microsoft Excel 365 and Lotus 1-2-3 for DOS running side by side…
The Spreadsheet Wars live again! 😀
Customers actively engaged in PoCs should consider upgrading to the latest version, to take advantage of all the new features, as well as fixes and performance enhancements. Existing customers obviously qualify for the upgrade as part of their support and subscription, but it’s not mandatory.
Droplet Computing is GA for Google Chromebook
A couple of weeks ago we GA’d the first release of our software for Chromebook. Initially, validated the solution with our DCI-X container (The X stands for cross-compatibility suitable for older Apps) container, and then last week – after substantial testing and QA – we were confident of the performance and stability to support our DCI-M container (M stands for modern, and I’ve had the DCI-M running Office97 and O365 suitable for modern and less Jurassic apps). If you’re not familiar with Chromebooks, Google has had a project called “Crostini” it’s called “Linux Beta” in the UI. Our regular .DEB file installs natively to this environment that we would usually use with Ubuntu. We have had this capability for more than a year, but recent changes in Crostini enabled by Google (THANK YOU GOOGLE, DROPLET LOVES YOU!) meant that finally, the performance was acceptable to us such that, with a modest amount bugfix es and testing, we were ready to GA.
Crostini has come on leaps and bounds in terms of performance in recent months, but the “killer moment” was the turning on of the access to Intel-VT instructions via the KVM /dev/kvm device. Performance is, from an end users’, perspective near native. From an end user experience perspective, it’s a “blink and you’ll miss it” level of performance. With our new development, we have been able to ramp up our relationship with Google directly, and I’m pleased to say that a recent tests conducted by Google engineers came back with a resounding thumbs up – not least because I was able to pull out the stops and build both a 32-bit and 64-bit container for their testing purposes, as well as an update to make things like Visual Studio 2019 work.
It is actually a feature that’s been around since the 1.2 release, but functionality that’s often overlooked by customers. So, I want to take this opportunity to highlight and focus on this feature. DirectLaunch something very simple – the ability to create shortcuts in Windows 10 that launches applications within the container. The syntax for DirectLaunch is very simple:
This will start the container using the configuration held in the per-user “settings” file:
“C:\Program Files\Droplet\Droplet.exe” launch
This will start the container (if not already started) and launch excel.exe, assuming MS Office of whatever flavor has been installed:
“C:\Program Files\Droplet\Droplet.exe” launch excel.exe
This syntax can be used to put shortcuts on folks’ desktops using a variety of methods such as AD Policies or your UEM of your choice such as VMware DEM or Liquidware ProfileUnity. They can also be used in “Application Publishing” solutions such as Citrix Virtual Apps, VMware Application Pools or Amazon AppStream. For example, in Citrix Virtual Apps 7.x you express the parameter in the command-line arguments section.
Support for Droplet 64-bit Containers on Linux and Chrome OS
As part of my engagement with Google Support staff, I was asked if we had, or supported, a 64-bit edition of our container image. The answer is we have always been able to support a 64-bit OS, currently supported on Linux and Google Chrome OS platforms. We are currently working on developing 64-bit support for Windows 10 and Apple Mac containers. With the updates that are coming from Intel we will be able to QA this support at some point in the future.
With that said, I haven’t actually seen a huge demand for 64-bit containers, mainly because there is usually a 32-bit edition of the software that offers the same functionality and performance. This was the case recently with a financial institution that had a legacy Java application. Initially, the customer said they “had” to use the 64-bit. Turned out this was just some “corporate standard” that because they had 64-bit Windows, they thought they “had” to use the 64-bit version of Java. Turned out the 32-bit version was just as good. So much for that “had”. I know that someday a customer will have an application that was only compiled and encoded in 64-bit. So, I feel it’s better to be ahead of that requirement.
Exporting Application Tiles and Disabling Shared Folders
Application Tiles is the term we use for the icons available in the Droplet Workspace UI that only allows the end user to launch their applications and for the administrator to configure. Essentially, these act as read-only shortcuts. Administrators can now easily export this application tile configuration to an apps.json file and reuse that configuration. In the case of AD GPO’s, it’s one of the core configurations files I push down to the user profile, so everything is configured for the first logon.
Next to the export functionality we now can disable “Shared Folders”. In case you don’t know we have our own internal file replication service (strictly speaking not a share as such as its not driven by SMB/CIFS/NFS). Occasionally, customers don’t want any file access – this is especially true when the containerized app is a DB application and all the end users changes are written to a DB backend from the client.
Droplet Computing 1.2.3 demonstrates our commitment to pushing our containers into every nook, cranny, and platform. With the incorporation of Chromebooks to our stable of support platforms, this opens new vistas and opportunities before ourselves as a company and our customers alike. I’m confident that this will provide a firm foundation from which we can focus on ceaselessly improving the user experience and creating ever increasingly seamless integration by which legacy and modern applications co-exist in the same instance. We have demonstrated our commitment to future-proofing the Droplet Computing platform by developing our capabilities to run 64-bit instances of our containers – as well as introducing the kind of administrative controls that befit a mature technology. I’m very excited about the future of technology.
You can learn more about what we do by checking out these resources, and if anyone would like to engage with me directly to stand up a ‘proof of concept’ just reach out to me thru the usual channels.
Case Studies including our very latest with Oxford University:
Product Admin Guides and Integration Guides:
Getting Started Videos:
My shortest most succinct blog post ever.
Don’t bother. Life is too short.
That was easy.
Joking apart what I decided to do with my Lenovo IdeaPad 530S was put Neverware CloudReady on to internal NVMe drive, and I bought 128GB MicroSD card for £20 and put Ubuntu on that. I have a separate box that runs Windows 10 on physical that I can Microsoft RDP into at home and remotely. That way, along with Apple Mac I have all my OSes covered….
UPDATE: Later in the year I was repairing a friend’s laptop. I bunged my SSD drive into their laptop, installed Windows to it, and then put the SSD in a USB-C caddy – from there I was able to boot the Lenovo from that, a bit a plug-and-play. So not quite a genuine dual boot (boot for single media, with a nice menu) but near with multiple devices and toggling with the BIOS menu instead. So in this configuration – allowed legacy (BIOS) and EFI booting, with EFI booting set as preferred – and place the internal SSD, external SSD into the EFI list, and the MicroSD card at the top of the BIOS list. That creates a menu like this:
Linpus: Neverware Cloud Ready
EFI USB: Windows 10
USB HDD: Ubuntu on a MicroSD