I have been working with Provisioning Services (PVS) for a while and one of the questions that keep coming up is around Provisioning Services High Availability (HA).

What is HA? Maintaining access to a service or resource is probably the best explanation for this type of functionality.

What does HA provide? Within the context of the Provisioning Services resource, we are referring to the target devices ability to maintain an active connection to a vDisk. This is different to redundancy, which I will cover in another topic. This ability manifests itself in the customers' expectation for the target device to maintain constant uptime. What we have seen in the latest release is instant availability (first error move to next PVS server providing vDisk) as opposed to failover if the system doesn't recover itself.

Types of HA: There are many ways of doing it, they all work, but which one is right for you? That depends. Let's take a look at the location of your vDisks.

Placing your vDisks Local on the Provisioning Server - "Distributed Store":

Using the local hard disk subsystem of the Provisioning Server to store the vDisks provides the easiest way of implementing vDisk High Availability without additional cost.
What should we consider with this solution?

• Although it is easy to implement and maintain vDisks need to be manually synchronized between the PVS Servers.
• I/O performance depends on the capabilities of the hard drive subsystem (usually equal to NAS).

What are the recommendations?  Network Interface Card (NIC) - Teaming should be used to increase the reliability and to I/O between PVS Servers and Target Devices. You can also add more PVS streaming servers and heavier reliance on load-balancing.

 

You might be thinking about the vDisk lock files. Would failover work properly redirecting the target device to another server without a vDisk access failure? Yes, vDisk locks should not be a problem. Let's say you are using the vDisk in Private Image mode, the lock file holds the information of the Target Device accessing it.  If it fails from Server 1 to Server 2, Server 2 should not have an associated lock file yet because no other vDisk has accessed it. It will then create a new one.  If it fails back over to Server 1 from Server 2, the lock file will have the Target Device information and re-connect it.  If you are using the vDisk in Standard Image mode the lock files should not prevent any read only access.

Now you might be concerned about the write cache. Server Side caching is not supported, unless the cache is re-directed to a share.  If cache is being stored on the Server's local drive and becomes unavailable after failover, the Target Device will eventually blue screen when it tries to access needed information on the cache file.

Elisabeth Teixeira.

Follow me on Twitter: http://twitter.com/lizteixeira

Microsoft, Intel & Citrix: Dynamics of Enterprise Virtualization

An interactive discussion led by Doug Brown

--------------------------------------------------------------------------------------

Attend this lively discussion with virtualization experts David Greschler, Iddo Kadim & Simon Crosby on the dynamics of enterprise virtualization. Register here.

Topics include:
• Virtualization in the enterprise & upcoming technologies
• Moving beyond consolidation & getting to Dynamic Datacenters
• Cloud computing & how does virtualization fit in
• Desktop Virtualization opportunities, barriers & adoption challenges

Date: Monday, June 22, 2009
Time: 1:00 PM Eastern; 10:00 AM Pacific

Don't miss this opportunity to hear perspectives on the current & future virtualization landscape and what this means for the enterprise.

Register here now.


Follow me on Twitter.

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

Citrix iForum Benelux 2009 is in Antwerp on June 9th and 10th. The Citrix Benelux team put together a little promo video for the event and posted it on YouTube.

---

---

You can register here. I hope to see you and the Citrix Angels there.

Follow me on Twitter.

Provisioning Services (PVS) solves many of the existing problems of datacenter and desktop administrators by reducing the number of unique images that need to be managed. Rather than dealing with application installs, conflicts, patches and errors on hundreds of different servers and/or desktops, they can deal with a single streamed golden image that remains pristine regardless of the changes made by users. 

However, even though this new approach solves many of the issues that have been plaguing IT administrators for years, a new concern comes up. In my role on the Consulting Solutions team, I've been asked the same question by clients and coworkers alike: "If I have a pristine, unchangeable image, how do I deal with antivirus updates and patching?"

The admin guide (page 109) gives detailed instructions on how to do exactly that. It goes, on a high level, something like this:

• Load a machine with a copy of the production vDisk in private mode
• Make your updates
• Shut it down and put it into standard mode
• Finally, increment the version number

It's simple, and the process is easy to do manually - if you only have to add updates to a single vDisk every once in a while, then there's no problem. However, Microsoft comes up with security updates on an almost weekly basis, and new anti-virus definitions come out nightly - most companies aren't comfortable leaving machines unprotected for extended periods of time, and IT administrators don't want to spend time doing a manual, repetitive task on a daily basis. Add in a few different vDisks for different workloads, and this can quickly grow into a time consuming process. How do we reduce the time-cost of keeping vDisks fully updated?

Enter Workflow Studio. Workflow Studio (WFS) is designed to reduce repetitive tasks into easy-to-manage workflows that can be run either on-demand or on a scheduled basis. Using Workflow Studio and PVS's built-in CLI, we're able to create a script that automates the entire process of updating vDisks, allowing for easy nightly or weekly scheduling with less chance for human error.

In order to be device/hypervisor agnostic, the script utilizes an always-on machine designated as an "update" machine, which allows PVS to use its own functionally to restart the machine when necessary. Updates can come in and automatically be implemented during the course of the day or week, and applications can be added or removed by any vDisk admin. Then, at the scheduled point or on a manual call, the script shuts down the server, makes a copy for future updates, and switches out the disks using the Auto-Update feature. After the next reboot, desktops will switch to the newest disk, no additional manual intervention required.

Additionally, the "update" machine can be given a "personality" that then executes scripts inside the image that aren't run on other machines - such as perhaps automatically copying files from a share, or enabling Microsoft's Auto-Update, or any number of other actions. Workflow Studio is a component of making the script function appropriately, and it has the added benefit of allowing role-based access to the Workflow, as well as built-in scheduling. However, if Workflow Studio cannot be deployed, then the components of the script can be broken apart and used solely with Windows Scheduler.

Grab the script at the Citrix Developer Network. If you have questions, comments, or ideas for improvement, leave me a comment or ping me on Twitter @mcbogo.

Best,
Michael Bogobowicz
Senior Consultant @ Citrix Consulting Solutions

Twitter is obviously growing rapidily in popularity. According to a recent TechCrunch article, "Twitter's global unique visitors in April, 2009 was a whopping 32 million, up from 19 million in March, 2009". Many different groups within Citrix have begun to embrace Twitter. I use Twitter quite a bit, and have found several different Citrix Twitter accounts that I follow. Below are several recent Twitter accounts started by different departments within Citrix -

@citrixsupport - Mike Stringer, a Senior Director in Technical Support, created this account to provide updates from Citrix Technical Support.

@citrixreadiness - David McGeough from our Dublin office has been very active recently on this account.

@xenappjunkie - Vinny Sosa just started this Twitter account about XenApp.

@xdsupport - XenDesktop support. I have not yet found out who owns this account.

@citrixpartners - This twitter account is specifically for info related to Citrix partners.

@nssupport - Julio Rodriguez recently started this NetScaler related account.

@citrixblogs - This is an automated rss feed account that posts links to every new group blog post on the Citrix Community blogs.

@citrixonline - This account is dedicated to info on GoToMyPC, GoToMeeting, GoToWebinar, and GoView from Citrix Online.

@go_view - This account by Brenda Dentinger focuses on the new GoView product from Citrix Online.

@ctxs - This account is an rss feed of Citrix press releases.

@xenserverarmy - This account posts info specific to XenServer and Essentials for XenServer.

@citrix_synergy - This account posted live updates from Citrix Synergy.
There are several other new accounts that have no or few updates yet.

@xasupport

@xssupport

@citrixeducation

You can also follow me on Twitter, and other Citrix employees such as Chris Fleck, Tedd Fox, Matt Lesak, Lauren Whalen, Rich Crusco, Vishal Generiwala, Dan Feller, and Pete Downing.

If there are other Citrix accounts or Citrix employees you follow on Twitter, please post them in the comments.

Let me setup the scenario for you. You've been using a golden image vDisk assigned to several target devices for a while and everything is working without issues. Sooner or later, the time comes when you have to update your hardware drivers on the golden image vDisk.

No problem, right?

You simply boot up your master target device that you used to capture the golden image, apply the updates, take a snapshot of the disk to your golden image vDisk, and all is well.

This would be true expect for one issue. What if the master target device you used was no longer available along with the disk that you took the snapshot from?

Why not have make copy of the vDisk, change the vDisk image mode to private, assign it to a new master target device, and apply your updates? Well, if you're like me and use virtual hardware, then the update will include network drivers. If you update your network drivers while attached to any vDisk, you will disconnect your network connection which in turn disconnects your vDisk. I'll be the first to admit, I've done this before and quickly realized the error of my ways

So what do you do? Fortunately there is a way to recover and it's an easy one.

1. Create a guest VM on your hypervisor using a template that contains the same operating system as your golden image vDisk. This will insure the disk is already formated, for example, to NTFS. You will also want to make sure the disk is the same size or larger then your golden image vDisk
2. Change the primary boot device on the guest VM to boot from the network card
3. Add the guest VM as a target device within the Provision Server console
4. Assign the golden image vDisk to the target device and set the boot order to vDisk
5. Once the guest VM is booted, double check that your primary disk is your vDisk and the secondary is your disk assigned within the guest VM
6. Run the Provisioning Server Image Builder to create a snapshot of the vDisk. Make sure your Source drive is your golden image vDisk and your Destination drive is your formatted guest VM disk
7. Once the snapshot completes, you now have an exact copy of the golden image vDisk on your guest VM disk
8. Within the Provision Server console, change the boot order of your guest VM to Hard disk, and reboot it
9. When the guest VM comes up, it should be booting from the snapshot of the golden vDisk.

Congratulations, you've just officially recovered your golden image vDisk to a local disk. You're now free to update when needed without issue.

Let me know if you have any questions. Just post a comment and I'll reply back.

Kind Regards,
Matt

---

Citrix XenDesktop is a finalist in the Virtualization category for the "Best of TechEd" award from Windows ITPro magazine.

If you are attending TechED 2009 in Los Angeles, please vote for XenDesktop as the "Best of TechED" at this link -

http://windowsitpro.com/awards/teched_finalists_2009.html

(you must be logged into to MSTechEd.com and attending the event to vote).

Follow the Twitter feed for "Best of TechEd 2009" here.

Follow the official TechEd 2009 Twitter feed here

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

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:

1. Anyone who is trying to design a Provisioning Services for XenApp environment
2. Anyone who has heard of Provisioning Services and thought it sounded intriguing
3. Anyone who has a XenApp environment and wants to makes management easier
4. 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

---

StorageLink is one of the components of the new Citrix Essentials for Hyper-V product that was just released last week.

I recently recorded a technical deep dive presentation and demo with Pete Benoit, the Senior Director of Engineering for StorageLink. You can watch the hour long presentation and demo below -

---

---

You can download the StorageLink Install Guide here. The StorageLink User guide is here and you can download the Powershell guide here.

UPDATE: I added the Deep Dive webinar video to my SkyDrive on Windows Live. You can download it here

Follow me on Twitter.

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

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

Streaming a Full OS to a ThinClient ... Step by Step

Provisioning Server(PVS) has been a amazing addition to the citrix "Dynamic Delivery Center" line up.  It is a game changing technology that has a wide range of use cases.

So for those of you not familiar with PVS .... The brief of it is.  We virtualize the Disk IO allowing you to host a full OS image in your data center and stream simultaneously to thousands of diskless Endpoints. (PCs, Servers, Thin clients, Virtual or physical) windows or linux

This is not another Altiris, SMS, or Ghost imaging solution. We do not stream the full image down to the endpoint we only send the blocks of information that the client requests into memory when they request them.

Common Use Cases-

1.  PCs .. Distribute processing power out to the edge but still manage centrally with one image.

2.  VDI .. Reduce storage 90%, dramatically reduce application and single image management.

3.  Datacenter.. Web and Application Server Farms- One Image, Consistency, flexible and dynamic.

4.  Thin Clients - Stream full OS to Thin Client- One image, no protocol limitations, central management.

So in this blog I want to address the specific use of streaming a full XP OS image to a Thin Client. There is usually a lot of confusion around this use case so hopefully we can clear it up some.

1.       First thing we need to do is make sure the Thin Client we are going to stream to has the following. In the examples you will see the Wyse V90L and HP 57xx Platforms.

           a.       Hardware capacity to run the OS and application locally on device.  CPU 800mhz+, 256mb+

           b.      Verify it has a standard IDE or EIDE interface that we can connect a hard drive to or if the

                   thinclient vendor has a Flash option that gives you at least 4GB of space that will work also.

           c.       Make sure you have the XP drivers for the hardware platform or if streaming linux

                     have the linux hardware drivers.

           d.      I am going to be using a Wyse V90 and a HP 5730 but as long as your TC can meet the above

                   requirements you should be able create a image successfully.

List of Required items:

    -Laptop eide harddrive

    -Eide hdd ribbon cable

    -If using a 80 pin ide HHD you will most likely need a converter to 40 pin eide as seen here. I would use a 40 laptop drive if the TC has a 40pin IDE interface to avoid having to use a converter.                                                                

       -Small Phillips screw driver

       -External usb cd/dvd drive

       -PVS 4.5/5.0 sp2 server running

Note *Microsoft XPe can be used but since every xpe image is custom for each manufacture you are never sure what you are going to get.  Sometime you can just install the pvs client and run image builder and it works fine but if it is missing some core components you will be scratching your head wondering why things are not working.   

2.       Open up TC and identify IDE slot and remove eide flash card if one exists.

 

 

3. Connect EIDE hard drive  
       
 

4.       Connect the USB DVD/CD Drive to use to install OS

5.        Insert XP CD, boot from CD and install the OS, add hardware drivers for platform.

  You will need to get these from your TC vendor. If they have a xpe version of the hardware you should  be able to copy them over from the xpe image.

6.        Install PVS client software into the image

7.       Add MAC address and Hostname of TC into the pvs console 

 

     8.       Right Click on client and choose properties> Set client to boot from HDD  

9.       Right Click on Vdisk Pool >Create vDisk  for our VHD image

10.    Right Click on Client >Properties>Vdisk Tab > Add  the vdisk we just created in step 9

 11.   PXE or ISO boot thin client and run image builder to start creating image.

  12.   You now should have a xp vdisk for you thin client. You can set the Vdisk to standard mode which enables you to stream this one vdisk to thousands of thinclients.  So not much different from doing this with a PC or a Server but just make sure you have requirements in step 1 covered and you should be fine.   

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

VDI Expert Series: Microsoft and Citrix - Exploring VDI's Myths, Limitations and Benefits

If you're considering Desktop Virtualization or Virtual Desktop Infrastructure (VDI), join Microsoft and Citrix to discover how to minimize the cost of a VDI implementation with the most comprehensive solution.

Hear about:
•Top 5 VDI Myths
•XenDesktop Technical Differentiators & Testing Metrics
•Minimizing the cost associated with a VDI implementation
•Enhanced security
•Increased business agility

Register for the Exploring VDI's Myths, Limitations and Benefits Webinar 

Webinar Speakers

---

Scott Woodgate
Director of Windows Business Group
Microsoft Corporation

Scott Woodgate is the Director at Microsoft® in the Windows® Business group. He owns the enterprise version of Windows Vista® and Windows 7, Software Assurance Business, and Windows virtualization strategy including new ways to deploy windows on a variety of form factors such as laptops, desktops, and thin clients. Scott created the Vista Enterprise Centralized Desktop (VECD) license for the virtual desktop infrastructure space. He was involved in the creation of the desktop optimization product and in particular the acquisition of Kidaro (MED-V) and SoftGrid (App-V).

Scott has eight years of experience at Microsoft across both enterprise servers and clients. Before joining Microsoft, Scott was project manager in New Zealand building projects for enterprise customers. Scott holds 5 degrees including a PHD in chemistry.

---

Sumit Dhawan
Vice President, Product Marketing
Citrix Systems, Inc.

Sumit Dhawan is responsible for leading the go-to-market strategy for the Citrix desktop virtualization product line including evangelizing and developing the rapidly emerging application and desktop virtualization markets.

Prior to his current role, Dhawan was director of product management for the company's flagship product, Citrix XenApp™ (the new name for Citrix Presentation Server®), and led the growth of this product line to generate $1 billion in revenue in 2007. Since joining Citrix in 1998, he has held product management, product development and product marketing leadership positions for a variety of product lines and markets.

Dhawan holds degrees in both business and science, with a master's degree in business administration from the University of Florida and a master's degree in computer science from the University of Minnesota. Dhawan graduated with a bachelor's degree in computer science from the Indian Institute of Technology.

---

Exploring VDI's Myths, Limitations and Benefits Webinar 

Learn more about Microsoft VDI

Learn More about Citrix XenDesktop

 Keith McLaughlin, Escalation Engineer
 
Keith McLaughlin is a Provisioning Server expert on the Citrix Technical Support Escalation team, joining the team when Citrix acquired Ardence about two years ago. Keith filled us in on the two sessions that he'll present at Citrix TechEdge during Citrix Summit and Synergy 2009: End-to-end virtualization with Citrix Delivery Center, with a focus on Active Directory integration with Provisioning Server, and then his in-depth session will be on Planning and implementing a Provisioning Server high availability (HA) solution.

Q. How has Provisioning Server improved from a support perspective over the past year?
Keith: The biggest improvement this year is the addition of the Streaming Service Logs.  These logs, which came out as part of 5.0 SP1 are extremely helpful in narrowing down the issue.

 Q. What Provisioning Server and Citrix Delivery Center tips will attendees learn at your session this year?
Keith: This year's session is focused on High Availability. In the session we are going to go over troubleshooting procedures and explain in depth what happens when a Target Device fails over and how to track that failover through the logs files. For the Citrix Delivery Center session, I'll focus on Active Directory integration with Provisioning Server Standard Image.

Q: What Provisioning Server Tech Tip can you give people now?

Keith: When planning your Provisioning Server deployment, give the Target Devices unique names in the Provisioning Server Console. Do not use the hostname of the machine that is being imaged as the name of the Target Device. This avoids conflicts when booting the Target Device from the Vdisk.

Q. What new tools or techniques are you using to troubleshoot Provisioning Server?

Keith: A year of working with the 5.0 is probably the biggest factor.  5.0 had many improvements over the previous version and many architecture changes.  Also seeing where customers and end users were running into problems and being able to identify the symptoms because of past experiences greatly cuts down on troubleshooting time.

 Q. What types of cases have you worked on this past year? Why?

Keith: As part of the Provisioning Server Escalation group, I have covered a lot of different issues ranging from Active Directory integration to tracking down possible bottlenecks on customers networks that could be causing timeouts on the provisioning server.

 About Keith McLaughlin

Keith's been with Citrix Technical Support for two years.  He holds certifications in Citrix Certified Administrator, CCA, for Provisioning Server and XenServer. During his free time Keith loves playing the guitar, and his favorite artist is Stevie Ray Vaughan.

  

Do you have a Provisioning Server troubleshooting area that you would like Keith to focus on during his presentation? Leave a comment.

 Want to learn more about TechEdge 2009, www.citrix.com/techedge. Stay tuned for our weekly close-up interviews on the TechEdge presenters.

Posts in this series:

• Citrix TechEdge - Troubleshooting Tips and Tricks

• Interview 1: Close-up with Jamie Baker

• Interview 2: Close-up with Keith McLaughlin  

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