Citrix PVS Image Preparation Script for XenApp 7.x Workloads

With this post I share a Powershell script that prepares the master installation of a XenApp 7.x Worker for imaging with Citix Provisioning Services, Prepare-XenApp7.ps1.

Due to fact that Citrix has ported its flagship XenApp to the architecture that was introduced with XenDesktop 5, there’s strictly speaking no need to generalize the PVS vDisk that provides the workload of a XenApp Worker because it doesn’t contain IMA-related stuff anymore. On the other hand there’s still room for some optimization steps before putting a XenApp vDisk into production/standard mode. The script automates the following steps:

Investigate the PVS’ Personality.ini in the root of the system drive in order to determine the disk mode that is read-write, read-only, or started from local HD

Clear Citrix User Profile Manager’s cache

Resync time

Update GPO settings

Clear network related caches (DNS and ARP)

Clear WSUS Client related settings

Clear event logs

Based on the findings in Step 1, suggest a convenient main action, that is either “Exit” (if we’re in maintenance/private w/ read-write vdisk access), or “Invoke ImagingWizard” (if we started from local HD), or “Invoke XenConvert” (reverse imaging scenario w/ read-only vdisk access)

BTW, the script should work for desktop workloads as well but I haven’t tested it so far.

“Is there something like WSUS for XenApp, or is it possible to extend Microsoft WSUS in order to download and apply updates and hotfixes to our XenApp servers?” No. But you can try my simple XenApp hotfix deployment framework that I want to share with you today.

Introduction

While (Cloud) service providers have evolved (or are evolving) an ideal approach to maintain their XenApp server farms there are uncountable companies across all sizes that are running one or more XenApp farms w/o a proper maintenance concept. Plenty of these companies indeed have service time windows with corresponding tasks. But quite often the implementation lacks class meaning that at the worst the admin updates each and every damned (sorry) XenApp server by hand.

A year ago or so, I developed a bunch of batch files that build a simple script framework for automated XenApp hotfix installation. My goals were to build a solution that supports the broadest range of XenApp farms as possible on the one hand and to build a “learning” framework that identifies new hotfixes in the source folder tree on its own (and releases the admin from the challenge to script). Therefore I chose Batch scripting and ini files instead of PowerShell and XML. Furthermore my solution either relies on MFCOM (API for legacy XenApp before version 6) nor it uses XenApp PowerShell Cmdlets. It just leverages cmd.exe and some standard commands that you’ll find on every Windows Server with Terminal Services or Remote Desktop Services. In short, the XenApp hotfix deployment framework is designed to update XenApp 4.5/5.0/6.0/6.5 on Windows Server 2003/2003 R2/2008/2008 R2.

Simple means basic. Please don’t expect a superduper allrounder solution. The script framework cares about the sessions though (if you want), gives them some (configurable) grace time and repeatedly sends a warning message. And it disables logons as well. This seems quite a lot but in a perfect world you would like a solution that monitors itself and stops processing on all remaining servers in case of fault for example.

Requirements

The XenApp hotfix deployment framework just needs storage space on a central folder share. The scripts and related files on its own allocate less than 200 KB, but you need to take the hotfix files into account as they’ll be stored inside the framework’s folder structure as well.

Strictly speaking, a dedicated active directory account that runs the maintenance process is not really required. But it is recommended to create such an account, especially if you opt for an automated invocation of the maintenace process via scheduled task for example.

Give the account that runs the maintenance appropriate access on the above mentioned share. Of course the account needs administrative access on the XenApp servers to be able to install the hotfixes successfully.

That’s all, nothing more required from a technical perspective.

Overview

The XenApp hotfix deployment framework consists of a main script, a bunch of library scripts, one or more config files, a folder structure, and – last but not least – a naming convention with a hidden sense (below more).

The main script, XenAppMaintenance.cmd, initializes and controls the progress of the maintenance work.

The config file, Settings.ini, includes changeable global settings that configure logging and session warning timeframe for example. Additional config files (per XenApp Server) can be placed aside the Settings.ini in order to overwrite to common settings for whatever reason or purpose.

The folder structure separates the framework components. This helps the admin to locate easily a config file or to save a new hotfix for example.

The naming convention for additional config files, for library scripts, and hotfix subfolders make up an important part of the framework. For example a part of a hotfix subfolder name is tied to the library script that the framework shall use in order to install the hotfix inside that folder.

Download and unzip the XenApp hotfix deployment framework to the shared folder

Open the file\Config\Settings.ini in order to configure settings (optional).

Download hotfixes from www.citrix.com. For each hotfix, create a subdirectory in the Source folder of the framework. A hotfix subdirectory consists of three parts separated by an underscore: three-digit installation order number, action library script, and optionally a comment. For example, the subdir “010_InstallMsp_CTX126679” stands for order number 10, use action script “InstallMsp” to install the hotfix, and article number CTX126679.

Invoke Maintenance

This is simple. Just double click XenAppMaintenance.cmd or create a scheduled task.

Disclaimer: I hope that the information in this post is valuable to you. Your use of the information contained in this post, however, is at your sole risk. All information on this post is provided “as is”, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by me. Further, I shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

This post outlines the steps to build a Reverse Image of a Citrix Provisioning Services vDisk with XenApp 6.5 Server to a VM with locally attached hard disk.

Whenever you have to install or upgrade software on a vDisk that interferes directly with the Citrix Provisioning Services infrastructure you need to choose the Reverse Imaging approach. The installation of such software would fail within a system that was booted either from the vDisk in Private mode or from a Maintenance version of the vDisk.

Reverse Imaging means booting from vDisk in order to capture the vDisk’s contents to a local hard drive. Afterwards you can boot from the local hard drive an make the changes without any of those issues that would arise if you’d have tried to change the vDisk directly.

Reverse Imaging is a time-consuming task. Normally you’ll capture a new vDisk following the Reverse Imaging process. In total you should plan a man-day including preparation, performing the Reverse Imaging, applying the updates, and capturing a new vDisk. Therefore, I recommend to start with it just at the beginning of the work day.

Dedicate or create a VM and PVS target device for the Reverse Imaging process. (For istance, an already existing update VM/target device for vDisk maintenance purposes would be a perfectly possible candidate for Reverse Imaging.)

Create and attach a new local hard disk to the Reverse Imaging VM that matches at least the size of the vDisk. (The HD size can be greater though, meaning that with Reverse Imaging you can’t only update software like VMware Tools but also increase the vDisk size as a side benefit.)

Prepare the source vDisk using one of this options:

Create a new version of the vDisk and keep the predefined mode, that is “Maintenance” (PVS 6 style)

Copy the vDisk and put it in Private mode (PVS 5 style)

Check or set the following target device properties:

Boot from: vDisk

Type: Maintenance

Double-check the target’s vDisk assignment. (Use the vDisk prepared in the third step)

Boot the target VM from vDisk and log on

Launch the disk management mmc snap-in.

Initialize the new local hard disk. (Keep default settings.)

Partition and format the hard disk. Keep the default disk type (Basic). The partition needs to be either a simple volume or at least a primary partition. (PVS reverse imaging doesn’t support both extended partitions and dynamic disks.)

Once again, the Image Builder will automatically reboot the target. Log on and confirm a message box saying “The device image build is complete”

Launch the disk management mmc snap-in and mark the partition of the new local hard disk as active.

In the PVS console, change the target’s “Boot from” setting to “Hard Disk”

Reboot the target and apply the required changes, updates, whatever..

Prepare capturing of a new vDisk with PVS Imaging Wizard, reboot, and log on to let XenConvert building the vDisk.

Close XenConvert to let Windows finalize the logon process.

In the PVS console, change the target’s “Boot from” setting to “vDisk”. Leave the vDisk in Private mode

Shutdown the target device VM.

Detach the local hard disk that was used to hold the Reverse Image.

Boot the target device VM and log on.

Launch the XenApp Server Role manager to prepare this server for imaging. (As the server already left the farm in step 8 you need to deselect the corresponding option.)

Shutdown

In the PVS console, change the new vDisk’s mode to Standard and configure the relevant targets to boot from this vDisk.

Clean up. For example you won’t ever use again both, the local hard disk created in step 2 and the Private mode vDisk or vDisk Maintenance version prepared in step 3.

Disclaimer: I hope that the information in this post is valuable to you. Your use of the information contained in this post, however, is at your sole risk. All information on this post is provided “as is”, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by me. Further, I shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

Run XenAppConfigConsole to prepare the server for imaging. (Based on the script user’s choice locally stored XenApp database information will be either kept or cleared from mf20.dsn and LGPO. Default is keep db information. If you choose to clear them you need to provide DB information through GPO.)

Clear XenApp related caches (LHC and RADE)

Clear Citrix User Profile Manager’s cache

Resync time

Update GPO settings

Clear network related caches (DNS and ARP)

Clear WSUS Client related settings

Clear event logs

Based on the findings in Step 1, suggest a convenient main action, that is either “Exit” (if we’re in maintenance/private w/ read-write vdisk access), or “Invoke ImagingWizard” (if we started from local HD), or “Invoke XenConvert” (reverse imaging scenario w/ read-only vdisk access)

The script raises no claim to completeness. For example, you should consider running chkdsk C: as consistency check and Mark Russinovich’s SDelete to reduce storage needs.

Disclaimer: I hope that the information in this post is valuable to you. Your use of the information contained in this post, however, is at your sole risk. All information on this post is provided “as is”, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by me. Further, I shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

With this post I want to share a simple approach to restart Citrix XenApp 6.5 servers within a given timeframe, each at a different time. Yes yes, there are Citrix policies to do that, but these settings only take effect with XenApp 6.5 Platinum Edition. If your company didn’t purchased Platinum licenses you need to rely on “traditional” ways like my ordinary scripted solution.

First take a look at this small PowerShell function Restart-ComputerSoon:

PowerShell

1

2

3

4

5

6

7

8

functionRestart-ComputerSoon

{

param(

$Timeframe=1800

)

$Timeout=(New-ObjectSystem.Random).Next(0,$Timeframe)

shutdown.exe/f/r/t$Timeout

}

If you execute this function on all XenApp servers at the same time (as a scheduled task), each server will actually restart at a different time because the function uses a randomly chosen amount of seconds to delay the restart.

Please don’t consider this a perfect solution. The function just cares about issuing a shutdown.exe command within a timeframe of 30 minutes (by default). But it doesn’t care about existing user sessions and giving them a chance to log off for example.

Administrators of Citrix XenApp (formerly known as: Presentation Server) normally use a Load Evaluator with an empty Schedule Rule to take a server offline for maintenance or troubleshooting purposes. An empty Schedule Rule maximizes the server’s load, thus it won’t accept any new ICA sessions while all active sessions are not affected. Compared to CHANGE LOGON /DISABLE the “Offline Load Evaluator” allows disconnected user’s to reconnect to their sessions, and Administrators are still able to establish new RDP sessions.

The PowerShell script in this article uses MFCOM to create the Load Evaluator and can be used in automated Citrix Farm setups.

Creating a new Load Evaluator and attaching a Rule to it is straightforward:

This article provides the script AttachLoadEvaluatorToServer.vbs that attaches a Load Evaluator to a Citrix terminal server. The script is proven in CPS 4.0 and 4.5 environments, and thanks to the hint of one of my fellows at Login Consultants it supports now the built-in Load Evaluators “Default” and “Advanced”.

Given that you have a Load Evaluator to put a terminal server in offline mode – that is a Load Evaluator with an according Scheduling rule to disable ICA logons – this script is useful for automated installation or maintenance tasks.

Since AttachLoadEvaluatorToServer.vbs automates a Citrix server configuration it’s no surprise that it requires MFCOM. Therefore you should it execute on a Citrix terminal server. You need to specify the computer name of a terminal server in the farm and the exact name of the Load Evaluator as arguments. Listed below some examples to clarify the usage of the script…

This one attaches the Load Evaluator “DisableIca” to the Citrix server “ctx01”:

Example Call AttachLoadEvaluatorToServer #1

Visual Basic

1

cscript.exe AttachLoadEvaluatorToServer ctx01 DisableIca

To attach the Load Evaluator “Advanced” to the Citrix server that executes AttachLoadEvaluatorToServer.vbs type: