Phew!

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.

The Setup

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.

https://docs.microsoft.com/en-us/windows/release-information/ 

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.

Sweet! 🙂

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.

Happy New Year! 

Happy New Integration Guide!

Late last year I spent time showing how Droplet Computing can run in the context of VMware Horizon Virtual Desktop as well as VMware Horizon Application Pools. I went on to show how you can leverage VMwareApp Volumes to deploy our software to a virtualized environment and use VMware  User/Dynamic Environment Management. It was nice to refresh my knowledge of VMware EUC offering as its been some time since I wrote my book about VMware VIew (that was back in version 4/5!). I was suitably impressed by the Instant Clones option which is a marked improvement on Linked Clones of old….

You can read our integration guide here:

https://www.dropletcomputing.com/wp-content/uploads/2020/01/VMware-Horizon-Integration-Guide.pdf

The last couple of weekends I’ve spent playing with Droplet Computing application containers solution. As ever getting “stick time” with any technology inevitably leads to thoughts about future functionality. I think the tricky thing for any new company is how far they want to carve out new features of their own, and run the risk of re-inventing a wheel that’s already been invented and in use already.

The dilemma though, is if you don’t spell out a management vision for a technology that’s essentially a platform, do you run the risk of looking like you’re lacking “vision”? The danger is you just want to be yet another vendor, with yet another ‘single pane of glass’ to be added alongside all the other ‘multiple pains of glass’ that customers have to toggle between. I guess the short part of that long-winded statement – what’s the best approach? To integrate or innovate?

I guess some Smart Alec would say the ideal thing would be to do both. Listen to customers and their needs and requirements and come up with solutions and functionality that addresses those needs. The only downside of this customer approach is customers can have a tendency to demand things, because they think they “should” be there. Only for the ISV to find out that this was tick-box exercise, and you have squandered precious development time for no reasonable benefit. It used to infuriate me when I suggested areas for improvement to VMware, only to be asked to explain and justify my thinking. Couldn’t they just see it was obvious! Of course, the reason I was asked to make my use case every time was to avoid the very situation I’ve just described. So featurism – the desire to add more features and options without a good use-case – is a crime I know I have been guilty of in the past. It’s crime I’m likely to continue to commit until I retire.

So, that gets me to the explanation of the title of this blogpost. Drip. Drip. It strikes me that the best kind of improvements to a new technology take little coding effort and improves functionality for all customers. A rapid series of quick updates is far easier to pivot, than massive undertakings that might take months to complete.

I think there’s another distinction to make with this type of approach. Do those drip-drip enhancements improve the users experience, or the administrator’s life and the deployment experience? For that reason, I’m going to separate them because at the end of the day no end-user ever patted on my back for well-administered systems.

User Experience:

Printing:

At the moment the only print support inside the container is for the native print driver that needs to be installed and configured by the administrator. Of course, customers may already have a license for some kind of universal print solution such as UniPrint. I think it would be great if Droplet Computing had some type of redistribution deal with a company like UniPrint. Ideally, this feature would retrieve the print configuration from the device OS, and then bubble those up into the container OS. This means the print configuration is ultimately managed by existing policies, profiles and/or scripts used to prepare the users environment to the device OS.

Unity-like Functionality:

If you’ve ever used something like VMware Fusion, you’ll have come across so-called “unity” style experience. This unity experience would essentially “hide” the Container environment as much as possible. Leaving just the application floating on the screen, and perhaps also creating shortcuts to Droplet Computing Apps contained inside the Droplet Computing Container. The end-user doesn’t need to interact with the “tiles” view in the main application.

But instead gains access to their application from an icon on their desktop. That said I’ve always been irritated about desktop icon clutter, where the entire desktop is covered with icons. Some kind of “Droplet Computing Apps” folder on the desktop that contains all the icons would be neat.

Content Redirection:

This is a Citrix feature that’s been around for sometimes. There are two types of “redirection”; one that takes from the device OS into the Container OS, and another that takes you out of the Container OS back to the Device OS. The former is 9 times out 10 the most common.

It’s very common for a user to find a document in a folder and want to open it with a double-click. Historically, in Windows that process been controlled with MIME file associations held in the registry. It can be tricky to get right. After all, generally file extensions tend to have no version information in them. For instance, the .PDF extension doesn’t help me decide if that application should run locally or within the Container OS. Nor does it help me in a situation where 9 times of 10, it should open locally, but in particular application scenarios it should open in the Container OS.

However, it is possible to create program logic that says for all Excel 2010 spreadsheets requiring Macros, to open in Excel 2010 in the Container OS, and for all spreadsheets created in Office 2016 open them Excel 2016. It would be possible to redirect these double clicks for the entire legacy XLS, XLM and XLT files to the Container OS. And to redirect all XLSX, XLSM, XLTX, and XLW to be redirected to a newer version of Excel running in the Device OS.

This kind of redirection also requires a method of passing the location of the file to the Container OS which I can used to retrieve the file. It’s one thing to call an .EXE using file extensions, and then another to then retrieve the data. It will generally require a communication channel and a file sharing protocol between the Device OS and Container OS.  And then there’s the tricky issue of authenticating the users access to the file – would that use the Device OS credentials passed-through to the Container OS, or would it use the credentials of the Container OS?

The other type of redirection flows in the opposite direction. This is typically where a link to some multi-media format is found in a web page or embedded as a link inside an application running in the container. In most cases that YouTube link, MP3 or MP4 video would be best played by locally installed application within the domain of Device OS. I see this as being less of an issue because the action happens less frequently as a double-click to open a file – because it’s easier to create and encode a simple “multi-media” rule to redirect all such links back to the Device OS.

Administrator Experience:

Multi-Container Support:

Currently the Container OS being used is Windows XP, and I understand a Windows 7 Container OS build is on its way. Although I think the numbers of users needing both Container OS’s at the same time would be quite small, it would be nice if there was an easy way for administrators to give access two more than one container at time – and for users to have an easy way to toggle between them. This isn’t a biggie as I suspect the number of people doing this will limited, and the best practise will be to keep these images to a minimum. Right now, it’s up to the user to browse between various image files. A task that’s probably beyond the abilities of the average user.

Tile Management – Clipboard and Browsing for .EXE:

Right now, the administrator has to type in paths to the EXE’s held within the Container OS. I would like to see the ability to browse these paths, rather needing to type them. Together with that I’d like to see the ability to copy an existing “tile” and modifying to reduce this sort browsing function to a minimum. It’s perhaps not a huge issue – it maybe that many customers of Droplet Computing are using the Container OS to deliver a single strategic legacy application rather than multiple applications after all.

Ideally, I’d like to see some sort of programable or scriptable method of setting up this environment, even if it something as crude as copying down an .ini file. I’ve no idea of where the tile data that makes up granted applications is stored, but I understand it’s not held within the Droplet Computing Image. So, it must be held somewhere probably in an ASCII file of some description. I assume the tile configuration is held in the user’s profile – so if they roam around the organization they find their Droplet Computing Container configuration follows them.

Web-Browser Support:

Currently, the Windows XP version of the Container OS contains no web-browser. I think that’s intentional to reduce the attack surface that legacy browsers bring, as well as keeping the Droplet Computing Image slim. That does present challenges – such as downloading software into the Container OS. I was forced to do that with an external NAS device that wasn’t too painful, but it does mean sourcing every piece of software from the Device OS and leaving it on shared locations.

It makes things like setting up the Container OS for Dropbox, Google Drive and OneDrive trickier. A lot of the download pages for these sites just inspect the OS with the web-browser to detect the extension required.

[Note: It’s perhaps worth noting that some of these extensions no longer work with Windows XP. For instance, Dropbox no longer supports Window XP for their download that extends the Windows Explorer environment.]

In the end I installed the K-Meleon (http://kmeleonbrowser.org/) web-browser into the Container OS that then allowed me to get some of my online software providers and extensions.

Conclusions:

This is my third and final post on Droplet Computing, but I’m sure I will be back for more in future. It’s worth remembering that users care less about HOW they get their applications, more than they just get them. So, whether its local or remote VDI, Server-based computing in the form of Citrix or Microsoft RDS or a Droplet Computing Container – they really aren’t that bothered by the delivery mechanisms. I know WE are, but they aren’t. And this is a reality that is often forgotten.

Ease of use is critical, and any delivery mechanisms that “gets in the way” of the user being productive is a distraction by any other name. Any feature or absence of a feature that results in a help desk ticket needs to be addressed. And, ideally, the delivery mechanisms must offer improved performance, ease of use and value for money to be able to unseat the incumbents. The ideal should be all three – but if a company can deliver two of these in a solution they will get traction in the marketplace.

It’s interesting how application delivery in the form of Containers has come full-circle. The much-loathed PC is a resilient little computing platform, one that has endured and survived huge changes in the last 40-odd years. Dismiss it at your peril. For me it’s testament to the economies of scale that the PC has honed over the years. Despite the rise of tablets and phones, these devices have excelled at delivering simple single-use applications.

But when it comes to the more productive knowledge work, it’s still the Office Suite of applications they spend hours in front of writing reports, presentations and maintaining the dreaded spreadsheet. Alongside these business-critical end-user applications, is a whole raft of applications that customers want to carry on using well beyond the vendors perception of end-of-life. It’s for these reasons I think the “Container” approach as delivered by Droplet Computing has legs. I can see customers adopting not just a method of delivering legacy applications to any type of device (Windows, Mac, Linux) but also as an application delivery method for new applications too.