<img src="//bat.bing.com/action/0?ti=5794969&amp;Ver=2" height="0" width="0" style="display:none; visibility: hidden;">

Citrix Profile Management Done Correctly (Part 2 of 2)

[fa icon="long-arrow-left"] Back to all posts

[fa icon="pencil'] Posted by Lewan Solutions [fa icon="calendar"] April 27, 2017

This post is a continuation of Citrix Profile Management Done Correctly Part 1.

If you haven’t had a chance to read that post yet, it’s a good place to start before reading this.

In Part 1, we set the foundation for our Profile Management configuration. Now I’ll cover how third party browsers such as Google Chrome and Mozilla Firefox are handled and what to do if Microsoft Exchange has been moved off-premise into Office 365.

Third Party Browsers

Google Chrome and Mozilla FireFox can introduce quite a bit of bloat into profiles. If you look at your Chrome AppData location right now, you’ll probably see data size in the gigabytes.

The ideal situation is not to have these browsers in your XenApp/XenDesktop environment. But let’s be realistic, your end users probably aren’t going to settle for using Internet Explorer or Microsoft Edge. They simply don’t have enough compatibility and features.

So why does having all that browser data matter?

Having gigabytes of data from Chrome and Firefox in XenApp and XenDesktop can severely affect login times. Just imagine copying ALL those gigabytes on login. If you recall, in Part 1, I said the profile shouldn’t exceed 10-20MB in size.

Again, I’m not saying you should stop your users from using third party browsers like Chrome or Firefox – I agree they are far better options. The good news is that you can mitigate the data hit that Chrome and Firefox adds to your system.

Here’s how to setup your Profile Management

Directory Exclusions for Chrome and Firefox:


Directory Synchronizations for Chrome and Mozilla Firefox to retain the user’s customizations:


File Synchronizations for Chrome and Mozilla Firefox to retain the user’s customizations:


Microsoft Office 365

Now let’s look at the behavior of Microsoft Outlook if Exchange was migrated off-premise to Office 365.


In a virtual desktop environment, there are two license schemas. A full-fledged Office 2010/2013/2016 license or Office 365 license.

If you have an Office 2010/2013/2016 license, you will need to setup KMS activation in your environment if you are doing non-persistent XenApp/XenDesktop machines in order to be supported.

If you’re working with Office 365, at minimum an E3 (Enterprise) or G3 (Government) license is required. Without this plan level, your end users will not be able to install an offline copy of the Office 365 client on their virtual desktop.

If you are not familiar with the Office 365 E3 or G3 licenses, they entitle users to five offline instances of the Office 365 client to be installed on any of their machines. The client also needs to be installed in shared activation mode to avoid exceeding the five offline instance activations. More info for shared activation mode is here.

Internet Bandwidth and Latency

Having a low bandwidth circuit or high latency to Office 365 will influence if Outlook should be placed in online mode or cached mode.

Having a low bandwidth cap such as a 10MBPS circuit is an issue because if Outlook is in online mode and you have many users on at the same time, users can have performance issues with their email.

If you have high latency to Office 365 (in excess of 110MS), users will also have performance issues with their email.

Online mode is easy but often cached mode is required and the standard Office 365 user’s mailbox is 50GB (this includes attachments, links, etc). If we were to cache all of this, it would take up a tremendous amount of space.

The solution? Cache a certain timeframe of the mailbox (3 or 6 months).

Studies have shown that most users typically need 3-6 months of data available to pull up in their Outlook client. Of course, there may be times they need something dating further back, at which point they can login to Outlook 365 on the web to access.

Setting up a Limited Length Cache

The cached .ost file should be redirected to the same file share the user shell folders are in. This way, the .ost file does not need to be rebuilt in its entirety every time the user logs in. This also keeps the file out of the user profile so that Profile Management does not attempt to copy it into the XenApp/XenDesktop session at login.

Here is the configuration for cached mode in Outlook 2016 and the .ost file redirection:


It’s basically configured via GPO. Also, notice that it’s configured to only cache three months of email. You will want to adjust this length accordingly to fit your environment.

For more information, don't hesitate to Contact Us. Lewan Technology is a Citrix Gold Solutions Advisor and has the largest resident Citrix consulting bench in Denver, CO and the Rocky Mountain region, comprised of certified architects, engineers and administrators. We also hold the Citrix Specialist in Virtualization distinction.

Topics: Citrix, Microsoft, Microsoft Exchange, Microsoft Office, Citrix XenApp, Citrix XenDesktop, Google, Microsoft Outlook

Lewan Solutions
Written by Lewan Solutions

  • View & Submit Comments

[fa icon="envelope"] Subscribe to Email Updates

[fa icon="comments-o"] Follow us

Get even more great content, photos, event info and industry news.

[fa icon="calendar"] Recent Posts