What if you want to merge four separate XenApp 6.0 Farms into one and upgrade to 6.5 along the way? Just one of many challenges at work :-) This made me think about some of the possible migration and upgrade scenario’s out there. With Excalibur on the horizon and multiple ‘End of Life’ dates passed (can be found on the Citrix Product Matrix, give it a Google) I guess there won’t be many admins migrating their 4.5 / 5.0 Farms to 6.0. I mean, why would they? 6.0 isn’t that different from 6.5 and we all know an even newer version will be released shortly. I know… there are some distinct differences between the two and I can also think of several reasons on why not to migrate, but you get my point right?!
The idea is to give you an insight on what it takes to successfully migrate your Farm to a version of choice. I’ll address some of the migration scenarios possible, things to consider when planning, tools you can use and some general information that might be of interest like, End of Life, Citrix support and licensing. Some in more detail than others. I won’t go over each and every step that’s needed but I will try and point you in the right direction. As a side note, according to Citrix it isn’t possible to do an ‘in-place’ upgrade from older XenApp versions to 6.5. But there is one tool out there which does come pretty close as you will see shortly, if you are migrating from 6.0 that is.
EOL?
Stands for End of Life and is one of the phases a product goes through during its lifecycle, the last phase to be exact. Basically, when a product hits the EOL phase the support options get (very) limited. Security hotfixes and other product related downloads will no longer be available as well as direct technical support from Citrix. Historical information in the Knowledge Center or other (online) resources will still be available but are no longer updated. If you can’t resolve your issues using these resources then an upgrade path or migration to the latest version (product replacement) is recommended. So why not make the first move?
You can always decide to buy Extended support for your product if available. As per Citrix: Extended support for a Citrix product version is intended to align with Microsoft’s current Extended Support milestone for the corresponding server OS version. This should enable customers to plan their XenApp migration as part of the underlying OS migration planning. They do, and that’s a no brainer, cost you money and unless you have plenty you might want to reconsider spending it on your future upgrade that will eventually sneak up on you (in most cases anyway). Have a look at what Citrix has to offer: citrix.com/support/programs/software-support.html I already mentioned that a few EOL dates already passed, let me fill you in.
Support
As you can see PS / XenApp 4.5 and 5.0 for Windows Server 2003 are already EOL with about a year left on extended support. The thing is, I’m certain that there are still hundreds if not thousands of 4.5 and 5.0 Farms out there running Windows Server 2003 (32 bit mostly) and like I said, in many cases upgrades do eventually sneak up on you if you want to or not. There are companies out there that don’t need Citrix’s ‘normal’ or ‘extended’ support, they can handle themselves, nothing wrong with that. But in general most companies do need or want to be able to contact Citrix for support, and if you’re one of them then the above Product Matrix might come in handy. Let’s say you have an active 4.5 / 5.0 Farm based on Windows Server 2003 32 bit and you would like to be able to contact Citrix for support, according to the Matrix you have a couple of options:
- Keep using what you have now and perhaps buy additional or extended support
- Stay on XenApp 4.5 / 5.0 and migrate your systems over to Windows Server 2008
- Migrate your systems over to Windows Server 2008 R2 and install XenApp 6.0
- Again Migrate your systems over to Windows Server 2008 R2 and install XenApp 6.5
Let’s go over the options mentioned above and since it’s just for show-case purposes I’ll leave the technical details on how to migrate, what tools to use etc… out of it for now. Option one gives you some breathing space but not much, let’s consider this one a no-go. Option two might be ok, you’ll have another 6 to 7 years of extended support left and if you keep using the 32 bit OS version you won’t have to worry about any application compatibility issues just yet. You do however need to take into consideration some of the 2008 specific OS changes like, UAC, Windows Resource Protection, IE8 & 9 compatibility and security restrictions and a few more. Never the less, with the right business case a potential winner.
Options three and four are different. Both XenApp 6.0 and 6.5 require Windows Server 2008 R2 which only comes in 64 bit. When migrating from 32 to 64 bit you will eventually run into application compatibility issues, it’s a fact of life! But hey, what must be done, must be done, you can’t keep running 32 bit forever, could you? If you are already running XenApp 5.0 on 2008 64 bit or 2003 64 bit even (not that common) then migrating to 2008 R2 still has some challenges but you won’t have to worry about app compatibility. Bottom line, if you are upgrading / migrating from an earlier XenApp version skip 6.0 and go with 6.5. In practice this is most likely what will happen anyway.
Upgrade or Migrate according to Citrix
Just to be clear on what is what. In our case we will be applying option 1, 2 and 4. Since Citrix sates that it isn’t possible to do an ‘in-place’ upgrade to XenApp 6.5 from older XenApp versions this might seem confusing but don’t worry, everything will be explained in more detail as we progress.
- Server upgrade: Installing a newer version of XenApp over an existing one
- Server migration: New installation of XenApp on clean OS
- Farm upgrade: Existing Farm and Data Store is maintained
- Farm migration: Create a new Farm and Data Store
Although my first line was “What if you want to merge four separate XenApp 6.0 Farms into one and upgrade to 6.5 along the way?” I’ll discuss one to one upgrades and migrations instead of many to one. Depending on the XenApp versions used (many to one) the process and steps will be much alike with a few exceptions, it’s just a bit more complex and requires more planning. You will need to inventory all of the separate Farms involved including their resources and decide which path to follow. Perhaps one Farm is leading when it comes to policies, applications, Worker Groups etc… but you still need to incorporate the other Farm servers and applications as well, and what if you have two 4.5 / 5.0 32 bit based Farms and two 6.0 Farms that need to be merged into one 6.5 Farm? Sure, I have some thoughts on the matter… maybe next time :-)
Things to consider
When migrating it’s not just the XenApp, Web interface (EOL in 2015) improved with every new release and although still usable it will eventually be replaced by StoreFront, your License server needs to be checked (see ‘Licensing’ below as well), Single Sign-on, perhaps Provisioning Services is used and so on. And when migrating to XenApp 6.5 you will most likely run into some application compatibility issues when coming from an 32 bit platform, which might take some time to figure out.
We also might need to re-consider our client software, distribute Citrix Receiver and corresponding plug-ins, implement or upgrade Merchandising Server etc. Relax, this all sounds more complex than it really is. Fortunately Citrix has multiple Technical Guides describing every step needed to migrate your existing Farm and build a new one alongside. Believe it or not, there aren’t that many steps! Here’s the one you need for XenApp 6.5: support.citrix.com/article/CTX130888
Building a new Farm alongside your existing Farm has several advantages, for one you can redesign your policies, move them from IMA to AD for example, start from scratch. And since Excalibur won’t make use of IMA anymore… just saying :-) The setup itself is pretty straight forward it installs all the missing prerequisites, if any, and you can select all server roles and sub features you need, again, Web Interface, Licensing, Singe Sign-on but also Desktop Director or Profile Management and more. The Technical upgrade & migration guide outlines all the new and improved roles and features available, use it to plan accordingly or just Install what you already have and you’ll be done before you know it.
Web Interface
Around for years and loved by many. Web Interface will be EOL and fully replaced by StoreFront in 2015, It’s not in the Citrix Product Matrix so I figured it might be worth to mention it separately. StoreFront has been on the market for about a year and a half now and has already conquered it’s piece of the market. Although part of the Citrix CloudGateway suite and separately available, it’s still being reviewed and improved on ongoing bases. The general recommendation is to keep using Web Interface when migrating Farms and to go with StoreFront if you can build it from the ground up. Especially when you have a complex set-up including Smartcard and or Token Authentication for example, this is still not natively supported in StoreFront (it is possible, just configured differently) the same goes for a few other features as well. Thomas Koetzing wrote up a real handy comparison between the two, have a look here: thomaskoetzing.de/index.php?option=com_content&task=view&id=368&Itemid=254 Eventually it will all be there in the end (I assume), so why not wait a bit and make life easier?!
Licensing
Can be tricky, Citrix states that whenever you upgrade your Citrix product, XenApp in our case, you should also upgrade your license server. Each time a new license server is released, it may contain better security, fixes to known issues, and so on. And… in some cases, new versions of the Citrix product will not work with older versions of the license server. As per Citrix: The new license server is backward compatible and will work with older products and license files; however, new products require the newest license server to check out licenses correctly
As far as licensing goes, if you are a current Citrix Subscription Advantage member, you are eligible to version upgrade to the latest release of Citrix products and upgrade your existing licenses to the license system used by these products. Otherwise, you’ll need to talk to your Citrix sales representative or Citrix partner.
Tools and general migrations steps
First of all… Because of fundamental differences between these products (versions) you cannot create mixed farms based on XenApp 4.5 / 5.0, 6.0 and 6.5. They need to be built in parallel before you can migrate your Farm resources (there is actually a way around this which I will discuss under: XenApp 6.0 to 6.5 Upgrade Utility, scroll down). Next to that you can configure Web Interface (or StoreFront) to aggregate multiple Farms if that’s what you need. One more thing, when we are referring to XenApp 5.0 it’s actually XenApp 4.5 with HRP5 installed, don’t ask… Mixed mode Farms are possible in some cases, here’s a nice quote from Citrix: Adding a XenApp 5 for Windows Server 2008 member server to a Presentation Server 4.0 farm, a Presentation Server 4.5 farm, or a XenApp 5 for Windows Server 2003 farm, regardless of zone designation, places the server farm into mixed mode. But that’s not what we want is it?! Let’s have a look at some of the tools available.
When migrating we need to have some way in which we can move all of our old Farm resources over to the new Farm. Of-course we can do it all by hand and although this may seem like a lot of work at first, in smaller Farms this may just be the way to go, why not?! But when things get a little more complex (larger) you may want to use one of the following tools:
XenApp 6.0 Migration Tool
Although I doubt this will be used much let’s have a look anyway. If you would like to upgrade your existing 4.5 / 5.0 Farm to XenApp 6.0 instead of 6.5 then this is your tool: support.citrix.com/article/CTX125471 Remember that XenApp 5.0 is actually XenApp 4.5 with HRP5 installed, in fact, for this tool to work this is the patch level your Farm needs to be on combined with either Windows Server 2003 or Server 2008, 32 or 64 bit. Choose the installer that goes with your platform. You can migrate the following XenApp object types:
I already mentioned (multiple times) that when upgrading from a 32 OS to a 64 bit OS you will run into application compatibility issues which can be time consuming to fix, keep this in mind because you don’t want to underestimate this one! The same goes for migrating from Server 2003 to Server 2008, never mind if they’re 32 or 64 bits the 2008 OS is just fundamentally different and you’ll need to address some of those changes. So make sure you migrate from a XenApp 5.0 Windows Server 2008 64 bit based Farm and you’ll be fine :-) Or do it the other way around and migrate from a XenApp 4.5 Windows Server 2003 32 bit based Farm and address everything at once. To be clear… all these ‘rules’ also apply if we upgrade to 6.5 so I won’t go over this again.
As per Citrix: This tool allows administrators to migrate settings from a XenApp 5 farm to a XenApp 6 farm. It is necessary because XenApp 6 farms do not support upgrades from a previous version or mixed-mode operation (useful for large farms or those with complex settings to prevent manual recreation). Need I say more?! You’ll find the migration tool and its supporting documentation here, give it a good read through: the Citrix E-Docs website: support.citrix.com/proddocs/topic/xenapp6-w2k8/ps-migrate-xa6-wrapper.html for some more information on installation prerequisites, an overview on objects that can be migrated and more. Oh, and it’s fully Command-Line based, just so you know.
XenApp 6.5 Migration Center
When migrating from 4.5 / 5.0 and or 6.0 to 6.5 this is what you use. Although the idea behind it is basically the same as described above, this one is more advanced and flexible in multiple ways, for one, it also has a GUI ;-) You still need to make sure that your applications get installed correctly for this to work but it can save you a lot of time re-creating all of your Farm application configurations resources and not just those. The following table lists the supported XenApp versions from source to new Farm.
I copied this in from the E-Docs site: In all migrations, Citrix recommends you first use the XenApp 6.5 media to perform a clean install of the XenApp server role on one or more Microsoft Windows Server 2008 R2 or Microsoft Windows Server 2008 R2 SP1 servers. Then, use the XenApp Server Configuration Tool to create a new farm or join servers to that new farm. A clean install means that there is no previous version of the XenApp server role installed on the server. Before we continue, here’s an overview on the Farm resources that can be migrated using the XenApp Migration Manager:
There’s one missing, the current Farm Administrators are or can also be migrated. After you configure and restart the new XenApp server, use the Migration Center installed on that server to import objects from the source farm. If you are migrating from a 4.5 / 5.0 Farm you can specify so called server-to-worker-group mappings. This will place servers from the source Farm directly into Worker Groups in the new Farm according to your specifications. When migrating from a 6.0 Farm Worker Groups already exist so you won’t have to configure any mappings. You can also perform a dry run first to see which objects will be imported during a migration A.K.A. an Analyze. Although this all works fine initially, Worker Groups, Zone Preference and or Failover policies are always worth having a second look at, think of it as an extra post migration task, especially when merging multiple Farms into one.
Here’s another quote from Citrix regarding Direct and Indirect migrations: Citrix recommends performing the migration entirely from a server in the new XenApp farm (a direct migration). However, if the source Farm and new Farm cannot communicate, perhaps because they are in different domains that do not have a trust relationship, you can perform an indirect migration. In an indirect migration, you run the Migration Center from a server in the source farm to export settings and then import the settings using the Migration Center on a server in the new farm. In this case, you must install the Migration Center on a server in the source farm. You must use the command-line interface for an indirect migration.
Post migration
A small note on the Post migration tasks. The migration wizard takes care of a lot, but unfortunately can’t take care of it all. Here are some examples on what you might need to check or re-configure after a successful migration, if applicable in your situation:
- Add new servers in the old server folder hierarchy to preserve delegated permissions
- Copy Health Monitoring test executables and configure Health Monitoring settings
- Check the migration log to confirm success, look for: skipped invalid file type
- After migrating a 32-bit XenApp 5 farm, rebuild profiled applications
- Initiate Configuration Logging in the new farm
- Associate servers or OUs with worker groups
- Create load evaluator policies
- Create zone policies
- Configure printer settings
More details can be found here: support.citrix.com/proddocs/topic/xenapp65-w2k8/ps-migrate-xa6-wrapper.html General recommendations, installation requirements, post migrations tasks and if you like you can use the Command-Line interface or just stick to the GUI, it’s up to you.
XenApp 6.0 to 6.5 Upgrade Utility
Last but not least… When migrating from XenApp 6.0 to 6.5 there’s another tool you can use. Although it’s called the XenApp 6.0 to 6.5 Upgrade Utility it’s basically a script taking care of business. It un-installs all of the XenApp 6.0 components in the right order, then installs 6.5 and by default joins the server to the new Farm as a worker. It also verifies if the IMA service is running to verify if the join was successful. Support.citrix.com/article/CTX130614 will give you a more detailed description. Although not a requirement, it might be a good idea to first remove the server from the old Farm before performing an in-place upgrade.
When you have complex applications running in your Farm this might just be the tool you need. You won’t have to go over configuring those horror apps again, a potential time saver. Think about it, you migrate all of your resources, including your published application configurations, using the XenApp 6.5 Migration Center and next you do an in-place upgrade on the machines that have the actual application bits installed and you’re done, well… sort of.
Like I said, it’s a script and thus fully customizable, have a look at the CTX130614 document, it will tell you exactly how to install and setup the script, how to edit, execute and so on. One last quote: IMPORTANT: This script is designed to operate silently in the background without requiring you to log in between reboots. After starting the script it takes 30 minutes (or more) and a few reboots to complete.
Requirements
There already needs to be a XenApp 6.5 Farm in place, it cannot be used to migrate a single server from 6.0 to 6.5, remember from earlier that because of fundamental differences between the different products Farms need to be built in parallel when migrating / updating, but wait… let’s first have a look at the automated actions that the tool / scripts performs, I got these from the CTX130614 document mentioned above:
- Checks if XenApp 6.0 is installed or not, and if the XenApp 6.5 installer is available.
- Prompts for a password to silently run the install process after reboot. Note: This is not stored by the script but is stored by the operating system in the Task Scheduler.
- Uninstalls XenApp 6.0 components. By default these include:
Citrix EdgeSight for XenApp 6 Agent 5.3 x64
Citrix XenApp 6.0
Citrix HDX MediaStream for Flash – Server
Citrix Common Commands
Citrix XenApp Commands
Citrix Group Policy Client-Side Extension (x64)
Citrix XenApp Server Configuration Tool
Citrix XenApp Server Role Manager
Citrix XenApp Management
Citrix Single Sign-On Console 4.8
Citrix XenApp Group Policy Management Experience (x64)
Citrix Single Sign-On Plug-in
Citrix XenApp Power and Capacity Management Agent
Citrix Offline Plug-in
Citrix Online Plug-in
Smart Auditor Agent - Installs XenApp 6.5 and, by default, joins the server to the farm as a worker. This can also be changed by editing the JOIN command parameters as outlined in the document.
- Verifies the join is successful by checking to see if the IMA service is running.
- Note: Once the script is complete, all of the discretionary components above need to be manually reinstalled and configured.
For all this to work User Access Control needs to be turned off, the PowerShell execution policy must be set to Unrestricted and If installing XenApp 6.5 from a network share, at least Read permission from the location is needed, when finished all settings can be put back if desired. Again, this whole process assumes that we already have a new separate 6.5 Farm configured (which is the preferred way of doing it). But what if we don’t have the proper resources to build another Farm? Then do as follows: first check the ‘Uninstalls XenApp 6.0 components’ bullet above for the correct un-installation order, then continue by:
- Pick one of your existing 6.0 servers
- Remove it from the Farm
- Uninstall all XenApp components
- Reboot the server
- Install XenApp 6.5
- Skip License Server configuration
- Create a new 6.5 Farm
- Reboot the server
- Install updates, RP’s etc… as needed
- Reboot again and you’re done
This way you don’t need extra hardware or virtual resources to build a new Farm, you just use what you already have. The Upgrade Utility automatically joins the server to the new Farm and checks if the IMA service is running, that’s why when using this utility a new Farm already needs to be in place. By doing it manually you have total control and decide what and when it happens. So instead of joining Farm you create a new one. Now continue by migrating your 6.0 Farm resources over to your newly created 6.5 Farm. When finished continue using the Upgrade Utility on the other servers to (automatically this time) migrate them over.
PVS
When using Citrix provisioning services for XenApp deployment the steps basically remain the same, the difference being that all takes place on the vDisk. Without getting into too much detail here’s what you do: make a copy of the existing vDisk, import it and put in private mode for editing, start up the target device and remove all XenApp related components (don’t remove the target device software a.k.a. PVS Agent) in the right order according to Upgrade Utility mentioned above, followed by a XenApp 6.5 installation, Farm creation etc… Migrate your Farm resources and finally reboot your target devices using the new vDisk.
Conclusion
Migrating your Farm isn’t as complicated as you might think. With the proper documentation and planning you can come a long way, all the way if you ask me. Don’t get overwhelmed by it all, go over some of the documents mentioned, plan accordingly and stick to your migration tool of choice. As far as tooling goes I only focused on what Citrix has to offer and although I’m sure that there are more out there I couldn’t find that many to be honest, any suggestions?! I know that migrating your old Farm(s) probably isn’t the most exciting job to look forward to… or is it?
Bas van Kaam ©
Reference materials used: Citrix E-Docs website, Citrix-Guru.com and Brainmadden.com
[twitter-follow screen_name='BasvanKaam']
3 responses to “End of Life… to Migrate or not to Migrate?”
[…] https://www.basvankaam.com/2013/04/28/end-of-life-to-migrate-or-not-to-migrate/ […]
[…] Citrix software upgrade: End of Life… to Migrate or not to Migrate? | basvankaam.com […]
[…] Citrix software upgrade: End of Life… to Migrate or not to Migrate? | basvankaam.com […]