Category: Application Masking

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:

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):

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.

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:
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.

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

# 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
        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. 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.