Category: Profile Container

How to install the FSLogix Apps agent

How to install the FSLogix Apps agent

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

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

Get the FSLogix Apps agent installer

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

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

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

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

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

Installing the FSLogix Apps agent

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

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

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

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

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

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

FSLogix Apps agent post-install modifications

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

Local Group modifications

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

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

Registry modifications

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

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


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

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

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


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

Install sequence

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

This is the install/configure sequence I always use:

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

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

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

Windows Search Roaming workarounds

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

Workaround 1

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

Workaround 2

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

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

Automated install and configuration

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

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

Windows Search service configuration

FSLogix Apps Agent installation and configuration

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

Windows Search Roaming workaround 1

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

Windows Search Roaming workaround 2

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

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

The rise and fall of a champion

The rise and fall of a champion

A couple a weeks ago a attended Citrix Synergy at the Hilton Convention Center in Anaheim in the US. I’ve been there a few times before, and it has been a pleasure visiting and attending Citrix Synergy at this venue every time.

There were a lot of great sessions which sometimes made it hard to decide which one to attend. However in this article I will bring my views and opinions about some announcements made regarding Citrix Workspace Environment Manager (WEM) and Citrix Profile Management (CPM) formerly know as Citrix User Profile Manager (UPM).

Citrix announced Office 365 experience support in CPM/WEM. This means that CPM/WEM will be able to handle an Outlook OST file and Windows Search Index Roaming in a non-persistent Session Host/VDI setup, exactly like the 3rd party vendors, FSLogix and Liquidware. This is somewhat great news, as this is a feature I have wanted in CPM for years, however Citrix may have been dragging their feet just a bit too long in this matter.

The Rise….

Before I go any further, a bit of history never hurt anyone. Back in May 2008 Citrix acquired sepagoProfile from sepago, this product was rebranded and became Citrix User Profile Manager (UPM) which meant that Citrix got a Profile Management solution that was far superior to the Windows Roaming Profile solution built in to most Windows versions.

Citrix UPM was THE profile management solution from there on out, well in most cases at least. Of course UPM had issues from time to time, but Citrix was usually very quick to address and solve these issues. Back in the days with Windows XP and Windows  Server 2003 we had to rely on tools like UPHClean to get a stable Windows Roaming Profile environment without profile lockups. With Citrix UPM this was no longer the case, as UPM was much more “intelligent” and had builtin mechanisms to prevent profile lockups.

Gone were the days where we needed obscure batch or VB scripts running during logon or logoff, to manage or support application settings that was not saved in the APPDATA\Roaming folder, Citrix UPM was able to handle files and folders in the APPDATA\Local or APPDATA\LocalLow folders.

UPM eventually got additional features like Profile Streaming which enabled parts of the user’s profile to be streamed to the Session Host or VDI during logon, which most of the times had a huge impact bringing down logon times.

The Fall….

Up until the release of Windows 10 and Windows Server 2016, this was more or less the story with UPM. However, Citrix UPM is curently on a deroute and should, in my opinion, no longer be considered the preferred solution, this is primarily because of how Windows 10 and Windows Server 2016 handles the user’s profiles.

As Citrix UPM still relies on the principles of a roaming profile, copying the profile back and forth between a file server share and the Session Host/VDI during logon and logoff, there are still some situations where Citrix UPM has issues, and it still requires a great deal of configuration and management to prevent profile bloating and to obtain a relatively stable profile environment. Yes it still supports the Profile Streaming feature, but even that has over time shown that it is not always the way to go, as certain applications does not support this feature and may break or not work properly.

Currently there is a major bug in the Citrix UPM version introduced in Citrix XenApp and XenDesktop 7.15 LTSR CU1, which is mentioned in the Citrix discussions forums here – https://discussions.citrix.com/topic/391754-windows-2016-start-menu-blank-icons-with-715-cu1/

Citrix has posted a CTX article with 2 workarounds, however a couple of people are mentioning that these workarounds are not working. There is however a workaround described in the forum thread, which involves a PowerShell script, that should be able to take care of things.

The fact that this bug still exists in both Citrix XenApp and XenDesktop 7.16 and 7.17 and was introduced in an LTSR edition of Citrix XenApp and XenDesktop is, in my opinion, a major let down by Citrix and illustrates just how much Citrix is struggling with Citrix UPM at the moment.

The Future….

In my opinion the future of Citrix UPM is a bit hazy.

Considering the amount of issues that I have personally encountered, with Citrix UPM in Windows Server 2012/2012 R2, Windows 10 and Windows Server 2016, and the major bug described above, I have very little faith in Citrix providing anything remotely stable within this year, eventhough they claim to have the Office 365 experience feature ready within the next 90 days. This means that we are probably going to see this feature in Citrix XenApp and XenDesktop 7.19 or 7.20.

UPDATE – 14-08-18: The UPM Office 365 Experience feature is available in Citrix XenApp and XenDesktop 7.18

Also to be considered is the fact that Citrix is around 4-6 years behind in developing anything disk based whether it be supporting Office 365 or the entire profile in a disk based solution. Microsoft have had their User Profile Disk solution since Windows Server 2012 which was released 6 years ago, FSLogix and Liquidware both have disk based profile solutions going on 4+ years now, so Citrix has some cathing up to do.

To spice things up, Citrix will now have 2 seperate and very different products covering the same Office 365 experience features as Citrix App Layering have the User Layers feature, which is the entire user profile in a disk based solution, this feature is still in Labs though, which means that it isn’t ready for production use yet.

With Citrix App Layering you also have the Office 365 Layers feature, this only covers the Outlook OST file and nothing else, this feature is however production ready, BUT and there is a major “but” in there, both User Layers and Office 365 Layers is only available with the Platinum license, mentioned in this article – A Breakdown of Citrix App Layering Features by Edition this will prevent a lot of customers from being able to implement these features.
UPDATE – 25-05-18:
Te above statement around the Office 365 Layer was incorrect. As per this article – https://www.citrix.com/products/xenapp-xendesktop/feature-matrix.html the Office 365 Layer is available in all XenApp and XenDesktop license models, however it’s currently only supported on Windows 7 and Windows 10 64-bit.

I am looking very much forward to see how Citrix will develop both the User Layer and Office 365 Layer in Citrix App Layering and the merge of Citrix WEM/CPM with the Office 365 experience feature. If Citrix manages to get the Office 365 experience feature stable, a disk based profile solution with WEM/CPM, may not be far behind and if Citrix goes down that road FSLogix and Liquidware may have their work cut out for them.

For now, my recommendation is still to go with a disk based profile solution, like FSLogix Profile Container and Office 365 Container.

AppLocker is breaking Windows Start Menu

AppLocker is breaking Windows Start Menu

The other day I was setting up a couple of Window Server 2016 XenApp VDA servers to do some more extensive tests of the different Citrix policy templates, to evaluate how the settings in these policy templates impacts the user experience.

During these tests I kept running into an issue with the Start Menu not working properly. The context menu worked is it should, but nothing happened with a regular left click on the Start button. I have run into this issue many times before, in both Windows Server 2016 and Windows 10, the main cause was always either Citrix UPM not being able to handle the Tile Data Service database, or plain old regular Windows Roaming Profile just being old and broken.

However in this case I had not configured either Citrix UPM nor Windows Roaming Profile, I had configured FSLogix Profile Container, so why was this happening? To make it even more strange I experienced the issue with an admin user with a local profile as well, so this ruled out any profile handling issues.

As you may already have guessed, AppLocker had a part to play in the issue I experienced, but what was AppLocker actually doing?

Well as it turns out, AppLocker was blocking the “Windows Shell Experience Host” and “Cortana”, and apparently both are necessary for the Start Menu to work properly.

During my troubleshooting I came across this message in the AppLocker part of Windows Event Viewer:

Not very helpful! I had Exe rules configured alright, but the “no Packaged app rules have been configured” part was a bit confusing. My AppLocker GPO was configured to enforce Packaged app rules, however no rules were configured, just like the event viewer was telling me. As it turns out Packaged Apps is another word for Universal Windows Platform (UWP) apps, these UWP apps are, among other things, handled by the before mentioned “Windows Shell Experience Host”.

As AppLocker was apparently blocking the Windows Shell Experience, this would explain why my Start Menu wasn’t working properly. The solution was actually really simple and required nothing more than creating another AppLocker rule.

Go into your AppLocker GPO and right click the Packaged app Rules and select “Create Default Rules” this should create one rule which allows all signed packaged apps to be executed.

Once this rule is created, either run a “gpupdate /target: computer /force” in a command prompt or simply reboot the server/computer.

This should bring back the Start Menu and Cortana and all your application shortcuts.