After installing onto my 2016 Hyper-V server, I lost access to all my VMs. The Virtual Management Service stopped working. I uninstalled the Symantec client and am still having issues. Any ideas?
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
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.
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:
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.
Citrix Hypervisor, formerly XenServer, is powered by the Xen Project hypervisor.
This article describes how to add an additional hard drive in XenServer.
When a new internal hard drive is installed on a XenServer to work as a new local storage repository, it is not immediately available to the XenServer Console.
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.
|Post-update tasks||Restart Host|
|Content live patchable*||No|
|Revision History||Published on December 12, 2018|
|* Available to Enterprise Customers.|
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.
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.
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.
There are three mechanisms to install a cumulative update:
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:
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.
Note: If you click Cancel at this stage, the Install Update wizard reverts the changes and removes the update file from the host.
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.
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>
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.
|Hotfix File sha256||64b9d387cfc79fb97245a2425babaa4f46ccf9edf4730cde18fea7fe954a0f42|
|Hotfix Source Filename||XS71ECU2-sources.iso|
|Hotfix Source File sha256||e46f7d3fb31b8e4bafcd5a49c06ce7b0d55f486489efd618514452aafb6c4305|
|Hotfix Zip Filename||XS71ECU2.zip|
|Hotfix Zip File sha256||7cb0130b2ac64e4c5c7ccbe57ea232ff1224888b0a4848d20d8ca0674614ba08|
|Size of the Zip file||277.16 MB|
For more information, see the XenServer 7.1 Documentation.
If you experience any difficulties, contact Citrix Technical Support.
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.
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.
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.
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.
A: Windows 7 x86, Windows 7 x64, and Windows 10 up to v1607.
A: Yes, XenApp and XenDesktop 7.15 LTSR supports Windows 10 1703 SAC. Reference Citrix product documentation for more information.
A: It is only supported on Desktop Operating Systems.
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 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.
32- and 64-bit operating system versions, where available, are supported.
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:
Updates (November 2018)
Updates (December 2013)
Updates (December 2012)
Updates (Aug 2012)
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:
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.
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.
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.
The script does have the following optional parameters.
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.
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.
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:
The Machine Image does not have the correct version of the Citrix VDA software installed.
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.
The issue detailed under Point 1 in the Background section should be easy to diagnose using the following procedure:
Start the original master Virtual Machine (VM).
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.
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”.
When the preparation VM is running, use the Hypervisor management console to log into the VM.
Check that image-prep.log exists in C: and open it.
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.
When finished with the investigations, remove the global setting as follows:
Remove-ProvServiceConfigurationData -Name ImageManagementPrep_NoAutoShutdown –AdminAddress <your Controller Address>
Set the registry key on the master image to 0 and create a new snapshot to provision.