Wilco van Bragt - LinkeIn Wilco van Bragt - Twitter rssa 

Best practices for migration with SBC Infrastructures

Because a SBC project has a pretty big impact on the organization and infrastructure I personally think it is was on the difficult projects to carry out. After (endless) discussions about the design and technical obstacles during the build phase probably the most important and difficult process needs to be started. How do we do migrate users smoothly to the new Citrix Infrastructure. In this article several scenarios and varieties will be described how the migration can be carried out.

Current situation and new situation




 

The possible migration scenarios really depend of your current situation and new situation. Is your infrastructure now based on a traditional client server model with fat clients? Do you already use a SBC product? Do you use Published Applications or Published Desktop? Do have Thin Client or Fat Clients? And so you can think of several questions. Because of this it's impossible to write the "always a success" migration strategy. I will describe several possibilities, pick out the things you can use in your environment, combine those and create your own perfect migration scenario.

Moving to SBC from the traditional fat client infrastructure

Still more and more companies are adopting the SBC concept for presenting the applications to the end users. Migrating scenario's are independent of the way SBC is introduced. Are (almost) all the applications presented via SBC (via a Full Desktop) or only a few applications (using Published Applications)?

To a Published Desktop

When using almost all the applications via SBC publishing a full desktop is best practice, because the users experiences is almost the same working locally on the workstation. The biggest issue can be that users' settings now stored in profile based on Windows XP (or lower). It's really not advisable to use those one on one on your Terminal Servers. Many companies just start over with a new profile (where the user needs to configure his settings again), but the technique as already described in the article Migrating User Settings with the FPK <<<<LINK>>>> is also a best practice for this kind of migrations. Offering a full desktop eliminates for most users the need for a fat client. You should consider using Thin Client or rebuilding your current Fat Client to Thin Clients. Although this can be done with a "normal" Windows installation base, a best practice is to use a managed solution based on Linux like 2X ThinClienServer, MultiFrame or similar product. Currently with Citrix Presentation Server the Web Interface is being used as presenting the applications/desktop to the end user. The biggest in comparison with the traditional PN client is central management of the configuration, where the downside is the additional server(components) are required. This scenario is the most difficult during the migration phase. Because rebuilding the fat client or place thin clients makes the workplace only usable for the new infrastructure. Normally not all users are migrated in a big bang scenario, so there is a period both infrastructures are used in production next to each other. A best practice is to divide users from one department into different phases for large locations. When migrating smaller locations you could consider to build a temporary office room. If the location is migrated to the new infrastructure a couple of systems for the old infrastructure are located in the room or if the office is not migrated the room has some new infrastructure clients. In this way traveling users can always use their applications.

To Published Applications

When just a set of your application portfolio is presented to you end user via Terminal Services a best practice is to use Published Applications presented seamlessly on the Fat Clients. Here also a consideration can be made to retain the user settings for these applications to the SBC infrastructure in necessary. Presenting the applications will mostly be done using the Citrix PNAgent (or similar component in other products), which integrates the applications into the local start menu and/or desktop folder. Because mainly the same fat clients are still used, only the PNAgent should be deployed on all workstations (and do not forget that the PN Agent configuration on the server can be reached from all clients).

When your SBC infrastructure is based on Windows 2003 Terminal Server only (so not using Citrix Presentation Server or another SBC Add-on) a best practice is a hardware Load Balancer or third party software load balancer in stead of Microsoft Network Load Balancer.

Moving from Published Application to Published Desktops

When your infrastructure already hosts Published Applications, but the next step is to go to Published Desktop the scenario is comparable with moving from fat client infrastructure to a Full SBC Desktop. Addition considerations are the needed space (storage) for hosting the (roaming) profiles and the farm which will be hosting the Published Desktops. If this is new farm check the paragraph Migrating to a new Citrix Farm. Also the scenario from moving to Fat Clients to Thin Clients fits into this method. It is a best practice to deploy a Full Desktop to Thin Clients in stead of Published Applications. The main reason is that the Thin Client is not offering any local resource or programs that are being used by the end-user and the user experience is uniform with a full desktop.

Migrating to a new version of Windows Terminal Server version

Normally every three/four years Microsoft is releasing a new version of their server product. After a while the servers should be updated with this new release. First of all it is best practice to rebuild the server in total in stead of upgrading the operating system. When implementing a new operation system the main concern are (again) the profiles. Although it is sometimes possible it is strongly recommend not using profiles of other version of the operating system. Again settings could be retained by migrating the user profiles. When the operating system version is only thing changing and Citrix Presentation Server is being used most times the servers will be stay in the same farm. Temporary two profiles or profilelocations could be defined (using the GPO Profile configuration per OU) or hybrid profiles could be implemented. It is best practice to update a silo (or Load Balanced Group) in one go.

If also a new version of Citrix Presentation Server is implemented read on in the next paragraph.

Migrating to a new version of Citrix Presentation Server

Also Citrix releases on a periodical basis new version of Citrix Presentation Server. Technically Citrix offers the possibility to add new versions of the product in the current farm (see knowledgebase article 1068832). This is the easies migration because no configuration changes need to be made to the clients. It can be considered to implement another way to present the applications when the "normal" Program Neighborhood is being used (see next paragraph).

But most times it is better to start with a new Citrix Farm. It this way the environment can start with a clean state and design can be made reflecting the current needs of your company/customer.

Migrating to a new Citrix Farm

When the decision is made to start with a new Citrix Farm the most concerns are how to present the applications to the user during the migration. Again this depends on the size of your organization and the amount of locations.

Thin Clients

When using Thin Client the migration can be carried out pretty easy. Almost every thin client solution supports multiple farms. In this way you could present two icons on the thin client during the migration phases and disable the auto start function. The first icon is pointing to the current farm and the second icon to the new farm. Use a new Active Directory group to assign users to the new farm, so not migrated users are prevented to start the new desktop already. When all users/locations are migrated you can remove the first icon and re-enabling the auto launch feature again.

Fat Clients

When using Published Applications on Fat Client the migration strategy should be simplified by using the PNAgent. With the PNAgent also multiple farms are supported. By using new Active Directory groups for the applications on the new Citrix farm only the migrated user see the new applications (remove the users from the old groups, so they do not see the "old" applications) and the other way around.

If you are using the Program Neighborhood you could use the just released ADM template or distribute new INI files to the clients. But it is a best practice (also Citrix is really pushing this) to use the PNAgent for Published Applications. When you choose to "update" to the PNAgent see my article "Remove the PN Configuration and Links" to delete the current configuration in the PN client, so users are not bothered with old and/or double application links.  

Conclusion

In this article several scenarios are described followed by the considerations and best practices.  As described earlier pick out the things you can use in your environment, combine those and create your own perfect migration scenario.