Author: Kasper Johansen

The curious case of the pinned Microsoft Edge shortcut

The curious case of the pinned Microsoft Edge shortcut

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.

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.

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 ūüôā

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 – 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

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)

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.

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.

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

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.

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 of the browser.

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

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

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.

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!


Citrix Published Apps migration script

Citrix Published Apps migration script

Recently I was working on a XenApp and XenDesktop 7.9 upgrade project. The customer didn’t want to touch the existing 7.9 environment, as it was a production environment with around 1000 concurrent users from different parts of the world. Instead a new XenApp and XenDesktop 7.18 site was created and we had to create everything manually in the new site.

Fortunately, besides the published application, there really wasn’t much to be done. We had to create a couple of Machine Catalogs and a few Delivery Groups. However the customer had 50+ published applications and it would take quite a while to manually create those by hand.

As it turned out, the customer couldn’t wait for me to develop this script, so I actually didn’t test it out in that specific environment. However that didn’t stop me from finishing the script, as I expect more 7.x to 7.x or 7.x to 1808 and later migration projects in the future.

As I wasn’t able to find any useful tools from Citrix to help me migrate a 7.x site to another 7.x site, I decided to write my own script, with some inspiration from some older scripts I had used earlier.

The script can be found here:

Copy the code above and save it to file called Migrate-XAapps.ps1. The script contains basic information on usage and also examples of the different switches and paramaters that can be used.

Let me know if you experience any issues. As mentioned in the script, I have tested the code on XenApp and XenDesktop 7.6 LTSR CU6, XenApp and XenDesktop 7.9 and Citrix Virtual Apps and Desktops 1808 and I haven’t run into any issues, however I have probably not covered every possible published application scenario out there.

Installing Foxit Reader

Installing Foxit Reader

A few weeks ago I came across blog post by Carl Webster on a guide on how to install Adobe Acrobat Reader DC. This guide is very detailed and if you are in need of performing an unattended deployment of Adobe Acrobat Reader DC, this is probably the only guide you will need.

However there are other PDF viewers out there, better viewers in my opinion. Adobe Acrobat Reader DC, and versions before DC (11.x, 10.x, 9.x), has become bloated with features most users will never need, especially the online features are almost useless, at least from my point of view. My point of view is of course based on how the application behaves in a non-persistent and/or multi-user environment and general functionallity.

This guide I will show you how to install an alternative PDF Viewer from Foxit. With Foxit Reader you will, in my opinion, get a better performing and less bloated PDF Viewer, compared to Adobe Acrobat Reader DC and it’s just as easy, or maybe easier, to deploy and customize compared to Adobe Acrobat Reader DC.

To get started you will obviously need the Foxit Reader source files. To get those, go to the Foxit website https://www.foxitsoftware.com/

Go to the Log In box and either log in, if you have an account or create a new account. The account is needed to be able to get the Foxit Reader MSI installer, the XML Editor, the Foxit Customization Tool and the Group Policy administrative templates.

Once logged in, go to the download section and click Free Software

Here you will need the Enterprise Packaging which is either an MSI or, depending on the language selected, an ISO with an MSI.

 

Select the language needed, amount of users and make sure to select the MSI package type. As mentioned, depending on your selected language, you may not be able to select the MSI package type, only EXE or ISO is available. In that case select ISO, it will have en MSI package that we can extract and use going forward.

Once past the image verification, you will get to the actual download site. The MSI package download will automatically prompt you to save the file, if not, go ahead and download it manually.

You will need the MSI package, the XML Editor and the Foxit Customization Tool.

So, this it how it should look like, when you have all the needed components:

How to install using an MSI transforms file

Next, extract the FoxitCustomizationTool.zip file, this is used to create an MSI transforms file with pre-configured setup settings.

Fire up the Foxit Customization Tool

Go to File and click Open and select the FoxitReader93_enu_Setup.msi file

Once opened, this is where the good stuff is..

From here on, I will show you how I usually configures the transforms file. The settings shown may not reflect your needs, so consider what you select and/or deselect.

I always disable the Auto Update feature, in non-persistent setups this is recommended.

In the Features pane you can choose which features of Foxit Reader to install or not to install.

This installs the bare minimum features, which allows you to open PDF files in either the Foxit Reader application or within browser windows.

I usually remove any unwanted shortcuts, in this case the Foxit Reader desktop shortcut and the Activate Plugins Start Menu shortcut.

Now all you have to do is save the configuration to an MST file.

Go to File and click Save-As, provide a name for your new MST file and save it in the same directory as the FoxitReader93_enu_setup.msi.

You are now able to deploy Foxit Reader unattended via MDT, SCCM, Altiris, PowerShell etc. using this command line:

msiexec /I¬†FoxitReader93_enu_setup.msi /qb TRANSFORMS=”FoxitReader93_enu_Setup_FCT.mst”¬†ALLUSERS=1

How to install using command line parameters only

If you for some reason don’t want to use a transforms file, a wide range of command line parameters are available when using the MSI installer.

This command line should provide you with the same result as the transforms install method described above:

msiexec /I¬†FoxitReader93_enu_setup.msi /qb ADDLOCAL=”FX_PDFVIEWER” MAKEDEFAULT=1 VIEW_IN_BROWSER=1 DESKTOP_SHORTCUT=0 AUTO_UPDATE=0 NOTINSTALLUPDATE=1¬†ALLUSERS=1

The Foxit Reader Deployment and Configuration guide describes a few additional command line parameters. The guide can be found on the Foxit Reader download site.

This covers the deployment of the Foxit Reader. Now, we are going to look a bit closer at what’s possible with the XML Editor.

Foxit Reader UI Customization

The XML Editor is needed to customize the graphical user interface of Foxit Reader. This means that you can hide certain parts of the application that may not be relevant for your users to access. I will show a few examples here, but there are a lot of different areas of the UI in Foxit Reader that can be hidden, so it’s really just a matter of picking out the parts that suit your needs.

I’ll usually hide the Help and the Share tabs. The Help tab isn’t really providing any useful information to user and the Share tab makes it possible to integrate with Evernote, OneNote and Sharepoint which may not be available.

To make these changes to the UI you will need an XML file, which you create using the XML Editor.

Open the XML Editor, it should look like this:

Make sure to click the Interface button, and select Foxit Reader. Also in the version box, make sure to type in the correct version of Foxit Reader.

Next go to the Ribbon Set tab. In here you will see a lot of different check boxes, each representing either a feature or a tab to hide. As mentioned, I want to hide the Help and Share tabs, this is done simply by checking the corresponding boxes:

Next click Export and save the XML file:

The XML goes into the¬†C:\Program Files (x86)\Foxit Software\Foxit Reader\ProfStore folder, just overwrite the existing profstore.xml file, as it’s a default XML containing the default out-of-the box configuration.

Look at this nice and clean UI:

You can download a pre-configured sample of profstore.xml file here. Be sure to review the customizations, before production usage.

Deployment script examples

The profstore.xml should be copied as a part of the deployment process. I have provided a couple of examples on how to create either a batch script or a PowerShell script to deploy Foxit Reader and copy the profstore.xml file.

Batch/CMD:

msiexec /I¬†FoxitReader93_enu_setup.msi /qb TRANSFORMS=”FoxitReader93_enu_Setup_FCT.mst” ALLUSERS=1

copy profstore.xml “C:\Program Files (x86)\Foxit Software\Foxit Reader\ProfStore” /Y

PowerShell:

Start-Process -Wait¬†FoxitReader93_enu_setup.msi -Argumentlist “/qb¬†TRANSFORMS="FoxitReader93_enu_Setup_FCT.mst” ALLUSERS=1″

Copy-Item profstore.xml -Destination “C:\Program Files (x86)\Foxit Software\Foxit Reader\ProfStore” -Force

This concludes the guide.

We are now able to get the source files to Foxit Reader and make UI custumizations and deploy it. Now, there is no excuse, start testing Foxit Reader! I am sure you’ll agrre with me that Foxit Reader can easily take on Adobe Acrobat Reader.