by Tim Mangan, CTP Fellow, Boston CUGC Leader

Field Book Chapter 4: Best New App Processes

ABOUT THE SERIES:

The Field Book on Citrix with App-V is a collection of experiences in customer implementations.  This article helps to understand building an application preparation process for implementing App-V in a Citrix environment.

Use tag FieldBook to search for more from the series.

Scenario:

A Customer is migrating  to XenApp 7.x and App-V 5.x.  They are struggling with getting the apps sequenced and tested.

Review of the existing process indicates a number of issues.

• The App-V sequencer is not domain joined, and they utilize contractor packagers that do not have domain admin credentials to do things like map drives and access the many non-standard shares that exist.  This results in wasted time in waiting for someone with credentials to come over and use their credentials to allow access for the packaging or testing attempt.
• Although both production and pre-production XenApp environments were built, they tend to sequence and immediately publish to a select delivery group to the production environment.
• After an app is sequenced, they go to the App-V server, import, assign, and publish. Then they go to Studio, refresh the list from the App-V Server, Add and Assign the package. Then they go to StoreFront to test.
• Because end-users do not get access to full desktops, they don’t make the full desktop available in the production environment, even to admins that might need it to test. Without this access it is difficult to diagnose new-package issues and the tendency is to just “guess at the cause, repackage, and hope for the best” without understanding the issue.
• The pre-production environment is very dirty.  Lots of things have been tried on it over time and it is not reverted to match the production build.
• The pre-production and production equipment are in two separate domains, with a one-way trust such that production accounts can access non-production resources but not the other way around.  As not everything has been duplicated for non-production (especially network shares that only exist on servers in the production domain), this adds to the issues of testing on the non-production servers.

Time-Frame:

This customer was implementing XenApp 7.7.

Considerations:

The customer needs to be coaxed to implement a process that will speed up the time to produce quality packages by not taking shortcuts.  Fortunately, they know they need to improve and are open to changes in process.

Result:

After a discussion, changes were made in order to streamline the process.

• Sequencing VMs were joined to the pre-production domain. They were placed in a special OU to prevent most of the GPOs from being applied.  Contractors were given domain admin accounts to the pre-production domain (but not the production domain).
• Important network shares were identified and either duplicated (DFS), moved to non-production equipment, or security settings modified, such giving everyone read access when appropriate.  (NOTE: Moving shares used in production to non-production equipment is highly discouraged as dangerous, but the customer feels that they have it under control with a relatively few number of people involved).  Between these two items, contractors now have access to about 98% of all network resources they need automatically. It would be 100% but there exist shares that nobody knows about until a repackaging is attempted.
• Non-production XA servers (they use MCS) are cleaned up to match production.  A nightly reboot schedule is implemented, and contractors are authorized to request a reboot if needed during the day.
• The non-production VDAs have a sequenced AppV_Manage package published globally in App-V.
• After sequencing an app, the contractor may now copy the package to the non-production share.  They then go directly to StoreFront and log into a full desktop on a non-production VDA. They launch AppV_Manage, and use it to directly add/publish the package to themselves.  They then test the app directly from inside their session, troubleshooting using whatever tools they need (AppV_Manage, Process Monitor, Process Explorer, RegEdit, etc).  When done, they unpublish and remove the package.
• If necessary, they repackage, remove the old package from the share and replace with the new, and repeat the previous step.
• Otherwise, they can import/assign the package in the App-V Server, then in Studio, and retest the published app through the entire process through the non-production storefront.
• If successful, the application expert is located, and assigned to test.
• When the application is approved for production, it is implemented on the production servers.

These changes have made a significant change in packaging throughput, cutting the average time to produce a package by more than 50%.