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… :)
From the virtual mind of Virtual Feller
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:
- 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).
- 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 @djfeller
We get so excited with the thought of VDI, we often forget to take a step back and focus on what we are trying to do. Here is a recent example…
We need to find a way to get an application to our users. Our first problem is that many of our users are not local, which makes installation a challenge. The second problem is that many users want to use the application on non-traditional devices (tablets) because it is more convenient. We’ve heard that VDI can help us with this. What will it take?
First, this is a good question, but unfortunately, the person has already decided on a solution without understanding what is possible. I can’t blame the person for already believing that VDI is the right answer because the marketing teams that are focused on VDI have done a great job blanketing us with the VDI message. And unless you are knowledgeable about the functionality with different products, you might miss the nuances and buy something you weren’t expecting.
If I were to make a recommendation with this particular customer, I would steer them to XenDesktop 7 App Edition (for those of us who have been around for some time, I’m referring to XenApp), which basically delivers an application to a user instead of the entire desktop. This solution aligns closely with what the user needs.
But what will it take for 500 users? Not much… just three physical servers using two Intel Xeon E5-2690 @2.9GHz with 192 GB of RAM.
Of course many will think this is all theoretical. But to prove this isn’t simply fairytales and unicorns, we built, tested and validated this Design guide to mobilize windows apps in the Citrix Solutions Lab (I will provide more gory details in a future blog).
When we go through the numbers and incorporate it into our 5-layer conceptual model, we get the following (Read about the XenDesktop 7 blueprint to better understand the 5-layer architecture).
This solution gets you the following:
- Delivery of almost any Windows-based application to any endpoint to any location without requiring the application to be rewritten for the numerous types of endpoint device types and form factors.
- Traffic is protected within SSL as it crosses over public network connections with NetScaler Gateway
- An environment, capable of supporting 500 concurrent users, with only 21 virtual servers (Note that VDI would require over 500 virtual machines).
- Most importantly, the entire environment is using standard local storage. There is nothing special about the local storage as each physical server includes (8) 300GB SAS drives spinning at 15,000 RPMs configured with RAID 10.
Of course this is just conceptual, so what does the physical architecture look like?
- 3 physical servers required to support 500 users, with each RDS host supporting roughly 50 users. If more users are required, another server is added resembling the “Server 3″ config. We don’t have to worry about scaling the Access and Control layer components for some time as they have low utilization.
- Three different VLANs for DMZ, VM, and Management traffic. I know some of you will point out the risk with putting the NetScaler Gateway VPX on internal servers and having the VLAN for that VM go to the DMZ. Depending on the size and complexity of your infrastructure, this might be a non-issue as long as you have the proper configuration and lockdown procedures.
- Access Layer and Control Layer configured with N+1 availability in that if one component fails, a secondary component is available to take over the load.
When trying to decide what to do in your own environment, remember to look before you leap.
If you want to read the entire design, check out the Design guide to mobilize windows apps
Daniel – Lead Architect
Based on the XenDesktop 7 Blueprint, we have already created a definition of our user layer. The next step is to define how users will access their environment. Just like a house, you have doors and locks. In order to gain entry, you have to have the right keys for the right door.
Defining the access layer is basically focusing on the required access policies for internal vs. external users. What’s an access policy? It is simply defining the following 4 items:
- Authentication point: Where do users first enter their credentials. Typically, this is either StoreFront or NetScaler Gateway.
- Authentication policy: How many and what type of authentication must users provide before access is granted. Username, password, RADIUS, etc.
Session policy: Will different devices receive different levels of access? Some people want to provide a different access experience based on their device being either mobile (iOS, Android or Microsoft tablets and phones) or non-mobile (such as Windows, Mac®, Linux). In order to do this, the NetScaler Gateway must be able to determine the endpoint device type. This is accomplished by using the following expressions:
- Mobile Devices: The expression is set to “REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver” which is given a higher priority than the non-Mobile device policy to ensure mobile devices are matched while non-Mobile devices are not.
- Non-Mobile Devices: The expression is set to “ns_true” which signifies that it should apply to all traffic that is sent to it.
- Session profile: What network connection will users be granted: Full VPN or ICA Proxy. Full VPN provides the endpoint with full access to the internal network while ICA Proxy only allows the ICA protocol access.
As you can imagine, there are many options for these 4 items, but here is what most people use
|Users connecting from…||Local, trusted network||Remote, untrusted network|
|Authentication Point||StoreFront||NetScaler Gateway|
|Authentication Policy||Simple authentication
(username and password)
(username, password and token)
|Session Policy||Not applicable||Mobile and Non-Mobile|
|Session Profile||Not applicable||ICA Proxy|
And with this, our diagram continues to evolve
We have now included the following:
- User group location
- User group end point device
- Full Access layer communication
- NetScaler added as an Access Controller in the Control Layer
Stay tuned for the Resource Layer…
Daniel – Lead Architect
Here is a little secret… Most XenDesktop environments are extremely similar. In fact, if you ignore the numerous hardware combinations out there, the similarities increase greatly.
You have user groups (some internal and some external) that need access to some type of resource, whether it be a desktop or an application, which is supported on a standard set of controlling components all running on some type of hardware combination.
So why is desktop virtualization so complex? Because we made it that way by believing that every deployment must start from scratch.
Think about if you were going to have a house built. You would start with a high-level blueprint. The first thing you do is figure out what type of house you want built: a rambler, split level, 2-story, etc., but it will have the same fundamental components (HVAC, electrical, plumbing, framing, roofing, etc). However, the first things you think about shouldn’t be the electrical wiring. It would be insane to start here because you don’t even know where the walls are going to be located that will contain the wires. So tell me why when doing desktop virtualization do people start with storage or servers?
This is why we have a XenDesktop 7 blueprint. To guide you on your way towards creating a desktop virtualization solution, every XenDesktop 7 solution has 5 parts:
1. User Layer – Defines the unique user groups and overall requirements.
2. Access Layer – Defines how each user group will gain access to their resources with a focus on secure access policies and desktop/application stores.
3. Resource Layer – Defines the virtual desktops and applications assigned to each user group
4. Control Layer – Defines the underlying infrastructure required to support all users accessing their resources
5. Hardware Layer – Defines the physical implementation of the overall solution
This is the framework to understand how all layers build upon the previous layer. When you begin to develop your solution’s conceptual architecture, it begins to resemble the following:
As we work through the layers in future blogs, we will see how this structure will take shape and what decisions you really need to make.
Daniel – Lead Architect