by Tim Mangan, CTP Fellow, Boston CUGC Leader
Field Book Chapter 3: Migration
ABOUT THE SERIES:
The Field Book on Citrix with App-V is a collection of experiences in customer implementations. This article helps to understand the decision points around how to configure the App-V client.
Use tag FieldBook to search for more from the series.
Scenario:
The customer is currently on XenApp 6.5 (and 5.5) with App-V 4.6 and wishes to migrate to the modern equivalents on Server 2012 R2.
The customer has a single site, and the existing App-V 4.6 servers are implemented in load balanced pairs with Management Servers on one set of VMs and Publishing Servers on another set.
The customer has a large number of home-grown applications that were often difficult to handle in App-V 4.x and impossible to deliver without application virtualization.
The customer uses all published applications and prefers slow migrations over massive cutovers. They prefer to roll out slowly with parallel implementations; migrating apps over on an app-by-app basis and migrating users over with individual or small chunks of related apps made available to users in small chunks.
Time-Frame:
The customer is implementing XenApp 7.9 with App-V 5.1 (and hotfixes). Server 2016 has not yet been released.
Considerations:
Given the versions being used, it is possible to use dual App-V clients with “Migration Mode” on the new XenApp VDAs. Initially, all apps would be delivered via App-V 4.6. Independent, and groups of dependent apps, could be converted or packaged for App-V 5.x and placed on the App-V Server and published, but since users do not get access to the desktop shortcuts they won’t be used until added in Studio and targeting is changed there.
With App-V Migration mode in place, the App-V clients will cooperate for any packages that are converted, and the old packages do not need to be immediately removed. This allows for a quick fallback to the existing apps if needed. In cases where apps are sequenced fresh in App-V 5.x, when the new version is published to the delivery group in Studio, the old should be removed unless the shortcuts in the new package have been modified to not conflict.
In discussing the situation with the customer, they really are not interested in gaining the advantages of the new integrations available in App-V 5 at this time. They want the fastest possible migration off of unsupported platforms. Thus package conversion of the old packages are the best approach.
Result:
A new set of App-V servers, using a new database, is implemented. Two load balanced VMs are used; each VM has both the 5.x Management and 5.x Publishing installed. Although I recommend configuring the publishing server to use the localhost management server portal, the customer opts to use the load balanced URL because Microsoft draws it that way.
Both 4.6 and 5.x App-V clients are installed and configured on the new XenApp VDAs. In addition to the same settings referenced in Chapter 2 (about configuring the 5.x App-V client via Group Policy) Migration mode is also enabled.
A conversion project for about 700 app packages is undertaken (this will be a separate chapter in the Field Book). It is scheduled that most of the packages would be cut over in about 3 months and hopefully all of the old App-V packages and servers decommissioned within 9 months.
