How to deploy dedicated Ubuntu VDA through MCS

Step 1: Create Ubuntu 16.04 VM on Hypervisor such as VMware vSphere or Citrix XenServer

Step 2: Install Hypervisor tools

Step 3: Install Linux VDA

sudo dpkg -i <PATH>/<Linux VDA deb>

sudo apt-get install -f

Step 4: Set up the runtime environment to complete installation

sudo /opt/Citrix/VDA/sbin/

Step 5: Configure mcs.conf

Change variables in /var/xdl/mcs/mcs.conf. The mcs.conf configuration file contains variables for setting MCS and the Linux VDA. The following are variables you can set as required:

dns: Sets the DNS IP address.

AD_INTEGRATION: Sets Winbind or SSSD (SSSD is not supported on SUSE).

WORKGROUP: Sets the workgroup name (case-sensitive) if it is configured in AD.

For dedicated single session VDA, set VDI_MODE=Y

Step 6: Shutdown VM and take snapshot.


  • No Related Posts

App Layering: Machine Time on a Published Image is Wrong at First Boot

You can always manually set the time once the machine starts, but that might be a pain to remember to do every time you publish a new image.

The initial clock time in Windows on a physical machine comes from a battery-powered clock on the motherboard (called TOD for Time Of Day), which is set to the local time in Windows’ current timezone. In a virtual machine, the virtualized TOD clock is set by the hypervisor at bootup. Since hypervisors normally know the time in GMT rather than a local timezone, your hypervisor has to know what “local time” is for your Windows instance in your virtual machine before it powers on. If the hypervisor doesn’t know the conversion factor for the VM’s local timezone, the initial time can be off by hours. Hypervisors learn the machine’s local time zone pretty quickly, but it means that the first boot for any VM is usually wrong.

In a published App Layering image, unless your template is derived from a VM that was originally a full Windows machine set to the correct timezone, the first boot usually has bad clock time. However, if your Platform Layer was added to the domain, your published VM should also have the correct information for how to sync its clock with the Domain Controller.

So make sure your Platform Layer was joined to the domain, so it can immediately correct the clock discrepancy.

Otherwise, consider setting this registry key so that Windows will treat the motherboard clock as being in UTC rather than the local timezone:


“RealTimeIsUniversal”=DWORD 1

Some hypervisors store the local timezone offset for a VM as a virtual motherboard resource. When Windows is running, every time it updates the clock time, it sets the motherboard resource to be the correct time. This is how your hypervisor finds out what the timezone offset for this VM is: because Windows is always writing local time to the motherboard, all your hypervisor has to do is compare the motherboard resource for the TOD clock to the hypervisor’s own clock. That timezone offset is an attribute of the VM itself, not part of Windows and not part of the virtual disk.

Note that Nutanix does not currently notice and record the time zone offset of a VM. You would need to set it manually. See this thread, for instance:

It may be worthwhile to generate a new template for your Connector, by having (or building) a Windows VM that has booted in the correct time zone. If you have a template you want to continue using, for instance, convert it to a VM, attach a bootable Windows disk (or boot from PVS or something like that – it’s just important that Windows run on this machine), power the machine on, and set the clock correctly. When you adjust the clock, Windows writes it to the motherboard, and your hypervisor records the offset in the virtual machine parameters. Then you can shut the machine down, remove any extra disks, and convert it back to a template.

You can also just take a working Windows machine with a correct local time, shut it down, clone it, remove any extra disks, and convert that to a VM template. This is one good reason to make a template out of a clone of your original Gold VM that you imported your OS Layer from: it already has all the virtual hardware parameters you want, including the local clock offset. Now that your template includes the current timezone offset, your hypervisor will be able to set the initial motherboard TOD clock correctly, meaning Windows has the correct time immediately and doesn’t need to wait for a jump when AD comes in to set the clock.

Configure your Connector to use this template so that newly published images will be correct. If you are using PVS, you should also use this template to build your Target Machines so that the virtual hardware of your Target Machines matches the hardware your layers were built from, including the local timezone offset.

Note that it’s also possible to have your hypervisor’s internal clock wrong. Also, your PVS server will try to set the machine’s clock based on the PVS server’s local clock. If any of these are wrong, you will need to get them synched as well.


XenServer 7.1 Cumulative Update 2

Who Should Install This Cumulative Update?

XenServer 7.1 Cumulative Update 2 (XS71ECU2) must be installed by customers running XenServer 7.1 LTSR CU1. It includes all previously released XenServer 7.1 CU1 hotfixes. Installation of XS71ECU2 is required for all future functional hotfixes for XenServer 7.1 LTSR.

XenServer 7.1 Cumulative Update 2 and its subsequent hotfixes are available only to customers on the Customer Success Services program.

Citrix will continue to provide security updates to the base XenServer 7.1 CU1 product for a period of three months from the release date of the XenServer 7.1 Cumulative Update 2 (until March 12, 2019). After this three month period elapses, any new hotfixes released will only support XenServer 7.1 with CU2 applied.

For more information about XenServer 7.1 CU2, see the Citrix XenServer 7.1 Cumulative Update 2 Release Notes.

Information About this Cumulative Update

Component Details
  • XenServer 7.1 CU1.

  • Licensed customer with Customer Success Service

Post-update tasks Restart Host
Content live patchable* No
Revision History Published on December 12, 2018
* Available to Enterprise Customers.

Included in this Cumulative Update

This cumulative update includes the following previously released hotfixes.

This cumulative update also includes additional fixes. For a list of the issues resolved by XenServer 7.1 CU2, see the Citrix XenServer 7.1 Cumulative Update 2 Release Notes.

Installing the Cumulative Update

Customers should use either XenCenter or the XenServer Command Line Interface (CLI) to apply this cumulative update. When the installation is complete, see the Post-update tasks in the table Information About this Cumulative Update for information about any post-update tasks you should perform for the update to take effect. As with any software update, back up your data before applying this update. Citrix recommends updating all hosts within a pool sequentially. Upgrading of hosts should be scheduled to minimize the amount of time the pool runs in a “mixed state” where some hosts are upgraded and some are not. Running a mixed pool of updated and non-updated hosts for general operation is not supported.

Note: The attachment to this article is a zip file. It contains the cumulative update update package only. Click the following link to download the source code for any modified open source components XS71ECU2-sources.iso. The source code is not necessary for cumulative update installation: it is provided to fulfill licensing obligations.

Installing the Cumulative Update by using XenCenter

Before installing this cumulative update, it is recommended that you update your version of XenCenter to the latest available version for XenServer 7.1 CU 2.

Choose an Installation Mechanism

There are three mechanisms to install a cumulative update:

  1. Automated Updates
  2. Download update from Citrix
  3. Select update or Supplemental pack from disk

The Automated Updates feature is available for XenServer Enterprise Edition customers, or to those who have access to XenServer through their XenApp/XenDesktop entitlement. For information about installing a cumulative update using the Automated Updates feature, seeApply Automated Updates.

For information about installing a cumulative update using the Download update from Citrix option, see Apply an updates to a pool.

The following section contains instructions on option (3) installing a cumulative update that you have downloaded to disk:

  1. Download the cumulative update to a known location on a computer that has XenCenter installed.
  2. Unzip the cumulative update zip file and extract the .iso file
  3. In XenCenter, on the Tools menu, select Install Update. This displays the Install Update wizard.
  4. Read the information displayed on the Before You Start page and click Next to start the wizard.
  5. Click Browse to locate the iso file, select XS71ECU2.iso and then click Open.
  6. Click Next.
  7. Select the pool or hosts you wish to apply the cumulative update to, and then click Next.
  8. The Install Update wizard performs a number of update prechecks, including the space available on the hosts, to ensure that the pool is in a valid configuration state. The wizard also checks whether the hosts need to be rebooted after the update is applied and displays the result.
  9. In addition, the Install Update wizard checks whether a live patch (this is an Enterprise Edition feature) is available for the cumulative update and if the live patch can be successfully applied to the hosts.

    Follow the on-screen recommendations to resolve any update prechecks that have failed. If you want XenCenter to automatically resolve all failed prechecks, click Resolve All. When the prechecks have been resolved, click Next.

  10. Choose the Update Mode. Review the information displayed on the screen and select an appropriate mode. If the update contains a live patch that can be successfully applied to the hosts, it displays No action required on the Tasks to be performed screen.
  11. Note: If you click Cancel at this stage, the Install Update wizard reverts the changes and removes the update file from the host.

  12. Click Install update to proceed with the installation. The Install Update wizard shows the progress of the update, displaying the major operations that XenCenter performs while updating each host in the pool.
  13. When the update is applied, click Finish to close the wizard.
  14. If you chose to carry out the post-update tasks, do so now.

Installing the Cumulative Update by using the xe Command Line Interface

  1. Download the cumulative update file to a known location.
  2. Extract the .iso file from the zip.
  3. Upload the .iso file to the Pool Master by entering the following commands:

    (Where -s is the Pool Master’s IP address or DNS name.)

    xe -s <server> -u <username> -pw <password> update-upload file-name=<filename>XS71ECU2.iso

    XenServer assigns the update file a UUID which this command prints. Note the UUID.


  4. Apply the update to all hosts in the pool, specifying the UUID of the update:

    xe update-pool-apply uuid=<UUID_of_file>

    Alternatively, if you want to update and restart hosts in a rolling manner, you can apply the update file to an individual host by running the following:

    xe upload-apply host-uuid=<UUID_of_host> uuid=<UUID_of_file>

  5. Verify that the update was applied by using the update-list command.

    xe update-list -s <server> -u root -pw <password> name-label=XS71ECU2

    If the update is successful, the hosts field contains the UUIDs of the hosts to which this cumulative update was successfully applied. This should be a complete list of all hosts in the pool.

  6. If the cumulative update is applied successfully, carry out any specified post-update task on each host, starting with the master.


Hotfix File

Component Details
Hotfix Filename XS71ECU2.iso
Hotfix File sha256 64b9d387cfc79fb97245a2425babaa4f46ccf9edf4730cde18fea7fe954a0f42
Hotfix Source Filename XS71ECU2-sources.iso
Hotfix Source File sha256 e46f7d3fb31b8e4bafcd5a49c06ce7b0d55f486489efd618514452aafb6c4305
Hotfix Zip Filename
Hotfix Zip File sha256 7cb0130b2ac64e4c5c7ccbe57ea232ff1224888b0a4848d20d8ca0674614ba08
Size of the Zip file 277.16 MB

Files Updated


More Information

For more information, see the XenServer 7.1 Documentation.

If you experience any difficulties, contact Citrix Technical Support.


  • No Related Posts

Upgrading OE on Unity that is configured for file services only

it depends what you understand as “disrupt connectivity”

a reboot – no matter how fast – will always be kind of disruptive on the lower levels

and a client will have to at least re-establish the TCP connection

The question is more how much of that is visible to the client OS and application

NFS clients using default hard mounts will just see a pause in I/O but no error to applications

The OS and protocol stack will of course re-establish the connection, recover locks, ….

for CIFS clients it depends on the application and OS

Windows itself will automatically reconnect

cluster aware application that retry internally should be ok

simple applications like copying files via explorer.exe can stop and show a “Try again” dialog

For those application that really require transparent failover – like SharePoint or Hyper-V over SMB shares you can enable SMB CA (Continuous Availability) per share

then they will also just pause and resume I/O similar to NFS

See the NAS white paper and Microsoft details about CA in SMB3

Why dont you just try it ??

all an upgrade is doing is a SP reboot – which you can easily do even from the GUI

If you dont want to use your hardware Unity as VSA will show the same behaviour


  • No Related Posts

FAQ: Personal vDisk in XenDesktop

Q: Can multiple PvDs be associated to a device/user?

A: There can only be one PvD per Virtual Machine. The PvD is assigned to a Virtual Machine when building the catalog of desktops. The pool type for a PvD catalog is a pooled static, which the desktop is assigned to the user on first use.

Q: Is the PvD a 1-1 mapping per user?

A: Actually, it is a 1:1 mapping to a Virtual Machine in a catalog, which is then assigned to the user on first use. A PvD is attached to a Virtual Machine assigned to the user. The administrator can move a PvD to a new virtual machine in a recovery situation.

Q: If you create a catalog for pooled with PvD, it does not mean that the user is always required to be assigned to that Virtual Machine defeating one of the benefits of a pooled?

A: The base image is still shared and updated across the pool. However, once the user makes an initial connection to a Virtual Machine, the Virtual Machine is kept assigned to the user.

Note: You must connect early in the starting stage long before you know who the user is in order to maximize the application compatibility for services, devices etc.

Q: How does the pooled with personal vDisk catalog affect idle pool?

A: After the user connects, this user is kept assigned to the Virtual Machine.

You must connect early in the starting stage long before you know who the user is in order to maximize the application compatibility for services, devices etc. So for hypervisor resource management, instead of idle pool management, you would use power management to handle Virtual Machine idle workloads.

Q: What Operating Systems are supported for PvD?

A: Windows 7 x86, Windows 7 x64, and Windows 10 up to v1607.

Q: Does Citrix 7.15 LTSR support Windows 10 1703 Semi-Annual Servicing Channel (SAC)?

A: Yes, XenApp and XenDesktop 7.15 LTSR supports Windows 10 1703 SAC. Reference Citrix product documentation for more information.

Q: Is PvD only for Desktop Operating Systems or will it also work with Server Operating Systems?

A: It is only supported on Desktop Operating Systems.

Design and Deploy

Q: What kinds of risks are there for BSODs with PvDs?

A: PvD is architected to be compatible with a wide range of Windows software, including software that loads the drivers. However, drivers that load in phase 0 or software that alters the networking stack of the machine (through the installation of additional miniports or intermediate or protocol drivers) might cause PvD to not operate as expected. You must install these types of software in the base Virtual Machine image.


Profile Management Configuration Checking Tool – UPMConfigCheck

Profile Management Configuration Check Tool (UPMConfigCheck)

Created Date: February 27, 2012

Updated Date: November 22, 2018


UPMConfigCheck is a PowerShell script that examines a live profile management system and determines whether it is configured optimally.


UPMConfigCheck requires PowerShell 2. UPMConfigCheck is designed to run on the Citrix Virtual Apps and Desktops (formerly XenApp servers and on XenDesktop) virtual desktops with Profile Management installed. Supported operating systems are the same as for Profile Management.

These include:

  • Windows XP (Deprecated since Profile Management 5.x)
  • Windows Vista (Deprecated since Profile Management 5.x)
  • Windows 7
  • Windows 8 and Windows 8.1
  • Windows 10, Windows 10 version 1607, Windows 10 version 1703, Windows 10 version 1709, Windows 10 version 1803, and Windows 10 version 1809
  • Windows Server 2003 (Deprecated since Profile Management 5.x)
  • Windows Server 2008 and Windows Server 2008 R2
  • Windows Server 2012 and Windows Server 2012 R2
  • Windows Server 2016 and Windows Server 2019

32- and 64-bit operating system versions, where available, are supported.

Installing UPMConfigCheck

The UPMConfigCheck tool is supplied in a zipped archive. Extract the contents of the file to a temporary folder on the machine under test.

Use Cases for UPMConfigCheck

UPMConfigCheck is designed to verify that Profile Management has been configured optimally for the environment in which it runs, taking into account:

  • Hypervisor DetectionThe presence or absence of supported hypervisors (for example, Citrix Hypervisor (formerly Citrix XenServer), VMWare vSphere, or Microsoft Hyper-V).
  • Provisioning DetectionThe presence or absence of a supported machine-provisioning solution (for example, Machine Creation Services or Citrix Provisioning Services)
  • Citrix Virtual Apps and DesktopsDetermines whether it is running in a Citrix Virtual Apps or Desktops environment
  • Personal vDisk Configuration – Determines whether the Personal vDisk feature of Citrix Virtual Desktops is enabled; reports the percentage of the Personal vDisk that is reserved for Applications, the details of which are in the Personal vDisk configuration.
  • User Store– Verifies whether the expanded path to user store exists. If the expanded path could not be found when the current user is not processed by Profile Management, user store root path is also checked
  • Profile Management Service Status Detection. If Profile Management is not installed or enabled, this tool exits.
  • WinLogon Hooking TestVerifies that Profile management is correctly hooked to WinLogon processing. This test is for Windows versions later than Windows Vista and requires the user running the Configuration Check Tool to have access permission to the relevant registry keys. Otherwise, an error might be returned.
  • Miscellaneous – Other factors that to the tool does not determine through registry or WMI queries, such as whether the computer running Profile Management is a laptop

Updates (November 2018)

  • Windows 10 / Windows 2016 / Windows 2019 support
    • Performs version checks for Windows 10, Windows 10 version 1607, Windows 10 version 1703, Windows 10 version 1709, Windows 10 version 1803, Windows 10 version 1809, Windows Server 2016, and Windows Server 2019.
  • Fixes certain false alarms.
  • Reorganizes checks against policy.
  • Adds path accessibility check for log file path.
  • Adds path accessibility check for user store root path.
  • Adds Profile Management service status check.
  • Adds a pause to wait for a user input so that the check result could be reviewed when this tool runs via right-click context menu.
  • Optimizes error and warning messages.
  • Adds an XML format output file for each check items in the temporary folder.

Updates (December 2013)

  • Windows 8 and Windows Server 2012 support
  • UPM 5.x Autoconfiguration Support
  • XenDesktop 7.x Support
    • Reports whether provisioning is through PVS or MCS, when this is exposed (XenDesktop 7 or higher)
    • Reports on HDX policies (for example, configured by the Policy Node in Desktop Studio) as a mechanism of configuring Profile Management
    • Provides a summary of which policies have been explicitly configured (and by which mechanism), identify which policies have been defaulted. Excludes Cross-Platform Settings policies.
  • App-V Support – detects the App-V client and checks for recommended exclusions when App-V is in use.
  • ShareFile Support – detects whether ShareFile Enterprise Desktop Sync is installed and configured correctly for interoperability with Profile Management.
  • Personal vDisk Support – Additional warning to remind that Profile Streaming and Delete Locally Cached Profiles settings are forcibly disabled if Personal vDisk is in use.
  • Additional Consistency Checks
    • Path to User Store: for presence of supported attributes and variables that will assist scalability and optimum ordering.
    • Profile Management logging
    • Template profile policies
  • Additional CSV Reporting – extra file UPMListPolicySummary.csv for reporting on Profile Management Policies that are lists of paths or Active Directory groups. This file is in addition to the existing CSV files (UPMEnvironmentSummary.csv and UPMPolicySummary.csv) and are used to assist offline analysis.
    • Bug Fixes – Miscellaneous bug fixes.

Updates (December 2012)

  • Profile Size Reporting For the currently logon user, reports the disk usage for the profile volume, and summary analysis of all profiles on the volume (profile type, local path, network path for Profile Management and Microsoft Roaming Profiles). A warning message can be returned if free space on profile volume is below 15% (this value is configurable via command-line parameter—ProfileDriveThresholdPercent)
  • Folder Direction – Compares the folder exclusion list with the Citrix-recommended exclusions and report on divergences. Also reports on folder redirection for the logon user, with recommendations.
  • Caching – Performs the analysis described at Profiles: To cache or not to cache, that is the question… and recommends configuration changes in accordance with that article.
  • VDA Configuration – For a XenDesktop environment, queries the Virtual Desktop Agent (VDA) WMI API (ROOTcitrixDesktopInformation) to report on VDA configuration
  • Additional Tests:
  • Check if UPHClean or User Profile Service is installed and active.
  • Check for VDI-in-a-Box or Kaviza installed and active
  • Check for Hypervisor tools and/or shutdown services for XenServer, Hyper-V and VMware (these are required for graceful shutdown of VDA and avoid profile data loss).
  • Identify origin of all policies applied to the system, if by INI-file or GPO policy. Warns if INI and GPO policies are both used.
  • Increased Reporting:
  • Added notes to all recommendations provided by the tool, containing reasons and/or explanations.
  • Include the date, time and UPMConfigCheck version for each run
  • Report inventory of installed Citrix products and components.
  • CSV Reporting – By using the new command-line switch -WriteCsvFiles details of settings and policies can be output to two separate CSV files (UPMEnvironmentSummary.csv and UPMPolicySummary.csv) to assist subsequent offline automated analysis.
  • Bug Fixes – Miscellaneous bug fixes.
  • Bug Fix – Corrected INI file processing.
    • Included help text, for use with PowerShell Get-Help command.
    • Report on when and how the profile was created and whether this is the first logon (from UPMSettings.ini and similar files). Report install and boot times.
    • Warnings, errors and recommendations are now collected and displayed at the end of the script execution, so you don’t have to read through all the output.

Updates (Aug 2012)

  • Improved Hypervisor Detection – recognition for newer versions of Hyper-V and reporting details of manufacturer for ‘unknown’ Hypervisors.
  • WinLogon hooking test – verifies that Profile Management is correctly hooked to WinLogon processing. This test is for Windows Vista, Windows 7, Windows Server 2008, Windows Server 2008 R2, and requires the user running the Configuration Check Tool to have access permission to the relevant registry keys. Otherwise, an error might be returned.
  • Personal vDisk test – Reports the percentage of the Personal vDisk reserved for Applications, the details of which are in the Personal vDisk configuration.
  • Verifies Path to User Store – Tests to determine whether the expanded Path to User Store exists.

For an explanation on how all of these factors influence the Profile Management configuration, see the Citrix Documentation topic Deciding on a Configuration.

UPMConfigCheck is intended to be used to help identify or solve problems and optimize configurations:

  • In a pilot deployment, to help set up the initial configuration for testing
  • In a production environment, to ensure that the pilot configuration has been correctly replicated
  • In either pilot or production environments, to detect a number of common known issues and misconfigurations


This tool is being released to customers on an “AS IS” basis. No support is implied, and customers are referred to the documentation Deciding on a Configuration to inform themselves on the suggestions made by the tool, and to decide for themselves whether the tool’s suggestions are appropriate for their own environment.

Support for Profile Management remains a part of your normal support contract. Nevertheless, your support representative might ask you to run this tool as part of the normal diagnostics gathering procedure.

Using UPMConfigCheck

Note 1: UPMConfigCheck does not require any special permissions to run.

Note 2: UPMConfigCheck does not make any changes to the file system or the registry.

Unless otherwise directed, run UPMConfigCheck when logging on as a normal user to a physical or virtual machine in the target OU.

  1. Start a PowerShell command window and ensure that PowerShell is set up to allow scripts to run.

    PS > Get-ExecutionPolicy


    Choose and set an appropriate execution policy according to your in-house guidelines. See about_Execution_Policies for help on understanding execution policies.

  2. Run the script from the temporary folder to which it was unzipped.

    PS > .UpmConfigCheck.ps1

    The script does have the following optional parameters.

  3. The script analyses the environment for any factors that influence the optimum Profile Management configuration. It reports the environment and any non-optimal settings in the configuration, defined either with .ini files or Group Policy. UPMConfigCheck does not make any changes to the configuration, and Citrix recommends that you read and understand the appropriate section of the Citrix Documentation topic Deciding on a Configuration before making any changes.
    • WriteCsvFiles – Outputs details of settings and policies to two separate CSV files (UPMEnvironmentSummary.csv and UPMPolicySummary.csv)
    • ProfileDriveThresholdPercent – a warning message will be returned if free space on the profile volume is below this value, in percent.

Understanding and Processing UPMConfigCheck Output

Non-optimal settings now are grouped and shown as warnings and errors such as:


Profile Management Log Settings

*** Error: PathToLogFile \MyTestPath is not accessible. Reason: Log file path should be accessible so that log files can be saved.


Profile Management Basic Settings

*** Warning: ProcessAdmins actual/effective setting (Disabled) does not match preferred setting (Enabled) Reason: ProcessAdmins should be enabled in desktop OS environments, where the end user also has the needs to administer the machine. ProcessAdmins is not recommended in server OS environments.

Profile Management Advanced Settings

*** Warning: ProcessCookieFiles actual/effective setting (Disabled) does not match preferred setting (Enabled) Reason: Citrix recommends to configure this setting to prevent cookie bloat.

*** Warning: OutlookSearchRoamingEnabled actual/effective setting (Disabled) does not match preferred setting (Enabled) Reason: Enable search index roaming for Outlook feature is recommended to be enabled to improve the user experience when searching mail in Microsoft Outlook. If enabled, the user-specific Microsoft Outlook offline folder file (*.ost) and Microsoft search database are roamed along with the user profile.


*** Consider redirecting local folder (C:UsersAdministratorMusic, C:UsersAdministratorPictures, C:UsersAdministratorVideos, C:UsersAdministratorDocuments, C:UsersAdministratorDownloads, ) to a network share

Press any key to continue…

Profile Management Basic Settings, Profile Management Advanced Settings, FolderRedirection are the categories while the warnings and errors start with three asteroids.

If you have been asked by Citrix Technical Support to run the tool and collect diagnostics from it, you should export the output to a file.

PS > .UpmConfigCheck.ps1 > diagnostics.txt

To gather the information about configuration in CSV format, run the utility with the -WriteCsvFiles command line switch.

PS > .UpmConfigCheck.ps1 -WriteCsvFiles

Then send the resultant files (diagnostics.txt, UPMEnvironmentSummary.csv and UPMPolicySummary.csv) as directed by your Citrix contact.

Removing UPMConfigCheck

To remove the tool from a computer, delete the UPMConfigCheck.ps1 script from the temporary folder created earlier.

Known Issues with UPMConfigCheck


Feedback / Contact Information

Feedback on the tool is welcome and can be provided via the Profile Management Forum.


These software applications are provided to you as is with no representations, warranties or conditions of any kind. You may use and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the software application may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software application fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software application. In no event should the code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE APPLICATION, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.

The above mentioned sample code is provided to you as is with no representations, warranties or conditions of any kind. You may use, modify and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that (a) the sample code may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the sample code fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the sample code. In no event should the code be used to support of ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SAMPLE CODE, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Although the copyright in the code belongs to Citrix, any distribution of the code should include only your own standard copyright attribution, and not that of Citrix. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the code.


  • No Related Posts

Error: “Preparation of the Master VM Image failed” when Creating MCS Catalog in XenApp or XenDesktop

This article contains information about creating a Machine Creation Services (MCS) catalog in XenApp or XenDesktop fails with error “Preparation of the Master VM Image failed”.


As part of the process of creating a machine catalog using MCS, the contents of the shared base disk are updated and manipulated in a process referred to as Image Preparation. Under some conditions, this Preparation step can fail completely without generating any information that can be used to derive the exact cause. Possible reasons for this are:

  1. The Machine Image does not have the correct version of the Citrix VDA software installed.

  2. The virtual machine used to perform the preparation never starts or takes so long to start that the operation is cancelled with the following symptoms:

  • Blue screen on boot.

  • No operating system found.

  • Slow start/execution of the virtual machine. This particularly affects Cloud based deployments where machine templates might have to be copied between different storage locations.

Triaging Issues

The issue detailed under Point 1 in the Background section should be easy to diagnose using the following procedure:

  1. Start the original master Virtual Machine (VM).

  2. Ensure that the Citrix VDA Software has been installed from the correct version using XenDesktopVdaSetup.exe.


  • It is not sufficient to install individual MSI installers, as the complete VDA functionality is provided by several distinct components which XenDesktopVdaSetup will install as required.

  • If a VDA from XenDesktop 5.x is installed (for example, to support Windows XP or Vista), then this does not support image preparation and you must select the option in Studio to tell the system that an older VDA is in use and this will instruct the services to skip the image preparation operation.

For the issues detailed in Point 2, more diagnosis is required as explained in this section:

Caution! Refer to the Disclaimer at the end of this article before using Registry Editor.

Note: The preparation step will be performed by a VM named Preparation – <catalog name> – <unique id>. The Hypervisor management console can be used to check that this VM manages to start and progress past the point of starting the guest operating system. If this does not occur then check that the snapshot used to create the catalog was made of a fully functioning VM.

MCS will only support a single virtual disk, so ensure that your master image only uses a single disk.

If the VM manages to start Windows, then information will be required from inside the running VM. As the machine will be forcibly stopped if the preparation step is not completed in the expected time, hence it is necessary to prevent this from happening. In order to do this, run a PowerShell console from the Studio management console and issue the following command:

Set-ProvServiceConfigurationData -Name ImageManagementPrep_NoAutoShutdown -Value $True –AdminAddress <your Controller Address>

This is a global configuration option and will affect all catalog creation operations, so ensure that no other creation operations are being run whilst you are triaging your issues. It also requires the issuing user to be a Full Administrator of the XenDesktop site.

After this property is set, the preparation VM will no longer shutdown automatically or be forced down on expiry of allowed time.

  1. To obtain additional information from the preparation operation, it is necessary to enable diagnostic logging on the Machine Creation components in the master image. To do this, set the following DWORD registry value to 1 in the master image and create a new snapshot of the master image.


    After this is set, the image preparation operation will create log files in C: on the preparation VM. The logfiles are “image-prep.log” and “PvsVmAgentLog.txt”.

  2. When the preparation VM is running, use the Hypervisor management console to log into the VM.

  3. Check that image-prep.log exists in C: and open it.

  4. Check for errors in the log file. These might be sufficient for the problem to be resolved directly, otherwise the details must be used in reporting an issue to Citrix Support.

  5. As the preparation VM is created, the network adapters disconnects in order to isolate it from the rest of the Active Directory domain, it is not possible to copy the log file to an external destination. Screen shots of the VM console will be the best way to obtain a report. Ensure that all parts of the log file are captured.
  6. When finished with the investigations, remove the global setting as follows:

    Remove-ProvServiceConfigurationData -Name ImageManagementPrep_NoAutoShutdown –AdminAddress <your Controller Address>

  7. Set the registry key on the master image to 0 and create a new snapshot to provision.


  • No Related Posts