Do you use XenApp? Thinking about it? Heard of it?  Want to make it better?  Are you alive?   If you answered Yes to any of those questions, then I highly encourage you to attend the XenApp Deep-Dive TechTalk series.  Each TechTalk focuses on one aspect of making your XenApp environments easier, better and more available.

Part 1: Simplifying the Migration to XenApp 5 with XenServer (Register)

The first TechTalk on February 2nd at 1PM Eastern Time is focused on a task I did not like doing when I was an XenApp admin (although it was called MetaFrame back then)... XenApp Migrations.  Each release of XenApp has some pretty cool features to help make the users more productive or make the environment easier to manage and XenApp 5 is no exception.  So the big question is why aren't you migrating?  Is it because it takes too much time? Is it because it is too difficult?  A few months ago I blogged about the possibility of simplifying XenApp migrations with the use of XenServer (here and here).  This TechTalk will tell you if it is indeed possible.    Who knows, I might speak for 1 minute and say it doesn't help at all, but I highly doubt that will happen .  If you want to find out if XenServer helps and how, you will just have to tune into the upcoming TechTalk to find out

Part 2: Simplifying Desktop Delivery with XenApp (Register)

A lot of talk lately is virtual desktop this and virtual desktop that.  Well, this TechTalk is also focused on the virtual desktop, but not in a way you would expect. Most people talk about virtual desktops as a new way of managing the desktop infrastructure and how XenDesktop is the best solution.  This TechTalk, on February 3rd at 1PM Eastern Time is focused on the XenApp portion of desktop delivery.  How can and should we use XenApp to make the virtual desktop solution easier?  What best practices are there for application delivery and integration into XenDesktop? Tune in to find out.

Part 3: High Availability for XenApp with XenServer and NetScaler (Register)

Is your XenApp environment delivering mission-critical applications?  What happens if a physical server fails, or a hard drive crashes, or a internet link dies or an entire data center goes offline?  As we all know, XenApp contains many different components and each one is critical to the proper operation of the environment.  This TechTalk, on February 4th at 1PM Eastern Time, will provide some of the best practices for providing fault tolerance and high-availability to XenApp environments.  Don't leave your XenApp users in the dark if the lights go out.

I'm sure everyone will learn something or at least come away with a new perspective or idea on how to use and improve their XenApp environments.  I know I'm looking forward to getting some of your comments on your environments and how they can be made better.  Hope to see many people there.

Daniel

Welcome to the new year and my first blog of 2009.  Let's kick off '09 with a focus on simplification.

Let's focus on a topic that often brings chills to a XenApp administrators spine... upgrades.  Back in the day when I was a MetaFrame administrator, I remember the time, patience, and sometimes stress involved with trying to upgrade 100 servers to the latest version of MetaFrame.  Well, a lot has changed in the world of application delivery. MetaFrame went through numerous identity changes to become XenApp. With those new identities we have witnessed a maturing of the product to include more functions, features and abilities to deliver troublesome applications.  But one thing has remained fairly constant, XenApp upgrades are not as easy as flipping a switch. 

Take, for example, the following knowledge base article from one of my coworkers, Jo Harder.  Jo created a great article explaining the technical concepts for upgrading and migrating XenApp 4.5 to XenApp 5. It covers the process, what to do and which approach to take.  This document has only been out for 4 months and has been the most read article for each of the past 4 months.  By my estimation, the topic of XenApp migrations is very important to people. 

Back in September 2008 I blogged about a potential way to simplify the migration process by integrating XenServer with XenApp.  In this blog I identified 5 areas where I thought this tight integration could show benefit and I called this the HOMER Criteria.  Well, after more investigation, analysis, testing and validation, I'm here to let you know that we can indeed simplify XenApp migrations if we integrate XenServer and Provisioning Server into our architecture. 

How is that possible?  Most people have a standard practice for incorporating new XenApp versions into their environment. This process typically takes on the following sections:# Server validation: We have to make sure that our applications work with the new version

1. Server builds: We have to spend time updating all of our server build images/scripts
2. Implementation: Need to update all servers while not impacting the user environment and not incurring huge hardware expenses
3. Maintenance: Need to keep our new servers consistent and updated with the latest hot fixes and service packs and updates
4. Rollback: In the potential event that the upgrade causes major issues, we need to make sure we have a fast way of recovering our old environment.
   

These are each critical to a successful migration to the latest version of XenApp.  Each one of these areas can be improved through virtualization and workload provisioning and you can expect the following benefits: # Time Savings: The time spent building servers is removed due to Provisioning Server's integration with XenApp. Brand new servers can be brought online in less than 30 seconds.

1. Repeatability: The integrated process used to upgrade to XenApp 5 can also be used for future versions of XenApp, except that future upgrades will be faster as the infrastructure is already virtualized and the process is familiar.
2. Simplification: The process is able to ignore the complexity of different configurations and drivers, helping to reduce the time spent developing server builds and installation configurations.
3. Maintainability: The solution guarantees consistency within the XenApp farm. When an application update or an operating system patch is validated, the entire XenApp farm will utilize the new configuration.
   

Some of you might be intrigued and want to know how to do it.  Learn how by reading the following materials:

• Reference Architecture*:* Understand the architecture, the areas of concern and the potential benefits
• Getting Started Guide*:* Get a high-level overview of the integration process.  This guide gives an overview of each phase, whereas more detailed steps can be found in the implementation guide.
• Implementation Guide*:* This guide takes you through, step-by-step, on how to upgrade your XenApp environments to XenApp 5 on Windows 2008 through the use of XenServer and Provisioning Server.  As you follow these steps you will see how the three products integrated into a solid solution for application delivery.
• Design Considerations*:* Follow these considerations to make your virtual XenApp environment easier to setup, maintain and manage.

So remember, if you are not thrilled about doing a XenApp migration, then try a new approach... Virtual and Provision. 

Daniel

It's that time in the XenApp world again... Migration.  With the release of XenApp 5, many of you are contemplating a migration.  Why is migration such a big deal? I've heard numerous reasons like "It takes a long time to test my applications with the new XenApp (especially true if there is a new operating system involved)", "It takes a long time to rebuild my servers as I have to update my server build scripts" or "My current XenApp environment works fine, so why change it".

Those were all good points a few years ago.  But with the enhancements and optimizations made on XenServer for XenApp virtual machines, it is a great time to test server virtualization for XenApp to simplify migration.  And if we virtualize the XenApp servers, migration to XenApp 5, 6, 9, 11 or even XenApp 243 will be even easier (of course we will have changed the product name a few times. Let me hear a Hallelujah for HomerFrame or XenHomer).

But if we are going to migrate to XenApp 5, why not make the migration easier. Just how will XenServer make migration easier?  That is a great question, and I'm glad I asked it

Hardware
First, part of a new XenApp version means organizations will have to update their server builds.  Many of the server builds I've seen are complex scripts or require many manual changes once the build is complete.  Many times, there are multiple builds because of differences in the underlying hardware.  With XenServer , the links between the OS and the hardware are cut resulting in the ability to create a single build that can span multiple hardware variations.  How many fewer images will you now have to maintain?  Simplified

Optimization
With XenApp, you want to get the most users out of  your hardware.  This has been true with previous versions, is true with XenApp 5 and will be true in the future versions.  With a new OS and a new XenApp, do you have any idea how much hardware you need to support your users for the different application sets?  This is a challenge, especially when trying to design the new environment.  When you designate a server for a certain function, it is awfully hard to change the server's function, unless you virtualize.  With XenServer, you can make a virtual machine into anything you want.  You can move the running virtual machine to another physical server without the users ever knowing.  With XenServer and XenApp, you are no longer stuck in your static environment; instead, you are dynamically changing the environment based on the needs of the business. Simplified

Maintenance
How many of you like spending your days patching servers?  Not many.  Unfortunately, with each piece of software, there will undoubtedly be patches. With physical servers, you have to patch each server. With server virtualization, you still have to patch each virtual server.  But with XenServer Platinum, you only have to patch your base image, which is delivered to the virtual server via Provisioning Server.  If I have one XenApp image for SAP and another XenApp image for all of my other applications, I only have to patch both of those images.  Those images are then streamed to hundreds of physical or virtual servers.  Simplified

Evaluate
How could we do a migration without evaluating the apps and OS and XenApp configuration? This is critically important, especially if you are upgrading to a new OS like Windows Server 2008. With XenServer Platinum, the evaluation and testing phase is simplified.  How do you typically do this?  Well, you build the environment in a test lab.  You run test, modify, re-test. The cycle continues until a golden image is created.  That image must be used as a guide for rolling into production.  If you use scripts, you have to figure out how to script the build process to mimic your image.  If you use cloning solutions, you have to modify based on hardware.  If you use Provisioning Server, which is part of XenServer, you take your server, create a Provisioning Server image, and copy the image to production for delivery.  Simplified.   

Rollback
Let's say you upgraded without doing a proper test (shame on you).  As it turns out, one of the applications, which unlucky for you, is mission critical and is not working correctly.  What do you do?  Well, you have a few options:

• Try to troubleshoot and fix. You will be under the gun to get it fixed quickly as the business needs the application.
• Rebuild the physical server with the old setup. This will take a few hours for the build to complete and configure the applications.
  

Neither of those options sounds good to me.  Instead, if the environment was virtualized with XenServer Platinum, you would easily be able to change the version of XenApp delivered based on the Provisioning Server image you associated with each target device.  Simplified

XenServer for XenApp can simplify migrations by focusing on the areas of Hardware, Optimization, Maintenance, Evaluation and Rollback (This is what I like to call the HOMER Criteria).   It's a great way to get more done without working harder.  You get the migration done faster while providing a more dynamic environment for the business. 

Daniel

In my last post, I talked about our plans of moving XenApp farm settings, server settings and session policies into Group Policy Objects. This time, I want to describe our plans on a related topic: how to migrate XenApp 4.x farms into this new management model.
XenApp 4.5 Administrators have two options to migrate their farms: either upgrade the existing farm over time, running the farm in mixed-mode; or create a new farm and move users and applications over time. 
The mixed-farm approach seems to be the easier of the two, but it has an important drawback: the migration cannot be staged. The recommended first step is to upgrade the Zone Data Collectors, which in turn affects all users and applications in the farm. If anything wrong happens - which is usually detected once users start to login and use their applications - there is no way to rollback without creating a farm outage.
The new farm approach is safer, as it allows Administrators to perform an "in-production" validation, migrating users and applications to the new version over time. The old production farm is not touched, which allows quick rollback of users to the previous farm if anything wrong is detected.

However, creating a new farm from scratch is not realistic in many environments. The reasons:

• Farm configuration documents may not exist, or be out-dated.
• Not sufficient hardware to maintain both farms in parallel. Servers have to move from one farm to other over time.
• The migration is not transparent to end-users. If a single Web Interface is used, it will list applications as "Application (Old Farm)" and "Application (New Farm)". If a separated WI is used, then users must configure browser and PNA to use another URL.

We do not plan to support mixed-farm migrations when we move XenApp configuration to Group Policy. Instead, we will focus on the issues above, creating the necessary tools to facilitate the transfer of configurations, users and servers from farm to farm.
This is the plan:
The first step is to create a new farm, installing a new Data Collector and creating a new IMA database. Infrastructure servers (License, Database, Edgesight, etc) may be shared between the old and new farm. The next step is to launch the Migration Wizard and go through the following steps:

• The migration tool wizard will ask information about the old farm (address, authentication). You may chose to export all the old farm data into an XML file and modify it before importing the data in the next steps.
• The wizard will ask the new farm information. It will then convert session policies, farm and server settings into Group Policies, and automatically associate GPOs with the new farm Organizational Units.
• If the old farm contained multiple application silos, the wizard will ask for a server that represents the old farm silo, and create a Group Policy Object containing that server configuration. The wizard will then associate that GPO with the OU representing the Application Silo in the new farm configuration.
• You will be able to select a list of "in-production" test users. The new farm will only enumerate applications to users in that filter list, regardless of the Application object configuration.
• Add the new farm in your Web Interface sites. Web Interface will suppress enumeration of applications coming from multiple farms, based on configuration. This change will make the migration process completely transparent to end users.

At this point, you will have a fully configured, although empty new farm. Over time, you will:

• Add more users to the new farm filter
• Remove servers from the old farm
• Upgrade XenApp software in the server (or re-image)
• Assign the server to the new farm Organizational Unit.

This method is very flexible, you may stage the process based on application silos, zones, users, or any combination of these. The migration tools provided here are also very useful for other use-cases, such as replication of settings between test and production environments.

This plan is still on the drawing board, please feel free to comment and raise scenarios where you believe it wouldn't meet your needs. Note that this is planned for the next major release after project Delaware, therefore still a long way in the future.