Category Archives: XenApp

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:

 

 

 

PROOF[Video] – New XenDesktop and XenApp Storage Optimizations Does Improve the User Experience


I’ve written and seen numerous blogs/tweets about how great the new storage optimization feature is for XenApp and XenDesktop. I’ve read how this feature can reduce IOPS from an average of 15 IOPS per Windows 7 user down to 0.1 IOPS. I’ve read how this feature functions by creating a small RAM buffer within each VM. I’ve seen tweets showing crazy IOPS numbers on using standard, spinning disks.

In fact, I’ve done some of this analysis and was completely blown away by the results.

But who cares? Who cares if my IOPS are reduced by 99%?

Unfortunately, unless you are responsible for storage, you probably don’t care.  But what if this drastic reduction in IOPS had a direct impact on the user experience?  And from someone who uses VDI remotely 100% of the time, the user experience is what I really care about.

Let’s see what the new RAM Cache with Disk Overflow feature can do for the user experience…

What impresses me the most is that the workload used isn’t some crazy operation that a typical user wouldn’t really do.  You can easily see the improvement to the user experience with something as simple as browsing a few web pages.

And all of this is done

  • Without complex configurations
  • Without expensive SANs
  • Without SSDs
  • Without additional hardware
  • Without additional licenses
  • Without a learning curve

From the virtual mind of Virtual Feller

Upgrading from XenApp 7.5 to XenApp 7.6


After delivering the XenApp 7.6 Upgrade webinar, I received a few questions asking if it is a good idea to upgrade from XenApp 7.5 to XenApp 7.6. My first reaction is, “Of course you should. Why wouldn’t you?”

But I’m a little biased J

You need to ask yourself if the new features within XenApp 7.6 are important enough to upgrade. Look at the following subset of features and determine if they are something that would be valuable for your users and admin:

  1. Unauthenticated Logons: This feature allows a user to access an application without being required to authenticate. This feature is mostly used in healthcare. If you need this, you must go to XenApp 7.6 feature
  2. Connection Leasing: You ever watch Star Trek and you hear the engineers talk about having secondary backups? A secondary backup won’t let your starship reach Warp 9, but it will keep your ship from exploding. That is essentially what connection leasing does for your XenApp site. Your first layer of backup is configuring your database to be highly available (mirroring, clustering or AlwaysOn). If that fails, you want to have a secondary backup, which is connection leasing. Another XenApp 7.6-only feature
  3. App Usage: Provides additional reporting capabilities for admins so they can see usage patterns for the applications. It’s good to know what your users are using.
  4. Fast App Access: “Patience you must have, my young padawan” is great if you are a Jedi. Unfortunately, my patience decreases waiting for my logon. A Windows logon includes a list of things (policies, logon scripts, drive mappings, etc.) that must execute before you can get to an application. Fast App Access essentially does all of the session creation processes before you request an app, greatly reducing logon times. In a production environment, the logon process that the user experiences is as follows:

    Take a look at the Session Prelaunch video to see how it is configured and functions.

What’s nice about being on XenApp 7.5 and upgrading to XenApp 7.6 is that the upgrade path is very easy. At a high-level, you essentially do the following:

You will notice that these are all upgrades. No need to rebuild. Of course, if you want more detail and guidance, then take a look at the following eDocs article.

The XenApp 7.5 to 7.6 upgrade is probably one of the smoothest upgrades I’ve ever done, and I’ve been upgrading since WinFrame.

 

From the virtual mind of Virtual Feller

The Latest XenApp 7.5 Read/Write Ratios


As technology changes, so too does a recommendation.

For years when you deployed XenApp servers with Provisioning Services, the storage Read:Write ratio would be 10:90. This is still the case in most scenarios. But in analyzing the latest data from the Citrix Solutions Lab, who were testing the “RAM Cache with Overflow to Disk” option, we encountered some results that will make us revisit some of our old recommendations.

  1. IOPS: For a medium workload on XenApp 7.5 on Hyper-V 2012R2, the average IOPS per user is 1, as explained in the previous blog.
  2. R:W Ratio: When using the new write cache option on Hyper-V 2012R2, the read:write ratio changes to 40:60. (Note: These numbers are taken at the physical host layer and not the VM layer)

Why is this? Why the change?

Think about what the RAM Cache with Disk Overflow does… It uses a section of allocated VM RAM to cache disk activity. As this cache fills up, it will start to move portions to disk. If you allocated enough RAM, you significantly reduce the number of IOPS (especially write IOPS). Look at the differences between PVS Disk and RAM Cache options

We’ve significantly reduced write activity because writes go to RAM. And whatever writes do make it to disk from the RAM Cache are bigger block sizes, thus also helping to reduce IOPS.

And finally, if you look at the disk idle time on the physical host, you can clearly see that the disks have a higher idle percentage when using the new RAM Cache with Disk Overflow option within PVS because we have less data going to the disk.

So far, the RAM Cache with Disk Overflow option is looking very promising. Soon, I’ll show you what it can do for Windows 7 workloads

For this setup, we used

  • LoginVSI 4.0 with a medium workload
  • Hyper-V 2012R2
  • XenApp 7.5 running on Windows Server 2012R2
  • 6 vCPU, 16GB RAM, 2 GB RAM Cache
  • 7 VMs per physical host

From the virtual mind of Virtual Feller

Follow

Get every new post delivered to your Inbox.

Join 478 other followers