Back when I started with Droplet (it will be two years in Sept 2021!)  we had quite a simple product. Back then we just had two container types and a limited number of places where we supported them. Since then we have had many different container types running both in physical, virtual, and cloud environments. Additionally, there’s been an explosion of features and possible configuration options. I’m pleased to say that 100% of this development has been customer and demand-led. That’s how I feel it should be, and how it should remain. I’ve seen software companies go adrift chasing featurism. The endless development of new features simply to have something “new” to bring to customers, which lacks a strong, compelling use case driven by customer need.

Most software companies address this increased “flexibility” (what they mean is complexity!) by series of tables or matrix. I find these a turn-off mainly because they are not focused on the organization and reduces a product to series to “tick boxes”. I think they are difficult to navigate, often confusing in their own right – and don’t simplify the story in the way they intend. I prefer to have series of scenarios that are firmly rooted in a real-world scenario which makes it much easier for organizations, partners, and our staff to ask the right questions, and save in the process customers bags of time and energy – especially now we have 4 core types of container – with two sub-types within each category. Of course, even a scenario approach has its limitations – in that few organizations fit into a “one size fits all” – so multiple scenarios can and do exist – which lends itself to a more “blended” solution. The other thing I don’t like about matrices is they lead to drag-race comparisons between vendors based on a feature list – how often is it the case that a missing X or present X is latched onto as a deal-breaker – only to find that feature never gets enabled once in production!

So let’s look at some common scenarios and outline what my recommendations would be for the customer…

Scenario 1: Legacy Apps on Physical Hardware

This is probably our most common scenario – although I would say a significant minority of customers are using our technology to deliver a modern application stack.

Whether you’re running on Microsoft Windows 10, Apple macOS, or Google Chromebook I would recommend our DCI-M7x32 container leveraging the native hardware acceleration provided by the local OS. In the case of Microsoft Windows 10 that would be WHPX, Apple macOS that would be HVF, or on Google Chromebook those would be the KVM extensions. The DCI-M7x32 container is a good all-rounder for both legacy, and some modern applications too – and is probably our most popular container type.

Scenario 2: Legacy Apps On-premises VDI environments

We support hardware acceleration in VDI environments where Windows 10 is the primary OS running inside the VM. For on-premises environments like VMware vSphere, the Intel-VT or AMD-V attributes need to be exposed to the VM. For on-premises environments, we would recommend using Windows 10 Version 1909 or higher. Assuming you have all your ducks-in-a-row, then we would recommend our DCI-M7x32. In short, physical and virtual environments are treated equally. In case you don’t know hardware acceleration to the VM is very easy to enable on the properties of the CPU in VMware vSphere:

Scenario 3: Legacy Apps on Multi-Session environments

In this case, a server OS is enabled Microsoft Remote Desktop Session Host (aka Terminal Services) and multiple users connect either to a shared desktop or shared application infrastructure. In this scenario, we would recommend our multi-session container which is 64-bit enabled – the DCI-M7x64. Although this container type doesn’t currently support hardware acceleration it does provide up to 4-core and 192GB of memory. So that offers fantastic scalability – where one container image is accessible to multiple users – offering the same concurrency model as the RDSH host within it runs.

In Microsoft WVD Whilst E-series-v4 and D-series-v4 instances do pass hardware acceleration the benefits are limited to a power-user style environment where there is a 1-2-1 relationship between the user and desktop. In our literature, we refer to the model offering as the “Flexible Model”. As each user gets their own personal container accelerated by Intel-VT. In this case, the DCI-M7x32 container is the best type to go with.

In environments like Microsoft WVD we recommend the same configuration as we would with a RDSH – essentially Windows 10 Multi-session offers the same multi-user functionality RDS enabled Windows 2016/2019 server. The DCI-M7x64 container which multi-session enabled offers greater consolidation and concurrency ratios.  Laying the technical issues aside for a moment, economically, the utility model seems to allow wins as a multi-session environment is always going to offer consolidation and concurrency benefits. In our literature, we refer to this as the “Scalable Model” as this most cost-effective method of serving up containerized apps to multiple users. There’s an implicit lack of scalability for a multi-session container on a 32-bit kernel. Since that kernel is limited to using 4GB of memory – it means once you have around 9-10 users connected into the container – you run the risk of ‘out of memory’ conditions and swap activity. On an x64 container that isn’t a problem as the maximum amount of configurable RAM is 192GB.

Scenario 4: Modern Apps on Physical or Virtual Hardware

Frequently we have organizations wanting to run modern apps of Windows 10 rather than installing those apps directly to the OS. The reason for this can be multiple – but often it’s about wanting to decouple the apps from the OS to allow for portability, security and able ingest Windows 10 updates without fearing they will clobber the delicate blend applications. Another motivation can be trying to support applications across other platforms like Apple macOS or Google Chromebook. As the Droplet image is portable across all three platforms without modification it’s often the best approach.

In a pure Windows 10 environment – whether that was physical or virtual we would recommend the DCI-M8x32 or DCI-M8x64 container with hardware acceleration – the same container type would be used on the Google Chromebook. The Apple macOS on the other hand would benefit from the use of our DCI-M8x32 which we have been running for some time – which gives excellent performance. We do have a DCI-10×64 container type but you do need that with physical hardware (currently it’s simply too resource-intensive for a virtual/cloud environment – although that will change with improvements in software and hardware). We tend to reserve the DCI-M10x64 container for high-end devices (8-16GB, SSD/Nvme) as this offsets the payload associated with this generation of the kernel.

Scenario 5: Really Jurassic Apps on Physical or Virtual

Occasionally, we come across an organization with really old applications. For these organizations I recommend, they give the DCI-M7 container type a try, as often we find even really old applications will install and run inside our container runtime. If that’s not the case then I would recommend the DCI-X container type (hint: X refers to cross-compatibility). It offers the same “Droplet Seamless App” experience but contains an old set of application binaries and frameworks, often missing or depreciated in the DCI-M7 generation.

Sorry, it just amuses me that we use the term “firewall”. Yup, I know it comes from the construction industry, as a way of saving people’s lives and the integrity of the building. I sometimes wish hackers and other bad actors did have to walk-through fire as part of their punishment – but I guess that’s against some crazy health and safety laws. If you don’t know by now, I am joking. Besides which I felt “Walls of Fire” is a suitable “clickbaity” blogpost title that might garner me some additional views – and if that is the case, I’m very sorry for that.

So anyway, in the Droplet we have two firewalls – external inbound, and internal outbound. The important thing about the external inbound firewall is that is turned on by default and blocks all inbound traffic. There is no API or SDK – which means there are controls for the hacker leverage to facilitate an attack. That does have implications clearly for “push” based events, but so far in my experience the vast majority of networking activity is actually “pull” based – in that some software inside the container is responsible for initiating network activity. In that case, our triggers the internal outbound firewall…

The internal outbound is stateful by design – which is just firewall speak for saying that if a client apps open a TCP/UDP port to the network, then allow that to pass – and when communication ends or times out – then close that door. It’s the basis of many firewalls for decades. By default, our outbound firewall doesn’t block any traffic (remember ping and tracert do NOT work inside our container). The default configuration allows ANY:ANY. To a great degree, this is a deliberate choice on our part to deviate away from our usual stances of “all the doors are closed until you open them”.

[Aside: It’s the response to the reality in our time-pressed world, that almost no one has the time to RTFM these days. Heck, I’m surprised you even have time to read this blog post – but here you are. Thanks for that 🙂 ]

So, if we made our default BLOCK:BLOCK precisely zero packets would be able to leave the container, and we spend hours explaining why that was the case… So, if you look at our default firewall configuration when the container is powered off this is what you will see:

Changes to the firewall require access to the Droplet Administrator password, and that the container is shut down or the droplet service stopped. The changes made in this UI are permanent and survive reboots and shutdowns.

Note: Enabling block with no rules defines – blocks ALL network traffic from the container. This is a viable configuration if you wanting to block all communications in and out of the container except those allowed by our redirection settings or other internal droplet processes.

I can make this configuration very restrictive by only allowing port 80 traffic inside the container to work for 192.168.101.101, 192.168.101.104, and 192.168.101.105. This is common when a customer is running a legacy web browser for example IE8 to connect to a legacy backend web service.

In this screengrab below the web service running 192.168.101.101 is accessible (incidentally it’s running in a Droplet Server Container protected by secure and encrypted link…) but www.dropletcomputing.com is not accessible – notice also how my mapped network drive to S: no longer works. The Droplet redirected drives still function – which goes to show that for every rule – there’s an exception. So, our firewall does not block our own trusted internal communications – such that drives our file replication service.

So this blogpost is all about our networking and our built-in firewall. This is intended as a primer for geeks like me who like nitty-gritty details. You don’t need to know ANY of this stuff to use our product or deploy our product. In this first part, I will talk about the raw IP of the container and how that functions. In part 2 I will focus on our built-in firewall controls and how they work.

Firstly, let’s talk about the IP configuration of the container. The Droplet container is configured to be a DHCP client but critically does NOT get that IP address from your DHCP services on the network. Instead, a built-in service is responsible for assigning this IP that requires zero configuration. An ipconfig inside the Droplet container reveals the IP address assigned – incidentally it is always 10.0.2.15 for every container.

Notice the Default Gateway is 10.0.2.2 – this means that any packet outside of this network will be directed to 10.0.2.2. So, the thing to understand here is we by default NAT all traffic out of the container across this IP address which is assigned to the host device. Together with our firewall configuration this effectively “hides” the container on the network making it invisible.

One of the common admin tools to confirm network communications are utilities like tracert and ping. It is possible to ping the Default Gateway address, and get a positive response from the host device – but all other ping/tracert will fail. So, we don’t allow ICMP (the protocol that drives ping/tracert) to escape this host/container network. In the screengrab below the ping of 10.0.2.2 to the Default Gateway works, but all other ping tests fail.

The main takeaway is if you are experiencing networking problems – ping can and does result in false positives indicating a problem – when the issue lies elsewhere. Incidentally, this does not impact other utilities such as nslookup where the requests are driven by a different protocol. In case you don’t know nslookup requests are driven by UDP Port 53. So a nslookup on 192.168.1.1 will give a positive response (assuming a DNS PTR record exists for this reverse lookup). So in the screengrab below, you’ll see a positive answer to the query nslookup 192.168.1.1 and nslookup dc.corp.local

If you look closely, you’ll see the address 10.0.2.3 listed as the “unknown” server. So, a DNS forwarding is taking place on another built-in IP address of 10.0.2.3 which you can see listed if you run an ipconfig /all

So, if a container cannot get to \\dc.corp.local it more likely the case that the host device is misconfigured – or else there’s a problem with DNS where that name either doesn’t exist or is incorrectly configured. A nslookup is probably the most crudest and basic test of connectivity because if you get an answer it proves that the container is forwarding queries to the host device, which in turn is forwarding those requests onto the real DNS infrastructure.

Whilst I’m on the subject of names – one word about using names inside a container. The Droplet container is for the most part completely unaware of your network or domain (both DNS and AD) infrastructure – but it does understand IP and DNS based FQDNs.

[Aside: If you join the container to the domain – the above isn’t true. Our default behavior is the container is a member of its workgroup]

So opening explorer window on \\192.168.1.1 or \\dc.corp.local is highly likely to work – but using \\dc – the short or NETBIOS name is less likely to be successful, and is more likely to be slow. Here’s why. Many years ago, we embraced DNS as the main name resolution system – and most organizations decommissioned the systems that supported the short NETBIOS system that goes back to Microsoft’s NETBIEU protocol (commonly referred to as the less-than-good-old-days :p). NETBIOS names used to be resolved by either a host file, lmhost file or system call WINS (ah remember the days of JetDB driven name resolutions systems!), however, In the absence of these systems, a broadcast packet is probably the only way these shorter names will be resolved. As broadcasts are not proliferated across routers and inhibited by network switches and VLANs, the chances of successful resolution are slim – unless you run a flat network like you would on a simple home-based WIFI network.

What if you have a legacy application is so old, decrepit, and poorly written that it only works with NETBIOS names, and not the face new DNS names that started to be adopted with Windows 2000? Simplez, simply tell it the DNS Suffix information required to complete the short name on the LAN adapter inside the container.

A good way to illustrate this name resolution issue of NETBIOS names is trying an NSLOOKUP on a short name. Here you can see the query of “dc” using nslookup fails:

However, if I manually tell the Droplet container what my preferred domain name is (something it usually gets from domain membership or option 015 DNS Domain Name on your DHCP server) this “problem” goes away…

Of course, the simplest and recommended method of avoiding this issue altogether is to use FQDNs or IP addresses where possible, and avoid the use of NETBIOS names altogether…

So now, we have a good idea of the networking inside the container – what are some practical uses? Here’s one practical example – suppose you have adopted cloud-based solutions such as OneDrive, GoogleDrive, or Dropbox – and you wish to access those systems within the Droplet container. I wouldn’t be recommending installing the software to these systems INSIDE the container, as the synchronization process behind these systems is like starting to fill the container with redundant data. Better to use either our built-in drive redirection to access these or share out the OneDrive/GoogleDrive folder, and then map a network drive to it.

With our drive redirection enabled, any folder accessible on the host device is accessible to the end-user (based on their user login details…) and in this way, the File Manager of the container “mirrors” the File Manager of Windows 10.

So on the left we see the the C, F, L and S drives of the Windows 10 PC, and on the right we see the redirected drives of the Droplet container.

Another approach would be to share the OneDrive folder on the Windows 10 PC, and then map a network drive to the 10.0.2.2 address using that share name. So after sharing out the folder, I can connect to using SMB/CIFS by browsing to \\10.0.2.2 and right-clicking the share, mapping a drive to C: using the standard tools:

One of the most common questions that come up around Droplet containers on Google Chromebooks is the hardware specification. Whilst that is important and significant what I usually direct customers to validate first is what kernel generation is being used by the Chromebook. You see, it’s entirely possible that a very modern and powerful Chromebook is using an older kernel, and that an old and underpowered Chromebook is using a modern kernel. There isn’t any link between horsepower and the generation of the kernel in use.

Why is this significant? Well, kernels from 14.4 onwards were compiled by Google to allow grub (the bootloader) to expose Intel-VT attributes from the kernel to the wider ChromeOS. This attribute is passed as “VMX” in the grub bootloader. As probably know ChromeOS is a very lightly loaded and sealed environment – which drives great performance and security. For that reason, you can’t just change the kernel or modify the bootloader. Well, you can – by using “Developer Mode” – but that essentially “breaks” the security model. For the uninitiated “Developer Mode” essentially gives you “root” access to the device – and often say it’s not unlike “jailbreaking” an IOS/Android phone or tablet. It’s not so much the “kernel” that’s the issue but the parameter passed to that kernel via grub.conf. It just so happens that checking the kernel version is the quickest route to determine the capabilities.

How does this impact Droplet containers? We leverage Intel-VT to deliver our hardware acceleration for our popular 32-bit containers and some of our 64-bit containers too (depending on their generation). It’s worth saying not all Droplet containers benefit from this hardware acceleration – such as our DCI-X container. That’s because some of the kernels we use pre-date Intel-VT anywhere – so there’s no performance benefit to be had. I’m keen not to overstate the performance delta between accelerated or non-accelerated containers – often we are talking about the difference of seconds when the first Droplet containerized app loaded.

So how does one work out the kernel type on an existing Chromebook? First, you need to launch the Google Chrome web browser, and open a terminal prompt using [CTRL]+[ALT]+[T] on the keyboard, and then issue the command:

uname -a

This will print out the data needed to ID the kernel in use – in my case, this is a Lenovo laptop running Neverware’s CloudReady. This is an open-source flavor of ChromeOS used to repurpose laptops, PC and Apple Mac devices for ChromeOS. Performance can be stellar because often these devices have huge amounts of resources to run huge OSes – with ChromeOS being so light touch it means they are superfast. So, you know Neverware was recently acquired by Google – and think this is part of Google’s strategy to get a foothold in the world of Enterprise IT. Neverware can be a great ‘get out of jail” card for devices that are powerful enough to run Droplet containers, but where the kernel can’t be updated.

As for new hardware – we would always recommend speaking to your preferred OEM provider, as their internal inventories should allow them to find the details of kernel generation. Another source of information is the community sharing their experience – but need to be careful as some of these devices are only available in certain geographical regions – plus you not just looking at the kernel type but the specifications of CPU/Memory and local storage.

https://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices

My personal favorite (which is fantastically priced) is the ASUS C436 Flip 14in i5 8GB 256GB 2-in-1 Chromebook which is retailing here in the UK at the £799 bracket include VAT (or Sales Tax, if you are based outside of the EU).

https://www.asus.com/uk/Laptops/For-Home/Chromebook/ASUS-Chromebook-Flip-C436/

It’s a super-powerful unit for its price. In terms of CPU, my idea would some kind of Intel Core i3/i5/i7 device. Memory, I would say would be a minimum of 4GB, ideally 8GB. Storage-wise, capacity isn’t the issue but IOPS is significant – so I would prefer an SSD or NVme drive, over eMMC fundamentally an SSD or NVme drive wipes the floor of an eMMC type – which is usually fine as simple boot media for ChromeOS, but I feel isn’t up the job when it comes to run a Droplet container.

So, the main takeaway – Droplet containers run on Chromebooks and watch out of under-resourced Intel Celeron type devices and powerful machines with the old kernels. Once our Droplet software is installed you should be looking to see “KVM” is listed as the accelerator in the Help, About menus like so:

There many, many ways to get data in and out of the Droplet container – my own personal favorite is just to use my NAS-based storage on my network – as it gives me a centralized location for all my storage needs on a super-fast network. There other ways of course and that include using the clipboard to copy & paste a file into a container, as well as using our redirect drives. For some time we have also had our own file replication service or “Droplet Share”. The term “Droplet Share” is more of a marketing term because this does not leverage shared storage protocols such as NFS, SMB/CIFS, or iSCSI, but a built-in replication service. In fact, it was developed a secure method to get data in/out of the container even if protocols like SMB/CIFS are blocked. That’s the case in my many high secure environments where these Microsoft protocols are expressly blocked by the policies of our customers.

You can see if the file replication service is running if the orange cross appears in the bottom left-hand corner:

There are two main uses of this feature – a gorilla usage as an easy way to copy install media into the context of the container. I’ll often use this when a customer has already downloaded their install media to their desktop and started the container – and other methods are not available. A more legitimate use is in highly secure environments where such protocols as SMB are deliberately blocked, and security policies decree that redirected drives or the clipboard are not enabled. This is often the case in some banking and financial services environments where physical and virtual airgaps enforced when dealing with legacy applications that handle sensitive data.

The “Open Device File Share” opens a File Explorer/Finder Window on the host device, and the Open Container File Share opens a Windows Explorer application on the container:

So to the “back” is the Windows 10 File Explorer which opens the default path for the file replication service which is:

C:\Users\%USERNAME%\AppData\Roaming\Droplet\Shared

And the Window to the “Front” is Windows Explorer inside the container which opens a default path for the file replication service which is:

C:\Shared

Our replication is bidirectional, so any file/folder created in either Window results in it being replicated to and from the container. So here I create folders in either direction – and they were replicated in both directions:

We can cope with very large files – double-digit GB files – are not a problem. Of course, the bigger the volume of data the longer it takes to complete the replication. Some actions are almost immediate – such as file deletes – because no network IOPS are generated.

If customers are not wanting to use this feature it can be disabled from our settings.json or from our core UI under the settings gear icon:

Once the Droplet Fileshare feature is disabled – the services that back it are stopped, and the UI is redacted and the shortcuts removed – so there no orange plus in the bottom left-hand corner of the UI.

Finally, a word of warning about the Droplet Fileshare. When you are building your “master” image you might want to clean out the contents of C:\Shared and turn off the Fileshare feature – occasionally system administrator forget this and leave unwanted installers, scripts, and other such code – and that can end up being pushed out during the deployment phase.

One of the common questions that come is what options exist for presenting Droplet containerized apps in platforms like Citrix Virtual Apps. I have a bit of pedigree with Citrix – before pivoting to VMware in the 2003/4 era, my main role was as Citrix Certified Instructor (CCI) delivering their official curriculum – I started with Citrix MetaFrame 1.8 on the NT4 TSE platform. So, there is a number of ways that you can make Droplet containerized apps available these include:

• Full Application in Desktop
• Full Application as a published app
• Individual apps within the container

This guide handles that last one. The goal is to be able to present just a single application or .exe within the context of the container – so it advertised in the StoreFront like so:

So here I’m publishing the core droplet.exe and also a copy of Excel 2003 and Notepad within the container. Let’s have a look at the Excel 2003 example.

In the Citrix Studio we can use the Application node to make new definitions:

When adding the droplet.exe – you can change the icon by providing a .ico file:

We can modify the “Location” add additional command-line arguments – in our case “launch winword.exe –minimised”

This syntax instructs droplet.exe to start Microsoft Word and to launch the droplet.exe in a minimized mode if it’s not already started. The result is Microsoft Word launches, and droplet.exe is “hidden” in the Windows System Tray.

This is advertised in the StoreFront like so:

There’s a couple of other recommendations I would make if you’re opting to use a third-party-based publishing system to serve up Droplet containerized apps…

Firstly, you don’t need our publishing front-end called “Application Tiles” in this environment. You could if you so wished “mirror” the configuration in Citrix StoreFront in the Droplet client. Alternatively, you could remove all the “Application Tiles” – if you also disable our FileShare feature this makes the client, very much like an agent sitting in the system tray waiting for Droplet containerized applications to be launched from the Droplet Windows Service:

This configuration is not uncommon in environments where organizations have a method of controlling access applications which they have been using for some time, and prefer to create shortcuts to Droplet containerized apps in the standard way using:

droplet.exe launch “excel.exe”

Secondly, in our new release, we will be supporting the settings.json option called:

“hideSettingsMenu”: false

This has the effect of suppressing the “gears” icon in the UI which makes the UI a little bit neater.

For some time, we have supported joining our containers to Active Directory. Its function that’s always been built-in to our technology from its inception. There are several reasons why a customer might want to go down this route. Firstly, I should say we do usually try to avoid it mainly because it’s an extra piece of configuration to consider before going into production – with that said in many cases, it’s an unavoidable requirement of the containerized application.

AD Authentication became endemic as soon as Microsoft won the wars of the Directory Services fought against Novell NDS. Those wars remain firmly in the past, and you’ll find AD based authentication is pretty much the default method for many of the legacy applications – whether that’s some pass-through authentication where no pop-up boxes appear or some propriety UI that confronts the user – either way these methods usually require a computer account in the domain. Of course, nothing stays still – and the rise and rise on non-Windows devices (iPhone/iPad/Android) and web-based applications are fueling authentications methods which although tied to LDAP infrastructure, but use a system of tokens such as SAML/OATH as the protocol for the username/password. So, by a country mile, the primary reason for joining a container to a domain is to meet these authentication requirements – and the way those requirements are often found out is by testing.

The second reason for joining the domain is accessing other resources which may be backed by AD-based ACLs. In the workgroup model, this is going to create some kind of Windows Security box, where the user will need to type their domain credentials. We can store and pass those credentials, but if there’s an excess of them – then sometimes the quickest route to avoid these pop-up box “annoyances” is to join the container to the domain – and course, as soon as one application requires it the rest of the environment benefits from it as well.

There are other use-cases as well – and that’s to leverage other management constructs and tools that are AD domain-based. Not least AD GPOs – whilst the local security policy remains intact inside the container – many organizations would prefer to have an OU and policy setting pushed down to the container. For those organizations using some end-point management tools like SCCM to manage their conventional Windows 10 PCs, they may also wish to use the same management tools to control the software stack. Our general line on this is – fill your boots. Droplet isn’t about imposing restrictions on how you manage your stuff, nor are we about creating another “single pane of glass” for you to navigate through. But rather empower you to leverage your already very serviceable management infrastructure.

Finally, there’s one other reason to join the container to the domain – and that’s to take advantage of our multi-session capabilities. This is a scenario where the container runs in either a Remote Desktop Session Host (aka Terminal Services) or Windows WVD where Windows 10 multi-session is in use. It also applies to scenarios where more than one user logs into the same physical PC at the same time using the Microsoft “Switch User” feature – this is a common requirement in healthcare settings where staff on shift-share the same Windows PC and toggle between users using the “Switch User”. Of course, in the multi-session environments where one container provides applications for many users – we tend to use our 64-bit container type as it offers great memory scalability – and we need to separate the different users by their userID to prevent one user from getting the Droplet Seamless Apps of another. Whilst you could create users inside the container – that makes no sense logically when there is an AD environment in place.

The joining to the domain process is no different from the process you would use on a physical Windows PC. However, this is a manual process, so we provide customers a series of complementary scripts that automate this process. This includes are “arming” process so as a container is deployed on the first start-up it runs through these scripts which automates changing the computer name, joining the domain itself (creating the computer accounts in a designated OU), and ends by ensuring various AD-based groups allow access to the Droplet Seamless App. At the same time the default logon process is modified by changing an option in the settings.json:

This setting essentially turns off our default login process using our service account and instead challenges the user to supply their domain password.

By default, end-users will see the Windows Security dialog box connecting through to the container listening on the internal, non-routable IP address of 127.0.0.1. This uses the discrete, encrypted private network channel created between the host device and the container itself. Some customers like this approach as they see it as an additional layer of security, especially those organizations that have acquired third-party software that augments these MSGINA dialog boxes with other functionality. As you can see the domain/username is already pre-filled, or that we are waiting for is their password.

If customers would rather pass through the credentials from the main Windows 10/2016/2019 logon. That’s very easy to do with a couple of minor changes in the GPO that focused on the Windows systems run our software is all that’s needed. Again, we supply the documentation to configure those options if desired.

Other Considerations:

Now that the container is joined to the domain there are some other considerations and configurations to think about. By default, the Microsoft Firewall inside the container is turned off. We do not need it – because we have our firewall configuration. However, joining a container to the domain, means there’s a good chance that domain GPO could turn back on the “Domain Profile”. This policy won’t stop our core technologies – but it can stop the Droplet Fileshare service and stop our UsbService both of which are network processes.  This triggering of the Windows Firewall can be stopped by enabling this disabling policy (did you see what I did there?)

Computer Configuration > Administrative Templates > Network > Network Connections > Windows Defender Firewall > Domain Profile

The policy-setting “Windows Defender Firewall: Protect all network connections” can be set to disable for a GPO that filters just on the container computer object in Active Directory:

Another consideration is user profiles – as soon as multiple users are login in into the container this will generate a user profile. In most cases, this isn’t an issue because organizations have already a profile management system in place – not least Microsoft own roaming and mandatory profiles. That said it shouldn’t be overlooked – not least that the creation of the profile isn’t very quick, and the last thing you’d want is multiple containers with multiple different local profiles being created.

So that’s joining the container to the domain in a nutshell – mainly done for applications that require AD authentication and with our “multi-session” based containers used in RDSH and Windows WVD environments.