In the EUC workspace, application layering is not to be ignored as a solution to maximize flexibility combining applications in an image resulting in a lower amount of images needed, and minimize the effort maintaining image updates. The most known products in this workspace also provided by the main vendors in this workspace are;
The focus of this article will be around Citrix App layering.
At a customer we planned multiple enterprise layer manager (ELM) appliances to process layer updates and images trough a DTAP (Development, Test, Acceptance and Production) -like workflow. In this situation we started with two appliances. One for development, test and acceptance and one for production. The DTA appliance helps us to develop and build (an sometimes break) stuff without effecting production, test appliance upgrades and lab features etcetera. The production appliance which should stay stable and ‘clean’ is the final destination for layered images.
Administering which layers have been updated and what layers are referenced in an image can be hard as there’s no build-in functionality to do so. Let alone that you should keep this in sync manually! on multiple appliances. For everyone who has tried this before, you really want to automate that.
Citrix does not provide integrated functionality for exporting and importing layered images while that functionality is there for the layers. I started searching for a possible community contribution which could make it feasible to solve my challenge in an out-of-the-box way. I stumbled on a GitHub project from Ryan Butler who wrote a reversed engineered SDK that emulates the SOAP calls that Citrix App Layering uses to manage the appliance.
It already included a great amount of powershell scripts to automate the creation of layers and managing layered images on the appliance. I felt that it made sense to start leveraging this great SDK and apply for some additions to meet my goal. Literally one day later new commandlets with the necessary logic were provided by Ryan getting me going.
For download of the SDK and install instructions see this link.
The automation process:
To be changed initially prior to running the script;
Define appliance full qualified domain names for both DEV and PROD
Define fileshare location to export/import the layers
The following steps are processed while running the script.
Provide credentials to connect to the applicance (we assume the credentials will be the same for both),
Provide credentials to connect to the fileshare (R/W Permissions required),
Getting the existing images from the Dev Appliance and present a gridview to select the image(s) to process (multi-select is possible).
Retrieving the details for all layer revisions on the appliance and store them in an array ($AllLayersRevDetailsDEV),
Comparing the array with the contents of the selected image(s),
Building a new array table containing the specifc image layers details which is used to compare the imported layers against in the follow-up stage ($ImageLayersDEV),
Building the list of layers from the image to process to be exported and export those which do not exist already on the fileshare,
Retrieve all importable layers based on the ImageLayers Table defined previously and import those which do not already exist on the appliance,
Retrieving all the details for all layer revisions on the Prod appliance and store them in an array ($AllLayersRevDetailsPROD),
Retrieve the layer revision Id matching the guid in the $ImageLayersDEV table created prior to the export,
Store the Layer revision Id to be used for the image creation,
(re)create the Image
Build the array table with the created image details for a visible comparison ($ImageLayersPROD)
Purpose: Clone existing image(s) from the DTA appliance to the Prod Applicance using a (multi-select) gridview selection window. It also provides an argument to publish the image from the prod appliance after import. One at the time
Parameters: The parameter section for the script let you choose between two appliances if you like. In my scenario I have a Development/Test/Acceptance and a Prod appliance to choose from. The credential environment allow for a PSCredential object as input or a username object which presents a popup to provide the admin credentials to connect to the appliance with the appropriate permissions.
$publish = "NO", #define if image need to be published or not
$Inputpath, # provide the path to the Images4$Environment.json file containing the references names for the images to export
$Credential = [System.Management.Automation.PSCredential]::Empty
DTAAppliance: The name of the Dev/Test/Acceptance appliance
PRODAppliance: The name of the Production appliance
logpath: Place the FQDN UNC path for the logfile here
HVConnectorProd: Place the name for Production Hypervisor Connector
Mypath: Place the FQDN UNC path for the export/import location
Skiplast: The number of most recent exported layers to keep on $mypath, older ones will be removed at the end of the process
$DTAApliance = "DTAAppliancehere"
$PRODAppliance = "PRODAppliancehere"
$logpath = "loguncpathhere"
$HVConnectorProd = "hypervisorconnectorenamehereD" # Place the name for Production Hypervisor Connector
$mypath = "\\importexportuncpathhere\layers$"
$Skiplast = "3"
[6 February 2019 – streamlined output, test AD credential and included Image size sync
be sure to set the management console timeout long enough, so the websession is not interrupted to soon. I have set it to three hours (180 mins)
I’m still working on to export/import the image associated icon, this is a bit challenging but hopefully can be added in a subsequent revision.
Automate Layers creation
See the following blog from Chris Jeucken for a great example on how to fully automate the creation of layers using the same SDK as used above.