If you have paid any attention to any articles relating to desktop virtualization, you will quickly see claims like:

• Will Windows 7 fuel desktop virtualization adoption
• How desktop virtualization eases Windows 7 Migration
• Windows 7 Drives Desktop Virtualization
• Windows 7 and Desktop Virtualization: The New Tools
• Windows 7 - The Desktop Virtualization Catalyst 

 
I could go on, but you get the point. The major thought is that Windows 7 and desktop virtualization go hand-in-hand, but how do you get there?  You are not only migrating the OS but you are also migrating to a virtualized desktop operating environment.  Is this too much change for an organization?  
 
NO.  This is the perfect time to make the move.  Think about it this way, we have the opportunity to start with a clean slate.  We can define the new operating system that completely aligns with the organization's policies.  We can provide an environment that self heals and is optimized each and every time a user connects.  But in order to achieve these benefits, we have to design the environment correctly.  We need to focus on
•    What do we include in our base desktop image?
•    How do we deliver the operating system to our end point (which might be a physical or virtual desktop)?
•    How do we integrate applications into the mix?  
•    What are the recommendations for allowing users to personalize their environment without impacting the business?
•    What are the best practices for providing a great user experience for any user over any connection?
 
These are some of the topics being presenting in this week's Microsoft TechNet broadcast focusing on "Accelerating Windows 7 Migration with Citrix and Desktop Virtualization"
 
The show starts on Thursday, November 12th at 1PM Eastern time and you can register here

Daniel - Lead Architect - Worldwide Consulting Solutions

• Twitter: @djfeller
• Desktop virtualization information: Ask the Architect - Next-Generation Desktop site
• Questions - Then Ask The Architect

---

---

Best Practices for Deploying and Managing Hyper-V Infrastructure

Date: Thursday, August 27, 2009
Time: 2:00 PM Eastern; 11:00 AM Pacific

Join Microsoft and Citrix as they explore best practices for deploying and managing Hyper-V. Learn how to rapidly provision Hyper-V infrastructure, reduce your Hyper-V storage footprint by over 50%, increase I/O performance by up to 30%, and much more.

Discover how Microsoft System Center together with Citrix Essentials for Hyper-V helps you effectively manage and automate the delivery of virtual and physical infrastructure for your Hyper-V deployments, including how the solutions:

• Rapidly provision virtual and physical infrastructure
• Improve storage utilization with the seamless storage integration
• Conquer VM sprawl and take back control of virtual labs
• Maximize performance and resource utilization

REGISTER NOW.

About the Presenters:

Gordon Mangione; VP, Emerging Virtualization Products; Citrix Systems, Inc.
Gordon Mangione leads the Advanced Products group at Citrix, where he is specifically focused on building products for the Microsoft platform. Previously, Mr. Mangione was responsible for product operations with a focus on engineering, support and services at XenSource before its acquisition by Citrix. Prior to that, Mr. Mangione held several VP roles at Microsoft, where he was responsible for Exchange, SQL Server and incubating the security business.

Dai Vu; Director, Virtualization Solutions Marketing; Microsoft Corporation
Dai Vu leads the team responsible for Hyper-V product marketing and marketing solutions built on Microsoft virtualization products and technologies. His team works closely with solution partners to define, develop, and market joint solutions to drive horizontal and business solution scenarios enabled by virtualization technologies. Previously, Dai was responsible for mid-market/channel strategic initiatives on the Server and Tools Strategy and Planning Team. Prior to Microsoft, Dai was Program Director at IBM and Engagement Manager at McKinsey and Company.

REGISTER NOW

In Provisioning Services for XenApp Best Practice #5, I wrote about application streaming integration. I talked about two different options:

1. Stream on-the-fly: which results in the vDisk write cache growing as the application is streamed
2. Pre-cache: which stores the application cache within the vDisk, but helps to reduce the size of the vDisk

Both of these options had their issues. Option 1 would grow your write cache quickly, especially on XenApp servers hosting tons of applications. Option 2 creates a link between the vDisk and applications, which adds another step to application updates.

I received many suggestions and alternatives, some were quite interesting . The one that resonated the most was to store the application streaming cache on another disk that is not delivered via Provisioning services.

• Physical Servers: You would use the physical disks installed into the physical servers
• Virtual Servers: You would use a virtual disk assigned to the virtual machine (preferably shared storage so you can still do XenMotion).

This setup doesn't really change our architecture in that many implementations have a non-Provisioning Services disk associated with each server to store items like event logs, local databases, write cache and pagefile (as explained in BP 8?).

Honestly, I haven't had the opportunity to set up an environment like this in a large environment, so I didn't want to offer it as a best practice yet. But I've had many of you say that this is about the only way you deliver XenApp images with Provisioning Services and have had no issues with the environment from configuration or maintenance. I've always thought this provided the best solution as it overcomes many of the lingering challenges of option 1 and option2. So, how do you do this? It is actually pretty easy:

1. Make sure you have an NTFS disk associated with the physical server (physical disk) or virtual server (virtual disk)
2. With the Provisioning Services image in private-image mode, change the location of the Application streaming cache location
   1. Launch C:\Program Files\Citrix\Streaming Client\ClientCache.exe
   2. Change the client cache directory to the virtual or physical disk
   3. Shut down and place vDisk back into standard image mode
      
      
      When you boot, and launch your applications, your application cache is now stored on the physical/virtual disk that is not erased during reboot. What does this get you?

• Faster application launch after server reboots because the application cache is not erased
• Easier application maintenance because the application cache is not included within the vDisk

But this configuration does come at a price. You have to have a persistent disk associated with each physical and virtual server. Although this cost is pretty small as most Provisioning Services/XenApp implementations already have a local disk to store local monitoring databases, event logs, etc.

My list is now empty, but will post new topics as they come in.  Feel free to tweet me some ideas on Twitter.

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drive
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more

By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly.  I'm a little biased, but I think it is a good one.

Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

This was posted some time ago, but I suspect that there are many that may have missed it since there are so many new virtual desktop projects springing up all the time. So I'm bringing it back up to the top for more exposure!

This blog has been invaluable for our field, for our technical marketing staff and for our event demo preparations. It's called "Windows XP Performance Optimizations for XenDesktop and Provisioning Server vDisks."

There's more to be discussed on how to successfully make that P2V conversion of a desktop, and we are working on additional white papers that will outline some of the real world best practices we've uncovered - so stay tuned!

The whole concept of a standard image used across multiple end points is a great idea. Think about it, 1 image for hundreds/thousands of servers. Talk about simplicity. I only have to make updates once and every server has the same update. Every server is identical. This makes scaling up the environment easy. Of course there are some challenges, as many of you have pointed out after my very first blog posting where we spoke about vDisk type. That challenge is that the "write cache" is destroyed upon server reboot.

For the most part, this is a good thing. Those changes gives each XenApp server a personality. I don't want my XenApp server to have personalities. Its kind of like running Microsoft Word one day and it is using United States English and then the next day it uses United Kingdom English. This little personality change doesn't seem to be a big deal, but it is. For example, I like my words to use the letter Z. I believe you spell color without the letter U. I believe neighborhood is spelled without the letter U too. Of course this is a simple change for a user, but we shouldn't make our users do this. But there are some changes on XenApp servers which are valuable (many of you have pointed them out to me) like event logs and performance metrics.

So how do I use a standard image but still allow these important items to remain persistent across server reboots? Some of you have raised good points on this, especially around the use of differential disks, but the problem with differential disks is that the differential cache will go away if the base vDisk is changed. So, differential disks do not really help us out that much. What we can do instead, which again some of you alluded to, is to use a local disk.

Now I bet some of you have alarms going off in your head and are thinking, "Hey, I thought the benefit of Provisioning Services is that I don't need local disk". Well, you are 100% correct, that is one of the benefits, but there are more like standardization and synchronization but will leave that for a marketing-type blog. But with standard images you do lose some items like persistent storage of event logs, metric databases, etc. But if we allocate a local disk to the server, we can redirect the storage of the persistent data. BTW, this works when XenApp is virtualized on XenServer and when XenApp is on bare-metal.
You do this by doing the following:

1.  Your virtual machine must have 2 virtual disks assigned. Remember if you want to do XenMotion, the second virtual disk must be on shared storage. How large you might ask? For XenApp, a 4GB partition is a good starting recommendation, but with most decisions, it depends.
2. Build XenApp on the first disk and format the second disk NTFS so it shows up in your system (use basic disk and not dynamic).
3. Change the storage paths of your persistent databases, event logs and anything else to the second virtual disk.
4. Build your vDisk from the C drive, but not the second drive. When done, shut down the virtual machine.
5.  Detach the OS virtual disk from the virtual machine, but leave the second virtual disk attached.
6. Clone the virtual machine including the virtual disk.
7. Now stream the vDisk image to this new virtual machine. Your event log should be stored on the virtual disk instead of within the write cache.

So now we are using a base vDisk for our image and still allowing persistent data storage. And what's more, you can also use that persistent disk to be the write cache storage location as well. Just tell Provisioning Services to store the write cache on local storage, and the persistent disk will hold that information for the server's session.

My list is now empty, but will post new topics as they come in.  Feel free to tweet me some ideas on Twitter.

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.

By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly.  I'm a little biased, but I think it is a good one.

Daniel - Lead Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

This best practice was requested by a comment on a previous blog posting. With Provisioning Services, we are able to use a single image for hundreds of XenApp target servers.  Making a change to the image is a big deal because every XenApp server will use the new image after a reboot (of course this is also a huge benefit).  How do we keep control over these images and make sure you don't break your entire environment with a new update?

Truthfully, it is a fairly straight forward process, but just like all processes, you need to follow them if you want things to go smoothly.  High-level process overview is in the following figure:

 
These are all logical systems, meaning that they could be virtual servers, physical servers, different volumes on the same storage infrastructure. The recommended process is as follows:

1. When you have a valid vDisk on your production Provisioning Services server, make a copy of it and store it in your library.  The library is just that, a location where you keep the current and old revisions of vDisk images.  
2. When you need to make an update, copy the vDisk from your library to your test environment Provisioning Services server.  
3. Make your changes in the test environment. When the changes are done, update the revision number and filename of the vDisk. Copy the vDisk back into your library and to the production Provisioning Services server.
4. Tell the production Provisioning Services server to auto-update vDisks.  This is actually a really cool feature. The auto-update process will automatically update the vDisk file of all affected target devices upon next reboot.  How can you tell which target device will be updated?  By the Class information.  Each target device and vDisk file has a Class field.  The class fields are the link for auto-updates.  Provisioning Services will look to see if there are any vDisks with a higher revision number (which there is as we just updated the vDisk and incremented the revision number).  Provisioning Services then checks the Class of the vDisk.  Any target device with the same Class will receive the new vDisk upon next reboot.  This is a great way to simplify the management of your XenApp farms.

Ok, so we updated our XenApp servers with a new vDisk, but what happens if there is a problem with the vDisk updates?  Have you ever installed a hotfix to find out it broke other things? I bet so.  If you followed the process outlined above, you have a build in rollback feature by doing the following:

1. You make a copy of the previous vDisk image from your library to the Production Provisioning Services server.  
2. You increment the revision number on the old vDisk image to a number that is higher than the updated vDisk image.
3. You implement the auto-update feature of Provisioning Services
4. Reboot the XenApp servers

As you can see, the processes for updates and rollbacks are very similar and it works great.  Stay tuned for more best practices regarding Provisioning Services and XenApp.  

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.

By the way, if you haven't done so already, take a look at the Provisioning Services for XenApp TechTalk presented by yours truly.  I'm a little biased, but I think it is a good one. 
Daniel - Sr. Architect - Worldwide Consulting Solutions
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

Pagefiles, partitions and drives are an interesting combination of items to talk about regarding Provisioning Services and XenApp. Each one will have a direct impact on your environment.  First, let's be clear, Provisioning Services does support many of these items, but when I design a Provisioning Services solution (or any solution for that matter), I'm always reminded of a message a professor told me once.  The professor was a fan of the group KISS and he always wanted you to follow the KISS motto... "Keep It Simple Stupid", but I'll be a little more polite and say "Keep it Short and Simple".  Keeping it simple is how we will design the following items.

Pagefile

The first area deals with the page file.  Before we got into provisioning and virtualization, I would see many people put the page file on a different drive letter than their OS or applications.  At first glance you would think, OK, they want the page file to respond fast. But the page file was only on a different drive letter at the logical layer. At the physical layer, the page file was still on the same physical disk as the other partitions.  So, my question was "Why are you moving the page file? You are causing yourself more work for no benefit."  The same holds true in Provisioning Services.  

The pagefile is undergoing constant modification by the operating system. As physical memory is paged, it is stored in the pagefile. Upon reboot, the contents of the pagefile are not important, and it is overwritten on subsequent startups. In a Provisioning Services environment, the pagefile will be located on the vDisk, but any change made to the file will be recorded in the write cache, because the vDisk image is read-only. Assigning the pagefile to a different partition within the vDisk is not recommended, because there is no speed benefit. You are just causing yourself more work.

 
Multiple Partitions

On the heels of the page file decision is whether to use multiple partitions.  Does this look familiar?  

• One Partition Server
  • Partition 1: Operating System, Pagefile, Applications
• Two Partition Server:
  • Partition 1: Operating System, Pagefile
  • Partition 2: Applications
• Three Partition Server
  • Partition 1: Operating System
  • Partition 2: Applications
  • Partition 3: Pagefile

Provisioning Services can deliver an image with one or two partitions, but not three. Plus, based on the Pagefile section above, there is no gain from having a separate pagefile partition on a provisioned XenApp server as the pagefile changes will be stored in the write cache.
 
Although two partitions are supported, it does increase the complexity of the environment and does not offer any performance benefit to the environment. There is a Citrix article (CTX116698) that explains how to provision a server with multiple partitions, but why go through the hassle.  Keep It Simple.  

 
Drive Remapping

Finally we get to remapping XenApp server drives. Remember, this is when you change the C drive of the XenApp server to the M Drive. D becomes N and so on.  Why would you do this you might ask?  Well, the most common justification for this design consideration was for users to have their client drives mapped within their XenApp sessions as C and D. However, this approach should be re-examined. Remapping server drives is not considered a best practice for XenApp environments because:

• Drive remapping is no longer an option in XenApp 5 running on Windows 2008 Server.
• Giving users access to their local C and D drives within a XenApp session is considered a security risk. If the applications are hosted on the XenApp servers, the data should be in the data center for best application performance.
• It makes the environment more difficult to setup, maintain and troubleshoot
   

 So remember, Keep it Short and Simple (KISS):

• Page file: don't create a special vDisk partition
• Partitions: Use a single partition
• Drive Remapping: Don't do it.  

 
What do you think? Agree or disagree? BTW, we will be revisiting the page file topic again in an upcoming blog when we discuss Local Database Storage.  How does the page file fit with local databases? Well, you will just have to stay tuned.

As always, stay tuned for more best practices regarding Provisioning Services and XenApp.  

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.

Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

As we continue to discuss Provisioning Services best practices for XenApp, I want to talk about a question I hear a lot, especially when people see the value of Provisioning Services and XenApp Application streaming "Should I pre-deploy my streamed applications into the Provisioning Services vDisk?"  If Provisioning Services wasn't in the picture, I would say let the streaming infrastructure manage the application streaming delivery, but Provisioning Services must be taken into account because the act of application streaming has a direct impact on the provisioned server. 

The streamed application is a change to the base vDisk image. These changes are stored within the write cache for each provisioned XenApp server.  Depending on the size of the application, the simple process of delivering an application on top of a Provisioning Services' streamed XenApp server can make the write cache grow by many gigabytes as shown in the following diagram:

Using a provisioned XenApp server will generate the typical swap and temp files, which will be added into the write cache. When a streamed application is requested the first time, the application profile is delivered to the XenApp server from the Application Hub in a compressed format (.CAB files).  The application profile is delivered and then decompressed so it can be utilized. This process adds information to the write cache.
Depending on the write cache option selected, this could have a significant impact on the usability and speed of the XenApp server.  If the write cache size is a concern, then a pre-delivery option exists that will reduce the size of the write cache. This process is shown in the following figure.
In this example, the vDisk image has a pre-delivery of the streamed applications. Users still have to access the applications as before, but the applications are already on the vDisk so the application stream process is complete. This removes the application CAB files and the decompressed application cache from the write cache. This also speeds up the application stream process because the application is already present on the vDisk, although this is a minor concern due to the XenApp servers and Application Hub server residing on the same high-speed network.
The challenge with doing the pre-cache of the streamed application is that each time a streamed application is updated (which could be often), the application cache within vDisk image should also be updated (at least that is the assumption). This adds more steps into the application update process.  But I don't believe every application update requires an update to the application cache on the vDisk, only major updates are a concern. 

For example, if an application has a new patch or a new file update, simply updating the application profile will be adequate.  When a user tries to start the application on a provisioned XenApp server, most of the application cache is correct except for a file or two.  Those two items will be updated from the application hub, and will only slightly increase the size of the write cache. However, if a large update to an application is performed, like adding a service pack to Microsoft Office, then it would be advantageous to refresh the application cache on the vDisk because these updates impact a large percentage of the files in the cache. When the application is executed, all of the updated files will be streamed down and placed in the write cache.

As always, stay tuned for more best practices regarding Provisioning Services and XenApp.  

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.

Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

Here we are again, for another Provisioning Services for XenApp Best Practice.  This best practice focuses on integrating applications into the vDisk image.  Pretty simple Yes or No answer.

But this is one of the major challenges with creating a base XenApp image is determining what to include and what not to include.  Of course, you need the operating system and XenApp and Provisioning Services tools, but beyond that what is recommended and why?  Take the following scenario: due to business reasons, an environment has three sets of XenApp servers hosting different line-of-business applications.  All three line-of-business applications are dependent on Microsoft Excel for viewing and editing integrated spreadsheets.  Should Microsoft Excel be part of the base image or should it be a streamed application?  There answer is... there is no right or wrong answer; it is all dependent on other factors within the environment. Don't you just love answers like that?

The decision to include core applications is oftentimes a result in the belief that the base image should contain the greatest number of items that are common between XenApp servers.  If every server requires the same application, more network bandwidth will be used when the application is streamed to every server as part of the application streaming process.  Also, application streaming, in the default configuration, does not initially start as fast as a previously installed application because the application must be sent across the wire.  Thus, users will experience latency while the application is streamed for the first time (this latency can be overcome with application pre-caching, as explained in the Application Cache section).

There is also a business aspect to this decision. In some organizations, one set of administrators is responsible for applications and another set is responsible for the XenApp configuration. By separating the applications from the base image, the technical solution can align more closely with the organizational structure of the business.

	Base Image Application Inclusion	Base Image Application Exclusion
Benefits	Base image and applications included in a single server role, which will allow for the fastest rebuild and delivery times. * Less network bandwidth is used because the applications are already present in the base image and no additional installations are required.  The complete image can be deployed during off hours so as to not impact availability of the XenApp servers during the day.  * Application startup time is shorter because the application is already part of the image and does not need to be streamed.	With fewer items included in the base image, maintaining the image is easier as only the core operating system and XenApp are provisioned initially.* XenApp base images are managed with one set of tools, and applications and corresponding updates are managed with a different set of tools.  This makes it easier to have multiple administrators responsible for different areas of expertise. * XenApp silos become a thing of the past. A single XenApp server image can be used to deliver any application at anytime.  A single image to maintain for the entire XenApp farm greatly simplifies support
Concerns	Core application versioning changes can impact the base image.  For example, if all servers require the same version of Microsoft Excel, no issues are raised.   However, when individual application upgrades occur, some applications might require Excel 2007 while others require an older version. This would have a profound impact on the contents of the base image. Modifying an application within an image will impact all servers that rely on the image. This might require different levels of change control for applications that are integrated with the base image and applications that are not integrated. More images to maintain, which can make support more difficult, although the number of Provisioning Services images is still far fewer than the number of images required for other server build solutions	Streaming applications will increase network utilization during startup, although this can be mitigated with application pre-caching.  In the default configuration, the first user starting an application will notice a pause before application startup as the application is streamed to the server.  This can be overcome with application pre-caching. Not every application can be streamed. Although XenApp streaming has improved to include more applications, there are some that cannot be streamed because they require special functionality

Regardless of the decision on which applications to include and exclude in the base image, the following are general best practices for the base image:

• All relevant operating system and XenApp hotfixes and service packs should be included in the base image.
• The most common operating system and XenApp configuration should be used for the base image. If 80% of the servers require a specific setting while another 20% do not, the base image should include the special setting.
• The base image should include all appropriate XenApp plugins.  If application streaming will be used, the streaming plugin should be installed as part of the base image.
• Depending on the usage of server certificates, the appropriate root certificate should be part of the base image.  

What do all of you think? Do you install the common applications into the base vDisk, or do you rely on XenApp application streaming? How many unique XenApp images do you have in your environments? 

As always, stay tuned for more best practices regarding Provisioning Services and XenApp.  

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.

Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Follow me in the Blogs: http://community.citrix.com/blogs/citrite/danielf

In the previous Provisioning Services with XenApp best practice blog, I spoke about the type of vDisk to use (the feedback was great. So much so that I've added new items for future best practices discussions).   If you are going down the route of using a standard image, you must make another decision. This is probably one of the most commonly asked questions regarding Provisioning Services for XenApp environments, where do I place the write cache?  The goal is to select a location that gives you the best performance without sacrificing other important items like fault tolerance or scalability.  What makes this such a challenging discussion is the number of options we get. 

• Target Device (Physical XenApp or Virtual XenApp) - RAM
• Target Device (Physical XenApp or Virtual XenApp) - Local Storage
• Target Device (Physical XenApp or Virtual XenApp) - Shared Storage
• Provisioning Services - Local Storage
• Provisioning Services - Shared Storage

Each write cache storage option has many different benefits and concerns, especially for the XenApp workload. For most XenApp environments, the best solution will be the one that takes on the following characteristics:

• Fast: XenApp requires a solution that responds quickly as XenApp is maintaining live, interactive user sessions. Any delays in the write cache might be noticeable to the users.
• Dynamic: XenApp servers are delivering many different applications and supporting many different users. Each user and application will have an impact on the write cache. The amount consumed will change day-to-day. The risks of exhausting write cache space would be detrimental to the success of a XenApp environment.
• Available: XenApp servers must be protected from environment failures, because each server is supporting many users simultaneously. The write cache solution selected should be one that does not impact high-availability options from functioning.
  

Target Device - RAM

Definition: The first option for write cache storage location is the target device's RAM. A portion of the target device's RAM is set aside and used for the write cache.

Benefits: The main benefit for using the target device's RAM is it provides the fastest type of write cache.

Concerns:

• A portion of the RAM cannot be used for the server workload. RAM is often better used for XenApp applications or user sessions than for write cache. Plus, using RAM to support the write cache is more expensive than using storage.
• Part of the challenge with using RAM as the write cache storage is determining the amount of RAM required. Provisioning Services can set aside a certain portion of RAM for the write cache, but what happens when the RAM runs out? The write cache is critical to the stable functioning of a provisioned server. When available write cache is exhausted, the server can no longer make changes, which results in a server failure. If the write cache size is not estimated correctly, using a Target Device's RAM might pose detrimental to the stability of the environment.

Target Device - Local Storage

Definition: The second option for write cache storage location is the target device's local storage. This storage could be the physical disk drives on the physical server, or it could be the virtual disk on a virtual server

Benefits:

• This solution does not require additional resources, in that most physical servers being provisioned already have local disks installed and unused.
• Although target device local storage is not as fast as RAM, it still provides fast response times because the read/write to/from the write cache is local, meaning that the requests do not have to cross the network.
• Trying to estimate the size of the write cache is difficult and if done incorrectly, can result in server failure. However, local storage typically provides more than enough space for the write cache, without requiring the administrator to estimate space requirements.

Concerns: If the target device is virtualized, using local storage will prevent live migration processes from succeeding because the storage is not shared across virtual infrastructure servers, like XenServer.

Target Device - Shared Storage

Definition: The third option for write cache storage location is on a shared storage device attached to the target device. This solution is usually only valid for environments virtualizing the target device with a solution like Citrix XenServer. This storage is assigned to each virtual machine from a shared storage repository.

Benefits:

• Although target device shared storage is not as fast as RAM or target device local storage, it still provides fast response times. If the shared storage infrastructure is a SAN or NAS, the reads/writes will still perform adequately because the optimized shared storage infrastructure will help overcome the time added for traversing the network.
• Although the configuration of this solution requires the identification of the shared storage size, the costs associated with over-estimating are not nearly as detrimental as overestimating with RAM. Storage costs are significantly cheaper than RAM so a sizeable buffer over the space estimates is of little concern.
• Because the target device's storage is accessible from multiple virtual machines, virtual server live migration, like XenServer XenMotion, is viable.

Concerns: This solution requires the setup and configuration of a shared storage solution. However, if XenServer is already being utilized, the same shared storage solution can be used for the write cache storage.

Provisioning Services - Local Storage

Definition: The fourth option for write cache storage location is on the Provisioning Services' local storage. This storage uses the physical disks installed within the Provisioning Services.

Benefits: This solution is extremely easy to setup and requires no additional resources or configuration within the environment.

Concerns:

• Requests to/from the write cache must cross the network and be serviced by the Provisioning Services streaming service. Because the write cache is across the network, servicing write cache requests will be slower than the previously mentioned options.
• The streaming service is responsible for sending the appropriate parts of the vDisk to all target devices. Having the write cache on the Provisioning Services server will negatively impact the server's scalability because the streaming service must also service the write cache requests.
• Provisioning Services includes a high-availability option, but in order for this solution to function, all Provisioning Services servers must have access to the vDisk and the target device's write cache. When the write cache is stored on one Provisioning Services server's local storage, this makes it impossible for other Provisioning Services servers to gain access, thus denying the ability to enable Provisioning Services high-availability.
• Although disk space is fairly inexpensive, chances are the Provisioning Services does not have an extensive supply of storage space. With each Provisioning Services server supporting a few hundred target devices, it is quite possible the total write cache could exceed hundreds of gigabytes of storage space. This could result in exhausting all local storage on the Provisioning Services server causing a server failure.

Provisioning Services - Shared Storage

Definition: The fifth option for write cache storage location is on the Provisioning Services server's shared storage. This option utilizes a share storage solution that is connected to the Provisioning Services server.

Benefits:

• The shared storage solution allows for Provisioning Services high-availability as each server can access the vDisks and the write cache.
• Size concerns are mitigated because shared storage devices typically contain significant amounts of storage and can be expanded easily.

Concerns:

• This is one of the slowest solutions because requests to/from the write cache must cross the network and be serviced by the Provisioning Services streaming service. The Provisioning Services server must then forward the write cache requests onto the shared storage, thus resulting in two network hops for the write cache.
• Provisioning Services scalability is impacted as the streaming service is responsible for handling Provisioning Services write cache requests and forwarding them onto the shared storage.
• The solution requires the installation and configuration of a shared storage solution into the environment. If one is already present, then this concern is mitigated.

Best Practice:

Based on the aforementioned criteria and the explanation of the different options for write cache, XenApp servers provisioned with Provisioning Services are best suited for

• Virtual XenApp Server: Target Device - Shared Storage
• Physical XenApp Servers: Target Device - Local Storage
  

Please comment with your thoughts or if there is another best practices you are wondering about. The list has already grown based on feedback from previous blogs. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:

• vDisk Type
• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Image Management
• Local Database Storage (event viewer, EdgeSight, AntiVirus updates)
• Plus more if we get some good ideas on other areas of focus.
  

Daniel

Follow Daniel's Blog: http://community.citrix.com/blogs/citrite/danielf

Follow Daniel on Twitter: http://www.twitter.com/djfeller

Finally, XenApp server farms are going to be easier to manage. Am I the only one jumping for joy?  As many of you have heard by now, XenApp Platinum is going to include Provisioning Services.  This is an announcement I've been waiting for, for quite a long time.  Provisioning Services is a great secret weapon for maintaining any system, but I'm going to focus on is XenApp.  If you want a great overview of what Provisioning Services will do for you, take a look at Vinny Sosa's blog.  What I want to focus on are the best practices for integrating Provisioning Services for XenApp. 

The first best practice, is one you need to decide very early on in your build-out... What type of vDisk should you use?  Private, Standard or Differential.  Take a look at the three options below:

	Standard Image	Private Image	Differential Image
Description	Each target devices stores vDisk writes in a unique change file that is destroyed upon each target device reboot.	Each target device has a dedicate vDisk image configured in a read/write fashion. All changes are part of the vDisk.	Each target device stores vDisk writes in a unique file that is kept upon subsequent reboots, allowing the server to keep configuration changes, until the base vDisk is modified.
Benefit	Servers revert back to a consistent, optimized and approved state after each reboot Storage requirements are reduced as the write cache is reset after each reboot	Complete personalization of the environment because all changes are stored, but at a cost of storage and support.	Allows for greater levels of system personalization by not discarding system-level changes upon subsequent reboots.
Recommendations	Standard images are a recommended best practice for XenApp servers. XenApp servers delivering the same applications should be: Consistent so users do not experience differences between servers Optimized to allow for the best application response times and processing speed In an approved configuration, especially for industries requiring strict enforcement of standards for certification or compliance.	There is little need for Private Images in a XenApp environment because of the differences each image will take. This will go against the core best practice of consistency.	Differential images are appropriate for a small subset of use cases where users have the need to install their own applications. In a XenApp environment, this is not recommended. Once the base vDisk is modified, the differential image is destroyed and the user must rebuild their personality into the target device.

Standard Image is the way to go.  The benefits are great. They align completely with the best practices for XenApp servers... Consistency.  The standard image is the key to consistency.  But how can a single image be used for multiple XenApp servers? If I install the operating system and XenApp onto a base image and then use the same, exact image to hundreds of servers, aren't there issues with farm membership, especially as each server has the same name? 

This is the really cool thing about Provisioning Services.  Within the console, you define each target device with a name and a MAC address. The MAC address links the defined target device within the Provisioning Services console to the actual physical/virtual server.  Whatever name you enter will become the actual computer name of the streamed server.  The Provisioning Services streaming service inserts this identification information into the stream.  So, Provisioning Services takes care of the computer name, but we still have to deal with XenApp farm membership. 

Included in the base image, along with the operating system and XenApp, is the XenApp Prep Tool.  Immediately before you create your base image, you run the prep tool. This tool does exactly what you think it should do, it prepares the XenApp server for streaming by removing items (local host cache, Resource Manager local database), stopping services (IMA Service, Citrix SMA service) and a whole slew of other things.  The XenApp Prep tool also creates a new service so when the base image is streamed to any target, the XenApp Prep service starts and begins the personalization and integration into the XenApp farm.  It does a whole bunch of things, but of importance is the changing of the STA ID (they have to be different), updates certain registry keys to force the XenApp server to request updates to the local host cache, recreates local XenApp databases, and restarts XenApp services. I've left off a few items, but essentially what happens is when the XenApp services start, they will try to communicate with the XenApp farm.  If the server does not have a presence in the farm yet, it will automatically be added. If the server has a presence, it will simply receive its local host cache from the data store automatically.  If you want to get more information and the XenAppPrep tool, get it from here:

If you want to see it in action, take a look at this video

Please comment if there is another best practice you are wondering about. Stay tuned for more upcoming best practice blogs specifically focused on Provisioning Services and XenApp:

• vDisk Cache
• Active Directory
• Application Integration
• Application Streaming Cache
• System-level settings: Page file, drive remapping and multiple drives
• Plus more if we get some good ideas on other areas of focus.
  

Daniel

Follow Daniel's Blog: http://community.citrix.com/blogs/citrite/danielf

Follow Daniel on Twitter: http://www.twitter.com/djfeller

 

This is an interview with Andrew Innes.  Andrew is the Platform Architect for user interaction components of XenApp and XenDesktop, notably Web Interface and the desktop integration clients.  His job entails finding creative ways to improve the usability and security of these products, and helping strike the right balance between them.

Here is Andrew:

 Q: Andrew, what are the security issues Citrix Admins should be aware of with Web Interface?
A: Hi Kate.  There are two main categories of issues admins need to think about: security of the web server itself and security of the whole XenApp or XenDesktop delivery system.  For the web server itself, there are all the standard hardening rules to follow, especially if it is facing the Internet - I won't try to summarize these here.  The aim is to prevent intrusions into the web server itself or the network behind it.

It's worth mentioning though that Web Interface has undergone probably hundreds of evaluations in customer environments as well as regular security audits within Citrix as part of our secure development process.  It has been engineered with all the known web application threats in mind, and we track 'webappsec' developments closely to build in defenses against new styles of attack as they emerge. 

Hardening the web server itself is the #1 recommended best practice for everyone.  Some customers will still want to employ extra measures, such as a web app firewall or other monitoring systems to spot potential attacks.  NetScaler can easily be configured to provide web app firewall, SSL and detailed logs.

For the Citrix specific aspects of security, the admin should start by understanding the business reason for publishing resources (apps, desktops, documents etc) via the web, and the appropriate policies on access rights and restrictions.  These feed into the design requirements for the delivery system, including the configuration of Web Interface.  The aim here is primarily to ensure authorized users are allowed access in the intended way while unauthorized users are denied access, and that policies are not circumvented.
Web Interface has a brokering role in the delivery system, making it an effective place to enforce certain policies, for instance ensuring strong authentication happens before access is granted.  It can be augmented with Citrix Access Gateway to scan end point devices to make fine-grained access decisions; in this case Web Interface plays a supporting role in upholding those policy mechanisms.  It also implements a number of sensitive features, like password change and password reset, which can be enabled when the usability gains outweigh the security considerations.

Q: What are the prescribed security precautions Citrix Admins should use with WI?
A:  There are a few standard precautions we recommend all customers follow:
   -      Require SSL on the Web Interface server; this protects user credentials in transit and helps prevent spoofing attacks (like those that could result from the recent DNS vulnerabilities). 
   -    Use SSL or IPSec for requests to the XML service on XenApp or XenDesktop; again this protects credentials.
   -      Follow best practices for web server administration; this protects against accidental or malicious reconfiguration.
   -      Disabling the HTTP port, or having it redirect to the HTTPS port can be helpful.  Then to prevent potential phishing attacks (MITM against the HTTP connection that redirects to a replicated WI site) the Internet Option setting "Websites in less privileged web content zone can navigate into this zone" should be disabled.

Where possible, we encourage customers to consider using the Kerberos or smart card support in XenApp which avoids the need to send passwords at all.

Q: Do you have any Knowledge Base articles to reference that might be of help?
A:  There is a collection of technotes for Web Interface which cover useful points, but my favorite reference is the Troubleshooter's Guide for Web Interface.

This whitepaper recently released by out guys in consulting covers the design considerations on how policies can impact your XenApp (Presentation Server) 4.5 environment...

---

There are numerous ways to apply a configuration or security setting onto a group of servers within a Citrix Presentation Server environment. Because policies are so unique, diverse and customizable, there is no single, correct method toward policy design. However, this document will give the key areas to consider when deciding on the appropriate approach to implementing a setting using a policy.  
This design consideration will look at the following types of policies and the comm on practices associated with them:

• Citrix Presentation Server policies: These policies are defined within the management console on Presentation Server and only apply to connections using the Citrix ICA protocol but not the Microsoft RDP protocol. Presentation Server policies also allow for the configuration of Presentation Server-specific options like Session Printers and Progressive Display. The power of these policies is that they have the ability to be filtered based on users, location and even the method for launching the published applications. Many of these filters are only available within Presentation Server.
  
  
• Active Directory Policies: These policies are configured within Active Directory. They are applied to organizational units (folders), domains, sites, etc. within the Active Directory structure. A single Active Director y policy can consist of a computer policy and a user policy. A computer policy consists of settings that affect the physical computer and impact all users logging onto the computer while a user policy affects the user and is applied on all systems the user logs on to. Local server policies and custom policies are types of Active Director y policies and are described as:
  
  
  • Local Server Policies and Settings: Local Server policies are similar to Active Directory policies, except they are managed on a server-by-server basis and configured locally on that specific server, where Active Directory policies are managed centrally and can impact hundreds or thousands of users or computers with a single application of a policy.
    
    
  • Custom Active Directory Policy Templates: Custom ADM templates, like the Citrix icaclient.adm template, are Active Directory or Local Server policies used to make configuration settings. They can be custom registry settings or simply standard policies re-organized as two examples. The concept of custom templates is supported, but depending on the author of the custom template, supportability by either Citrix or Microsoft might not be available. Organizations will have to verify the supportability of custom ADM templates. Also, any custom template used might already have settings configured, potentially causing issues with the environment. It is highly recommended to test custom policies in a test environment before implementing in production.

The following five areas are the basis f or the design decisions for an enterprise deployment of Presentation Server. These types of policies will be impacted by the following design areas:

• Policy Type
• Policy Integration
• Policy Filters
• Policy Prioritization
• Policy Precedence
  
  

Download it here

This whitepaper outlines the best practices for implementing SAP GUI 7.10 for Windows using Citrix XenApp 4.5