Citrix App Layering: Desktop Recovery Utility for vSphere

Organizations perform DR in many different ways. This scripting was developed to help customers that use a full replication strategy for disaster recovery. The utility is built using two scripts that can be pre-defined and set up in the DR datacenter. One script handles adding, reconfiguring and staring the desktops, and the other adding them into VMware View. The scripts can be easily run in response to a declared DR event.

The script will perform the following tasks in DR

• The script will search pre-defined Datastores for VMX files. Then if the vmx filename matches a pre-defined desktop naming standard the VM will be added to vCenter. There is also a desktop naming exclude standard if that makes more sense to use in your environment.
• The script will spread the VMs across a set of pre-defined hosts.
• The script can optionally remove all the VMs disks and Add them back in with the same datastore name. This will update the disk signature if it has changed. If the disk signature does not change this can be disabled.
• The script will answer the VM Question if there is one and start the desktops.
•  The script is designed to run in batches. You set the number of desktops top run per batch and the wait time between batches. This is to ensure that when starting many desktops the virtual infrastructure is not overloaded.
• The process of starting and reconfiguring each desktop in the batch runs in a parallel process as a PowerShell “job”. If the batch size is 20 then 20 jobs are started at a time to add, reconfigure and startup the 20 desktops.
• When the desktops are confirmed to be Running a flag file with the desktop name is place in a share.
• At the end of the DR RESTART script the CPs will be added to vCenter and started.
• After the CPs are started three tables in the management Appliance Database will be updated to the new IDs for this vCenter. Rememeber the VLAN/Network Switch names must match.
• The DRUPDATEVIEW script monitors the share for RUNNING desktops. When the flag file is put in the share the script will find it and add the desktop into VMware View, in the pool that has been defined as a mapping for that desktop and the user that was assigned the desktop before is assigned the desktop in the new pool. The script assumes that View will be a different “Replica Group” and that the desktops are not already defined with the View Connection Server ADAM store.

In order to use this utility you require:

For DRRestart

• A console machine to run the utility that has:
  • PowerShell installed
  • vSphere PowerCLI matching your version of vCenter. Note powercli 6 has not been tested.
• Available Storage
• A Domain account that is a local Administrator on the console machine, and an Administrator at the root of vCenter. The Service account will work for this.
• SSH open from the Console machine to the management Appliance.
• Unique Datastore names must be defined in the primary and DR vCenters and the replicated Datastore should be re-attached with the same name.

 

For DRUpdateView

• Currently the utility only supports VMware View. If you need to use this with XenDesktop contact us and I will add support for it.
• The DRUpdateView utility must be run on a View connection server with
  • PowerShell installed
  • VMware View PowerCLI
• Available Storage
• A Domain account that is a local Administrator on the console machine, and a an Administrator in View.

For both

An SMB Share to fold flag/result files. (Both Utilities/scripts can be configured and run from a Connection Server.)

Note:

• Recovery is based on replication of a vSphere datastore. Desktops can be filtered out of the recovery based on naming conventions but all desktops on the datastore will be replicated.
• One VLAN will be defined for desktops and one for Appliances. If you use multiple VLANs for desktops contact us and we will work on a custom solution to that issue.
• In DR if a separate vCenter and Horizon View Replica Group will be used. The desktops being recovered will not already have existing entries in this View Replica Group.
• Datastore Names will be the same in Production and DR. Datastore names will be unique within each vCenter.

Two scripts are used for the processing. DRRESTART will find VMX files, Add desktops to vCenter and start them. The Update View script will process the running desktops adding them into the correct View Pools and assigning the correct user to the desktops.

DRRESTART will also add all the CachePoints and start them once all the desktops have been added and started. The CachePoints come last to ensure that if they have any tasks waiting to run on desktops they don’t perform those tasks until the desktops are fully reconfigured.

The last scripted part of the process is to update three tables in the Management Appliance Database that store Network Ids. Since the IDs are different in this new vCenter these must be adjusted by the script.

Important! The last step in the recovery is to perform a Synchronize Infrastructure in the Unidesk Management Console for all the CP Appliances and their desktops. Unidesk tracks appliances and desktops using their VMID. All the VMIDs will be new in the DR vCenter. This command will sync up the machines using name and network.

The utility is created using several components:

• Console Machine to run the DRRESTART.ps1 script that finds vmx files on a datastore then adds them into vCenter and starts them.
• A set of folders on an SMB share to hold flag files that are used both for reporting and integration between the two scripts.
• A script running on a View connection server that reads the flag files, adds the desktops into View and assigns the desktops to users in View.

All of these components can be installed and run from a View Connection Server or two machines can be used to run the scripts with an available SMB share.

The diagram below shows the interaction between script components.

• Add Desktop To vCenter/Host
  • Filter based on Naming Convention
• Optionally Set Network Adapter to New Network
• Optionally Remove/Add Disks
• Start Desktop
• Check for Running
• Add Flag File to Running or NotRunning
• Get Flag File From Running
• Add Desktop to VMware View Pool
• Test Addition to View
• Move to ViewAdded or ViewNotAdded
• Assign Desktop to User
• Test Assigned User
• Move Flag file to Assigned, NotAssigned_NoUser, or NotAssigned_Error

p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 10.0px Helvetica; color: rgb(96,96,96); }

p.p1 { margin: 0.0px 0.0px 0.0px 0.0px; font: 10.0px Helvetica; color: rgb(96,96,96); }

First download the zip. Before unzipping the download, check the properties of the zip file to see if they are blocked as shown on the right. If they are click unblock. This will unblock all of the files as long as you unblock the zip before you extract the files.

In powershell the execution policy should be set to remotesigned or unrestricted. The utility is a 32 bit application so the PowerShell called will be the 32 bit version. Then extract to a folder and open the executable.

DR Restart

This interface allows you to enter the information required by the utility.

• Configuration onfiguration Step 1 – vCenter Connection Information

Once the Utility is opened enter the vCenter connection information and click Save Credentials. The credentials are saved encrypted using the logged in user and the machine the encryption was run on. If you configure the utility but don’t use it, then come back and log in as a different user the credentials must be saved again or the script will not be able to unencrypt the password.

• Misc Configuration

In this section you will add most of the configuration information including the folder the desktops and appliances will be added to in vSphere, whether or not to integrate with the VMware View script to add desktops to View, if using the broker integration you must also create an SMB share to hold the flag files then enter that share here.

Batch Size and Wait Time

This functionality is intended to ensure that the infrastructure is not overwhelmed by starting too many desktops at once. The script will start the number of desktops defined in batch size the wait the time defined in Wait Time before starting the next batch. If you are using the remove add disks option, there is a significant mount of processing of each desktop so the wait time should be set to a longer amount. The processing during the startup process is run in parallel for all the desktops defined in the batch size so the starts should happen approximately at the same. The last setting in this section is to tell the script whether or not to remove all the disks and attach them back in. This is used if the replicated storage when remounted in the DR site has a different disk signature than the original datastore in the primary site.

• Information Loaded from Configuration Files

The script uses a series of files to define important information for the recovery. The UI shows the file information on the right.

Configuration Files

The DR scripting for adding and starting desktops is driven by a set of configuration text files stored in the config folder. These files must be created and loaded before using the utility.

The following files are required:

• Hosts.txt

• Datastores.txt

• Cps.txt

• Networks.txt

• DesktopNamingInclude.txt

• DesktopNamingInclude.txt

• PoolMap.txt

• Uuidmatch.txt

The format of each file is listed below

a. Hosts.txt - One hostname per line. The hostname should match what is defined in vCenter for each host. Usually the FQDN

b. Datastores.txt - One Boot Image Datastore per line. The Datastore name should match that defined in vCenter. Only Boot datastores should be added here.

c. Cps.txt - This file is used to define the path to each CP’s vmx file. The format is “[Datastore] cpname\cpname.vmx

    Note: This line is Case Sensitive make sure the Case is correct for the entire path.

d.DesktopNamingIncude.txt - If a boot datastore contains non-unidesk desktops or CPs as well as Unidesk desktops you can have the utility filter the found vmx files based on a naming standard. The naming standard is defined by the first x characters of the name. So for example If the vdi desktops all start with “vdi-“ you enter that into the DeskotpNamingInclude file and only VMs that start with “VDI-” will be processed.

    Note: To skip the filtering for naming convention add “ALL” as the only entry in this file.

e. DesktopNamingExclude.txt - If a boot datastore contains non-unidesk desktops or CPs as well as Unidesk desktops you can have the utility exclude the found vmx files based on a naming standard. The naming standard is defined by the first x characters of the name. So for example If the appliances all start with “UniCP“ you enter that into the DeskotpNamingExclude file. If there is no pattern to your naming you can add the entire name for each appliance or non Unidesk vm on the datastore.

f. Networks.txt - Unidesk stores Network/VLAN Ids in several tables in the Management Appliance Database. The networks are stored by Name and also ID. When adding the desktops into a new vCenter the Network can have the same name but it will have a different ID so the script needs this file to replace the old ID with the new ID. It also allows you to define a totally new netwo9rk name and that change will be applied to the desktops before they are started. This file is used only by the DRRESTART script. Make sure to include this file in the config folder on the machine running this script..

In vSphere networks are defined in the VMX file differently for standard and distributed switches. Standard Networks just use the driver and Network Name. These do not need to be updated unless the name changes. But distributed switches are defined using the Port Group ID. So this must be changed on the desktops in DR.

The format is Type, Old Network Name , Old Network ID , New Network Name, New Network ID

Example:desktops,VM Network,Network-37, VM Network ,Network-2476 appliances,Mgmt Network,Network-49392, Mgmt Network, Network-99988

To find out what the IDs are you can use the vCenter Managed Object Browser or MOB.

Browse to https://<vcenter address>/mob

Then click on Content and scroll down to rootFolder it should say group-d1(Datacenters) and click on that. 

You should then see all your datacenters click on the appropriate one for VDI.

Then go down the page to network. This shows the network names (Isolated Network, SandboxNetwork, VM Network etc) with their

network IDs (network-46995,network49392,netwrk-37 etc)

g. PoolMap.txt - This file is used only by the DRUPDATEVIEW script. Make sure to include this file in the config folder on the connection server if running the utility scripts from different machines. It provides the mechanism to match pool names from the primary View Replica Group to the DR View Replica Group. The format of the file is Primary Pool DR Pool. If both are the same then enter them that way but both primary and DR and required.

h. Uuidmatch.txt - The uuid is the same thing as a disk signature. In some cases it it easy to keep the disk signature of the production datastores when attaching replicated datastores in the DR sight and in some cases it is not. This functionality allows you to reset the disk signatures when the script runs to the new signature but to do this the script has to know what datastore name is associated with the old signature and you have to keep the datastore names the same as the original datastores.

If you are using the functionality to remove and read the disks to update the datastore UUIDs then you must create a mapping between the production uuids and datastore names for the script to use.

To make this easy I created a PowerShell script that captures the uuid/datastore name match. It is called CreateDSMatch.ps1 and its located in the PowerShell folder. To run the utility modify lines 13 and 14 for your environment and run the script. It will create the uuidmatch.txt file. Check to make sure it worked. Remember that if you are failing back from DR to production you will need to update this file to the DR location settings.

 

DR Update View

To configure the DR Update View script open the utility (drupdateview.exe) to see the following screen. Enter the IP or FQDN of the Management Appliance. If you have worked with support to change the Management Appliance root password enter the password here. Leave blanks for the default root password.Then enter the flag share and press the Create Flag File Folders button to create the 7 folder required.

Note: The share must be created before this step and the logged in user must have modify permissions for the target folder.

Then add wait time between processing runs.

Finally click Save Configuration

• Add Management Appliance to vCenter Inventory
• Edit Properties on the MA and Add DR Hosts and Storage
• Run the DRRESTART Script
• Allow All Desktop and CPs to start up
• In the MA console run “Sync Infrastructure” for All CPs.

To start each utility run the executable, review the settings and click “run”. The DR Update Vew script will process any desktops that are configured to be added to vSphere based on the flg files in the Running folder. Therefore the Update View script can be started before or anytime after the DR Restart script.

The last step in the recovery is to perform a Synchronize Infrastructure in the Unidesk Management Console for all the CP Appliances and their desktops. Unidesk tracks appliances and desktops using their VMID. All the VMIDs will be new in the DR vCenter. This command will sync up the machines using name and network.

Note : They can all be selected within the table then click the sync infrastructure button.

Progress of both scripts can be monitored by reviewing the folders in the SMB share. When desktops are successfully started their flag file will be created in the Running folder. Any desktops in the NOTRUNNING folder should be immediately investigated as the script was not able to add or start those in vCenter.

If the View Update script is being used desktops will be moved from the RUNNING folder to the ViewAdded or ViewNotAdded folders. The later indicates a failure to add the desktop to View.

For the added desktops the script will assign users and move the desktop flag file to one of three folders:

• Assigned

• NotAssigned_NoUser

• NotAssigned_Error

Both assigned and NotAssigned_NoUser are successful states. If a desktop is moved to NotAssigned_NoUser the desktops did not have a user assignment in the primary View pool. Desktop whose flag file is moved to the NotAssigned_Error folder should be reviewed to see why they could not be added to the pool. To see what user the script was trying to assign to the desktop open the flag file.

Log files are located in a log folder under the folder created to store the utility. To View the logs click “Open Log Folder” in the utility. Logs are listed by the date and time when the utility was run.

The log file detailed each step of the process as it happens. The log will also show warnings or errors that happened during the processing.

 

DR Restart

The DR Restart will have entries for each desktop and CP processed. The log will show status and errors.

Update Networks

At the ned of the DRRESTART script the UpdateNetworks script is called. This script is used to modify three tables in the Management Appliance Database. If successful you will see log entries like the ones shown below. Check the Summary section and make sure the before and after count matches for each table. If it does not contact support.

Note: you can run the UpdateNetworks.ps1 scritp on its own if you didn’t set up the networks.txt file correctly.

 

DR Update View

The log file for the DR Update View utility will show every desktop found and results for that desktop. The log will also show statistics for each batch run and any errors that happen during the processing.