Author: Kasper Johansen

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

# Configure Windows Search service auto-start
$ServiceName = "WSearch"
$Service = Get-Service -Name $ServiceName
If (($Service).StartType -eq "Disabled")
{
    Set-Service -Name $ServiceName -StartupType Automatic -Verbose

        If (($Service).Status -eq "Stopped")
        {
            Start-Service -Name $ServiceName -Verbose
        
            # Disable Delayed Auto Start
            Set-ItemProperty -Path "HKLM:SYSTEM\CurrentControlSet\Services\WSearch" -Name "DelayedAutoStart" -Value "0" -Verbose
        }
}

FSLogix Apps Agent installation and configuration

# Define variables
$AgentInstaller = "FSLogixAppsSetup.exe"
$Switches = "/install /quiet /norestart"
$OS = (Get-WmiObject Win32_OperatingSystem).Caption

# Install the FSLogix Apps agent
Start-Process -Wait ".\$AgentInstaller" -ArgumentList $Switches

# Windows Search CoreCount modification
If (!(Get-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Windows Search" -Name "CoreCount" -ErrorAction SilentlyContinue))
{
    Write-Output "Windows Search registry fix" -Verbose
    New-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Windows Search" -Name "CoreCount" -Value "1" -Type DWORD -Verbose
}
    else
    {
        Write-Output "Windows Search registry fix exists" -Verbose
    }

# Enable FSLogix Apps agent search roaming - Apply different configurations based on operating system
If (!(Get-ItemProperty -Path "HKLM:SOFTWARE\FSLogix\Apps" -Name "RoamSearch" -ErrorAction SilentlyContinue))
{
If ($OS -Like "*Windows Server 2016*")
{
    New-ItemProperty -Path "HKLM:SOFTWARE\FSLogix\Apps" -Name "RoamSearch" -Value "2" -Type DWORD -Verbose
}
        If ($OS -Like "*Windows Server 2019*" -or $OS -eq "Microsoft Windows 10 Enterprise for Virtual Desktops")
        {
            New-ItemProperty -Path "HKLM:SOFTWARE\FSLogix\Apps" -Name "RoamSearch" -Value "0" -Type DWORD -Verbose
        }
            If ($OS -Like "*Windows 10*" -and $OS -ne "Microsoft Windows 10 Enterprise for Virtual Desktops")
            {
                New-ItemProperty -Path "HKLM:SOFTWARE\FSLogix\Apps" -Name "RoamSearch" -Value "1" -Type DWORD -Verbose
            }
                else
                {
                    Write-Output "FSLogix Search Roaming enabled" -Verbose
                }
}

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

# Define CIM object variables
# This is needed for accessing the non-default trigger settings when creating a schedule task using Powershell
$Class = cimclass MSFT_TaskEventTrigger root/Microsoft/Windows/TaskScheduler
$Trigger = $class | New-CimInstance -ClientOnly
$Trigger.Enabled = $true
$Trigger.Subscription = "<QueryList><Query Id=`"0`" Path=`"Application`"><Select Path=`"Application`">*[System[Provider[@Name='Microsoft-Windows-Search-ProfileNotify'] and EventID=2]]</Select></Query></QueryList>"

# Define additional variables containing scheduled task action and scheduled task principal
$A = New-ScheduledTaskAction –Execute powershell.exe -Argument "Restart-Service Wsearch"
$P = New-ScheduledTaskPrincipal -UserId "NT AUTHORITY\SYSTEM" -LogonType ServiceAccount
$S = New-ScheduledTaskSettingsSet

# Cook it all up and create the scheduled task
$RegSchTaskParameters = @{
    TaskName    = "Restart Windows Search Service on Event ID 2"
    Description = "Restarts the Windows Search service on event ID 2"
    TaskPath    = "\"
    Action      = $A
    Principal   = $P
    Settings    = $S
    Trigger     = $Trigger
}

Register-ScheduledTask @RegSchTaskParameters

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.

# Check if registry value exist.
# If registry value exists configure value data to 0, otherwise create registry value
If (!(Get-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Windows Search" -Name "EnablePerUserCatalog" -ErrorAction SilentlyContinue))
{
    New-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Windows Search" -Name "EnablePerUserCatalog" -Value 0 -PropertyType "DWORD" -Verbose
}
    else
    {
        Set-ItemProperty -Path "HKLM:SOFTWARE\Microsoft\Windows Search" -Name "EnablePerUserCatalog" -Value 0 -Verbose
    }

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.

The curious case of the pinned Microsoft Edge shortcut

The curious case of the pinned Microsoft Edge shortcut

I really love the new Microsoft Edge browser! Most of all because we now have a modern browser which is supported by Microsoft in a server operating system, but also because we are now able to integrate our Microsoft Azure AD/Office 365 account with Edge, which among other things enables favorites and password sync.

UPDATE – 06-06-2020 (June 6th 2020): I did not do proper testing during my last update, rather embarrassing. This means, that you will still get a pinned taskbar Edge shortcut. It looks like Microsoft implemented a partial fix, which doesn’t pin Edge to the taskbar of the account installing Edge. Any other accounts logging in, will still get the pinned Edge shortcut on the taskbar. I uploaded a new screen recording, recorded on a non-domain joined Windows Server 2019 with the latest CU installed and using the latest version of Edge.
Solutions in this article are still valid!

UPDATE – 04-06-2020 (June 4th 2020): As of 83.0.478.44 stable Microsoft has now fixed the install/configuration process, so a pinned shortcut is no longer created. I have tested this in both Windows Server 2019 and Windows 10. However in Windows 10, if the legacy Edge browser is pinned to the taskbar before deploying the new Edge browser, it will be replaced with a shortcut to the new Edge browser.

It’s been a few months since my very first article on the Microsoft Edge browser, written during Citrix Summit 2020. As you’ll probably notice, this article is focused mainly on how to install Edge in a Citrix setup.

I have penned an additional Edge article where I focus on how to secure the browser using the Microsoft Security baseline GPO settings.

As you can see I have spent a great deal of time with Edge, and it has of course also become my first choice of internet browser. The are so many scenarios where Edge fits right in, so I also spend a great deal of time telling customers and colleagues about the fantastic use cases where Edge might provide new or better functionality or solve an issue in a Citrix VAD setup.

However as much as I like Edge, I have found that Edge is now doing stuff it shouldn’t be doing. To be specific, when launching Edge for the first time in Windows Server 2016/2019 (probably also 2012 R2) a pinned taskbar shortcut is created, for no apparent reason. It is well known that when installing Edge on an up to date Windows 10 machine, the so called “legacy Edge browser” is replaced, Microsoft published an article around the same time as the first stable release of Edge. This means that any legacy Edge browser shortcuts, are replaced with shortcuts to the new Edge app, however we do not have the legacy Edge browser in a server operating system. I have also seen that evene if I don’t have a pinned “legacy Edge” shortcut in the taskbar, a pinned shortcut to the new Edge browser i still created, not OK!

I have created a small screen recording to shown what is going on. To rule out any domain related configuration like group policy, scripts etc. I have conducted the test on a non-domain joined Windows Server 2019 with the latest cumulative update. I am of course installing the latest Microsoft Edge stable release.

Screenpresso.com does not endorse this recording or this blog, I simply forgot to register the application 🙂

UPDATE – 06-06-2020: New screen recording uploaded showing the pinned Edge shortcut still appears with the latest Edge build v83.0.478.45

How is the pinned shortcut created?

During the installation of Edge an Active Setup registry key is created which launches a setup.exe file with a specific set of parameters.

This particular Active Setup is created during setup:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\{9459C573-B17A-45AE-9F64-1857B5D58CEE}

From what I can see in Process Monitor, the setup.exe process actually doesn’t do very much, but it does create a registry value in HKCU\Software\Microsoft\Edge (even in a server OS) called TaskBarAutoPin.

The first time Edge is launched, and this value data is “1”, a pinned taskbar shortcut is created, and the value is deleted.

How to get rid of the pinned shortcut?

I started looking into the documentation a The Chromium Projects website, and I found an article describing how to create a master_preference file. I have used master_preferences before in Google Chrome and also with the earlier releases of Edge, to remove the Edge shortcut on the desktop. In the documentation a “do_not_create_taskbar_shortcut” setting is mentioned, however it only works in Windows 8 and older, which I confirmed to be true, it does not work in either Windows 10 or Windows Server 2019.

With the Edge stable version 81.0.416.32 , Microsoft introduced an MSI command line parameter the “DONOTCREATEDESKTOPSHORTCUT=TRUE” which does indeed work, it prevents the desktop shortcut from being created. Hoping that Microsoft had built in a “secret” command line parameter I had to try “DONOTCREATETASKBARSHORTCUT=TRUE”, unfortunately it did not work.

I reached out to a former colleague of mine who is now a program manager at Microsoft. We discussed this issue for quite some time, and it basically ended up with him recommending me to submit a so called Microsoft Edge User Voice where I should describe the issue. Someone had beat me to it, a User Voice for the issue had already been submitted here. Please cast your vote, we need to make Microsoft aware of this issue and hopefully make them change this unusual behavior of creating pinned taskbar shortcuts. Or at least give us a way to prevent the pinned taskbar shortcut from appearing, in both Windows Server and Windows 10.

I am a tenacious guy, so I managed to find 4 different ways to get rid of the pinned taskbar shortcut, take that Microsoft! Credit goes out to Trentent Tye, James Rankin and Nathan Sperry for providing inspiration and/Or information to a couple of the solutions described.

Solution 1:

Using one of my favorite applications, Citrix Workspace Environment Management, we are able to remove all pinned shortcuts in the taskbar during logon by simply checking a box:

This will delete the shortcut during logon, it works and it is a non-destructive way of removing the shortcut. It’s was not quite what I was looking for though, I wanted to flat out prevent the shortcut from ever appearing, this procedure also removes any other pinned shortcuts, that might not be desirable.

Solution 2:

Another favorite of mine is FSLogix. The App Masking feature in FSLogix can be used for a variety of different things, but in this particular case it can be used to hide the entire Active Setup registry key created by the Edge setup, so the setup.exe process is never even launched.

I have created a very simple hiding rule which hides the Edge Active Setup key. This procedure is non-destructive which means it doesn’t delete anything, so if something breaks you can remove the hiding rule and the Edge Active Setup key is back in business.

I have created a hiding rule via the FSLogix Rule Editor:

Create a new blank hiding rule

Provide the hiding rule with a name and click the New Rule button:

In the object name box put in the full key path to the Edge Active Setup key and specify that it is a Directory/Registry in object type and click OK.

Lastly we need to specify which users/groups this hiding rule is applied to. I have specified that Everyone should have this rule applied, but if you want to be a bit more granular in your approach, you might want to select one or more AD groups instead.
To configure the user/group assignment, right click the name of the hiding rule and select Manage Assignments:

Here you will be able to enable the Everyone group and specify other groups this rule should apply to.

Click OK. Your hiding rule is now ready.

The only thing left to do is to copy the hiding rules files to the C:\Program Files\FSLogix\Apps\Rules folder:

The Edge Active Setup key is now hidden for all users logging on to the server, hence it will not run the setup.exe process and we will not get the pinned taskbar icon, happy days!

Solution 3:

Really simple solution. Delete the Edge Active setup registry key entirely. This can of course be done manually via regedit or via PowerShell::
Remove-Item -Path “HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{9459C573-B17A-45AE-9F64-1857B5D58CEE}” -Force

This is a destructive solution, so if anything breaks, you will have to have some way back to the original state. You can incorporate this solution is a part of the Edge setup process.

Solution 4:

Also a fairly simple solution. Delete the TaskbarAutoPin value in registry. Again this can be done manually via regedit or via PowerShell:
Remove-ItemProperty -Path “HKCU:\Software\Microsoft\Edge” -Name “TaskbarAutoPin” -Force

However I will of course recommend using Citrix WEM to delete the TaskbarAutoPin value via a registry action:

Like solution 3, this is also a destructive solution, so if needed you will also have to have a way back if things go sideways.

So there you have it, leave it to a Citrix-guy to fix Microsoft’s mess. I do hope that Microsoft will provide us with a better and/or simpler solution to prevent the pinned taskbar shortcut from being created. In the meantime we now have a couple of different workarounds to remove the shortcut.

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:
https://products.office.com/en-us/microsoft-teams/download-app

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 1.3.0.4461 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:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run

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:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run

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:
https://docs.microsoft.com/en-us/microsoftteams/teams-client-update

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:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run

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:
https://www.deyda.net/index.php/en/2020/02/25/install-teams-onedrive-in-citrix-machine-based/

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:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run

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!

Exclusions:
AppData\Local\Microsoft\Teams\Packages\SquirrelTemp
AppData\Local\Microsoft\Teams\current\resources\locales
AppData\Local\Microsoft\Teams\Current\Locales
AppData\Roaming\Microsoft\Teams\Service Worker\CacheStorage
AppData\Roaming\Microsoft\Teams\Application Cache
AppData\Roaming\Microsoft\Teams\Cache
AppData\Roaming\Microsoft Teams\Logs

AppData\Roaming\Microsoft\Teams\Media-Stack
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

[HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\AddIns\TeamsAddin.FastConnect]
“Description”=”Microsoft Teams Meeting Add-in for Microsoft Office”
“LoadBehavior”=dword:00000003
“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 1.2.00.31357, however Citrix recommends version 1.3.00 .4461 or later.

Refer to this article for additional information:
https://support.citrix.com/article/CTX253754

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:

https://techcommunity.microsoft.com/t5/microsoft-security-baselines/security-baseline-final-for-chromium-based-microsoft-edge/ba-p/1111863

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:

https://www.microsoft.com/en-us/download/details.aspx?id=55319

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:

https://www.oreilly.com/library/view/active-directory-cookbook/0596004648/ch09s08.html

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:
file:///A:/
file:///B:/
file:///C:/
file:///D:/
file:///E:/
file://localhost/c$/
file://localhost/d$/
file://localhost/e$/
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:
receiver://*
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:
{google:baseURL}search?q={searchTerms}&{google:RLZ}{google:originalQueryForSuggestion}{google:assistedQueryStats}{google:searchFieldtrialParameter}{google:searchClient}{google:sourceId}ie={inputEncoding}
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:
hdppkjifljbdpckfajcmlblbchhledln
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:
hdppkjifljbdpckfajcmlblbchhledln;
https://clients2.google.com/service/update2/crx
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:

https://www.microsoft.com/en-us/download/confirmation.aspx?id=49974

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.

Microsoft Edge in Citrix

Microsoft Edge in Citrix

We have a new internet browser! Microsoft Edge based on Chromium, available and supported on Windows 7, 8 and 10 and most importantly in Windows Server 2008 R2, 2012/2012 R2, 2016 and 2019. This means that we now have a modern and secure browser that can be managed via Group Policy and is supported by Microsoft in a server operating system.

I have been using this browser for quite some time now and it is awesome. One of the really great features is that you are able to install browser extensions from the Google Chrome Web Store, as Google Chrome has been available for a very long time, there are a lot of available extensions.

However with that said Microsoft now finds themselves in a situation where they offer a browser based on Chromium, which is an open-source project, which then again means that Microsoft does not control the entire code in the Edge browser. I am really excited about how Microsoft will handle this in the future.

Get the Edge Installer

So, how do we get the browser up and running in a Citrix VDA? We’ll start with downloading the enterprise MSI file here:

https://www.microsoft.com/en-us/edge/business/download

Edge administrative templates

And while there, we’ll also grab the administrative templates which enables us to configure around 200 different settings in the browser. Remember to copy the administrative templates to your Central Store.

Edge security baseline GPO

Microsoft has also created a security baseline GPO which can be found here:

https://techcommunity.microsoft.com/t5/microsoft-security-baselines/security-baseline-for-microsoft-edge-v80/ba-p/1233193

With this, we are now ready to install and configure the new Microsoft Edge browser.

Installing the Microsoft Edge browser

Before installing the browser, be aware that you will have to prevent the Citrix API hooks from latching themselves onto the Microsoft Edge process. Citrix has an article on how to disable Citrix API hooks on a per-application basis. Two options are described in the article, I am using the option for XenApp and XenDesktop 7.9 or later. So your UviProcessExcludes value name should look like this:

What you need to do is to add the msedge.exe to any existing value data. This change requires a reboot, so you will have to apply this when installing the browser.

I have created a small PowerShell script which will add the msedge.exe value to any existing value data:

$RegPath = "HKLM:SYSTEM\CurrentControlSet\services\CtxUvi"
$RegName = "UviProcessExcludes"
$EdgeRegvalue = "msedge.exe"

# Get current values in UviProcessExcludes
$CurrentValues = Get-ItemProperty -Path $RegPath | Select-Object -ExpandProperty $RegName

# Add the msedge.exe value to existing values in UviProcessExcludes
Set-ItemProperty -Path $RegPath -Name $RegName -Value "$CurrentValues$EdgeRegvalue;"

The Microsoft Edge browser also creates a shortcut on the public desktop (C:\Users\Public\Desktop). I always recommend deleting application shortcuts on the public desktop, as I prefer to control which application shortcuts appear on the user’s desktop. Unfortunately deleting the shortcut on the public desktop is not enough, a shortcut is also created on the user’s desktop (C:\Users\%username%\Desktop) during first logon, even though we deleted the shortcut on the public desktop.

This behavior is not new to me, it is also seen with the Google Chrome browser .

To prevent the shortcut from being created on the user’s desktop, a “master_preferences” file has to be copied to the C:\Program Files (x86)\Microsoft\Edge\Application folder, overwriting any existing master_preferences file.

UPDATE – 21-04-2020 (April 21st 2020): As of v81.x stable build it is now possible to use an install parameter, to prevent the creation of a desktop shortcut during user logon, a desktop shortcut is still created in the Public user desktop folder!

The parameter is: DONOTCREATEDESKTOPSHORTCUT=TRUE

Which means an install string could look like this:
MSIEXEC /I MicrosoftEdgeEnterpriseX64.msi REBOOT=ReallySuppress /qn DONOTCREATEDESKTOPSHORTCUT=TRUE

UPDATE – 22-09-2020 (September 22nd 2020): As of v84.x stable build it is now possible to prevent the pinned Edge shortcut creation during the first launch of Edge. Like the desktop shortcut, this i achieved via a install parameter.

The parameter is: DONOTCREATETASKBARSHORTCUT=TRUE

Which means in install string could look like this:
MSIEXEC /I MicrosoftEdgeEnterpriseX64.msi REBOOT=ReallySuppress /qn DONOTCREATEDESKTOPSHORTCUT=TRUE DONOTCREATETASKBARSHORTCUT=TRUE

The last thing we need to do, is to disable the services and delete the scheduled tasks that are responsible for doing automatic updates of the Edge browser. As with any other application in a non-persistent setup, we will have to disable any auto-update feature.

Here is a small post-install PowerShell script which will do the shortcut cleanup and disable the services and delete the scheduled tasks responsible for the auto-update feature in Edge:
UPDATE – 21-04-2020 (april 21 2020): I have removed the edgeupdatem service from the script below, as it triggered an error in Edge and an accompanied UAC prompt, when automatic update is disabled via GPO. The master_preferences file copy is also removed.
If you have en earlier version of the script, please update it with the new information.

The update error received, when the edgeupdatem service is disabled:

UPDATE – 28-05-2020 (may 28 2020): I have added Remove-Item -Path “HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components{9459C573-B17A-45AE-9F64-1857B5D58CEE}” -Force to the install script. This prevents a pinned Edge shortcut in the taskbar from being created. There are other solutions to this issue, which I have described in this article.

# Microsoft Edge post-install script

# Stop and disable Microsoft Edge services
$Services = "edgeupdate","MicrosoftEdgeElevationService"
ForEach ($Service in $Services)
{
If ((Get-Service -Name $Service).Status -eq "Stopped")
{
Set-Service -Name $Service -StartupType Disabled
}
else
{
Stop-Service -Name $Service -Force -Verbose
Set-Service -Name $Service -StartupType Disabled
}
}

# Delete Microsoft Edge scheduled tasks
$EdgeScheduledTasks = "MicrosoftEdgeUpdateTaskMachineCore","MicrosoftEdgeUpdateTaskMachineUA"
ForEach ($Task in $EdgeScheduledTasks)
{
Unregister-ScheduledTask -TaskName $Task -Confirm:$false
}

# Remove Microsoft Edge shortcut on Public Desktop
Remove-Item -Path "$env:PUBLIC\Desktop\Microsoft Edge.lnk"

# Remove Microsoft Edge Active Setup registry key
Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components{9459C573-B17A-45AE-9F64-1857B5D58CEE}" -Force

Now with the Edge browser installed we can move on to some basic configuration of the browser.

Group Policy Configuration

As mentioned earlier Microsoft has a baseline security GPO, and I would recommend to import this in your current environment, obviously you will have to do some testing, but from what I have seen, the current settings shouldn’t be “destructive” meaning, that nothing is broken in the browser. I will bring one additional group policy settings to the table, which are not found in the security baseline GPO. Any additional configurations should be added to another (new) GPO which should be linked to the same OU as the baseline GPO, but with a higher link order.

So in short, you end out with two GPOs. One GPO with the Microsoft security baseline settings, and one with any additional settings you configure.

Here is what a GPO configuration and link order could look like:

If you are unfamiliar with importing GPO settings, I would recommend looking at this guide:

The benefit of doing it this way, is that when Microsoft eventually release updates to their security baseline GPO, your can safely import these updated settings to the baseline GPO or a new GPO, and still have your own custom settings apply, as they are in another GPO.

The Microsoft Edge v79.x Security Baseline GPO contains the security baseline settings from Microsoft, and as mentioned this GPO shouldn’t be modified, as it will complicate any future updates of the GPO settings.

The Microsoft Edge v79.x Additional Configuration GPO should contain whatever policy configurations that applies to your setup. In here I have configured the “Update policy override” the reason for this is that if the user manually triggers the update of Edge, the user is prompted by UAC asking for an administrative username and password, not good,

This concludes the guide and you are ready to start testing the Microsoft Edge browser in your Citrix environment and eventually releasing it to production.

The Windows Server 2019 Start Menu is playing nice

The Windows Server 2019 Start Menu is playing nice

A couple of months ago I penned an article about how to rein the start menu in Windows Server 2016 mostly because I couldn’t find much information, on how to handle the start menu in Windows Server 2016.

I am always aiming at providing the best possible user experience in Session Host scenarios and that, among other things, implies cleaning up the start menu, as it, from a user’s point of view, contains a lot of irrelevant tiles, folders and application shortcuts. In the article 3 different scenarios are described, in each scenario you can achieve certain levels of “lockdown” or clean up of the start menu.

Unlike Windows Server 2016, the start menu in Windows Server 2019 is no longer driven by a mini database, actually Microsoft have deprecated the Tile Data Layer (the mini database feature) , but keeping it alive in Windows Server 2016, probably because it’s an LTSC edition of Windows.

This means that with Windows Server 2019 it’s now a whole lot easier to roam the start menu and customize the tile layout. However considering that we are all now switching to disk based profiles with FSLogix, roaming is a thing in the past.

In this article I’ll be focusing on how to clean up the start menu in Windows Server 2019 using scenario 3 as a baseline. The reason for this is that it provides the highest level of flexibility and customization with the start menu, as you see further on in this article. However scenario 1 and 2 are also possible in Windows Sevrer 2019.

Now, let’s get to it!

In scenario 3, I configure this group policy setting:

I also delete these 4 folders using Citrix Workspace Environment Management:

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Windows PowerShell
%APPDATA%\Microsoft\Windows\Start Menu\Programs\System Tools
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessories
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessibility

Using these steps, the start menu in Windows Server 2019 ends up looking like this:

So, besides the Windows Security app, this is looking pretty good. At the moment, I haven’t found any way to hide or remove the Window Security app, it’s an immersive app aka. a Universal App, so there’s no actual shortcut, like other apps and folders in the start menu.

/StartofUpdate
Update – 16-07-2019:
I was doing some additional testing and came across something that looks like a timing issue. During my testing I started seeing different variants of tiles not getting deleted/removed correctly. The folders where the tile shortcuts are located are deleted, but the tiles themselves are not.

These are some of the different variants of the start menu I have come across:

This is really strange. I tried configuring Group Policy Preferences to delete the folders in the user Programs folder, that didn’t make any difference at all.
This forces me down a path that I was really hoping to avoid, but at the moment I don’t see any other alternatives. A few years ago I was looking into how to build a custom start layout using a so called LayoutModification.xml file.

This XML file can be used to create a custom tile layout with the tiles you specify, I will not elaborate further on how to do this, as I will only use this XML file to clear out any tiles in start menu, and while we’re at it, the taskbar area as well.

Microsoft has a very extensive whitepaper on how to create the LayoutModification.xml file.

Here are the contents of my LayoutModifications.xml file:

<?xml version="1.0" encoding="utf-8"?>
<LayoutModificationTemplate
xmlns="http://schemas.microsoft.com/Start/2014/LayoutModification"
xmlns:defaultlayout="http://schemas.microsoft.com/Start/2014/FullDefaultLayout"
xmlns:start="http://schemas.microsoft.com/Start/2014/StartLayout"
xmlns:taskbar="http://schemas.microsoft.com/Start/2014/TaskbarLayout"
Version="1">
  <LayoutOptions StartTileGroupCellWidth="6" />
  <DefaultLayoutOverride>
    <StartLayoutCollection>
      <defaultlayout:StartLayout GroupCellWidth="6" />
    </StartLayoutCollection>
  </DefaultLayoutOverride>
<CustomTaskbarLayoutCollection PinListPlacement="Replace">
    <defaultlayout:TaskbarLayout>
        <taskbar:TaskbarPinList>
</taskbar:TaskbarPinList>
    </defaultlayout:TaskbarLayout>
</CustomTaskbarLayoutCollection>
</LayoutModificationTemplate>

This will clear out any tiles left in the start menu, and also clear out any tiles/pinned apps on the taskbar. If you don’t want to clear out the taskbar, remove the lines 14 through 19.

When you save the LayoutModification file, make sure to save it as UTF-8 encoding, otherwise it might not work.

There are 2 ways of distributing this XML file. It can be done either via a GPO or copied to the Default User folder. There are pros and cons with either method.

Deploying the XML file via a GPO

This can be done using the Start Layout policy which can be found in:
User Configuration/Administrative Templates/Start Menu and Taskbar

Input the path to the LayoutModification.xml path

Pros:
Easy to configure
Easy to manage

Cons:
Disables to ability to pin applications to the start menu
Citrix Workspace Environment Management is no long able to pin applications either

Deploying the XML file via the Default User

This is done by copying the LayoutModification.xml to the Default User profile, the exact path is:
C:\Users\Default\AppData\Local\Microsoft\Windows\Shell

Copying the file can be done via Group Policy Preferences or a startup script. It can also be done during any automated deployment jobs you might have.

Pros:
Does not disable the ability to pin applications to the start menu
Citrix Workspace Environment Management will be able to handle both application shortcuts and tiles in the start menu

Cons:
Only works for new users, which does not yet have a profile
Existing users, with existing profiles, are not affected by the LayoutModification.xml file.

I prefer copying the LayoutModification.xml to the Default User profile, this provides the best user experience and enables me to use Citrix Workspace Environment Management to build and manage the start menu.

/EndofUpdate

Windows Security

If you, like me, are running the Windows Defender on your servers, users will actually be able to go into the management console of Windows Defender, and poke around. They will obviously not be able to change anything because of the lack of administrative privileges, however in my opinion, they really shouldn’t be able to access this management console.

The only way, for now, to implement some kind of restriction, that doesn’t restrict administrative users, only non-admin users, is to use our good, old friend AppLocker. One of may very first bogs posts, was actually covering AppLocker breaking the start menu. Since then it has become a known fact, that if we enable AppLocker, and you really should, then we have to enable the default Packaged app rule, otherwise the start menu in modern Windows versions break.

However to prevent access to the Windows Security app, you have to take a different approach. You have to remove the default rule, which targets Everyone, and then create to new rules which are slightly more restricted.

How to create the AppLocker rule:

If you are not familiar with AppLocker, Microsoft has a basic guide here that shows how to enable AppLocker in Windows 10. It’s the same procedure on Windows Server 2019.

Start by removing the default rule. Then right click the Packaged app Rules and select Create new rule

Click Next
Click the Select button and specify the Domain Users group
Click the Select button and select a random app in the list, it doesn’t really matter which app
Select an app
Move the slider all the way up, so that there is a * in every box. This tells AppLocker allow any signed packaged apps to run
Click Next
Give the rule a name
Make a similar rule, but target Administrators, instead of Domain Users. Make sure to select BUILTIN\Administrators, otherwise you might block any local administrative users,
Right click the rule that targets the Domain Users and select Properties, go to the exceptions pane
Click add and select Windows Security in the list
Note: This can only be done on a server running Windows Server 2019
Move the slider up a notch, so that there is a * in Package version. This is done to make sure the rule still works, even if Microsoft should change the version of the app
The exceptions box, should now look like this.

Make sure that AppLocker is running and processing rules. Then either reboot your server or do a gpupdate /target:computer /force, to make sure AppLocker picks up the new rules.

Once the new Packaged app Rules are processed and working, users will be met by this message:

The Windows Security app is now blocked by AppLocker

This is not the prettiest of solutions, but it gets the job done, and prevents the users from accessing the Windows Security management console. Hopefully Microsoft comes up with another solution, which is a bit easier to configure, until then this is the way to go.

This concludes the article. The start menu in Windows Server 2019 is a bit easier to handle, than the start menu in Windows Server 2016 and if you are still holding on to any legacy profile handling tehcnology, like Windows Roaming Profile or Citrix Profile Management, then you’ll find that roaming the start menu in Windows Server 2019 has also become a bit easier and more stable, compared to Windows Server 2016.

How to rein the Start Menu in Windows Server 2016

How to rein the Start Menu in Windows Server 2016

In this article I am going to show how to control or rein the start menu in Windows Server 2016. There are a lot of articles describing how to handle the start menu in Windows 10, but very few about Windows Server 2016.

Even though the steps are almost identical in Windows Server 2016 compared to Windows 10, there are a few differences. For instance in Windows Server 2016, you don’t have to remove all the “crap” applications, like Candy Crush, trial editions of Office etc. as they are simply not included with this operating system, as it is an LTSC edition of Windows Server.

Some of the best articles out there are written by James Kindon and James Rankin, I have followed these guys for quite a while, and they know what they are doing. Some of their guides can be found here:

James Kindon:
https://jkindon.com/2018/03/20/windows-10-start-menu-declutter-the-default/

James Rankin:
https://james-rankin.com/articles/management-of-start-menu-and-tiles-on-windows-10-and-server-2016-part-1/
https://james-rankin.com/articles/management-of-start-menu-and-tiles-on-windows-10-and-server-2016-part-2/

James Rankins article is great because it focuses on how to persist, or roam, the start menu, if you haven’t read it yet, it’s highly recommendable.

Both James Rankin and James Kindon adresses the Start menu Tiles, and historically these tiles have been the source of all kinds of issues since they were first introduces in Windows Server 2012/2012R2, but the start menu is not just tiles, it’s also part “old school” start menu, like the one we have in Windows 7 and this part of the start menu, can be handled in a few different ways.

In this article I’ll will cover 3 ways on how to handle the start menu. The start menu in Windows Server 2016 is “split” in two areas the”old school” part is the part in the red box below, also know as All Programs or Programs, in the green box we have start menu tiles.

I’ll will not be covering the different ways to handle the start menu tile configuration, as both James Kindon and James Rankin have provided excellent guides for that part. However I will touch on how to manage app tiles leveraging Citrix Workspace Environment Management.

You will need to have some knowledge of Group Policy and Citrix Workspace Environment Managent and a basic understanding of how a Windows profiles works is also recommended.

I’ll be focusing on 3 different scenarios. Each scenario provide certain levels of usability, or lack thereof, in the start menu and start menu tiles sections

Here is a “before” screenshot of how the start menu looks at the first logon with my test account:

This is a pretty default start menu, one I have seen in many Session Host setups. As you can see I have a range of different applications available to me in the Programs area of the start menu, and of course the default pinned application tiles.

14-07-2019. Extensive edits have been made to the different scenarios outlined below. A colleague of mine made me aware of another, and cleaner approach on how to clear the All Users programs. And unfortunately I may have switched some screenshots and text boxes around in scenario 1 and scenario 2.

Scenario 1 – Total lockdown

This configuration, is by far the easiest one to configure and requires next to no work at all and it will provide a clean start menu with no visible applications. The All Programs section of the start menu i disabled and not visible to the user.

Isn’t this the cleanest start menu you have ever seen?

This configuration can be achieved by configuring the “Remove common program group from Start Menu” and “Remove All Programs list from Start Menu” which can be found in:
User Configuration/Administrative Templates/Start Menu and Taskbar

This setting will remove the common shortcuts found in C:\ProgramData\Microsoft\Windows\Start Menu\Programs and prevent them from being visible in the start menu.
Remove and disable setting, does what it says, removes and disables the Programs area of the Start Menu.

If you do not have the Remove and Disable setting available, you may need to get the latest Windows 10 adminstrative templates.

You will also need to delete four folders in the user’s profile:

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Windows PowerShell
%APPDATA%\Microsoft\Windows\Start Menu\Programs\System Tools
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessories
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessibility

In this case I have configured each folder to be deleted via Citrix Workspace Environment Management like this:

Note that Citrix Workspace Environment Management doesn’t usually take Windows variables, like %APPDATA%, so in this case I have used the so called dynamic token ##UserAppData## which is the equivalent to %APPDATA%. As the folder is deleted, there is no need for the action to run everytime the user logs on, so make sure to click the “Run Once” checkbox.

You will of course have to configure the “Delete Files/Folders” action type.

Repeat this process for the remaining three folders and don’t forget to assign the actions.

One major downside with this scenario is that it may be fairly difficult for the user to pin applications to the start menu, as they are not able to browse any apps via the start menu. However using Citrix Workspace Environment Manager users are able to pin apps to the start menu. This can be achieved via the Citrix Workspace Management Agent, like this:

Right click the the Citrix WEM Agent in the taskbar tray and select “Manage Applications”. In the list of applications, select the app and then click the “Start Menu” and “Start Menu (P) check boxes and click “Update shortcut(s)”.

A possible use case for this scenario could be if your users have gotten used to accessing everything via desktop shortcuts and don’t have the need or demand for using the start menu or start menu tiles.

Scenario 2 – Moderate Lockdown

This configuration is almost identical to Scenario 1, however due to a slightly less restrictive group policy configuration, users are able to access both the Programs and Tiles areas of the start menu.

Here you’ll notice that a nice and clean Programs area of the start menu is available and no tiles are present.

That can be achieved via the group policy setting:
“Remove common program group from Start Menu” which can be found in:
User Configuration/Administrative Templates/Start Menu and Taskbar

This setting will remove the common shortcuts found in C:\ProgramData\Microsoft\Windows\Start Menu\Programs and prevent them from being visible in the start menu.

And as described in scenario 1, we will also have to delete these four folders:

%APPDATA%\Microsoft\Windows\Start Menu\Programs\Windows PowerShell
%APPDATA%\Microsoft\Windows\Start Menu\Programs\System Tools
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessories
%APPDATA%\Microsoft\Windows\Start Menu\Programs\Accessibility

This scenario delivers a nice and clean start menu where all tiles have been removed and all apps in Programs have been removed. The user will however have to go and find the apps they need on their own.

Scenario 3 – Moderate Lockdown and app shortcut management

This solution is the most flexible solution as it enables us to have more or less full control with the start menu and its appearance. This scenario is basically the same as scenario 2, however we are going to use Citrix Workspace Environment Management to build a start menu, and group the different applications shortcuts.

Here we have a nice and clean start menu, as shown in scenario 2. The Search and Settings shortcuts are, in my opinion, harmless as Search only opens the search bar in the start menu, and settings can be locked down via Group Policy or registry.

Now we bring in Citrix Workspace Environment Management to populate the start menu with application shortcuts.

Just look at this! Doesn’t it bring tears to your eyes?

Citrix Workspace Environment Management is great at populating the start menu, and provides range of different possibilities of grouping application shortcuts etc.

Application shortcuts in Programs, the same apps pinned to the start menu.

Based on your or your users need, you could populate the Programs area and then leave it to the users, to configure the needed tiles using the Citrix Workspace Environment Management agent, as outlined in scenario 1.

This concludes the article. Reining the start menu in Windows Server 2016 can be a daunting task, but if you have Group Policy and Citrix Workspace Environment Management in your arsenal of tools, you will now be able to combine these to provide a great start menu configuration for your users and provide different levels of lockdown and user customizations.

Installing FireFox

Installing FireFox

In this article I’ll show you how to install and configure FireFox in a non-persistent Session Host environment. By non-persistent I mean in a Citrix Virtual Apps and Desktop setup deployed either via Citrix Provisioning or via Citrix Machine Creation Services. However you should be able to use this guide in Microsoft RDS and VMware Horizon as well.

During my research and testing of FireFox I have of course become more familiar with the browser, and it is also currently my second choice of browser, my first choice is still Microsoft Edge. Until recently my second choice was actually Internet Explorer, but I am more and more often experiencing issue with different web sites when using IE, so it’s now down to third choice.

Unfortunately in Session Hosts, we do not have access to the Microsoft Edge, only Internet Explorer is available out of the box. Microsoft has decided that the Edge browser, among other in-box Universal Windows applications, are only available in the semi-annual releases of Windows.

For anyone caring a bit about privacy, it may also be that FireFox is becoming one of the last independent browsers out there, as Microsoft late last year announced that Edge is moving to the Chromium open source project.

This means that at some point two of the four major browsers (Edge, Google Chrome, FireFox and Internet Explorer) will be running on the Chromium core.

To get started you will need to pick a FireFox installer that suits your needs. Currently FireFox is being maintained in two tracks, the Regular Release and Extended Support Release (ESR).
The ESR edition of FireFox is not updated with new features, updates will only address security vulnerabilities. Updates to the Regular Release may contain feature additions and will also address security vulnerabilities. So going with the ESR edition, could mean less testing when the browser is updated, as any updates will not contain new features.

Mozilla has a release calendar for 2019 where you can track when a new Regular Version is released.

For this article I am using the latest ESR 64-bit edition of FireFox, which currently is version 60.5.0. You can find the latest ESR edition here:
https://www.mozilla.org/en-US/firefox/organizations/all/.

You will also need the Group Policy Administrative Templates for FireFox, they can be found at Mozillas GitHub repository here:
https//github.com/mozilla/policy-templates


Click “Clone or Download”. That triggers a download of a ZIP file which contains the ADMX and ADML files needed.

So let’s get started.

Installing FireFox manually is pretty straight forward, I will not provide an install guide here. I will instead show how to do an unattended install of FireFox.

To do an unattended install of FireFox via command line or a script, you will need an INI file, with a few options.

Here are the contents of the INI file I use:

[Install]
;The name of the directory where the application will be installed in the system's program files directory
InstallDirectoryName=Mozilla Firefox

;Create a shortcut for the application in the current user's QuickLaunch directory.
QuickLaunchShortcut=false

;Create a shortcut for the application on the desktop.
;This will create the shortcut in the All Users Desktop directory
;If that fails this will attempt to create the shortcuts in the current user's Start Menu directory.
DesktopShortcut=false

;Create shortcuts for the application in the Start Menu.
;This will create the shortcuts in the All Users Start Menu directory
;If that fails this will attempt to create the shortcuts in the current user's Start Menu directory.
StartMenuShortcuts=true

;The MozillaMaintenance service is used for silent updates and may be used for other maintenance related tasks.
;It is an optional component.
MaintenanceService=false

Additional information about the arguments can be found here:
https://wiki.mozilla.org/Installer:Command_Line_Arguments

An important thing to remember is to include the “MaintenanceService=false” in the INI file, this excludes the FireFox Maintenance Service from the install process.
According to Mozilla this service is used for silent updates and “other maintenance tasks” whatever that means. As we all know it’s usually not a good idea to do any kinds of updates or “other maintenace tasks” in a Session Host based setup, whether it’s non-persistent or not. A certain degree of application control is still needed.

To install FireFox unattended using the INI file, use the /INI=<full path to configuration INI file> install switch, like this:
“Firefox Setup 60.5.0esr.exe” /INI=”C:\Temp\FireFox-Unattend-INI.ini”

If you are using the INI file provided above, everything should go through smoothly and you should now have a shortcut to FireFox in the Start Menu only, and no Maintenance Service. To verify whether the Maintenance Service is installed or not, go the Services console. If you see a service called “Mozilla Maintenance Service”, the service is installed. You can either remove FireFox and do another install, or simply disable the service.

Now to the more exiting part, group policy. We are going to create a FireFox GPO which configures a few things that addresses general usability and a bit of security/privacy.

Import the ADMX and ADML into your Central Store, then you should be able to access the FireFox group policy settings.

As you can see, we have a few possibilities when it comes to managing the configuration of FireFox. I will not go through every single policy, I will however show you the GPO I have implemented. Just remember that some of the settings in this GPO might not apply to your environment, so read the policy descriptions, understand them, and test whatever policies you apply.

All policies are configured in User Configuration. I prefer this approach, as I am then able to do security filtering of users and/or groups, which enables users and/or groups to receive different group policy configurations.

Here I block the access to the “about:config” page. This page contains a lot of very advanced features and settings, which probably isn’t a very good idea for a regular user to be messing around with.

Other noticeable policies are “Disable System Addon Updates”, which disables the update of System Addons, again we don’t want that in a Session Host based environment. The “Disable Update”, disables the update of FireFox itself.

“Tracking Protection” is enabled, and the user cannot disable it. This provides a security/privacy feature in FireFox which blocks content, cookies or scripts from collecting your browsing data across multiple sites. I recommend enabling the feature in a Session Host based environment, as it will reduce the CPU usage of the FireFox browser dramatically and provide some basic privacy when browsing the internet. A similar feature exists in Internet Explorer, which I have mentioned in another blog post.

The “Allow add-on install from website” is disabled, which prevents the user from installing add-ons to FireFox. We want control of the FireFox application, there are all kinds of add-ons doing all kinds of different things, we don’t want that on our Session Hosts.

The last part is the “Default Search Engine”. Here I configure Google as the default search provider, have you ever met a user that wanted another search provider than Google?
I also remove some built in search providers and essentially only allow Google and DuckDuckGo in the list of search providers and prevent manual addition of other search providers.

This concludes the guide. With this information you should be able to do an unattended setup of FireFox and configure a basic lockdown GPO to deliver a good user experience and prevent users from “messing thing up” for themselves, other users on the Session Host or the Session Host server.

How to prevent Citrix Workspace App popups

How to prevent Citrix Workspace App popups

The other day a coworker approached me to get a solution that would suppress the popup boxes you get, after a successful Citrix Workspace App install.

This first popup you see it this “Add Account” popup box:

The second popup box you see, is this “Citrix Receiver is now Citrix Workspace App” popup box:

Both popup boxes appear after a reboot of the computer and they both require user interaction, to make them go away.

Some may argue that it’s just one or two clicks and you’ll never see them again, I have however seen that at least the “Add Account” popup box can confuse the user and even trigger a support call. So why bother the user with these popup boxes and potentially generate more support tickets?

According to Citrix you are able to remove the “Add Account” popup box by using a combination of command line switches and registry changes:
https://support.citrix.com/article/CTX135438

This works, I have used it plenty of times and it’s easy to implement when you have 100% control over the computer via a deployment system and/or group policy.

However the command line switch /ALLOWADDSTORE=N prevents any manually configured stores to be added to the list of accounts in Citrix Workspace App. Usually that’s not an issue in a 100% managed environment, as we are able to push Citrix StoreFront store account information to the Citrix Workspace App, either via command line switches or via GPO.

But if you are in a situation where you want to remove the popup boxes, but you don’t want to restrict the manual Citrix StoreFront store account configuration, you need to apply a few registry keys and values in HKCU and not HKLM, as described in the Citrix article.

First off. To remove the “Add Account” via HKCU (User context), apply these registry fixes:
HKEY_CURRENT_USER\Software\Citrix\Receiver
HideAddAccountOnRestart=1

HKEY_CURRENT_USER\Software\Citrix\Receiver
EnableFTU=0


Both values are DWORD values.

To remove the “Citrix Receiver is now Citrix Workspace App” popup box apply this registry fix:
HKEY_CURRENT_USER\Software\Citrix\Splashscreen
SplashscreenShown=1

This value is a string or REG_SZ value.

I have tested this procedure on Windows 10 v1809, Windows Server 2016 and Windows Server 2019 with Citrix Workspace App 1812.

Try it out and silence that Citrix Workspace App!