Post to Twitter
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:
- 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.
- When you need to make an update, copy the vDisk from your library to your test environment Provisioning Services server.
- 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.
- 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:
- You make a copy of the previous vDisk image from your library to the Production Provisioning Services server.
- You increment the revision number on the old vDisk image to a number that is higher than the updated vDisk image.
- You implement the auto-update feature of Provisioning Services
- 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
I recommend having a separate Development machine and Test machine for working with the SDK. I have mine set up as follows:
- Development machine - contains Visual Studio 2008, Workflow Studio 1.0, and the Workflow Studio 1.0 SDK (C# templates).
- Test machine - just has Workflow Studio 1.0 on it for testing activities created on the development machine. Having a separate box for testing allows you to be sure that your activity works on a non-development machine.
One thing you may notice is that I have the full Workflow Studio 1.0 product on my development machine as well. The benefit of placing Workflow Studio on the development machine is that it allows you to step through your code in Visual Studio by attaching to the key Workflow Studio processes. I'll go into more detail on that later in this blog series. Technically you can get by without installing Workflow Studio on your dev machine by copying over 5 key DLLs from another Workflow Studio installation. The Activity Developers Guide provides details on how to locate and copy these DLLs if you wanted a more minimal installation.
1 - My initial development machine layout:
When I started building my Dev machine I had a barebones Windows Server 2003 installation:
- Windows Server 2003 SP1
- IIS with ASP/ASP.NET enabled
2 - Install the prereqs for Visual Studio 2008 and Workflow Studio 1.0:
Next, I installed the prereqs for Workflow Studio and Visual Studio listed below.
3 - Install Visual Studio 2008
Third, I installed the Visual Studio product.
- During installation, select at least the C# language since the WFS Activity templates are based on C#. You can choose other languages as well if you want to use this machine for other purposes later on.
- After installation, launch Visual Studio and select the C# development layout on the first time use screen. I've tried both the VB IDE layout and C# IDE layout and the C# layout makes it a lot easier to set up the "stepping through code" settings for later on.
4 - Install Workflow Studio 1.0
Fourth, I installed Workflow Studio 1.0.
- During installation, point to your SQL Database installation (mine was local SQLEXPRESS). When configuring the Runtime Service, I added one service that is tied to my local admin account.
- After installation, launch Workflow Studio and ensure you can access the Workflow Studio Console
5 - Install Workflow Studio 1.0 SDK
Finally, I installed the Workflow Studio SDK. This installation adds 4 templates to Visual Studio (2 project templates and 2 class templates)
- During installation, take all of the defaults.
- After installation, launch Visual Studio and verify that these templates are present. Essentially, try to create a new C# project and the Workflow Studio project templates should be listed there.
After completing the final step, you're all set to start writing custom activities. If this is your first time developing an activity I definitely recommend checking out the Activity Developers Guide that explains how to create a few sample activity projects.
Blogs in this series:
- Getting Started
- Setting up your Visual Studio development environment (this one)
- Anatomy of a Workflow Studio activity project
- Testing your Workflow Studio activity project
- Stepping through your Visual Studio code
I've been using the Workflow Studio SDK for about a month and just wanted to share with everyone some things I've learned along the way. I figured a good approach to get the word out to our partners, customers, and Consulting teams about how to use the Workflow Studio SDK was to try a blogging series. Over the course of the next few weeks I'll blog about some of the fundamentals of using the Workflow Studio SDK. This is part 1 of the series in answering some of the beginning questions.
What is the Workflow Studio SDK?
The Workflow Studio SDK is a series of C# templates for Visual Studio 2008 that allows you to create activities for Workflow Studio. There are two types of activities you can create using the templates:
- Powershell Activity - this is an activity based on a Powershell command. When you choose this activity type within Visual Studio, the Powershell Converter opens where you select the Powershell command you want to transform into an activity. The Powershell Converter then creates the activity code based on the Powershell command(s) that were selected. You can then further modify this code to customize as you see fit.
- Standard Activity - this is an activity used for standard actions not based on Powershell commands. Essentially, you will create a standard activity if you are not creating an activity based on a Powershell command. The code you get looks about 95% the same with a few differences.
What skills do I need to use the Workflow Studio SDK?
From a programming side I would say you need a basic background in using Visual Studio and C#. The templates are only available in C#, so if you are a VB or VB.NET programmer you'll have to walk on the other side of the fence here.
My personal coding experience mainly comes from web development (HTML, JavaScript, ASP, etc.) several years back. I'm not an extensive coder but I do understand the object-oriented programming principles. Using the SDK was my first time to extensively use C# and if you understand coding principles and object-oriented programming, it's really a matter of learning the new syntax. For example, for me I found myself asking things like "I know how to create properties in VB, how do I do this in C#?"
In addition to the recommendations above, I would definitely recommend playing with the Workflow Studio product before you start using the SDK (that's probably a given 
). You'll want to understand how activities tie to each other through binding, as you'll be creating "bindable" properties in your code.
Using the SDK might sound pretty complex at the beginning, but the templates you are given have so many comments that they really guide you through the process as well.
Where can I find the Workflow Studio SDK?
The SDK can be found on the Citrix Developer Network site (http://community.citrix.com/cdn/wf/sdks).
Is there a Developer's Guide for getting started with the SDK?
Yes, a great guide is available on the Citrix Developer Network site (http://community.citrix.com/cdn/wf/sdks). If you are new to using the SDK this guide is a must for getting started. You should come here first before venturing out on your own. This guide will walk you through creating two sample activities:
- "GetDate" Powershell activity - creates an activity based on the "Get-Date" powershell command. This activity returns the current date/time of the system.
- "AdvancedDelay" Standard activity - creates an activity that allows you to specify a time delay for your workflow. For example, in Workflow Studio if you want the runtime to pause a certain length of time before continuing with executing the rest of the workflow, you can add the AdvancedDelay activity to pause a certain amount of time.
Upcoming blogs in this series:
As many of you who follow my blog postings will realize, I love talking about Provisioning Services
- Provisioning Services Best Practices (6, 5, 4, 3, 2, 1, plus more to come)
- Quickly deliver XenApp Servers with Provisioning Services
- Use Provisioning Services to Create XenApp Swing Servers
I've spent a significant amount of time discussing best practices for integrating XenApp and Provisioning Services and thanks to many of you and your questions, I've been able to create and define new best practices; all of which will make it easier for you two simplify you XenApp environments.
If you are still wanting more information on the Provisioning Services for XenApp, then I highly recommend you attend this recently released TechTalk. For those of you who have attended my TechTalks before, my goal is to explain the how's, the why's and the when's for creating a solution of your own. This TechTalk is no different as I go through the following topics
- How Provisioning Services overcomes many of the ongoing challenges associated with XenApp environments
- How to create and deliver a set of XenApp servers with Provisioning Services
- How to design a Provisioning Services solution while following recommended best practices
Who do I recommend that should watch and listen to the TechTalk? Well, the following is a good idea:
- Anyone who is trying to design a Provisioning Services for XenApp environment
- Anyone who has heard of Provisioning Services and thought it sounded intriguing
- Anyone who has a XenApp environment and wants to makes management easier
- Anyone who knows already knows a lot about Provisioning Services. You might learn something new, or you might be able to provide me with some of your thoughts/insights.
After watching the TechTalk, feel free to post a question or comment on this blog as I'm always interested in hearing your thoughts, suggestions and recommendations.
BTW, you can reach me on Twitter at http://www.twitter.com/djfeller or on the blog site http://community.citrix.com/blogs/citrite/danielf
So, set aside 60 minutes, grab some food, go to this TechTalk link, sit back, relax and enjoy.
Daniel - Sr. Architect (Worldwide Consulting Solutions)
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
Securing Web Applications with an Application Firewall
I have been working with Application Firewalls for quite a few years - many times to protect web applications published in languages and character sets that I didn't understand. Frequently, I have seen these Application Firewall deployment projects get bogged down in pursuit of the perfect policy set.
I have also seen many situations in which this process and application changes actually break these applications.
The NetScaler Application Firewall deployment can also be subject to these issues since the appliance provides extensive application firewall features. Even with the learning capabilities, creating the ideal set of security policies for any application can be a trial and error process that can take significant time.
In this blog, I would like to share an implementation methodology that shortens the deployment, and helps avoid breaking the applications to be protected. Experience has shown that approaching the configuration of the Application Firewall in stages is the key to timely success. This methodology is effective for all types of applications and their needs.
To alleviate the time and risk of varying degrees of policy complexity, break the task into stages. That is, separate the policy configuration into groups of ascending risk. While some may raise the point that a simplified protection policy set is not complete, it must be remembered that protection stages will build upon each other, and will be better than allowing unfiltered access while all policies are in learning or logging/warning mode.
The benefit of staging is that a basic set of policies are made operational. Then, the following stages will consist of conducting a repeatable process of "policy tightening" procedures as required by the application.
Stage I
When configuring the NetScaler Application firewall policies, start with some of the basic protections. Activating the simple, generic policies almost never produce false positives. These typically include: 
- Protect against Cross Site Scripting (XSS) attacks
- Protect against SQL Injection attacks
- Protect against Buffer Overflow attacks
- Prevent Credit Card Leakage
- Prevent access to system files
- Alter the contents of the server headers
Activating these policies will typically not break applications. As such, a small user community - with etc/hosts overrides - can be used to validate the configuration over a fairly brief validation period.
More importantly, this is a great start. These policies create security effectiveness that can typically be rated as a level seven on scale of zero though nine (you can never get to a perfect "10" in security).
Stage II
The next stage will include applying policies that require more application validation to determine the application specific relaxation adjustments ("policy overrides").
But first, don't forget to ask yourself if this application actually requires tightened policies.
If so, Stage II protections should be sequenced - Cookie Tampering prevention should be blocked first. Then, move on to blocking tampering with the values of parameter and/or hidden form fields.
Start with cookie poisoning prevention ("Cookie Consistency"). It will be likely require the least number of relaxations. This will build on the Stage I successes most rapidly.
To do this, use the learning process to identify the cookies that are legitimately altered between the response and request process. Minimally, relaxations will be required for cookies that are set and modified by third party monitoring services. Again, because of the staging, this learning can happen while the basic policies are in place and actively applying their protection mechanisms.
If further tightening is required, focus on creating policies that prevent users from tampering with the values of parameter and hidden form fields. This is achieved by activating "Field Consistency" learning in the NetScaler application firewall. Depending on the architecture of the application or a frequent use of client side scripting, these policies carry a higher risk of blocking legitimate requests. These policies thus require a more extensive learning period and associated relaxation overrides.
It should also be noted that these Stage II policies and their relaxations do have a tendency to be susceptible to producing false positives as applications change, and should be re-evaluated in conjunction with major application changes.
Stage III and Beyond
If the application is contains super sensitive information, and undergoes frequent changes, further security configuration may be required.
Stage III typically involves enforcing field formats and enforcing user navigation paths. Adding restrictions to field input types, such as date formats, and more, will require further time for learning these application attributes. Be aware that these policies will also be more likely to be sensitive to application changes.
Enabling the "Start URL" facility allows users to access only the specifically stated URL types. Due to the flexibility inherent in application architectures, however, these restrictions may require modification to include additional request types present in a particular application.
Lastly, carefully consider activating "URL Closure" to control 
the flow of access by users. Enforcement of this policy set disallows users from navigating to locations not previously offered by an application response. These policies may require significant application validation if client side scripts modify URLs, or if FLASH objects contain links.
The above policies tend to bend the needle towards the nine level and will be more likely to cause false positives during policy refinement or when the application changes. Leaving these to Stage III, however, allows continued protection afforded by the policies of Level I and Level II during the refinement, however.
Summary
Personally, when I plan my application firewall deployments, I always attack 
the assignment in the phases outlined above. I focus on the quick return policies first. Then I take time to consider if the sensitivities of the specific application even warrant the extra effort of going all the way to Stage III. This last question can produce some interesting answers that pit my application security ideals against the practicalities driven by the depth of my current to-do list.
And then, of course, this staged approach may be completely ignored in situations in which a specific application just suffered from an attack through a specific Level III vulnerability. Such situations may warrant overriding the staged approach and focusing on addressing the impacted vulnerability immediately.
Also, don't forget to sign on to MyCitrix and download the Application Hacking Kit and actually try some of the most common application attacks on the BadStore application!
How many of you have worked with or started designing a XenDesktop solution? Chances are you have tons of questions about the best way to design the environment for growth, scalability and stability. I know this because I, like so many others, are asked the same questions. For example
- Should I install or stream applications into the virtual desktop?
- Where should the Provisioning Services write cache go?
- How should I design my Web Interface implementation to provide seamless integration without causing confusion for my users?
- How do I provide better availability to the TFTP server used to deliver the Provisioning Services bootstrap file?
Thomas Berger and I started gathering these questions to build the XenDesktop Design Handbook. The current release of the Handbook is focused on Operating System, Application and Virtual Desktop delivery design decisions, but this is only a start. Over the coming months, we will continue expanding into different design decision areas commonly discussed in a XenDesktop solution including: virtualization infrastructure and implementation practices. We will discuss the Citrix Consulting Best Practices about these topics and encourage you to submit your related questions . Thanks and we look forward to hearing from you
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 |
|
|
| Concerns |
|
|
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
We are moving down the best practices road and now we come up to Active Directory. This, of course, is just a recommendation as I know everyone's AD structure will be different. But let's start out with a long-standing best practice... XenApp servers have warranted their own organizational unit within Active Directory for organizational and policy enforcement purposes. The recommendation has also included breaking out specific XenApp roles or locations into their own OU. Each identical group of servers would have the same policies applied. Typically, this creates an Active Directory structure like the following:
With the inclusion of Provisioning Services into the XenApp architecture, this recommendation does not change. In fact, this best practice becomes even more important because there will probably be special policy settings specifically for provisioned servers. Depending on how Provisioning Services is integrated with XenApp will help to determine if new OUs are required.
- If the OU contains a set of XenApp servers all provisioned with the same vDisk, then any Provisioning Services related policies can be applied to the entire OU.
- If the OU contains provisioned and non-provisioned XenApp servers, all hosting the same applications, then a new OU should be created that contains only the provisioned XenApp servers.
- If the OU contains provisioned and non-provisioned XenApp servers hosting different applications, then multiple OUs should be created containing only identical servers.
With Provisioning Services, the XenApp OU structure might resemble something like the following:
Each OU contains:
- Similar servers: Applications, infrastructure components, XenApp components
- Similar delivery processes: Provisioned or not provisioned
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 - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
Many of you tuned into the TechTalk webinar over a month ago when I spoke about how to integrate applications into a virtual desktop. If you didn't attend the live event, you can still listen in to the recorded version of it. It sounds like an easy topic, right? "Just install them stupid!" Of course that approach does work, but is it the best approach? Many of us are long-time XenApp people. We see the value with virtualizing applications in XenApp. We've already spent lots of time, money and sanity to get our XenApp environments tricked out so it is running smooth. So I'm here to tell you, leverage it. Just because you are going to do a virtual desktop solution does NOT mean you have to throw away your XenApp environment. That is just crazy.
Before you start on the XenDesktop build out, take a look at the just released Reference Architecture. You can share and streamline your XenDesktop environment by using and sharing your XenApp environment. Some of the XenDesktop components can be shared with XenApp components. Which ones? How about the license server, data store or Web Interface?
Also, the integration must be streamlined. You don't want to make your users jump through 20 hoops before they get to their applications. They will be tired and hate the solution, resulting in your project failing. Make it look like the following diagram... Simplified user perspective
The user authenticates once, and they get a standard desktop image that is personalized with their unique set of applications, automatically.
Next, which apps go where? This is a big question. Do I let my XenDesktop users simply connect to hosted XenApp applications? If that is your objective, then why are you using XenDesktop? Truth be told, some applications work better on a desktop OS. But these applications can still be delivered via XenApp. Focus on application categories of Base, Anomalous, Resource Intensive and Technically Challenging. These categories will guide you to the best solution.
Click for larger image
Interested in building the XenDesktop/XenApp solution? Then grab the Implementation Guide. Step-by-step instructions (with pictures) that shows you how to leverage your XenApp environment for XenDesktop. If you are really good and just need a high-level guide, then grab the Getting Started Guide
The important thing to remember is don't throw away your past successes to build something new. Leverage your past success to make your future success easier.
Daniel - Sr. Architect
Follow me on Twitter: http://www.twitter.com/djfeller
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 |
|
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:
|
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