Migrate XenApp 6.x 编辑

NOTE: You cannot use the Citrix Smart Migrate product with this version of XenApp and XenDesktop. However, the Migration Tool is available.

You can use the Migration Tool described in this article to migrate from XenApp 6.x to XenApp 7.6. Then, you can upgrade from XenApp 7.6 to a supported LTSR or the current Citrix Virtual Apps and Desktops release.

XenApp 6.x Migration Tool

The XenApp 6.x Migration Tool is a collection of PowerShell scripts containing cmdlets that migrate XenApp 6.x (6.0 or 6.5) policy and farm data. On the XenApp 6.x controller server, you run export cmdlets that gather that data into XML files. Then, from the XenApp 7.6 Controller, you run import cmdlets that create objects using the data gathered during the export.

The following sequence summarizes the migration process. Details are provided later.

1. On a XenApp 6.0 or 6.5 controller:
   1. Import the PowerShell export modules.
   2. Run the export cmdlets to export policy and farm data to XML files.
   3. Copy the XML files (and icons folder if you chose not to embed them in the XML files during the export) to the XenApp 7.6 Controller.
2. On the XenApp 7.6 Controller:
   1. Import the PowerShell import modules.
   2. Run the import cmdlets to import policy and farm data (applications), using the XML files as input.
3. Complete post-migration steps.

Before you run an actual migration, you can export your XenApp 6.x settings and then perform a preview import on the XenApp 7.6 site. The preview identifies possible failure points so you can resolve issues before running the actual import. For example, a preview might detect that an application with the same name already exists in the new XenApp 7.6 site. You can also use the log files generated from the preview as a migration guide.

Unless otherwise noted, the term 6.x refers to XenApp 6.0 or 6.5.

New in this release

This December 2014 release (version 20141125) contains the following updates:

• If you encounter issues using the migration tool on a XenApp 6.x farm, report them to https://discussions.citrix.com/forum/1411-xenapp-7x/.
• New packaging - the XAMigration.zip file now contains two separate, independent packages: ReadIMA.zip and ImportFMA.zip. To export from a XenApp 6.x server, you need only ReadIMA.zip. To import to a XenApp 7.6 server, you need only ImportFMA.zip.
• The Export-XAFarm cmdlet supports a new parameter (EmbedIconData) that eliminates the need to copy icon data to separate files.
• The Import-XAFarm cmdlet supports three new parameters:
  • MatchServer - import applications from servers whose names match an expression
  • NotMatchServer - import applications from servers whose names do not match an expression
  • IncludeDisabledApps - import disabled applications
• Prelaunched applications are not imported.
• The Export-Policy cmdlet works on XenDesktop 7.x.

Migration Tool package

The migration tool is available under the XenApp 7.6 Citrix download site. The XAMigration.zip file contains two separate, independent packages:

• ReadIMA.zip - contains the files used to export data from your XenApp 6.x farm, plus shared modules.

• ImportFMA.zip - contains the files used to import data to your XenApp 7.6 farm, plus shared modules.

Limitations

• Not all policies settings are imported. See Policy settings not imported. Settings that are not supported are ignored and noted in the log file.
• While all application details are collected in the output XML file during the export operation, only server-installed applications are imported into the XenApp 7.6 site. Published desktops, content, and most streamed applications are not supported (see the Import-XAFarm cmdlet parameters in Step-by-step: import data for exceptions).
• Application servers are not imported.
• Many application properties are not imported because of differences between the XenApp 6.x Independent Management Architecture (IMA) and the XenApp 7.6 FlexCast Management Architecture (FMA) technologies. See Application property mapping.
• A Delivery Group is created during the import. See Advanced use for details about using parameters to filter what is imported.
• Only Citrix policy settings created with the AppCenter management console are imported. Citrix policy settings created with Windows Group Policy Objects (GPOs) are not imported.
• The migration scripts are intended for migrations from XenApp 6.x to XenApp 7.6 only.
• Nested folders greater than five levels deep are not supported by Studio and will not be imported. If your application folder structure includes folders more than five levels deep, consider reducing the number of nested folder levels before importing.

Security considerations

The XML files created by the export scripts can contain sensitive information about your environment and organization, such as user and server names, plus other farm, application, and policy configuration data. Store and handle these files in secure environments.

Carefully review the XML files before using them as input when importing policies and applications, to ensure they contain no unauthorized modifications.

Policy object assignments (previously known as policy filters) control how policies are applied. After importing the policies, carefully review the object assignments for each policy to ensure that there are no security vulnerabilities resulting from the import. Different sets of users, IP addresses, or client names might be applied to the policy after the import. The allow and deny settings may have different meanings after the import.

Logging and error handling

The scripts provide extensive logging that tracks all cmdlet executions, informative messages, cmdlet execution results, warnings, and errors.

• Most Citrix PowerShell cmdlet use is logged. All PowerShell cmdlets in the import scripts that create new site objects are logged.
• Script execution progress is logged, including the objects being processed.
• Major actions that affect the state of the flow are logged, including flows directed from the command line.
• All messages printed to the console are logged, including warnings and errors.
• Each line is time-stamped to the millisecond.

Citrix recommends specifying a log file when you run each of the export and import cmdlets.

If you do not specify a log file name, the log file is stored in the current user’s home folder (specified in the PowerShell $HOME variable) if that folder exists. Otherwise, the file is placed in the script’s current execution folder. The default log name is XFarmYYYYMMDDHHmmSS-xxxxxx where the last six digits are a random number.

By default, all progress information is displayed. To suppress the display, specify the NoDetails parameter in the export and import cmdlet.

Generally, a script stops execution when an error is encountered, and you can run the cmdlet again after clearing the error conditions.

Conditions that are not considered errors are logged. Many are reported as warnings, and script execution continues. For example, unsupported application types are reported as warnings and are not imported. Applications that already exist in the XenApp 7.6 site are not imported. Policy settings that are deprecated in XenApp 7.6 are not imported.

The migration scripts use many PowerShell cmdlets, and all possible errors might not be logged. For more logging coverage, use the PowerShell logging features. For example, PowerShell transcripts log everything that is printed to the screen. For more information, see the help for the Start-Transcript and Stop-Transcript cmdlets.

Requirements, preparation, and best practices

To migrate, you must use the Citrix XenApp 6.5 SDK. Download that SDK from https://www.citrix.com/downloads/xenapp/sdks/powershell-sdk.html.

Review this entire article before beginning a migration.

You need to understand basic PowerShell concepts. Although extensive scripting expertise is not required, you need understand the cmdlets you run. Use the Get-Help cmdlet to review each migration cmdlet’s help before running it. For example: Get-Help -full Import-XAFarm.

Specify a log file on the command line and always review the log file after running a cmdlet. If a script fails, check and fix the error identified in the log file and then run the cmdlet again.

Good to know:

• To facilitate application delivery while two deployments are running (the XenApp 6.x farm and the new XenApp 7.6 site), you can aggregate both deployments in StoreFront or Web Interface. See the product documentation for your StoreFront or Web Interface release (Manage > Create a store).
• Application icon data is handled in one of two ways:
• If you specify the EmbedIconData parameter in the Export-XAFarm cmdlet, exported application icon data is embedded in the output XML file.

• If you do not specify the EmbedIconData parameter in the Export-XAFarm cmdlet, exported application icon data is stored under a folder named by appending the string -icons to the base name of the output XML file. For example, if the XmlOutputFile parameter is FarmData.xml, then the folder FarmData-icons is created to store the application icons.

  The icon data files in this folder are .txt files that are named using the browser name of the published application. Although the files are .txt files, the stored data is encoded binary icon data, which can be read by the import script to re-create the application icon. During the import operation, if the icon folder is not found in the same location as the import XML file, generic icons are used for each imported application.

• The names of the script modules, manifest files, shared module, and cmdlets are similar. Use tab completion with care to avoid errors. For example, Export-XAFarm is a cmdlet. ExportXAFarm.psd1 and ExportXAFarm.psm1 are files that cannot be run.
• In the step-by-step sections, most <string> parameter values show surrounding quotation marks. These are optional for single-word strings.

For exporting from the XenApp 6.x server:

• The export must be run on a XenApp 6.x server configured with the controller and session-host (commonly known as controller) server mode.
• To run the export cmdlets, you must be a XenApp administrator with permission to read objects. You must also have sufficient Windows permission to run PowerShell scripts. The step-by-step procedures contain instructions.

• Ensure the XenApp 6.x farm is in a healthy state before beginning an export. Back up the farm database. Verify the farm’s integrity using the Citrix IMA Helper utility (CTX133983): from the IMA Datastore tab, run a Master Check (and then use the DSCheck option to resolve invalid entries). Repairing issues before the migration helps prevent export failures.

  For example, if a server was removed improperly from the farm, its data might remain in the database; that could cause cmdlets in the export script to fail (for example, Get-XAServer -ZoneName). If the cmdlets fail, the script fails.

• You can run the export cmdlets on a live farm that has active user connections. The export scripts read only the static farm configuration and policy data.

For importing to the XenApp 7.6 server:

• You can import data to XenApp 7.6 deployments (and later supported versions). You must install a XenApp 7.6 Controller and Studio, and create a site before importing the data you exported from the XenApp 6.x farm. Although VDAs are not required to import settings, they allow application file types to be made available.
• To run the import cmdlets, you must be a XenApp administrator with permission to read and create objects. A Full Administrator has these permissions. You must also have sufficient Windows permission to run PowerShell scripts. The step-by-step procedures contain instructions.
• Do not have any other active user connections during an import. The import scripts create many new objects, and disruptions might occur if other users are changing the configuration at the same time.

Remember that you can export data and then use the -Preview parameter with the import cmdlets to see what would happen during an actual import, without actually importing anything. The logs indicate exactly what would happen during an actual import. If errors occur, you can resolve them before starting an actual import.

Step-by-step: export data

Complete the following steps to export data from a XenApp 6.x controller to XML files.

1. Download the XAMigration.zip migration tool package from the Citrix download site. For convenience, place it on a network file share that can be accessed by both the XenApp 6.x farm and the XenApp 7.6 site. Unzip XAMigration.zip on the network file share. There are two zip files: ReadIMA.zip and ImportFMA.zip.

2. Log on to the XenApp 6.x controller as a XenApp administrator with at least read-only permission and Windows permission to run PowerShell scripts.

3. Copy ReadIMA.zip from the network file share to the XenApp 6.x controller. Unzip and extract ReadIMA.zip on the controller to a folder (for example: C:\XAMigration).

4. Open a PowerShell console and set the current directory to the script location (for example: cd C:\XAMigration).

5. Check the script execution policy by running Get-ExecutionPolicy.

6. Set the script execution policy to at least RemoteSigned to allow the scripts to run (for example: Set-ExecutionPolicy RemoteSigned).

7. Import the module definition files ExportPolicy.psd1 and ExportXAFarm.psd1:

   Import-Module .\ExportPolicy.psd1

   Import-Module .\ExportXAFarm.psd1

   Good to know:

   • If you intend to export only policy data, you can import only the ExportPolicy.psd1 module definition file. Similarly, if you intend to export only farm data, import only ExportXAFarm.psd1.
   • Importing the module definition files also adds the required PowerShell snap-ins.
   • Do not import the .psm1 script files.

8. To export policy data, run the Export-Policy cmdlet.

   Parameter	Description
   -XmlOutputFile “<string>.xml”	XML output file name. This file holds the exported data. Must have an .xml extension. The file must not exist, but if a path is specified, the parent path must exist. Default: None. This parameter is required.
   -LogFile “<string>”	Log file name. An extension is optional. The file is created if it does not exist. If the file exists and the NoClobber parameter is also specified, an error is generated. Otherwise, the file’s content is overwritten. Default: See Logging and error handling.
   -NoLog	Do not generate log output. This overrides the LogFile parameter if it is also specified. Default: False. Log output is generated.
   -NoClobber	Do not overwrite an existing log file specified in the LogFile parameter. If the log file does not exist, this parameter has no effect. Default: False. An existing log file is overwritten.
   -NoDetails	Do not send detailed reports about script execution to the console. Default: False. Detailed reports are sent to the console.
   -SuppressLogo	Do not print the message XenApp 6.x to XenApp/XenDesktop 7.6 Migration Tool Version #yyyyMMdd-hhmm# to the console. This message, which identifies the script version, can be helpful during troubleshooting. Therefore, Citrix recommends omitting this parameter. Default: False. The message is printed to the console.

   Example: The following cmdlet exports policy information to the XML file named MyPolicies.xml. The operation is logged to the file named MyPolicies.log.

   Export-Policy -XmlOutputFile ".\MyPolicies.XML" -LogFile ".\MyPolicies.Log"
   <!--NeedCopy-->