Blog Archives

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


Jackpot!

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

Sizing XenDesktop 7 App Edition VMs


In the Mobilizing Windows applications for 500 users design guide, we made the recommendation to allocate 8vCPUs for each virtual XenDesktop 7 App Edition host (formerly known as XenApp). Spreading this out across a server with two Intel Xeon E5-2690 @2.9GHz processors and 192 GB of RAM, we were yielding about 200 users per physical server and roughly 50 users per virtual server.

Of course, the design guide is the end result of a lot of testing by the Citrix Solutions Lab. During the tests, we had the Solutions Lab compare many (and I mean many) different configurations where they changed the number of vCPU, RAM size, and RAM allocation (dynamic/static) as well as a few other things. We ended up with the following:

A few interesting things:

  1. Dynamic vs static RAM in Hyper-V appeared to have little, if any, impact on overall scalability. The only time when the RAM allocation had a negative impact was when not enough RAM was allocated (no surprise there).
  2. The 8vCPU and the 4vCPU configurations resulted in very similar user concurrency levels. Get ready… The battle is about to begin as to whether we should use 8 or 4 vCPU. (Is anyone else besides me having flashbacks to 2009?)

A few years ago, we debated about using 2vCPU or 4vCPU for XenApp 5 virtual machines. A few years later, the debate is resurfacing but this time, the numbers have doubled: 4 or 8. Here is what you should be thinking about… VMs are getting bigger because the hardware is getting faster, RAM is getting cheaper and the hypervisors are getting better (Nick Rintalan provided a pretty good overview on some of the reasoning for this during his discussion on NUMA cores in his XenApp Scalability v2013 Part 2 blog). The whole point is that none of this is new. It has been going on for a long time and will continue to do so.

The hypervisor helped us reduce our physical footprint by allowing us to better utilize our physical hardware. Now, with better technology, we are able to reduce our virtual footprint because the technology is able to support larger VM sizes.

Daniel – Lead Architect

Follow

Get every new post delivered to your Inbox.

Join 475 other followers