Blog Archives

XenApp Best Practice #2: Optimize

On many moonless evenings, I will be outside, next to my telescope snapping pictures of clusters, nebula and galaxies for my astrophotography hobby. But there is a balance of creating a great image vs just wasting time. Once it gets past 2am or the temperature drops below 0 Fahrenheit, I’m done. But do I have enough pictures to create an OK photo or a great photo?

You see, in order to take a photo of deep sky objects, you need to let your camera capture a lot of light by keeping the shutter open for many minutes at a time. Of course, at the same time, you also build up noise on the imaging chip.Here is an example of a single, 90 second image of M27 – The Dumbbell Nebula


If you take and stack multiple images together, you increase the signal while reducing the noise. This is a stack of 29 frames, each 2 minutes in length for a total of 58 minutes

M27 - The Dumbbell Nebula

The image got quite a bit clearer. The signal got stronger and the noise was reduced.  Of course, the more images you take and stack, the stronger signal you achieve, but the noise is only reduced by the square root of the number of images. Don’t worry, I’m not going to go into the math for this because this graph makes the concept very clear


As I take more frames, the noise decreases. But in order to have the noise drop by another factor, I have to take many, many, many more pictures. Now I will spend hours of time capturing the extra images, processing the images and all for a minimal improvement in image quality. And while I’m outside using the telescope, I run the risk of getting frost bite (true story), going into hypothermia or get eaten by a bear a wolf or a moose (Yah sure you betcha. don-chya-no I in da Minnesoda)

The same concept holds true for XenApp and XenDesktop deployments. You can optimize and then you can optimize.

There are hundreds of ways you can better optimize XenApp. Some of these are easy, proven and will have a noticeable, positive impact on either the user experience or resource utilization. But there becomes a point of diminishing returns. For example, what benefit will I get if I disable a Windows service? Most likely, not much. And in fact, the more you tweak, the greater the possibility of doing something hazardous to your system’s health. I’ve heard many times that someone turned off some innocuous Windows service only to find out a few months later that a new application or update requires that service.

Does this mean stick with the default configuration? OMG NO.

Start with the big items. Start with those items that are proven and have been shown to improve the experience or reduce utilization without potentially harming the system stability. I’m talking about things like

  1. Provisioning Services RAM Cache: This will not only reduce storage utilization, but it will actually improve the user experience.       In the simplest terms I can provide… Disk is slow, RAM is fast. Use RAM. :)
  2. Microsoft Lync/Skype for Business optimization: As we see more people make video calls with Lync and Skype for Business, we see a hit on our processor. Using this XenApp/XenDesktop feature, we are able to drastically reduce resource consumption on our host servers.
  3. Session Prelaunch: Logon complaints might be one of the most common issues for any system, and I’m not even talking about XenApp/XenDesktop. But at least with XenApp, we can overcome the logon delays with Session Prelaunch
  4. Policy Templates: XenApp and XenDesktop have a very powerful policy engine, allowing you to match the user experience with the scenario. If you are external, you get this, if you are external on this device with this configuration, you can do that, if you belong to this group, you can do something else, if you are on this subnet, this desktop group, have this tag, then you get this config, and if your iOS device is jailbroken, you can only do this one thing. It is very powerful, which means many implementations don’t configure anything. Again, a great starting place is to use the latest policy templates in XenApp & XenDesktop 7.6 Feature Pack 3, as they are tailored for a specific use case.

Now don’t get me wrong, you can go and tweak the system as much as your heart’s desire, but at a minimum, you should focus on those items that can have a big impact.

XenApp Best Practice #2: For the best combination of user experience and resource consumption, optimize appropriately

Daniel ()
XenApp Best Practices
XenApp Videos

Video Proof: Optimizing Microsoft Lync on XenApp and XenDesktop

I spent the last few blogs, dissecting Microsoft Outlook and how we can integrate an Exchange Online server, as part of Office 365, with XenApp and XenDesktop.

(I really need to be a little more creative with these titles)

As we saw in these blogs, when you start deploying Office 365 to your users, Cached Exchange Mode becomes more important if you want a good user experience. But what about other items within Office 365? What about Microsoft Lync? What about Microsoft Lync in an RDS/VDI environment?

I didn’t know. I, of course, have heard and seen the marketing materials about how the Citrix Optimization Pack for Lync should help the experience, but I wanted to see for myself. And I wanted you to also see.

A few things I find interesting with the optimization pack

First, it works for Lync 2010, 2013 and Online servers. As you start looking at deploying Office 365, it is very easy to see the value of a Lync Online implementation. With the Citrix optimization pack, you can still achieve the same benefits you would get with an on-premise deployment like Lync 2010 and 2013.

Second, it supports any type of XenApp/XenDesktop deployment including published applications, shared desktops, non-persistent desktops and persistent desktops.

And finally, it demonstrates another way that Citrix continues to extend the Microsoft platform.

The following provides more details on Deploying Office 365 on XenApp and XenDesktop

From the virtual mind of Virtual Feller

How to use Outlook Cached Exchange Mode on XenApp and XenDesktop

A little bit of knowledge can save you a lot of time (or even an arm).

As I mentioned previously, I’ve been building a new desk for my wife. For this particular project, I drew the entire desk to scale in a CAD program. The drawings were detailed to the point that they included the depth and width of the dados and rabbets (not the animal hopping in my yard). I wasn’t always this detailed. Years ago when I started woodworking, I would oftentimes just wing it. I would have no plans, no dimensions; only an idea in my head for what I wanted to build. I would eventually succeed, but it cost me in wasted lumbar and time because I would cut a board to short as I forgot to include an extra ½ inch length for the dado. With this particular project, because I took the time to draw it out to scale, the entire build went smoothly and with no wasted lumbar.

The same thing happens in IT when we try to implement something new. We oftentimes don’t think through the solution enough to come up with a solution that will align with our circumstances. Let’s think about the discussion with Outlook and whether or not to implement Cached Exchange Mode. If we use Office 365 as our Exchange Server but still implement the native Outlook client on a XenApp server, we would most likely recommend enabling cached Exchange mode.

Mailbox size

I have some concerns with ending it there. With Office 365, every user is granted 50GB of mailbox storage. If I use Cached Exchange Mode, then I will have to accommodate 50GB of storage space for every user. This will break my storage bank. Plus, I personally find it crazy to keep a complete copy of that mailbox in two places.

Recommendation 1:

This will limit the size of the cache file by only caching the last 3 months. Most users only access emails that were sent/received within the last 3 months. Anything older are still accessible, but via online mode only. In online mode, the access might be slower, but the frequency of users accessing those files is extremely small so why waste valuable resources keeping them local.

Storage location

My other concern is where do I store my cached file? In the blog “When to use Outlook Cached Exchange Mode on XenApp and XenDesktop?” we already said that a network share is the best option due to the non-persistent nature of XenApp and XenDesktop pooled desktops, but where?

Personally, I prefer the user’s profile directory and not their home drive. If a user sees a file in their home directory they don’t recognize, they will end up deleting it (I know I do that). I don’t want the users to physically manipulate that file. If the file is in their profile location, it becomes more difficult for the user to delete the file as they typically don’t have Explorer access to this location.

Recommendation 2:

  • Decide where in the profile path to store the Cached Exchange Mode file (.OST) file.
  • Use the Microsoft Office group policy template to set the Default Location for OST Files

Folder redirection

This now brings us one more question; should we leave the OST file on the network share and access it via the network or do we sync the file to the virtual desktop and access it locally? I believe that by keeping the file on the network share, we simplify the environment and put less strain on the physical servers hosting our virtual XenApp and XenDesktop machines. Plus, test data I’ve seen shows this to be a perfectly acceptable solution, especially when the file server is configured correctly with at least SMB 2 and the file server resources are monitored appropriately, which we should already be doing.

Recommendation 3:

  • Utilize Citrix Profile Management
  • Set a policy for Profile Management that excludes the folder containing the OST from being copied to the XenApp and XenDesktop hosts.
  • Utilize at least SMB 2 on the file server and monitor appropriately

White Paper Reference: Deployment Guide: Office 365 for XenApp and XenDesktop

Blog Series Summary:




When to use Outlook Cached Exchange Mode on XenApp and XenDesktop

The other day, I was in my workshop building a new desk for my wife when one of my kids came in asking me about the different tools I had scattered all over the room.  I said “this is a radial arm saw, this is a circular saw, this is a band saw and this is a scroll saw”.  Of course they asked “Why do you have so many saws?”.  I replied “Because each saw does something really well and if I use the wrong one for the job, we will have big problems.”

Your IT toolkit will also contain many different tools, but it is important to understand when to use which tool.

In my last blog, I talked about how using a network share to store your Cached Exchange Mode files (.OST) for Outlook IS supported on a VDI and RDS solution like XenApp and XenDesktop. The basis for the blog was because I kept hearing and reading conflicting answers.

After the blog, I got a bunch of tweets, emails and comments disagreeing with me. They didn’t disagree that it was or was not supported on a XenApp or XenDesktop implementation, they disagreed because it is a bad idea to use the feature in an RDS and VDI implementation. Citrix even has an article that basically says do not turn on cached exchange mode. If you do, your email might be slow, your VDI/RDS will be hit at the CPU level, and network usage will increase. The Citrix recommendation is to use online mode where all of the processing happens on Exchange server and you keep an open connection between Outlook and Exchange.

Historically, this is how I’ve seen most implementations and it would be safe to assume that this would be considered a best practice. And I 100% agree. The previous blog simply states that storing the Cached Exchange Mode file (.OST) on a network share is a supported option, but with most decisions there is an appropriate place.

There is a reason why this decision has become more important to me.

I’ve recently been spending more time working with Office 365. My question now is what do I do if I use Exchange Online? Easy, use Outlook online.

Unfortunately, that doesn’t always work as users are accustomed to their local install or you have apps that rely on the local install of Outlook client. So in the scenario with Exchange online and Outlook installed locally, would you still use online Exchange mode? Have you actually tried it?

I have. It isn’t the most pleasant experience. To do online mode effectively, you really need a low-latency network link. Neil Johnson at Microsoft posted a blog a few years ago looking into the connection status for Outlook. Based on the blog, an optimal experience is to have your max average response time be less than 325ms. My IT delivered Exchange was 4ms, which makes perfect sense considering Outlook client and Exchange are on the same, low-latency network. Online Exchange mode works great for this scenario. But my connection to Exchange Online from Office 365 was 110ms. Not bad right? Unfortunately there were noticeable performance issues that shown themselves as application lags (you would click an email and it would take a few seconds for the message to appear).

This is making our traditional best practice of using online mode for XenApp and XenDesktop implementations not so strong. In reality, you are probably going to do something like

  • If Outlook client (running on XenApp or XenDesktop) and Exchange server are on the same low-latency network, use online mode
  • If Outlook client (running on XenApp or XenDesktop) and Exchange server are not on the same low-latency network, use cached exchange mode with network storage.

But that isn’t the end of the story. We will want to optimize Outlook for this implementation.

Stay tuned for more…

Cached Exchange Mode Blog Series:

From the virtual mind of Virtual Feller

Can I use Outlook Cached Exchange Mode on XenApp and XenDesktop

You are driving a bus and you make a stop and pick up Margaret, a 66 year old woman. At the next stop, you pick up two people, a 22 year old man named Ralph and a 44 year old woman named Lisa. At the next stop, Margaret gets off, while 3 more people get on, a 35 year old man named Fred, his son who is 4 named Colby and a 32 year old woman named Heather. What is the name of the bus driver?

Did you get it? Was it too easy?

How about this one.

First, read through the Microsoft KB article that discusses where to store Outlook data files.

After reading it, can you tell me if Microsoft will support a configuration where Outlook is running on a RDSH (XenApp) or VDI (XenDesktop) instance in Cached Exchange Mode where the .OST file is stored on a networked file server?

Your answer will be based on how far you read. Unfortunately, I’ve witnessed many very bright people tell me that this configuration is not supported. The reason is that they were either told it wasn’t supported or they read this article and stopped before reaching the end. Why would they stop? Because in the “More Information” section of the article, only 1/3 of the way down says

It clearly states “Because of these behaviors, Offline Folders (.ost) files and Personal Address Book (.pab) files on a network share that are accessed remotely are also unsupported configurations.”

That is if you stop reading.

Further down, the article provides special statements for different circumstances. We are interested in the RDS/VDI section that says


So if I use RDSH (XenApp) or VDI (XenDesktop), I can use Cached Exchange Mode with the .OST file being on the network if I have a high-bandwidth, low latency connection. Well, that is our XenApp best practice, keep the data and app in close network proximity. So the network file server you use to store the .OST file should be in the same data center as the XenApp server, with this configuration, the location of the Exchange server become irrelevant.

Now should you implement it?  Stay tuned… :)

Cached Exchange Mode Blog Series:

From the virtual mind of Virtual Feller


Get every new post delivered to your Inbox.

Join 4,216 other followers