Month: July 2020

How to get rid of Internet Explorer

How to get rid of Internet Explorer

The time is right. Internet Explorer has had a very, very good run and it has been a good browser. For years it was the only Microsoft supported browser in a Windows Server operating system, even when Edge (the 1st) was released we still had to make due with Internet Explorer in Windows Server operating systems.
It’s now time to look in a different direction. A direction where we have a fully supported and modern browser with the new Edge browser based on the Chromium project. This browser is also available and supported in a Windows Server operating system.

During the last 6 months I have written a couple of articles about how to install and configure the new Edge browser, I have even penned an article about how to remove the pesky pinned takbar shortcut, which is created during the first launch of Edge.

In my article about how to configure Edge via group policy, I finish off by showing that it is possible to run sites with java content in Edge, something we historically had to use Internet Explorer to do. This is no longer the case, or technically it is, but we can now use “emulated IE” tabs, called IE Mode, within the Edge browser, so we don’t have to leave the browser when accessing legacy sites.

A couple of days ago I was helping a customer, and I noticed that he had Edge running, but Internet Explorer was also running in the same session. So we had a short conversation about IE Mode, he knew about it and what the possibilities were with sites with java content. It turned out he was accessing a Hitachi storage web based configuration site, which needed Adobe Flash Player. Seriously Hitachi, you need Adobe Flash in 2020? In all fairness I have to mention that I don’t know if my customer is on an older model of a Hitachi storage box, which for some reason can’t be updated.
Nonetheless we are also able to use IE Mode with sites with Flash based content.


Be aware that Adobe has announced that the 31st of december 2020 is the End of Life (EOL) for Flash Player.

This means that you should probably start looking at alternatives to whatever sites you are using, if Flash is still a requirement.

What is IE mode

IE Mode is a feature that allows us to specify that certain URLs should open in an “emulated IE” tab within the Edge browser. This is great because the user will never have to leave the primary browser, which is of course Edge, to access legacy sites or sites with legacy content (Java and Flash), everything is kept within the Edge browser window.
We can also open the specified sites outside the Edge browser in a standalone Internet Explorer browser, and not in an IE Mode tab in Edge. We might not get rid of Internet Explorer, but with IE Mode we can limit the use of Internet Explorer to a certain selection of URLs.

Java and Flash in IE mode tabs

I have included a screen recording of Java and Flash content running in IE Mode tabs within Edge:

Standalone Internet Explorer

Here we see the www.citrix.com and www.microsoft.com URLs both open in a standalone Internet Explorer. We also see that the Java.com site opens in IE Mode, we can have both configurations at the same time, so it’s not one or the other.

By now you might be wondering, what is stopping us from keep using the Internet Explorer window, which Edge conveniently launched for us? By default, nothing. We are able to use Internet Explorer all day long, we don’t want that, we want to get rid of Internet Explorer or at least limit the use of it.

Configure IE Mode

Let’s have a look at how to configure IE Mode, and how to prevent us from keep using Internet Explorer, if we are using standalone Internet Explorer windows. In this article I have configured IE Mode via traditional group policies. It is also possible to configure IE Mode via Microsoft InTune, this is not in scope here though.

Group Policy Configuration

The configuration of IE Mode is really easy, it’s basically 4 policies and you’re done.

With the policy configuration for Edge we have specified that we want to use Internet Explorer Mode (IE Mode) and we are also supplying a specific XML file using the Enterprise Mode Site List feature.
For Internet Explorer we have configured the “Send all sites not included in the Enterprise Site List to Microsoft Edge” and we are also, again, supplying the Enterprise Mode Site List.


Configuring the “Send all sites not included in the Enterprise Site List to Microsoft Edge” policy prevents the use of Internet Explorer all day long. If we are trying to access sites not specified in the Enterprise Mode Site List, we are directed back into the Edge browser. This is a very good way of limiting the use of Internet Explorer.

Enterprise Mode Site List

So, how do we create this so called Enterprise Mode Site List?
I would recommend the free tool by Microsoft called “Enterprise Mode Site List Manager”.

The Enterprise Mode Site List Manager can be found in Microsoft’s Download Center here:
https://www.microsoft.com/en-us/download/details.aspx?id=49974

The download provides you with a EMIESiteListManager.msi file. Go through the setup process:

Once installed you should have shortcuts to the Enterprise Mode Site List Manager on both the desktop and in the start menu.

When lauching the Enteprise Mode Site List Manager for the first time, it provides you with a blank site list configuration:

Here you will have to add the URLs for either IE Mode and/or standalone Internet Explorer.

Click Add:

  1. Specify in the URL, without http/https.
  2. Select Open In IE11
  3. If you want the URL to open in a standalone Internet Explorer, click the “Standalone IE:” check box
  4. If you check the “Allow Redirect” box, if there is a server-side redirected URL, it will have the same browser configuration applied.
  5. Leave the Compat Mode dropdown box at the default configuration

When you have the needed URLs configured, you will end up with something looking like this:

These are the URLs demonstrated in the screen recordings earlier. Notice the “Standalone IE” is true for www.citrix.com and www.microsoft.com, these URLs will open in standalone Internet Explorer windows, any other URLs will open in IE Mode within the Edge browser window.

To save the current list of URLs to an XML file go to File and select Save to XML:

Provide a name, in this example, for lack of creativity, I call it Sites.xml:

Once the XML file has been saved, be aware that a version number is assigned, you can find the version number here:

Or you can crack open the XML file and find it here:

The Sites.xml should be made available from a central location. Microsoft recommends to publish it via a web server, this is due to performance reasons. I usually makes it available via the NETLOGON share, as regular users cannot write/modify files and folders in that location.

When the user logs on, the Sites.xml is copied to the user’s profile, we’ll see where in a moment, the version of the Sites.xml is important, as the one in the user’s profile is compared to the one in the central location.

The downside by publishing is via NETLOGON or another file share, is that the file is copied to the user’s profile before a version comparison is made. If you have hundreds or thousands of URLs, it’s performs better via HTTP/HTTPS, as IE Mode can read the version number before copying the file.

If you need to make changes to an existing Sites.xml file, remember to also export the URL list configured.

The exported Sites.emie2 is needed for future changes as it keeps the version information.

So, import the Sites.emie2, make whatever changes necessary and then click Save to XML and save and overwrite the Sites.xml in the central location:

As you can see we are now on version 2 of the XML file.

The 65 seconds delay

The version comparison has a timeout of 65 seconds. This means that Edge and IE Mode does nothing with the Sites.xml until after 65 seconds after Edge is launched. At that time the Sites.xml in the central location and the one in the profile are compared and if a Sites.xml with a higher version exists in the central location, it’s copied and enumerated. This means that for 65 seconds after launching Edge, IE Mode is basically not in effect, which means that any sites that are configured to open in an IE mode tab or a standalone Internet Explorer are treated as any other sites, and will open in Edge.

I have worked with a lot of customers which wanted their intranet site as default startup page. If that intranet site is now configured to open in an IE Mode tab, because of the 65 seconds delay, that will not happen.

Luckily for us Microsoft introduced a new feature in Edge v84.0.522.40, which was released a couple of weeks ago, that enables us to prevent navigation in Edge if the Sites.xml does not exist in the user’s profile.
If a Sites.xml file exists, there is no longer a wait for the central Sites.xml and local Sites.xml to be compared, the local Sites.xml file will be used and any changes in the central Sites.xml file will be copied in the background. The feature can be enable via the Require that the Enterprise Mode Site List is available before tab navigation policy:

Here we see the new feature in effect. If we immediately after logon launch Edge, and type mycugc.org, Edge stalls until the Sites.xml is enumerated, as mentioned a great feature if you have an intranet site or a similar legacy site configure as a startup site. Unfortunately this new feature, doesn’t work with sites configured to open in a standalone Internet Explorer.

Keep in mind that Microsoft does not recommend enabling this feature, unless there is a specific need for it, as you can see it can/will slow down Edge in certain scenarios.

Now that we have the Sites.xml file and the 65 seconds delay covered, let’s see what happens on the client side.

IE Mode in effect

As mentioned, during logon the Sites.xml is copied to the user’s profile. The Sites.xml is copied to %LocalAppData%\Microsoft\Edge\User Data\Emiesitelist.xml and not Sitex.xml, a bit confusing:

If we open the EmieSitelist.xml with Notepad, we can see that the contents are the same as in the Sites.xml file:

Notice we are now using the version 2 of the Sites.xml, the one we created earlier.

This means that the latest addition to the Sites.xml file, www.mycugc.org, open in IE Mode within the Edge browser, as you have seen earlier.

The mycucg.org website is still opening in IE Mode tab within the Edge browser, so did both the Java test page and Adobe Flash test page.
The citrix.com and microsoft.com websites still open in a standalone Internet Explorer, but because of the “Send all sites not included in the Enterprise Site List to Microsoft Edge” policy we now also see that I am not allowed to use Internet Explorer to access youtube.com, that request is redirected back into the Edge browser.
There is a small delay on youtube.com, this is because of the Browser Content Redirection extension in Edge.

Troubleshooting IE Mode

The 65 seconds delay

When testing IE Mode the first thing that is almost always is reported back to me is, “IE Mode is not working!”. And it almost always turns out that the customer forgot about the 65 seconds timeout and being a bit more patient usually does the trick. If the Require that the Enterprise Mode Site List is available before tab navigation policy is configured that is probably not the case.

Also make sure that the Enterprise Mode Site list path and name is properly configured in the Configure the Enterprise Mode Site List policy.

Microsoft Edge policies

If you are experiencing IE Mode doesn’t work, make sure to check that Edge actually receives the IE Mode policies and a valid site list.
To verify the policies applied to Edge, you can enter edge://policy in the address bar:

If you don’t see the “InternetExplorerIntegrationLevel” and the “InternetExplorerIntegrationSiteList” values in this list, you can click the “Reload Policies” button, if that doesn’t help, you will probably have to check your GPO configuration.

Microsoft Edge Compatibility

If you are experiencing sites not opening i IE Mode or in a standalone Internet Explore, but you expect them to. You can verify which site list version is currently used and which sites are on the site list. This can be done by entering edge://compat in the address bar:

Now there should be no excuses for not getting rid of Internet Explorer, or at least limit the use of it.

This concludes the article. As always feel free to contact me on Twitter or in the World of EUC Slack channel if you have any comments or questions.

How to install the FSLogix Apps agent

How to install the FSLogix Apps agent

With this article I want to provide an overview on how I usually install the FSlogix Apps agent. The FSLogix Apps agent enables the use of the Profile Container, Office Container, App Masking and Java Redirection features.
This is by no means a “best-practices guide” however it does contain a few registry tweaks and workarounds that I have collected, and implemented, in a wide range of customer setups. This guide mainly focuses on the Profile Container and Office Container features, as the App Masking and Java Redirection usually do not need tweaks and/or workarounds, they just work.

I have been working with FSLogix for the better part of 5 years now, so I thought it might be time for me to both share a bit and also document the FSLogix Agent install process I have come to use over the years.

Get the FSLogix Apps agent installer

The first thing you need to do is to get the latest version of the FSLogix Apps agent, which can be found here:
https://social.msdn.microsoft.com/Forums/en-us/home?forum=FSLogix

Here you’ll most likely find the latest version of FSLogix Apps pinned to the top of the page in a “release notes” article:

Following the release notes link takes you to a new page, which contains a download link along with the release notes for the particular release:

If you just want the bits, here is a direct download link for the latest FSLogix Apps 2004 (2.9.7379.30108):
https://download.microsoft.com/download/0/3/3/0332586b-cd67-40f5-a16e-bb0bc6cfabaf/FSLogix_Apps_2.9.7349.30108.zip

I do however always recommend going through the release notes to see what has been changed/fixed!

Installing the FSLogix Apps agent

Once downloaded, you’ll need to extract the ZIP file which should provide you with the following contents:

In the x64 there is a release subfolder which contains 3 different setup files:

The one needed to install the FSLogix App agent, is the FSLogixAppsSetup.exe file.
The very simple manual install process looks like this:

If you want to change the install directory, click Options and specify the path, otherwise just click install. This will install the FSLogix Apps agent to the default folder which is %ProgramFiles%\FSLogix\Apps:

Besides installing itself to the %ProgramFiles%\FSLogix\Apps folder, the FSLogix Apps agent setup also creates 4 local groups:

As the description text says, these groups control who will be included (FSLogix Profile/Office Container should apply) or excluded (FSLogix Profile/Office Container should not apply). I’ll cover how these groups can be used in the next section.

FSLogix Apps agent post-install modifications

Now that the FSLogix Apps agent is installed, we have to do a range of different modifications.

Local Group modifications

The first thing we need to do is to remove the Everyone group from the FSLogix Profile Include List and FSLogix ODFC Include List groups:

The reason for this, is that we want to have more control over who get’s an FSLogix Container. If the Everyone group is not removed, any users logging on will get an FSLogix Container including administrative accounts, that is sometimes not desirable. You can populate these groups with Group Policy Preferences, scripts or simply bake it in the image. I always use Group Policy Preferences to populate both the includes group and the exclude groups, if needed.

Registry modifications

The second thing we need to do is to apply a few registry modifications. As with any other modifications, you will of course have to do some testing, to make sure they work as expected in your environment.

RoamSearch:
This registry value enables the Windows Search Index roaming feature in FSLogix. This value has to be configured during setup, to make sure that Windows Search roaming is working properly. More on that in the “Install sequence” section later on.
The registry value can be found here:
HKEY_LOCAL_MACHINE\SOFTWARE\FSLogix\Apps
RoamSearch=1, 2 or 0 (DWORD value)


1=Single-user search (Primarily to be used on VDIs)
2=Multi-user search (To be used on Session Hosts with multiple users)
0=Disabled (The default value)

Be aware that with Windows Server 2019 and Windows 10 Multi-User Microsoft no longer recommends to use FSLogix for Windows Search Index roaming, as it is now a part of the user’s profile and not machine-based like in earlier versions of Windows. However the built in Windows Search Index roaming is currently not working in either Windows Server 2019 or Windows 10 multi-user, so if you need that feature you will have to implement a workaround. I have described a couple of workarounds later in this article, one which contain an exception to Microsofts recommendations, great stuff.

CoreCount:
This registry value is not directly related to the FSLogix Apps Agent, it is however still relevant. Whether to configure it or not is still debatable, I do configure it though.
The registry value can be found here:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search
CoreCount=1 (DWORD value)


The CoreCount registry value limits the Windows Search service to 1 CPU core at all times. Back in the Windows Server 2012/2012R2 days, this registry value was needed to prevent Windows Search Index corruptions or bloating.
The indexing will take longer because of the limitation, if you have plenty of CPU capacity, then consider not configuring this registry value, as it may improve the indexing performance.

Install sequence

The correct install sequence is important if you want to make sure that the Windows Search Index roaming feature is working properly in a user session.
A quick brush up on Windows Search Index roaming. If you are going to use Outlook in “Cached Exchange Mode” (Microsoft recommends Cached Exchange Mode with Office 365) an OST file will be created, either in the Profile Container or the Office Container. This OST file has to be indexed in order to deliver fast search results in Outlook.

This is the install/configure sequence I always use:

  1. Configure the Windows Search service to automatic startup (not delayed startup) and start the service
  2. Reboot
  3. Install Office
  4. Reboot
  5. Install FSLogix Apps Agent + modifications
  6. Reboot

The configuration of the Windows Search service is only needed in Windows Server operating systems, as the service is enabled by default in Windows 10. The service needs to be running before installing Office, otherwise Office might not integrate itself with Windows Search and the indexing of OST files will not work properly.

I use this approach even if Windows Search Index roaming is not needed, it’s always nice to have the possibility of enabling it later on.
If Windows Search Index roaming is not needed you should disable the Windows Search service to conserve CPU resources, but do it after you have installed both Office and the FSLogix Apps agent, then you should be able to enable it if/when the need occurs.

Windows Search Roaming workarounds

You will have to implement a workaround, if you want Windows Search Index roaming to work properly in Windows Server 2019 and Windows 10 Multi-User.

Workaround 1

The first workaround, I call it the “EventID 2 workaround”, is covered by James Kindon on his blog. If you follow Microsofts recommendations, you need to let Windows roam the search index, which is in the user’s profile here – AppData\Roaming\Microsoft\Search. However, as mentioned earlier, the user-based roaming feature is broken, it simply does not work and once a single user’s index is broken, it takes down the entire Windows Search feature affecting all other users, and the only way to get it running again is to restart the Windows Search service. Some time during the process of breaking itself, the Windows Search feature logs an event with an ID of 2, the “Event ID 2 workaround” simply restarts the Windows Search service, whenever an event ID 2 is logged, which should be almost every time a user logs off.

Workaround 2

The second workaround is probably not know by many, and it is not supported by Microsoft.
I actually discovered the workaround in a Citrix article about the defunct Citrix Profile Management and started testing it in my lab. The preliminary results show a more stable Windows Search index process and most importantly no more corruption. Interestingly enough Citrix has also mentioned the registry change in the official Citrix Profile Management documentation where they state that you have to configure this registry value, to make the search index feature work in Windows Server 2019 and Windows 10 1809 and later, interesting. My guess is that this registry change makes the Windows Search index feature revert back to being machine-based, and not user-based, which enables us to roam the search index using FSLogix, however we will then have to go against Microsofts recommendations and enable the Window Search roaming in the FSLogix Apps agent.

Which ever method you choose, you will of course still have to do some proper testing in your own environment, to determine which solution best suits your needs.

Automated install and configuration

I am a very big fan of automation, and I try to automate as much as possible. Even though the FSLogix Apps agent install proces isn’t that difficult, we still have a few post-install customizations. If we want to deliver a uniform way of installing the FSLogix Apps agent and applying the post-install customizations, we need to automate the installation and additional customization configurations.

Here is how I usually install and configure the FSLogix Apps agent and the Windows Search service.

Windows Search service configuration

FSLogix Apps Agent installation and configuration

Depending on the workaround you choose, remember to adjust the RoamSearch value accordingly.
If you go with workaround 1, RoamSearch should be configured to 0. If you go with workaround 2, it should be 1 if using VDIs and 2 if using Session Hosts.

Windows Search Roaming workaround 1

Automating this workaround is not pretty, as PowerShell doesn’t natively support event based triggers. However my Google-fu is strong, and I managed to find an article describing how to create a scheduled task with an event based trigger, using only Powershell.
Credit for this solution goes out to – https://xplantefeve.io/posts/SchdTskOnEvent

Windows Search Roaming workaround 2

This workaround is very easy to implement, compared to workaround 1. As it’s basically only a registry value we need to write/change, this is really easy to do via Powershell.

This concludes the article. If you have any comments or questions feel free to reach out to me on Twitter or in the World of EUC Slack channel.