AVD client comparison IGEL – Windows10 – MacOS – Configuration and user-roaming

By Fredrik Brattstig @virtualbrat

In this blog post I made a comparison between the IGEL OS AVD Client, the Windows RD Client and the MacOS RD Client. There are some differences in getting your users able to access AVD sessions, and usability is an important piece.
There are differences in how different vendors look at the user experience, and the angle taken for how AVD sessions are accessed and used.
By playing around with the Windows RD client, the MacOS RD client and the IGEL AVD client, which are the equivalent client-side applications for the different endpoint OS’es, it is obvious how the vendors think about the way a user gets setup and connected, and if the use-case includes simple switching of users using the same endpoints.

IGEL is always enabling the “multi-user – single endpoint” while The Windows and MacOS are more of “single user – single endpoint”.

The endpoint configurations here are from 0 to a functional and connected AVD session.
There is a big difference, the IGEL AVD client is baked in to IGEL OS, while on Windows and MacOS the RD client needs to get installed either by the user or via central management.
To make the videos I decided to have one IGEL OS, one MacOS, and one Windows 10 endpoint as stand-alone devices, making whatever needed on the different platforms to allow me to connect to my AVD session. The first video shows 0 – 100 on Windows 10, MacOS and IGEL OS:

As seen in the video, Using IGEL OS user is connected to AVD within 53 seconds from nothing. The benefit for IGEL is that the AVD client is baked into the operating system. The Windows 10 endpoint gets from 0 to session in 1minute and 44 seconds, which I would say is very decent, keeping in mind that I needed to download the RD client from Web. The MacOS downloads the client from the Store which makes it simple, but then the issue starts. Stock default, without configuring email discovery for the workspace, the Mac client cant detect the AVD Workspace’s just by the user entering their email address. You need to go and find the URL to connect to. I’ve seen easier ways…. Anyways, the Mac weight’s in at 2:37, but as I did a typo on the password field id say, let’s take away 5 seconds and set it to 2:32
I assume there are ways to configure email-discovery so that the email works for the MacOS client, but hey, the Windows 10 and IGEL OS clients does it without any issues…

All three operating systems do support central managed settings and application push, so yes, it is possible to streamline this a bit for the users.

Now, let’s have a closer look at the kiosk scenario. And this is obviously an area where IGEL OS AVD client is more suitable than the MacOS and Windows 10 clients.
I’d say the main reason for this is that IGEL OS is a “thin client” operating system where the fundamentals are that devices can be shared amongst users. For the MacOS client, it is obvious that the main market is “one user – one device”. For the Windows client, this is where I’m getting a bit confused. Generally, Windows (I’d say) is a “one user – one device” operating system (ha this might give a storm of comments 🙂 ) – with the possibility to have multiple users sharing one device (via local or domain logins). Every user has their own profile that needs to be loaded (if you are using separate logins to the endpoint) – if so, the configuration for the AVD client is persistent per user. But looking at the kiosk scenario you would like to have a simple OS that just allows the users to connect to AVD (or Windows 365, or any other VDI solution). No access anywhere, no logic running on the endpoint more than just enough to get users connected to the session. If we look at Windows as a “thin client” operating system, the main target would be to offer a quick way for your users to approach a endpoint and login without the need to care about what the previous user was doing. I assume there are tools to make the Windows 10 operating system to work better in this scenario, or is there?
We will now have a look at three different videos where a IGEL OS endpoint, a MacOS endpoint and, a Windows 10 endpoint makes user sharing of one device to connect to AVD. The user fred2 will login to AVD first, logs off, fred3 logs in to AVD and logs off and back to fred2 logging in. So, user roaming on shared devices. We start with the IGEL OS endpoint:


What did we see? The first 50 seconds, I just add a simple kiosk configuration of the AVD client. I add @azure.igelize.me as the login domain, which allows my users to only use the username instead of the full UPN when logging in, saving loads of keystrokes over time, time is money.. BTW, setting the logon domain in the AVD client prevents usage of any other domain for the AVD client if you wish. Then I set the AVD client to restart when a previous AVD session has terminated (logged off or disconnected) making the endpoint being ready for user number two in just seconds. Then I start the user roaming sequence fred2->fred3->fred2.. 1 minute and 40 seconds later this has been completed in a very user-friendly manner!

So, let’s look at it with the MacOS client?


In the video I was logged in to the RD client as fred2 and didn’t connect the first time, instead I unsubscribed by clicking the trashcan in the RD client. then tried to access fred3’s workspace with e-mail address, which failed, so I had to add the discovery URL to be able to complete the discovery for fred3. Connected to my resources and logged in, logged off, I accidentally logged in as fred3 again when trying to figure out how to switch to user fred2. Removed the workspace connection, then to login as fred2 I needed to add the discovery URL again, login and connect…. 3 minutes and 41 seconds… if we remove my mistake of the extra session launch, we end up in like 3 minutes and 10 seconds. And lots of user interaction..

And, what about Windows 10?

Windows 10

On the windows 10 client I started as fred2 logged in to the RD client, launched my session and had to type my password again before getting access to the desktop. Logs off the session and have to unsubscribe to the workplace feed to switch to fred3. Fred3 subscribes to feed using e-mail address (UPN), authenticate to get the feed of resources, start the AVD session of choice, gets prompted for password, and gets connected. Log off AVD session, un-subscribe to the feed. fred 2 subscribes to feed again using e-mail address and password. Picks a session and connects, is asked for password again (that was just a few seconds ago entered) and then gets connected. 2 minutes and 26 seconds for the sequence.

As we can see in the videos, that out of basic configuration the IGEL OS endpoint is by far the best suited endpoint in a thin client scenario, where multiple users share the same endpoints. But I’d say that the IGEL OS implementation of AVD client makes the user experience even for “single user – single device” scenario very attractive too. Try it!

I sure hope that at least for Windows 10 based thin client like operating systems, that there are easier ways of roaming users sharing the same devices, if not, go talk to your local IGEL sales representatives!

If you want to have a test of IGEL OS, goto IGEL.com/avd to download your test version of IGEL OS.

With that, stay well!

See you soon