Tag: Citrix

Microsoft Teams in Citrix

Microsoft Teams in Citrix

During the last couple of weeks I have been helping customers implement Microsoft Teams in their Citrix VAD setups. A common denominator for most of the Teams implementations was Teams consuming a lot of resources, different Teams versions were present in the environment and Teams generating a huge amount of temporary or cached data in the user’s profile.

In this article I’ll share my experiences with Teams in Citrix VAD. This is by no means a best-practices install or configuration guide it’s more of a guide on how to avoid a couple of different pitfalls and hopefully also provide a great user experience with Teams in a Citrix VAD setup.

If you are not familiar with Microsoft Teams, you might want to gather some information before installing or configuring anything with Teams in a Citrix VAD setup. Visit this site, if you want to know more about Microsoft Teams.

First of all I want us to be on common ground before going any further with this article, so we’ll have to cover the different ways of installing Microsoft Teams, as this is an area causing a bit of confusion. In this article I am using the 64-bit version of Teams and the 64-bit version of Office installed in Windows Server 2019 with using FSLogix Profile Container.

Installing Microsoft Teams Per-User:

Today there are 2 different ways of installing Microsoft Teams. You can install it either as a per-user install or a per-machine (machine-wide) install. Microsoft recommends to install Teams as a per-machine install in non-persistent setups.

The per-user install can be installed in a few different ways. Either via the Office 365 click-to-run installer, via an EXE file or via an MSI file, Microsoft isn’t making this easy! Both the EXE installer and MSI installer can be downloaded in either 32-bit or 64-bit, make sure to get to one matching the Windows architecture.

You can get the EXE file here:

You can get the MSI files here:
32-bit – https://teams.microsoft.com/downloads/desktopurl?env=production&plat=windows&managedInstaller=true&download=true

64-bit – https://teams.microsoft.com/downloads/desktopurl?env=production&plat=windows&arch=x64&managedInstaller=true&download=true

So, as you can there are 3 different ways of deploying Microsoft Teams as a per-user install, a bit of a mess if you ask me and I am not surprised if some finds it a bit confusing.

We’ll need to dive a bit deeper in how the per-user install actually works, even though it’s not the recommended way of deploying Microsoft Teams, there is some useful information for when we cover the migration from the per-user install to a per-machine later in this article.

Both the EXE file, MSI file and the Office 365 click-to-run “installs” a Teams.exe file and a setup.json file in C:\Program Files (x86)\Teams Installer:

In this case I have installed version of Teams:

The Teams.exe file is the actual installer, which installs Microsoft Teams in AppData\Local\Microsoft the user’s profile. The installation is triggered by Teams.exe process via registry, which can be found here:

For copy/pasting:

So a plain old registry value in Run is used to kick off Teams, not necessarily the best way to start an app in a non-persistent shared environment, but then again this is the per-user install of Teams, which is meant to be installed on a physical Windows 10 machine, not a shared environment.

As mentioned, during logon Teams is installed in the user’s profile and when Teams is started up and the user has logged on, this is how the Teams install folder looks like:

Once this is completed, the Update.exe process, now in the user’s profile, is used to start Teams. This is, again, done via registry:

For copy/pasting:

As you can see the Update.exe is executed with a few parameters. I have not been able to find any information as to why this procedure is used to start Teams in a per-user install. My guess is that this Update.exe process checks for any new releases of Teams during startup of Teams, and then downloads the latest version at some point.

Microsoft has a very short article about the update process here:

According to the article Teams is updated every two weeks, no specific time of day is mentioned, so we’ll have to assume that the update process just kicks in at random. I have had a Teams running in a session for a couple of hours, no update kicked in. I have tried to log on and log off several times with Teams auto launching, nothing. At a customer I have seen 3 different versions of Teams being used at the same time, by different users. This might complicate things a bit in terms of troubleshooting because of the different versions. Some users might have issues that other users don’t have because they user another version of Teams.

For the sake of this article, I have done a manuel update via the “Check for Updates” feature:

This kicks off the update process, where the Teams.exe process and the Updates.exe process both consume a considerable amount of CPU resources, both processes have the priority of “normal” in Windows, which means that it might slow any other applications down for a couple of minutes, especially if you have multiple users where this update kicks in at the same time.

The update process goes out to Microsoft and downloads the latest version of Teams to the AppData\Local\Microsoft\Teams\stage folder in the user’s profile:

Once the source files for the new version of Teams are downloaded, the user will get a notification about a new version being available:

If the user clicks the “Please refresh now” text box, the updater kicks in and is again consuming a considerable amount of CPU resources, still at “normal” process priority, which may once again potentially slow other apps down for a period of time.
Interesting stuff is also going on in the user’s profile. The “stage” folder is now removed, and replaced with a “previous” folder:

So the user now has two versions of Teams in the profile, the current updated version, which is installed in the “current” folder and is the one being actively used in the current folder, and then the previous version of Teams, which is no longer used, essentially now doubling the amount of space used for the Teams install. Considering that I have found no information of how a user might be able to revert to a previous version of Teams, there is nothing in the Teams app that enables the user to roll back to a previously used Teams version, I am having a difficult time understanding why it’s necessary to store the previous version in the user’s profile, why isn’t just deleted?

To wrap this section up, there really isn’t any reason to use a Teams per-user install in a shared environment. In a shared environment we should have a degree of control of the apps installed and update process of the apps, to ensure stability and functionality. With a Teams per-user install, we don’t have any control, from the moment it’s installed it’s out of our control, because we don’t control the update process.

Migrate Teams per-user to Teams per-machine

Now you have come this far and you might have realized that Teams isn’t installed in the correct and recommended way, you can go a few different ways. Leave it be, and hope that Microsoft doesn’t change anything major or add additional features, which might demand even more resources or maybe break existing functionality. Or remove the current Teams per-user install and deploy the Teams per-machine install instead, which is also the recommendation from Microsoft.

If you decide to leave Teams alone in it’s current state, then there is no reason for you to read any further. However if you want to deploy the Teams per-machine instead, then stay with me.

To be honest this isn’t really a migration, it’s really “just” an uninstall of Teams, and an install of Teams suited for non-persistent shared environments.

Switching to a Teams per-machine install is fairly easy, you are probably not expecting that, considering we have to go out to every single user profile and remove a Teams per-user install, but Microsoft has actually done some clever thinking, when it comes to removing Teams per-user.

Uninstall Teams per-user

The first thing we’ll need to do is to remove the Teams per-user install. In Windows Server 2019 we’ll go to Apps and Features select the “Teams Machine-wide installer” and click uninstall. In this case the name is not entirely accurate, or it is, but the “Teams Machine-wide installer” is the machine-wide, or the per-machine installer, but it can also do a Teams per-user install. You might see “Teams” or “Teams Installer” instead, this is because you have used the EXE installer, mentioned earlier.

Back on track. The uninstall should be pretty uneventful, it’s an uninstall like any other uninstall, other than this uninstall only removes the C:\Program Files (x86)\Teams Installer folder, and not the Teams installed in the user’s profile. So, how to remove Teams from the users profiles? This is where Microsoft has done some clever thinking. During the uninstall of Teams per-user, two registry values are created here:

For copy/pasting:

We need the data in the value “TeamsMachineUninstallerLocalAppData”, this string will uninstall Teams per-user, in the user’s profile.
For copy/pasting:
%LOCALAPPDATA%\Microsoft\Teams\Update.exe –uninstall –msiUninstall –source=default

You HAVE to use this uninstall string, it is not enough to just delete the Teams folder from the user’s profile, Teams will come back if you do and you could end up with a mix of Teams per-user and Teams per-machine, they are able to exist perfectly fine side by side, you don’t want that!.

If you leave both values where they are, Teams will be uninstall during the next logon. In some cases that might be OK, however if you want a more controlled process, let’s say you want to do the uninstall for a specific group of users or when user’s access a test-server, you can bring in something like Citrix Workspace Environment Management, to execute the uninstall string based on AD group membership or anything that would identify the server as a test-server or whether the Teams install is a per-user or per-machine.

If you are going with the WEM approach make sure that both the “TeamsMachineUninstallerLocalAppData” and “TeamsMachineUninstallerProgramData” values are deleted, before going any further.

In WEM we can use an external task to execute the uninstall string:

Instead of using an AD group membership as a filter for the Teams per-user uninstall, we can use a combination of two filter conditions doing File/Folder matches, making sure that Teams per-user is not uninstalled, unless there is a Teams per-machine installed on the Session Host/VDI. We will have to create a filter condition which is checking to see if “%LOCALAPPDATA%\Microsoft\Teams\current\Teams.exe” exists and another filter condition which is checking to see if “C:\Program Files (x86)\Microsoft\Teams\current\Teams.exe” exists. The “C:\Program Files (x86)\Microsoft\Teams” folder is where the Teams per-machine is installed, we’ll cover that in a moment.

The filter conditions look like this:

With these conditions I can create a filter rule which can be assigned to the “Teams per-user uninstall” external task.

The filter rule looks like this:

For this filter rule to apply, both filter conditions have to me met.

The last thing we need is to assign the “Teams per-user uninstall” external task:

Go to Assignments and click the little arrow button

In the drop down box select the filter rule we just created

You should end up with an assignment looking like this.

To summarize – Via WEM we are now uninstalling Teams per-user if the user is logging on to a Session Host/VDI that has Teams per-machine installed and Teams per-user exists in the user’s profile. We now have a controlled way of getting rid of Teams per-user.

Install Teams per-machine (Machine-wide)

There are a lot of different articles and guides on how to install Teams in a non-persistent and/or shared environment, I recommend this article by fellow CTA Manuel Winkel:

Going further, I am assuming that you are going with the WEM approach, if you are not there might be some slight differences in how Teams behaves.

Also be aware that Microsoft is not making things easy for us at the moment. Currently there are two different download links for the Teams per-machine MSI installer, make sure to get the version from the link i Manuels article, as this is the version currently supported by Citrix (CTX253754). Make sure to keep an eye on that CTX253754 article.

The most important thing to remember is to user the correct install parameters during setup, to make sure that Teams is deployed as a per-machine install. Either go to the article by Manuel, refer to the official “Teams for Virtualized Desktop Infrastructure” documentation or use this command:
msiexec /i Teams_windows_x64.msi ALLUSER=1 ALLUSERS=1

To verify that it is a Teams per-machine install, make sure that you have a “C:\Program Files (x86)\Microsoft\Teams” folder. The folder structure in here should look familiar to you:

Teams is launched from the “current” folder via the Teams.exe process and once again a registry value is used to do the launch.
The registry value can be found here:

For copy/pasting:

Personally I delete this registry value, because I don’t want Teams auto starting via registry. There might be situations where you want to have a bit more control over who is running Teams, maybe because of license enforce ment or maybe you are testing Teams, and only want a certain group of users to be able to access Teams. Or perhaps you just don’t want applications auto launching during logon.

To control the Teams startup, we’ll again turn to Citrix WEM. Create an action, in this case it’s just called “Teams”:

Assign the newly created Teams action:

In this case I have created filter rule with a filter condition with an AD group membership check, so my user will have to be a member of a specific AD group for the action to apply.

Configure Teams for automatic start up:

Make sure Auto Start has a green check mark.

This is it! Teams per-machine is now alive and kicking.

Profile Exclusions

Both Teams per-user and Teams per-machine downloads a huge amount of temporary/cache data during first launch just to immediately flush it again, and to be honest I am not entirely sure why or what kind of data is downloaded, especially not with the per-machine install. However if you are not configuring the correct exclusions, you might see your FSLogix Profile Container increase in size, as the temporary/cached Teams is written and flushed.
With a fresh FSLogix profile, I have seen the container expand to around 4-5GB in size when launching Teams, with writes going the the AppData\Roaming\Microsoft\Teams\Service Worker\CacheStorage folder. If you mount the profile container, when it’s not in use, you’ll find that there’s only around 400-800MB of data in the container, and nothing or very few small files in the AppData\Roaming\Microsoft\Teams\Service Worker\CacheStorage folder.

As with any other profile exclusions, you should of course do some testing, before implementing in a production environment

UPDATE – 14-07-2020 (july 14, 2020):
If you are using FSLogix Office Container, do not include Teams data in the Office Container, as the exclusions mentioned will no apply to the Office Container, they only apply to the Profile Container.
This means that you should either leave this policy at not configured or configured it as disabled:

UPDATE – 19-05-2020 (may 19, 2020):
The list of exclusions, below, has once again been updated. Via a Citrix discussions forum post, I have been made aware that certain exclusions are breaking things.
Excluding “AppData\Local\Microsoft\Teams\current\resources\locales” apparently breaks the system tray menu
Excluding “AppData\Local\Microsoft\Teams\Current\Locales” apparently breaks SSO to Teams.

Do not add the folders with a strikethrough. If you do, test, test, test!

AppData\Roaming\Microsoft\Teams\Service Worker\CacheStorage
AppData\Roaming\Microsoft\Teams\Application Cache

AppData\Roaming\Microsoft\Teams\*.txt (Cannot be implemented with FSLogix Profile Container, as it does not support file exclusion or exclusions based on wildcards)

UPDATE – 03-05-2020 (march 3, 2020):
The list of exclusions, below, has been updated. According to the Microsoft Teams documentation the AppData\Roaming\Microsoft\Teams\Media-Stack should be excluded and the same goes with AppData\Roaming\Microsoft\Teams\*.txt files

Teams Outlook Add-in

For some reason the Teams per-machine Outlook add-in is not loaded, so when a user launches Outlook and wants to arrange a new Teams meeting, the Teams add-in is simply not there, and it’s nowhere to be found in the list of available add-ins:

I would expect the add-in to be between the Skype add-in and the OneNote add-in, but it’s not. I am not entirely sure what is going on here, but I have found a workaround which should bring the Teams add-in back.

UPDATE – 03-05-2020 (march 3, 2020):
Teams has to be launched at least once to be able to access the Teams plugin. This means that even if you activate the plugin in Outlook,during first logon, it does not work until Teams is launched. For now I haven’t found any solution to that issue.

The workaround is a minor registry change in HKCU, configuring the LoadBehavior value for Microsoft Outlook add-ins:

Windows Registry Editor Version 5.00

“Description”=”Microsoft Teams Meeting Add-in for Microsoft Office”
“FriendlyName”=”Microsoft Teams Meeting Add-in for Microsoft Office”

This should bring back the Teams outlook add-in. We can, once again, use our trusted Citrix WEM to do the import where we’ll create a nice little action group, with the Teams shortcut and the registry values like this:

Apply the Teams Auto Start filter rule we created earlier, in this way we have everything around Teams in one single group.

And here is the highly demanded Teams outlook add-in:

Citrix HDX Optimization

The last thing we need to do is to make sure that Citrix HDX Optimization has kicked in.

The Teams HDX Optimization is supported in Citrix Virtual Apps and Desktops 1906.2 and later and you’ll also have to use Citrix Workspace App 1907, however Citrix strongly recommends using Citrix Workspace App 1912 or 2002. You will also need Teams version, however Citrix recommends version 1.3.00 .4461 or later.

Refer to this article for additional information:

If all of the above mentioned criteria have been met, you should see a “Citrix HDX Optimized” notification in Teams (in about -> version):

The Teams HDX Optimization enables Teams video and audio calls to be offloaded to the local endpoint device, this feature offloads a considerable amount of CPU usage on the Session Host/VDI to the endpoint. Be aware that the Teams HDX Optimization feature is not available on Linux based devices, at the moment it’s only supported on Windows devices.

Thank you for reading. If you have any questions feel free to contact me via Twitter, LinkedIN or in the World of EUC Slack channel.

Microsoft Edge Group Policy Configuration

Microsoft Edge Group Policy Configuration

Some weeks ago i published an article about how to get started with the new Microsoft Edge browser in Citrix. In the article you got at glimpse of my take on how to configure a couple of GPOs with some configuration for the Microsoft Edge browser.

In this article I’ll drill down and go through some of the settings and what my recommendations are. I am mostly focused on the security side but I will also cover the Microsoft Edge IE Mode feature, which will help you with legacy sites that may only work in Internet Explorer and we’ll also have a look at how to set the default search engine.

Before going any further, please be aware that I assume you have some experience with Group Policy Objects and how they work, also there is information in my previous article you might find useful.

The internet can be a dangerous place, and thus we need to make sure that one of the primary applications used for accessing the internet is as secure as possible. To help us achieve that, Microsoft has provided us with some recommended security baseline settings. A short article by Aaron Margosis at Microsoft telling a bit about the security baseline settings can be found here:


The article contains a link to the Security Compliance Toolkit where you will find the Security Baseline Settings GPO for Microsoft Edge.

Security Compliance Toolkit:


On the site click the download button and select the Microsoft Edge v79-zip file and click next:

The contents of the ZIP file:

The folder names are self explanatory in regards of contents. The folder we need here, is the GPO folder as it contains the actual GPO we want to import to Active Directory. If you haven’t been doing a lot of GPO importing, there is a Baseline-ADImport.ps1 script in the Scripts folder, which may help you import the GPO to Active Directory.

If you prefer a more manual approach, this very basic guide provides the necessary information:


Group Policy configuration

You should now have a GPO with the latest Security Baseline settings. In my setup it looks like this:

I have imported the Security Baseline settings to a GPO called “Microsoft Edge Security Baseline Configuration and it has been linked to an OU with just one other GPO. The “Microsoft Edge Addtional Configuration” GPO additional settings that I want to apply to the Edge browser. The names here are not set in stone and are purely for reference. Use the naming convention in your own setup or whatever names that makes sense to you.

Using a separate GPO for the additional settings will keep the Security Baseline GPO “vanilla”, which means that the only settings in this GPO are the ones from the Security Baseline GPO provided by Microsoft. This is very helpful when/if Microsoft releases an update for the GPO, as you can import the updated settings to the current Security Baseline GPO, in my case the”Microsoft Edge Security Baseline Con figuration GPO”, and not have to worry about any custom settings configured getting overwritten. Needless to say, a scenario like this will of course mandate a bit of testing before released to production. Also keep in mind that the Security Baseline GPO is targeted the “Stable” release of Edge, not the BETA, DEV or Canary releases.

You will notice that the Security Baseline GPO settings from Microsoft are Computer Configuration settings only:

This is probably because Computer Configuration settings cannot, in most cases, be overridden by User Configuration settings and will therefore always apply.

This is basically what I’ll cover with the Security Baseline GPO. You will have to know the settings in this GPO and what they mean and what impact it may or may not have to your current setup. However I am configuring the Security Baseline GPO as a “mandatory” GPO configuration which should always apply, sort of laying the groundwork for the Edge policy configuration, whether the endpoint being Windows 10 or Windows Server.

The “Microsoft Edge Additional Configuration” GPO, is where I’ll configure settings which adds to the overall configuration of Edge. Which means that the settings in this GPO is combined with Security Baseline GPO, and together they serve as the complete configuration of Edge.

To achieve that, you’ll have to be aware of the link ordering of the GPOs. The Security Baseline GPO should always have a lower link order, than the additional configuration GPO, otherwise the settings in the Security Baseline GPO might not be correctly applied. In my case, as the screenshot above shows, my Security Baseline GPO has a link order of 2, and my additional configuration GPO is linked as order 1.

The link ordering is important if you want to counter a specific setting in the Security Baseline GPO, with the additional configuration GPO. As an example, let’s look at a specific feature in the browser. The Password Manager and protection feature, this feature is disabled in the Security Baseline GPO and from a security stance, that’s not a bad idea. However from a user’s point of view it might be helpful to have a password manager if he user accesses a lot of different website which require a username and password. Combined with an Azure AD login, it’s possible to backup/synchronize the password manager, so if user logs on to a new device, the password manager contents follow the user. Obviously you will have to decide, or maybe your security guys will have to decide, whether or not this feature should be enabled. If you want to counter the disabling of this feature done by the Security Baseline GPO, you can enable the feature in the additional configuration GPO which will, because of the link ordering, then take precedence.

Let’s go over the settings in the additional configuration GPO.

Computer Configuration
Microsoft Edge Update/Applications/Microsoft Edge
Update policy override Enabled –
Updates Disabled
As with all other apps in a non-persistent setup, we do not want any auto updating.
Microsoft Edge/Password manager and protection
Enable saving passwords to the password manager Enabled If you want your users to be able to save passwords to various websites in the password manager in Edge, enable this setting.
User Configuration
Microsoft Edge
Automatically import another browser’s data and settings at first run Disabled I prefer to be in control if any imports of other browser data and settings. This disables the automatic import feature in Edge, which is triggered during first launch.
Block access to a list of URLsEnabled –
Block Access to a list of URLs:
Credit goes out to Dave Bretty for this one. A while back he posted an article about how to prevent local drive access via Google Chrome. The same principles goes for Edge – https://bretty.me.uk/secure-local-drive-access-on-your-euc-endpoints/
Configure Internet Explorer integrationEnabled –
Configure Internet Explorer integration: Internet Explorer Mode
Enables the Edge IE Mode
Configure the Enterprise Mode Site ListEnabled –
Configure the Enterprise Mode Site List:
URL to the sitelist.xml file
This provides the URL to the sitelist.xml file. Contains a list of URLs which should trigger IE Mode, and open in a new Internet Explorer “emulation” tab in Edge.
Configure whether a user always has a default profile autimatically signed in with their work or shcool accountEnabledThis prevents the user from deleting the configured Edge profile, if an AAD login is associated with this profile
Define a list of allowed URLsEnabled –
Define a list of allowed URLs:
This can be used to pre-approve certain URLs and sort of whitelist them. In this case the receiver//* is configured, which means that Edge no longer asks about what should happen with ICA files, they are automatically launched with Citrix Workspace App/Receiver
Enable profile creation from the Identity flyout menu or the Settings pageDisabledCreating new profiles in the browser may pose a security risk, as the user will be able to configure non-enterprise accounts and configure synchronization account specific data, extensions etc.
Hide the First-run experience and splash screenEnabledHides or disables the first-run wizard seen during the first launch of Edge.
Set Microsoft Edge as default browserEnabledDoes what it says. Configures Edge as the default browser.
Microsoft Edge/Default search provider
Default search provider nameEnabled –
Default search provider name: Google
Specifies a name of the default search provider.
Default search provider search URLEnabled –
Default search provider search URL:
Specifies the search URL for the default search provider. In this case it’s Google.
Enable the default search providerEnabledIt does what it says. It enables the default search provider in Edge. Doing this prevents the user from change the default search provider.
Microsoft Edge/Extensions
Allow specific extensions to be installedEnabled –
Extension ID to exempt from the block list:
AS per the Security Baseline GPO, all extensions are blocked. This policy provides a list of approved extensions which may be manually installed. In this case I approve the installation of the Citrix Browser Content Redirection extension
Control which extensions are installed silentlyEnabled –
Extension/App IDs and update URLs to be silently installed:
In combination with the policy above, this policy can install any extensions configured. If you want to install extensions from the Google Webshop, you will have to also specify the Update URL
Windows Components/Internet Explorer
Use the Enterprise Mode IE website listEnabled –
Type the location (URL) of your Enterprise Mode IE website list:
URL or UNC to your sitelist.xml file
This is the last of 3 policies to enable the IE Mode feature. Here you specify where IE should look for the sitelist.xml file

You’ll notice that most of the settings are User Configuration settings, the main reason for this is the ability to apply AD user or AD group filters to the User Configuration part of the GPO. This is useful if I have some settings I don’t want to apply to certain user, I can so to say exclude them from the GPO and then configured set of policy settings in another GPO for these users instead.

Internet Explorer integration – IE Mode

One of the great features of Edge is Internet Explorer integration, or IE mode. IE Mode integrates with an already known feature called Enterprise Mode, which surfaced a few years ago in Internet Explorer 10.

What Edge and Enterprise Mode basically does is that based on a list of URLs in an XML file, it can determine if a specific URL should be launched in Internet Explorer and not Edge. We all know these 2 or 3 URLs that will only work in Internet Explorer, well now we can have Edge as the primary browser, and then configure Enterprise Mode to handle these 2 or 3 URLs, so that they open in Internet Explorer.

The way Microsoft has implemented this in Edge is that you can choose to either have Internet Explorer open as a separate process/window, or you can have Edge kind of “emulate” Internet Explorer in a tab within the Edge browser.

As I have mentioned in the group policy overview, you need to have an XML file where the Enterprise Mode URLs are defined. For that Microsoft has provided a tool called Enterprise Mode Site List Manager, which can be downloaded here:


Once installed you will have this very basic UI:

To populate the list, go to File and click Add:

Here you will have to type in the URL, in this case www.citrix.com. You will also have to select the “Compat Mode”, this is a list of compatibility settings available in Internet Explorer, for now just select Default Mode, this is the default IE11 Mode. Click Save.

Here is my very basic list, with www.citrix.com and www.youtube.com:

Now click File and then save to XML:

Once you have the XML, you need to copy it to a location where your users have read access. I usually copy it to the NETLOGON share, as the users have read access and the XML is also distributed across multiple servers (Domain Controllers). As mentioned, make sure to configure the URL/UNC to the XML file in the “Configure the Enterprise Mode Site List” policy.

So how does it look from to user’s point of view when IE mode is active? It’s very elegant and discreet:

And within the same Edge window I can have another tab open, which is not in IE Mode:

And here I am running Java inside Edge, isn’t that beauti….wait it’s not beautiful, we all hate java, but it is possible to put those legacy java sites inside the Edge browser.

Keep in mind though, that the XML is only parsed during logon, so if you make changes when users are logged only, they will get picked up during next logon.

Remember, group policies are not bad, they are often misunderstood, but not bad.