SBC Migration Best Practices

Because an SBC project has a pretty big impact on the organization and infrastructure I personally think it is one of the most difficult projects to carry out. After (endless) discussions about the design and technical obstacles during the build phase the most important and difficult processes will begin! How do we migrate users smoothly to the new Infrastructure? In this article several scenarios will be described.

Current situation and new situation

The possible migration scenarios really depend on your current situation and the new, required, situation. Is your infrastructure now based on a traditional client server model with fat clients? Do you already use an SBC product? Do you use Published Applications or Published Desktop? Do you have Thin Clients or Fat Clients? And so you can think of several questions.

Because there are so many possibile scenarios it is 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 them 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 scenarios 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 are almost the same as working locally on the workstation. The biggest issue can be that users’ settings now stored in a profile based on Windows XP (or lower). It’s really not advisable to use those on one of 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 is also a best practice for this kind of migration.

Offering a full desktop eliminates the need for a fat client, for most users. You should consider using Thin Clients or rebuilding your current Fat Clients 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 ThinClientServer, MultiFrame or similar products. Currently with Citrix Presentation Server the Web Interface is used to present the applications/desktop to the end user. The biggest advantage, in comparison with the traditional PN client, is central management of the configuration, where the downside is the additional server (components) required.

This scenario is the most difficult during the migration phase. Because rebuilding the fat client 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 where 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 building a temporary office room. If the location is migrated to the new infrastructure a couple of systems running the old infrastructure are located in the room, or if the office is not migrated, the room contains 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 as necessary. Presenting the applications will mostly be done using the Citrix PNAgent (or similar components 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, a best practice is a hardware Load Balancer or third party software load balancer instead 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 a Published Desktop, the change over is comparable with moving from a fat client infrastructure to a Full SBC Desktop. Additional considerations are the needed space (storage) for hosting the (roaming) profiles, and the farm which will host the Published Desktops. If this is a new farm check the section below, 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 instead of Published Applications. The main reason is that the Thin Client does not offer any local resource or programs that are used by the end-users and the user experience is similar to a full desktop.

Migrating to a new version of Windows Terminal Server

Normally every three/four years Microsoft releases a new version of their server product. After a while the servers should be updated with this new release. First of all, it is a best practice to rebuild the server in total instead of upgrading the operating system. When implementing a new operatiing system the main concerns are (again) the profiles. Although it is sometimes possible it is strongly recommended to not use profiles of other versions of the operating system. Again, settings could be retained by migrating the user profiles. When the operating system version is the only thing changing and Citrix Presentation Server is being used most times, the servers will stay in the same farm. Temporary profiles or profile locations 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.

Migrating to a new version of Citrix Presentation Server

Citrix releases new versions of Citrix Presentation Server as well. Technically, Citrix offers the possibility to add new versions of the product in the current farm (see knowledgebase article 1068832). This is the easiest migration because no configuration changes need to be made to the clients. It can be considered as an alternative implementationof how 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. 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 migrate to a new Citrix Farm the biggest 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 Clients the migration can be carried out pretty easily. 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 points 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 non-migrated users are prevented from starting the new desktop. When all users/locations are migrated you can remove the first icon and re-enable the auto launch feature again.

Fat Clients

When using Published Applications on Fat Clients the migration strategy should be simplified by using the PNAgent. With the PNAgent 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 to use the PNAgent for Published Applications. When you choose to “update” to the PNAgent delete the current configuration in the PN client, so users are not bothered with old and/or double application links.


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.

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top