29
XenClient Enterprise Advanced Configuration Guide July 16, 2012
XenClient Enterprise Advanced Configuration Guide July 16, 2012
2
Table of Contents
About this Document .................................................................................................................4
XenClient Enterprise Synchronizer Sizing .....................................................................................4 Understanding VHD Disk Chains .................................................................................................. 4
Processor Factors .................................................................................................................................. 5
Memory Factors .................................................................................................................................... 6
Storage Factors ..................................................................................................................................... 6
Network Factors .................................................................................................................................... 7
XenClient Enterprise Synchronizer Sizing Guidelines ........................................................................... 8
Windows 7 Best Practices ...........................................................................................................9 Improving Performance on Installed Components ...................................................................... 9 Preventing Unnecessary Component Installation ..................................................................... 10
Windows XP Best Practices ....................................................................................................... 12 Operating System ....................................................................................................................... 12 Applications ................................................................................................................................ 14
App-V Client and XenClient Enterprise Interoperation ............................................................... 15
Complex Virtualized Application Requirements and XenClient Enterprise .................................. 15
Using SCCM with XenClient Enterprise ...................................................................................... 16 XenClient Enterprise Windows Guests and the SCCM Client .................................................... 17
Deploying the SCCM Client on XenClient Enterprise Dedicated Images ............................................ 17
Deploying the SCCM Client on XenClient Enterprise Shared Images .................................................. 18
The SCCM Client XenClient Enterprise Synchronizer OS Profile Policy ...................................... 19 Virtual Windows Instances in Active Directory .......................................................................... 19 XenClient Enterprise Hosts, Guest Windows Instances and SCCM Collections ......................... 19 Operating System Updates ........................................................................................................ 20 Application Deployment and Updates via SCCM ....................................................................... 20 Software Inventory .................................................................................................................... 20
Remote Server Functionality ..................................................................................................... 20
Appendix A: Sizing a Medium Installation ................................................................................. 22
Appendix B: XenClient Enterprise Installation FAQ ................................................................... 24
Hardware Compatibility ............................................................................................................ 24 CPU Compatibility ...................................................................................................................... 24 Video Compatibility .................................................................................................................... 24 Memory ...................................................................................................................................... 25
3
BIOS Configuration Settings ....................................................................................................... 25
Disk Configuration .................................................................................................................... 25 Disk Encryption ................................................................................................................................... 26
Installation Media .................................................................................................................... 26 Optical Media ............................................................................................................................. 26 USB Media .................................................................................................................................. 27 A Common Post Installation Issue ............................................................................................. 27
Advanced XenClient Enterprise Engine Installations .................................................................. 28 Dual Boot Installation................................................................................................................. 28 XenClient Enterprise Engine PXE Boot Installs ........................................................................... 28
Troubleshooting Installation Failures ........................................................................................ 28 Copyright © 2012 Citrix All Rights Reserved. Version: 2.1 Citrix, Inc. 851 West Cypress Creek Road Fort Lauderdale, FL 33309 United States of America This document is furnished "AS IS." Citrix, Inc. disclaims all warranties regarding the contents of this document, including, but not limited to, implied warranties of merchantability and fitness for any particular purpose. This document may contain technical or other inaccuracies or typographical errors. Citrix, Inc. reserves the right to revise the information in this document at any time without notice. This document and the software described in this document constitute confidential information of Citrix, Inc. and its licensors, and are furnished under a license from Citrix, Inc. Citrix Systems, Inc., the Citrix logo, Citrix XenClient, are trademarks of Citrix Systems, Inc. in the United States and other countries. All other products or services mentioned in this document are trademarks or registered trademarks of their respective companies. Citrix Systems, Inc. acknowledges all trademarks used in this document. Linux is a registered trademark of Linus Torvalds and Ubuntu is registered trademark of Canonical Ltd. Windows is a registered trademarks of Microsoft Corporation. All trademarks are the property of their respective owners.
4
About this Document This document provides information about advanced XenClient Enterprise topics. In addition, it also provides an installation FAQ that includes information about common installation problems.
XenClient Enterprise Synchronizer Sizing There are a number of factors involved in sizing XenClient Enterprise Synchronizer installations, including:
• the number of distinct VMs (virtual machines)
• the number of Client systems and the expected number of VMs each client will run
• the network topology including WAN/LAN speeds
• the type of VMs being utilized and the chosen model for user backups
Each of these factors will impact the XenClient Enterprise Synchronizer installation in a number of ways, including:
• processor loading; each server will require a certain amount of processing power to support the registered client population
• memory usage; in general, the more memory a server has, the better it will perform but there are minimum requirements on memory size to support the number of XenClient Enterprise Engine clients.
• storage; the storage needs of a Synchronizer Deployment can vary greatly depending on the deployment model chosen, number of VMs required, number of registered computers, and other factors
• network; part of the design of a Synchronizer installation is calculating bandwidth usage requirements and any limitations that should be applied to the XenClient Enterprise traffic, designing the server structure appropriately and configuring bandwidth management policies
Understanding VHD Disk Chains VM definitions are made available to each client system. There is one VM for each distinct OS installation; these are personalized for each user when they are deployed to the client systems. VMs consist of:
• meta data describing the VM (OS type, resource allocation, publish history, etc). • a chain of virtual hard drive (VHD) differencing disks that hold the system disk data. Each time a
version of the VM is published a new VHD delta is pushed onto the disk chain to hold the changes for the next version. The bottom disk in the chain is a VHD dynamic disk holding the
5
oldest maintained version of the VM; the Administrator can compress a set of the oldest existing versions into a single dynamic disk to manage the disk space consumed by the VM to manage disk space consumed by the VM, improve performance, and reduce the bandwidth required to transmit the VM to the endpoint.
• local user backups; the client systems can optionally send backups for each VM deployed to the client back to the server to which it is registered. The user disks are stored as a chain of VHD differencing disks with a VHD dynamic disk at the base. Backups are created based on the backup policy pushing a new, empty VHD onto the top of the disk chain – the latest backup is then represented by the VHD differencing disk that was on the top of the chain before this. Incremental backups are discarded by merging the differences into the VHD dynamic disk at the bottom of the chain (so the bottom always represents the oldest backup).
Processor Factors The processing requirements for a Synchronizer server are:
• creating and updating VMs (Synchronizer server only); the VMs are run under Hyper-V when they are being installed and updated. The Microsoft guidelines for Hyper-V VMs should be followed when calculating the processor requirements for these operations and should take into account the largest number of VMs that will be concurrently updated or published.
• publishing VMs (Synchronizer server only); the publishing process does cause the VM to be run under Hyper-V and also includes processing that is done in the Synchronizer OS instance itself. Since publishing is serialized by the product, it is only necessary to account for one VM at a time being published. The publish process consumes one processor core for the duration of the operation (typically 20-40 minutes per VM).
• deploying VMs (all Synchronizer servers); the server operates as a secure Web server to deploy images and take backups; this processing consumes approximately 3 Xeon class processor cores to saturate a single 1Gb/s link (which translates to around 800Mb/s actual throughput). Synchronizer servers provide this service for the Synchronizer Remote Servers and for any XenClient Enterprise Engines registered directly to the Synchronizer Central Office Server. Synchronizer Remote Office servers only provide this service to registered endpoints.
• XenClient Enterprise Control Functions (Synchronizer servers only); this component is responsible for managing the database and user interface for the XenClient Enterprise Installation and runs only in the Synchronizer Central Server, though it is accessible via the Synchronizer Console on Remote Office Servers.
6
Memory Factors The memory requirements for Synchronizer server include:
• memory required to create and update VMs (Synchronizer Central Server only) – The Microsoft guidelines for Hyper-V VMs should be followed when calculating the memory requirements for these operations and should take into account the largest number of VMs that will be concurrently updated and published.
• publishing VMs (Synchronizer Central Server only); the VM is run on the server system during publish and so enough memory must be free to run the largest VM during publishing. This process is serialized so only one VM will be published at a time.
• Deploying VMs (all Synchronizer Servers); the normal Windows file system cache is heavily utilized when deploying VMs and so the more memory that is available the better the system will run.
The minimum memory size for a Synchronizer Server is 6GB but increasing to 16GB or more will result in improved performance; also, consider memory requirements when rolling up backups (which applies to both central and remote servers).
Storage Factors Each Synchronizer Server must have enough storage to hold the following:
• Each distinct VM; this includes the base system disk (which can grow to the configured maximum size of the disk) plus any delta disks for intermediate versions. Local retention policies will control the details of how many delta versions should be kept, but best practice is to manage the set of delta disks to keep the following:
o A base disk that is the basis for the previous deployed version – when a new version has been successfully deployed, the existing versions from the base to the previous deployed version should be merged into a single version using the Synchronizer UI.
o All of the versions between this and the current deployed version and any version subsequent to this for an updated version under development.
In addition to the size of the disk, each VM is actually stored twice in the system; once uncompressed so it can be manipulated and then also a compressed copy is stored which is what is downloaded to other Remote Office Servers and clients. The compression ratio for these is typically around 50%; when calculating disk space requirements, the total disk space required must be multiplied by 150% to get the actual requirement.
When addressing storage, consider the following:
• All user backups for users registered directly to the server. There is a compressed user backup disk for each VM/User combination (for example, if you have 10 users each of which has 2 VMs
7
assigned to them then there will be 20 distinct backups. For each user backup, the following will exist:
o A base disk which can be up to the maximum size of the user disk as configured in the Synchronizer UI compressed. This is the oldest backup in existence.
o A series of delta disks that represent the maximum number of backups.
For example, if the maximum size of a user disk is 30GB and the backup policy indicates user disks should be backed up once per day and the last 7 days of backups are kept, then the following will exist:
o A full backup from 7 days ago which can be up to 30GB (uncompressed) in size
o 6 incremental backups for each of the subsequent days that hold the data modified by the user during each 24-hr period, again stored compressed all of which could theoretically consume approximately 30GB of disk space
When calculating how much disk space is required, a good rule of thumb is that the disks will be compressed by 50%.
Network Factors The network topology has a strong impact on the design of the Synchronizer installation. The following are the most important factors to consider:
• Slow speed (WAN) connections to remote sites. The system will perform at its best if Synchronizer Remote Servers are installed at the end of slow speed links as this will mean that VMs are only downloaded once no matter how many clients there are at the remote site AND no backups will be sent over the WAN connection. This results in greatly reduced utilization of the WAN link.
If it is not feasible to install a Synchronizer Remote Server at every remote location, it is still beneficial to install a server remotely to service a number of sites as this will reduce the load on the outgoing WAN connection from the central data center.
• Multiple high speed segments. If the network has multiple separate high speed LAN segments then it makes sense to install a Synchronizer Remote Server on each segment to maximize the number of clients that can be serviced concurrently and minimize the impact on the backbone network. For example, if there is a 10Gb backbone in the central data center and a series of 1Gb LAN segments distributed throughout the organization with small data centers on each segment connected to the backbone then a good implementation strategy would be to install Remote Servers in each satellite data center all connected to the 10Gb backbone and have the Central server in the main data center. This will result in data being distributed to the Remote Servers
8
very quickly and from there delivered in parallel to all clients on the various slower speed networks.
XenClient Enterprise Synchronizer Sizing Guidelines This section details specific guidelines that can be used to size a XenClient Enterprise Synchronizer installation. It is based on some fundamental assumptions concerning acceptable timeframes for deploying VMs as follows:
• It is often possible to perform an initial deployment of all VMs to all users within a several day time period. This particular operation should only ever be done one time and once all clients have received their VMs, it is only necessary to send updates to those systems. In the future, initial deployments will only be done to small numbers of systems at any given time (as new users are added or existing users are migrated to new hardware to fix h/w failures). It therefore does not make sense to architect the installation to be able to do this one-time operation quickly as it will result in the systems being oversized for normal operation.
• Clearly it must be possible to keep up with the backup policies – so if the policy is to backup all clients every day, it must be possible to transfer the associated data to the Synchronizer servers within the 24hr period.
In addition, there are some assumptions in this document regarding the likely size of VMs and backups:
• A VM will likely be initially around 20GB uncompressed (around 8-10GB compressed) with an absolute maximum size of 50GB uncompressed (20-25GB compressed). A full Windows 7 installation together with Office 2007 Professional is approximately 18GB for example. If we assume weekly updates with a maximum of 4 intermediate versions created, each of which is 1GB, and retaining the last two published versions at most, the estimate of maximum required disk space per VM (including the overhead for storing both uncompressed and compressed) is then:
(50 + 8*1) * 1.5 = ~90GB
• User backups; as stated previously, the size of a user backup can be the full configured size of the disk plus the configured maximum number of incremental snapshots. So, if a user disk is configured to be a maximum of 30GB with daily backups maintained for 7 days and if we assume any given user can modify 1GB of data per day, then the maximum on disk size at the Synchronizer server can be estimated as:
(30 + (6*1)) * 0.5 == ~20GB
With these guidelines in place, it is possible to determine how many Synchronizer servers should be deployed to handle the end client load on the system as follows:
9
• A Central Server:
o should have three Xeon class cores for each 1 GB LAN connection plus 1-2 cores for running the Synchronizer server processing.
o should have at least 8GB memory for the Windows instance running the Central Server image plus additional memory for creating, updating and publishing VMs (which should be greater than the largest expected memory size of any individual VM).
o requires sufficient storage to hold all VMs together with backups for any users directly registered to the server.
• A Synchronizer Remote Server:
o should have three Xeon class cores for each 1 GB LAN connection.
o should have at least 8GB memory
o requires sufficient storage to hold all VMs together with backups for all users that will be registered to the server.
Performance Test Results The following performance information illustrates expected behaviour when determining the number of XenClient Enterprise clients that can be provisioned with a typical Windows 7 virtual machine within 10 minutes.
This test involved using a typical server running the Synchronizer, in this case, a dual quad core (8 CPUs) server with 16 GB of memory and average disk drives. The Windows 7 VM image was approximately 8 GB uncompressed (3+ GB compressed).
Within 10 minutes, 15 Windows 7 VMs were provisioned, which equates to 90 users in one hour and 2,160 users in one day.
Windows 7 Best Practices There are two categorical ways to improve performance on any deployed operating system. One category includes performance improvements of installed components, while the other includes preventing the installation and execution of unnecessary components.
Improving Performance on Installed Components To improve the performance on installed components:
1. Install Windows Vista/7 with the latest service pack.
Citrix recommends that you install Windows with the latest service pack instead of installing a previously released service pack, then upgrading. For example, install Windows SP2 instead of
10
installing SP1 then upgrading to SP2. 2. Modify the installer partition table in Windows 7; delete the larger, second partition and
increase the size of the first partition to fill the disk. 3. After installing Windows, run Windows update and enable Microsoft update. 4. Run all updates; reboot and repeat until all updates are installed.
Do not install Office Live Add-in and turn off auto-run of Windows Update; disable warning messages related to Windows Update.
5. Turn off System Restore. A. Access the Control Panel > System and Security > System > System Protection screen. B. Click Configure. C. Select the Turn off system restore checkbox and click OK.
In some cases, disabling Remote Assistance and Remote Desktop is often recommended; Citrix recommends that these be enabled – they permit an Administrator to remotely debug an OS. While these abilities hinder performance, they provide a number of benefits.
6. Disable SuperFetch: A. Start > services.msc. B. Double-click SuperFetch. C. Click the Stop button to halt the service. D. Change the start-up type to Disabled.
7. Delete the EnableSuperfetch value. To delete the EnableSuperFetch value: A. Start > regedit. B. HKEY_LOCAL_MACHINE\SYSTEM\CurrentSetControl\Session Manager\Memory
Management\PrefetchParameters. C. Double-click on EnableSuperfetch. D. Change the value data field to 0.
8. After disabling SuperFetch and rebooting, delete the contents of c:\windows\prefetch. 9. Run disk cleanup; cleanmgr (specify All Users and keep defaults). 10. Set recycle bin to 100 MB. 11. Turn off scheduled disk defragmenter; start disk defragmenter, configure schedule and uncheck
the option.
Preventing Unnecessary Component Installation Many installed components, like Sun’s Java or Apple’s Quick Time, install their own updater engines. These components are not desired when running XenClient Enterprise.
The website appdeploy.com has information on how to customize application installations, including the removal of unneeded components; each application has its own page of appdeploy.
Many of these installed applications have custom settings that seek to turn off the automatic update settings of the applications – otherwise, each VM will check for updates and then try to install them,
11
only to discard the updates at the end of the session. You will update applications in the version on the Synchronizer, and then publish that version to distribute the updates to shared VMs.
1. Import the Office 2007 ISO file into the software library. Attach the ISO to the running VM. Install Office 2007 and click customize, run-all-from-my-computer. You can customize it further for your environment.
2. Install Firefox and modify the %program files%\Mozilla Firefox\defaults\pref\ firefox.js as follows (the default for these lines is true):
pref("app.update.enabled", false);
pref("extensions.update.enabled", false);
pref("browser.search.update", false);
For details, See Don’t make firefox go look for updates at: http://john.bryntze.net/jbkb/index.php?title=OpenSource-kb4_Silent_installation_and_configuration_of_Firefox
3. Download Adobe Reader 9 from ftp://ftp.adobe.com/pub/adobe/reader/win/9.x/9.2/enu/: 4. Obtain Adobe Reader 9.x by filling out an Adobe Reader Redistribution Agreement at
www.adobe.com/products/acrobat/distribute.html. 5. Download the AdbeRdr9x_en_US.exe from the link in the confirmation email and save the file
to your desktop. 6. Extract the adobe components using the command AdbeRdr9x_en_US.exe -nos_ne. 7. Download the Adobe Customization Wizard from:
www.adobe.com/support/downloads/detail.jsp?ftpID=3993. 8. Run the Customization Wizard. Under Installation Options, uncheck Enable Optimization, check
Suppress reboot. Under online acrobat.com, check disable all updates. Save the package. 9. Run setup.exe. 10. Install Adobe AIR 1.5 from http://get.adobe.com/air. Use the default values offered. 11. Install both versions (IE and Firefox) of Flash Player. Disable Flash Player’s automatic update. 12. Create or open the C:\WINDOWS\System32\Macromed\Flash\mms.cfg file in a text editor and
add the following line: AutoUpdateDisable=1. 13. Save the mms.cfg file with UTF-8 encoding.
For details, see http://kb2.adobe.com/cps/167/16701594.html.
14. Install latest Sun Java JRE. Create the following registry keys: • [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy] • "EnableJavaUpdate"=dword:0 "NotifyDownload"=dword:0 "NotifyInstall"=dword:0 • "UpdateSchedule"=dword:0 "Frequency"=dword:0
For details, see http://www.appdeploy.com/packages/detail.asp?id=1562.
12
15. Install VPN software. For full Cisco VPN client create an organization profile, for the SSL VPN the default profile should be downloaded with the client.
16. If iTunes is required for your environment, download iTunes from Apple. 17. After installation, disable iTunes update in the Apple Software Update program. 18. Disable iTunes update in the Apple Software Update program. 19. Disable Quick Time updates through its control panel. 20. In the Registry, set HKEY_LOCAL_MACHINE\SOFTWARE\Apple Computer, Inc.\iTunes\Parental
Controls\Default\AdminFlags to 0x00000101. 21. Install Skype for business using a kit from from http://www.skype.com/business/. 22. Disable the version check by setting the registry value:
• HKEY_LOCAL_MACHINE\Software\Policies\Skype\Phone\DisableVersionCheck to 1
For details, see the Skype's Network Administration Guide.
23. Install your AV/Spyware Engine. Prior to publishing, verify that your AV services are listed in the ‘turn OFF before publishing and ON after NxPrep list’ to prevent extremely long publish cycles.
For Sophos, do not turn on regular scans. Leave the default integrated scanning of all files opened intact. Run a full app and virus definition update.
Add additional corporate applications……
After all the applications have been installed, re-run Microsoft Update until nothing remains. Also remove all unneeded entries from:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
Windows XP Best Practices There are two major ways to improve performance on any deployed operating system. One category includes performance improvements of installed components, while the other includes preventing the installation and execution of unnecessary components.
This document details both categories, beginning with performance improvements for Windows XP system components, followed by improvements for several popular applications.
When the virtual machine is downloaded and prepared on a user’s computer, XenClient Enterprise Engine defines U: as the User drive (which is backed up based on the backup policy), L: as the Local drive (which is not backed up), and M: is used by default in the XenClient Enterprise Synchronizer Console to mount ISOs. Avoid using these drive definitions on your network.
Operating System Use the following procedure when installing Windows XP for XenClient Enterprise:
13
1. Install Windows integrated with the latest service pack instead of installing a previous version and then upgrading. For example, install Windows XP SP3 instead of installing Windows XP SP2 and then upgrading to SP3. Use the default installation procedure and settings.
2. Install Hyper-V Integration services by attaching ISO in the Synchronizer, and then reboot after installation has completed.
3. After installing XP, run Windows Update from start menu. Click on the “Get MS update Today” to enable Microsoft Updates (different from Windows updates).
4. Download and install all critical Updates. 5. In Windows components, remove MSN Messenger, MSN, and outlook express. 6. Delete Windows Update shortcut on the Start menu; leave Microsoft Update shortcut. 7. Turn off Dr. Watson debugging: Locate and delete the registry key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\AeDebug
See details at http://support.microsoft.com/kb/188296.
8. Turn off System Restore. 9. Start>My Computer, right click and select properties. 10. Click the System Restore tab. 11. Fill the Turn off System Restore check box or fill the Turn off System Restore on all drives check
box. 12. Click OK. 13. Click Yes at the confirmation pop-up to turn off System Restore.
See details at http://support.microsoft.com/kb/310405.
14. Based on your IT policy, disable Remote Assistance and enable Remote Desktop. 15. Since any changes to the golden image are thrown away after reboot, Windows Prefetch is
disabled automatically during Publish. Delete contents of C:\windows\prefetch before publishing the VM.
16. Run Disk Cleanup – ‘cleanmgr’ – All Users, keep defaults. 17. Set recycle bin to be 1% of disk size. Use on setting for all drives. 18. the Windows Defender Service if you have your own Anti-spyware Engine
Start->run->services.mmc
Wireless Zero Config (started->manual)
A number of other services will be disabled on publish.
14
Applications Many of these settings seek to turn off the automatic update settings of the applications – otherwise, each VM will check for updates and then try to install them, only to discard the updates at the end of the session. You will update applications in the version on the Synchronizer, and then publish that version to distribute the updates to shared VMs.
1. Import the Office 2007 ISO file into the software library. Attach the ISO to the running VM. 2. Install Office 2007 and click customize, run-all-from-my-computer. You can customize it further
for your environment. 3. Install Firefox and modify then the %program files%\Mozilla Firefox\defaults\pref\ firefox.js as
follows (the default for these lines is true): • pref("app.update.enabled", false); • pref("extensions.update.enabled", false); • pref("browser.search.update", false);
For details, See Don’t make firefox go look for updates at: http://john.bryntze.net/jbkb/index.php?title=OpenSource-kb4_Silent_installation_and_configuration_of_Firefox
4. Download Adobe Reader 9 from ftp://ftp.adobe.com/pub/adobe/reader/win/9.x/9.2/enu/: 5. Obtain Adobe Reader 9.x by filling out an Adobe Reader Redistribution Agreement at
www.adobe.com/products/acrobat/distribute.html. 6. Download the AdbeRdr9x_en_US.exe from the link in the confirmation email and save the file
to your desktop. 7. Extract the adobe components using the command AdbeRdr9x_en_US.exe -nos_ne. 8. Download the Adobe Customization Wizard from:
www.adobe.com/support/downloads/detail.jsp?ftpID=3993. 9. Run the Customization Wizard. Under Installation Options, uncheck Enable Optimization, check
Suppress reboot. Under online acrobat.com, check disable all updates. Save the package. 10. Run setup.exe. 11. Install Adobe AIR 1.5 from http://get.adobe.com/air. Use the default values offered. 12. Install both versions (IE and Firefox) of Flash Player. Disable Flash Player’s automatic update. 13. Create or open the C:\WINDOWS\System32\Macromed\Flash\mms.cfg file in a text editor and
add the following line: AutoUpdateDisable=1. 14. Save the mms.cfg file with UTF-8 encoding.
For details, see http://kb2.adobe.com/cps/167/16701594.html.
15. Install latest Sun Java JRE. Create the following registry keys: • [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Update\Policy] • "EnableJavaUpdate"=dword:0 "NotifyDownload"=dword:0 "NotifyInstall"=dword:0 • "UpdateSchedule"=dword:0 "Frequency"=dword:0
15
For details, see http://www.appdeploy.com/packages/detail.asp?id=1562.
16. Install VPN software. For full Cisco VPN client create an organization profile, for the SSL VPN the default profile should be downloaded with the client.
17. If iTunes is required for your environment, download iTunes from Apple. 18. After installation, disable iTunes update in the Apple Software Update program. 19. Disable iTunes update in the Apple Software Update program. 20. Disable Quick Time updates through its control panel. 21. In the Registry, set HKEY_LOCAL_MACHINE\SOFTWARE\Apple Computer, Inc.\iTunes\Parental
Controls\Default\AdminFlags to 0x00000101. 22. Install Skype for business using a kit from from http://www.skype.com/business/. 23. Disable the version check by setting the registry value:
• HKEY_LOCAL_MACHINE\Software\Policies\Skype\Phone\DisableVersionCheck to 1
For details, see the Skype's Network Administration Guide.
24. Install your AV/Spyware Engine.
For Sophos, do not turn on regular scans. Leave the default integrated scanning of all files opened intact. Run a full app and virus definition update.
Add additional corporate applications……
After all the applications have been installed, re-run Microsoft Update until nothing remains. Also remove all unneeded entries from:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
App-V Client and XenClient Enterprise Interoperation The Microsoft App-V client is deployed as part of the central image in either VM shared or dedicated image mode. Once the virtual image is deployed with the App-V client, the virtual Windows instance is ready to utilize App-V virtual applications as they would on any other physical PC. All of the delivery methods mentioned above work well with XenClient Enterprise. XenClient Enterprise redirects the locations for the App-V application cache, and virtualized application user preferences, to a location that is outside of the snap-back functionality and controlled through the default VM OS Policy. This means the virtual application and its settings are retained after reboots regardless if the VM image is in shared or dedicated mode. The virtualized application in a VM will operate the same way as it would if loaded on a physical Windows instance.
Complex Virtualized Application Requirements and XenClient Enterprise In the App-V world, there exists classes of applications that need a device driver deployed locally or require interaction with several applications that need redundant sequencing of applications for the
16
virtualized applications to properly function. XenClient Enterprise provides unique options to help with these issues.
Applications requiring device drivers can be sequenced and delivered, but the device driver can be added to the core VM image and deployed either with the core image or as an update layer. For example, Skype can use a Polycom speaker phone device; however it requires a device driver that is not part of Windows. The Administrator can add the Polycom device driver files to the device driver path in the centralized Windows image and deploy it utilizing the deployment and update capabilities. When the Polycom device is plugged in at the client, the device drivers are available for automatic loading and configuration. Once the App-V Skype instance is launched on the client, it will recognize and utilize the Polycom device.
In the case of a complex application environment, XenClient Enterprise can deploy and update the non-virtualized applications as part of the centralized images. For example, a law firm has multiple applications that need to tie into a common version of Microsoft Office. Instead of sequencing Office in multiple virtual applications, it can be installed into the central Windows instance. As the virtual Windows image is deployed or updated, the Office version will be local and available to all virtualized applications. Each virtualized application can then take advantage of the local copy, however the Administrator still gets the benefit of only having to update the application in the image once from a single location.
This capability now gives the Administrator a greater level of choices in how they can deploy applications and their dependencies. Instead of having to take the dependency that falls out of App-V’s virtualization capabilities, break it out from the existing MSI, package it into its own MSI and use PCLM to deliver it to any number of desktops, the admin simply adds the component to the centralized Windows image and it is deployed to all the related desktops on the next update. This functionality greatly simplifies this process and extends the value of App-V.
Using SCCM with XenClient Enterprise In order to understand the proper interactions between the two systems, it is important to understand how the client and its guest Windows instances are recognized. Since XenClient Enterprise is based on the XEN hypervisor, it isn’t recognized by Active Directory or the SCCM console directly. Therefore the management of the core XenClient Enterprise Engine (client) must be performed through XenClient Enterprise Synchronizer while the management of what is placed in the Windows guest instance can be controlled through SCCM.
The following steps will allow you to install a XenClient Enterprise Windows OS instance from SCCM OSD:
1. Follow the SCCM Standard procedure to create an OS image for SCCM delivery as outlined in
Microsoft TechNet: http://technet.microsoft.com/en-us/library/bb693478.aspx 2. Once the image is ready, create the Task Sequence Media following these steps:
http://technet.microsoft.com/en-us/library/bb632725.aspx.
17
• Make sure to select Bootable media
• Select CD/DVD set
• Select a location to save the ISO file in the Media File line
• Click Next
• Enable Unknown Computer Support
• Finish filling in the record according to your companies policy
• Click Next
• Select the x64 Boot Image as the Media File
• Select the Distribution Point to get the Boot Image files 3. Click Next twice and the Boot Image will be created in the save location.
4. Once created, copy the Boot Image ISO to the FileImport folder in the Synchronizer. 5. In the Synchronizer, import the ISO by clicking on Software Library…Import…Fill out the Name of
the ISO and select the Boot Image ISO from the drop down list…click Finish. 6. Create the VM per the standard creation steps outlined here:
http://www.virtualcomputer.com/Support/tutorials-publish-nxtop?nx, but make sure to select
the SCCM OSD Boot Image ISO as the installation media…. Installation process. 7. Once the system boots, it will go through the standard SCCM OSD installation process as the
physical machines using the corporate image. 8. Once the process is complete, the image is ready to have the SCCM client added and the any
finishing touches completed.
XenClient Enterprise Windows Guests and the SCCM Client The SCCM client must be installed on each golden image; however, it is not a requirement to add the client only to a fresh OS installation. Existing Windows images that have been either imported or previously existed in the XenClient Enterprise Synchronizer can have the SCCM agent added and deployed.
Deploying the SCCM Client on XenClient Enterprise Dedicated Images In the case of deploying the SCCM client to VMs utilizing dedicated images, the admin is presented with a couple of options. The SCCM client can be added to the golden image itself as long as the image has not been previously deployed, since any changes to the core dedicated image represent a wholesale replacement of the deployed image and resets the targeted systems user state.
In this case, the admin follows the same recommended steps from Microsoft as if they were deploying an image via Ghost or other imaging tools. There are considerations around auto-discovery of Site Codes and ensuring that the proper security keys are made available to the client after the XenClient Enterprise equivalent of SysPrep is run after image deployment. The proper process is as follows:
• Complete the golden image creation through the Synchronizer console
18
• Install the SCCM client per your company’s best practices. It is recommended to use auto site discovery if the VM will be assigned to different sites codes.
• Copy the CCMDelcert.exe and Tranguid.exe tools from the SCCM Client Toolkit (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=61e4e21f-2652-42dd-a04d-
b67f0573751d) to c:\Windows\System32
• Install the SCCM client
• Run “CCMDelCert.exe” on the golden image client. This removes the SMS Certificate.
• Run “Tranguid /r” on the golden image client. This will force a new SMS ID to be created.
• Start the Services manager and find the SMS Agent Host service. Stop the service and change the Startup type to “Disabled”
• Open Notepad.exe and add the following lines: o sc config "ccmexec" start= auto (please note there is a space between the equal sign
and “auto”) o net start "ccmexec"
• Save the file as “c:\NxPrepExtend.cmd”, make sure the extension is .cmd and not .cmd.txt by turning off “Hide extension for known file types” in the Tools…Options section for Explorer.
• Once completed, the image is ready for publishing and deployment.
The Administrator may choose not to install the SCCM client into the golden image and opt for a traditional approach to installing the SCCM client. Upon deployment, XenClient Enterprise will present the virtualized Windows instance as a normal Windows instance from SCCMs perspective. Since the dedicated images are not centrally updated and do not synchronize via the snap-back and snap-forward capabilities, the changes to the deployed dedicated image are persistent. This means the standard client deployment methodologies can be applied as outlined in “Tasks for Configuration Manager Client Deployment” from Microsoft TechNet.
Deploying the SCCM Client on XenClient Enterprise Shared Images XenClient Enterprise Shared Images are synchronized with the central image and have the snap-back capability enabled. This presents unique challenges for deploying the SCCM client. In this case, the SCCM client must be added directly to the golden image itself since the any installations after the shared image is deployed will be lost after the next client reboot. There are considerations around auto-discovery of Site Codes and ensuring that the proper security keys are made available to the client after the XenClient Enterprise equivalent of SysPrep is run after image deployment. The proper process is as follows:
• Complete the golden image creation through the Synchronizer console
• Install the SCCM client per your company’s best practices. It is recommended to use auto site
discovery if the VM will be assigned to different sites codes.
19
• Copy the CCMDelcert.exe and Tranguid.exe tools from the SCCM Client Toolkit (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=61e4e21f-2652-42dd-a04d-
b67f0573751d) to c:\Windows\System32
• Install the SCCM client
• Run “CCMDelCert.exe” on the golden image client. This removes the SMS Certificate.
• Run “Tranguid /r” on the golden image client. This will force a new SMS ID to be created.
• Start the Services manager and find the SMS Agent Host service. Stop the service and change
the Startup type to “Disabled”
• Open Notepad.exe and add the following lines: o sc config "ccmexec" start= auto (please note there is a space between the equal sign
and “auto”) o net start "ccmexec"
• Save the file as “c:\NxPrepExtend.cmd”, make sure the extension is .cmd and not .cmd.txt by turning off “Hide extension for known file types” in the Tools…Options section for Explorer.
• Once completed, the image is ready for publishing and deployment.
The SCCM Client XenClient Enterprise Synchronizer OS Profile Policy When Shared Images are deployed, the SCCM OS Policy must be enabled to ensure any change to the central image does not affect critical SCCM client operation.
Virtual Windows Instances in Active Directory While XenClient Enterprise Engine and XenClient Enterprise Synchronizer work in concert with Active Directory to assign VM resources, the Engine itself does not actually join the domain. Therefore it is not seen in Active Directory Users and Computers. This is no different than VMware ESX. However, the Windows guests are seen In Active Directory, just as they usually would if they were installed physically.
When the Synchronizer performs its preparation and delivery, regardless of whether it is deploying a Dedicated or Shared Image, it will change the name of the computer upon first deployment to the assigned users name combined with a series of numbers that provide a unique name in Active Directory. Once the name is changed, it will automatically be joined to the Windows Domain. This newly deployed name will appear in the Computers OU in Active Directory Users and Computers. This computer object now represents the virtual guest deployed to the VM. It may now be assigned to any OU in Active Directory depending upon organizational and Group Policy requirements.
XenClient Enterprise Hosts, Guest Windows Instances and SCCM Collections SCCM only recognizes Windows OS instances and pulls them into collections. Since XenClient Enterprise Engines are XEN-based systems, they cannot be seen directly inside of SCCM. However, the Windows desktops that are virtual machines with an SCCM client will be seen as part of the SCCM collections. XenClient Enterprise Engine injects hardware and host information into the
20
HKLM\Software\Citrix\XenClient registry keys in each Engine hosted virtual Windows instance. This information can be discovered through a MOF-based extension outlined in the “Hardware Inventory” section below and reported on. It can also be used to form collections by querying the different information surfaced by the virtual machine intermediary resulting in custom collections of Engine hosted virtual machines.
Operating System Updates Operating system updates are performed by two different approaches based on the type of image being used. With Dedicated Images, OS updates are able to be directly delivered to VMs via the SCCM or Windows System Update Server (WSUS) agents.
However, Shared Images do not retain any installed software after the next reboot. This means any updates to the operating system and applications must be performed to the central golden image through the Synchronizer. The process is to launch the golden image in the Synchronizer, then use SCCM and WSUS to perform the updates. The updates will be installed on the golden image, but will be deployed as an update layer through XenClient Enterprise Synchronizer.
Application Deployment and Updates via SCCM Application updates are delivered in the same manner as the OS updates and, once again, are performed by two different approaches based on the type of image being used. With Dedicated Images, application deployments and updates are able to be directly delivered to VMs via the SCCM or WSUS agent.
However, Shared Images do not retain any installed software after the next reboot. This means any updates to the applications must be performed on the central golden image through the Synchronizer. However, application updates can be deployed to the centralized golden image through SCCM. The updates will be installed on the golden image, but will be deployed by the layer update technology in XenClient Enterprise.
Software Inventory Regardless of VM image type deployment, software inventory through SCCM remains unaffected. Custom reports can be created to match the same software in multiple virtual machines on a single host so the real per device/seat licensing requirements are understood. For example, NXTOPHOST1 is hosting two virtual machine instances named “Admin-W7-01” and “Admin-W7-02”. Both instances have Microsoft Office 2010 installed. A custom report can be created to cross-reference the host name with the virtual machines and the software inventory to ensure that IT understands Office is virtually present on the same machine, eliminating any confusion over the number of physical hosts with Office present
Remote Server Functionality Leveraging the Synchronizer remote office server capability allows you to manage all remote servers from your central server. You can gain many key things by using the remote servers such as intelligent
21
caching of downloaded images, efficient use of bandwidth between remote offices, local storage and maintenance of backups, and fast recovery for remote clients. The remote server can be used in WAN or LAN setups. The remote server will require network access to the SQL database as well as the central server. The SQL port 1433 needs to be open for access to the database and port 443 needs to be open for access to the central server. All downloads from the central server are encrypted and compressed. As a user requests an image update, or a XenClient Enterprise Engine update they request it from the remote server to which they are registered, the remote server then checks with the central server to begin download of the update. Once the update is downloaded to the remote server it then caches it for the next user.
22
Appendix A: Sizing a Medium Installation A medium sized installation has the following characteristics:
• 1100 users at 10 sites (including the corporate headquarters and 9 remote sales offices). o The HQ site has 200 users of which
50 are mobile users who are connected remotely 50% of the time on average using a WAN connection that averages 10Mb/s down to the client system and 1Mb/s upload from the client system.
100 users are engineers who are all using desktops running the development environment.
The remaining 50 are support/IT staff running a single VM o Each remote office has 100 users of which
75 are mobile users who are connected remotely 75% of the time on average using a WAN connection that is 10Mb/s down and 1Mb/s up.
The remainder is support staff running a single environment. • 4 Distinct VMs defined, each of which has maximum size of 50GB (uncompressed) for the
system disk and 30GB (uncompressed) for the user disk: o Windows 7 Corporate (Windows 7 plus Office Professional plus sales tools and material) o Windows 7 Development (Windows 7 plus Visual Studio and Microsoft Office standard) o Windows 7 Support (Windows 7 plus Office Professional). o Windows 7 Personal OS (Windows 7).
• VMs will be updated and published weekly with hotfixes. Updates are 1GB (uncompressed) on average and the procedure will be to stage the update to IT first and then deploy to all users once testing is complete.
• Support staff (25 at each site) have a single VM assigned which is the ‘Windows 7 Support’ • Other users have 2 VMs assigned depending on the individual
o Windows 7 Corporate, Windows 7 Development o Windows 7 Personal
• Each user will modify on average 100MB/day of user data across all VMs deployed to his client system. With compression, this translates to backup sizes of around 50MB/day/user.
• Backup policy is to perform a backup every day and keep the last 7 days worth of backups for all assigned VMs except for users with the Development environment for which backups are kept for 4 weeks.
With this setup, there would be 10 Synchronizer Servers in the installation:
• One Synchronizer Central Server at the HQ location handling all Synchronizer Remote Servers and the 200 local users
• One Synchronizer Remote Server at each of the other 9 locations.
With this definition, we can calculate:
23
• At the Synchronizer Central Server: o Total storage required for VMs – 4 * 90GB = 360GB o Total Storage required for backups: 10TB
Engineers (total size per user disk 32GB) : 100 * 32GB = 3200GB Remainder (total size per user disk 30GB) : 100 * 30GB = 3000GB
o Total amount of data to be transmitted to deploy all VMs: 4TB For local users: (150 * 2 + 50) * 10GB = 3.5TB To Synchronizer Remote Servers: 9 * 4 * 10GB = 360GB
o Total amount of data to be transmitted • At the Synchronizer Remote Servers:
o Total Storage required for VMs : 360GB o Total Storage for backups: 100 * 30GB = 3TB o Total amount of data to be transmitted to deploy all VMs: (75*2 + 25)*10GB = 2TB
• Total time to initially deploy all VMs to HQ users & Remote Office Servers: 1+8.5+2.5 = 12hrs o Time to send VMs to Remote Office servers: ~1hr
Note that this can run first to enable remote sites to start deployment quickly. o Time for HQ users connected to corporate net (100 engineers getting two VMs, 50
support staff getting one and 25 mobile users getting 2): ~8.5hrs (125*2+50)*10GB/800Mbs = ~8.5hrs
o Time for HQ staff connected remotely – each one has dedicated 10Mb/s BUT this is not available whilst other central users being updated as the entire 1Gb/s link is being used to achieve the 8.5 hrs – however, once the other central users have been deployed, all 25 remote users run in parallel using a total of 250Mb/s : 2.5hrs 10GB/10MBs = 2.5hrs
• Time to initially deploy VMs to remote site users: 1.75+2.5 = ~4.5hrs o Time for users connected directly to remote site LAN (18 sales staff with 2 VMs and 25
support personal with 1 VM): ~1/75hrs (18*2 + 25) * 10GB / 800Mbs = ~1.75hrs
o Time for mobile users at remote site – these all operate in parallel but cannot run at the same time as the remote site LAN attached users: 2.5hrs (10GB/10MBs = 2.5hrs
• All 9 remote sites run in parallel with HQ site so the entire corporation is deployed in ~12hrs. • Total amount of data to be transmitted to update all VMs: (100 * 2 * 1)GB = 200GB • Total time to update all VMs: ~2hrs
o All systems connected to the corporate network will be complete in ~35minutes. o Remotely connected systems will take ~2hrs to download their two updates.
• Total backup data sent on the corporate network each day: 63 * 50 = ~3GB/day • Total backup data send on the WAN connection each day: 37 * 50 = ~2GB/day • Total time to backup via the corporate network at 800 Mb/s : 30s • Total time to backup via the WAN connection at 320Kb/s: 3 minutes
24
Each remote user has a DEDICATED 320Kb/s link. The total bandwidth used by 37 users at 320Kb/s is around 11Mb/s so all 37 transfers can be done simultaneously and each remote user sees just 3 minutes of backup time per day.
Appendix B: XenClient Enterprise Installation FAQ This appendix provides answers to the most Frequently Asked Questions and issues one may encounter when installing XenClient Enterprise Engine.
Installing the XenClient Enterprise Engine on a computer can remove the native operating system and any data. Before installing, back up any data from the computer that you want to preserve.
Hardware Compatibility While XenClient Enterprise Engine supports the broadest set of platforms for all desktop virtualization products, it does not support all possible configurations. Consider the following:
• Citrix recommends that you use business-class laptops/desktops with all Intel components (CPU, GPU, and networking) and 7200 RPM or faster hard drives are best.
• NVidia/Optimus systems are often problematic, if you are using such hardware: o disable Optimus in the BIOS; even then it might not work o experimental NVidia drivers should never be used in a production environment
CPU Compatibility The following CPU characteristics should be adopted for systems running XenClient Enterprise Engine:
• Use Intel or AMD dual-core processors with Intel-VT (VT-x) or AMD-V hardware virtualization technology.
• XenClient Enterprise Engine performs best on Intel-based hardware; for best results use Intel CPUs.
Intel provides a tool to determine if the chip in your computer supports virtualization: http://processorfinder.intel.com/.
• The CPU must support 64-bit operation. • As noted above, the CPU must support virtualization technology. However, on some platforms
enabling VT-d support in the BIOS (see BIOS Settings for more information) can sometimes cause problems.
Video Compatibility XenClient Enterprise Engine performs best when running on an Intel-based graphics system. Selection of graphics cards from other vendors may be problematic. Consider the following:
• XenClient Enterprise Engine provides limited support for newer NVidia and ATI graphics cards.
25
• Some graphics cards may cause the installation to fail.
If you are installing XenClient Enterprise Engine on a desktop with ATI or a Nvidia graphics card, remove it and use the onboard Intel graphics card instead if possible.
Memory The XenClient Enterprise Engine minimum RAM configuration is 2 gigabytes; Citrix strongly recommends 4GB or more to achieve best system performance and facilitate running multiple virtual machines (VMs) simultaneously.
It is possible to encounter installation failures related to system memory:
• Citrix has determined that in some cases corrupt memory leads to installation failures.
• PXE boot installations may fail if the computer has 2 GB RAM or less.
BIOS Configuration Settings To use XenClient Enterprise Engine, the system must support virtualization. BIOS settings must also be configured to match the following criteria:
Virtualization: enabled (checked)
VT: enabled (checked)
Trusted Execution: off (unchecked)
For Lenovo computers:
Timer wake with battery: enabled
You need to restart the computer for changes to the BIOS to take effect. On some systems, it may be necessary to power-down the computer for a few minutes, then restart.
Disk Configuration XenClient Enterprise Engine supports running on a single, local SATA drive and should be installed into a partition or hard drive with a minimum of 60GB free space.
The following disk configuration issues may pose problems during installation:
• Ensure that there is at least 60 GB free disk space; running multiple operating systems may require significantly more disk space.
• Installing over some Linux-based products may be problematic. • Installing over products with disk encryption may be problematic (for example, BitLocker). • XenClient Enterprise Engine should not be installed over other virtualizations solutions; it must
be installed directly on a bare metal platform.
26
• The Engine cannot be installed over disks configured with GPT or other non-simple partition layouts.
Disk Encryption
The Engine supports running with an encrypted disk; this decision must be made during installation.
The password used for the encryption is not set during installation, this happens during the registration process.
An encrypted hard drive cannot be accessed unless the registered owner’s password is entered. The user’s password needs to be entered before the Engine can start. Once the user logs in, the hard drive is accessible and the user experiences no difference due to the encryption. This is a strong security measure – the encrypted disk cannot be accessed without the proper authentication. The only cost is a very slight (few percent) increase in CPU use.
Installation Media The Engine can be installed via USB or Optical media as well as through a PXE (Preboot Execution Environment) server configuration. Creation or configuration of the selected approach is straightforward and utilizes industry standard approaches, all of which are discussed in the XenClient Enterprise Engine Installation Guide.
A general installation issue that may be encountered is due to working with an ISO file that is incomplete or corrupt.
In some cases it may be necessary to check the validity of the ISO file by verifying the MD5 checksum. A number of free ware tools are available for calculating and comparing MD5 files (for example: http://download.cnet.com/MD5-Checksum-Calculator/3000-2092_4-10964258.html).
Should other problems be encountered during the installation, refer to the appropriate section below.
Optical Media Creating optical media from which to install XenClient Enterprise Engine is as simple as burning any other ISO file. The process of burning an ISO file to disk has some inherent issues that may be encountered:
• XenClient Enterprise Engine requires at least 770 MB of free disk space; it may not fit on all CD readers/media. Use CD media instead of DVD media.
• Burning an ISO file located on a network share can be problematic so the file should be copied to the local system prior to initiating the burn.
• Bad optical media; use a different source • Bad disk creation; re-burn with another disk • Optical media incompatible with optical drive • USB optical drives can be problematic (some may work, others may not)
27
USB Media Creating a bootable USB installer for XenClient Enterprise Engine involves a few more steps beyond ‘typical’ USB stick usage. Doing so for XenClient Enterprise Engine is often the first time someone has created a bootable USB stick.
Please refer to the XenClient Enterprise Engine Installation Guide for the step-by-step process to follow.
The points below can help ensure success in this effort:
• Ensure that the computer’s BIOS setting enables booting from USB-based media.
• Unetbootin version compatibility issues.
The outlined process to create a bootable USB stick involves a third-party utility named ‘UnetBootin’.
If you retrieve the UNetbootin distribution from a location other than the Citrix website, ensure that it is at least version 549 or newer.
• The selected USB storage device should have a formatted capacity of at least 2GB. • The selected USB storage device should be freshly formatted with a FAT32 file system prior to
running UnetBootin. • Creating bootable USB media from an ISO file located on a network share can be problematic;
the file should be copied to the local system prior to running UnetBootin. • After the UnetBootin application has finished, exit the program (utilizing the supplied Exit
button) and properly eject the device using Windows Explorer.
A Common Post Installation Issue It is possible to configure the computer BIOS so that USB, CD-ROM, or PXE is the first boot device, ahead of the local hard disk. If the installation device is before the hard disk in the list of boot devices, after the Engine installation has completed and the system reboots, it may begin running the installation again. This would be normal behavior as dictated by the settings in the computer BIOS.
Should this situation be encountered, perform the following steps
• If using Optical or USB media to perform the installation, remove the device
• Configure the computer BIOS device boot order accordingly by rebooting the system and entering the computer setup functionality (often accomplished by pressing the F12 key as the system is booting).
28
Advanced XenClient Enterprise Engine Installations
Dual Boot Installation XenClient Enterprise Engine can be installed in a dual-boot configuration alongside Windows XP or Windows 7 installations. This option is for advanced users.
Refer to the XenClient Enterprise Engine Installation Guide for dual boot installation instructions.
Problems can be avoided by ensuring the following prior to installing the Engine:
• Ensure sufficient free disk space exists • A free primary disk partition is required
There are numerous disk partition tools. For Windows XP-based computers, Citrix has tested the procedures in this document using the EASEUS Partition Master Home Edition. For Vista and Windows 7, use the native Disk Manager to create a partition.
• Dual boot installations will not work if Windows is using disk encryption (for example, BitLocker).
XenClient Enterprise Engine PXE Boot Installs Installation of the Engine via a PXE server configuration is an advanced topic. Please refer to the XenClient Enterprise Engine Installation Guide for specific instructions in this area.
If you have problems PXE booting the Engine, first validate your PXE boot environment using a standard Linux distribution.
Troubleshooting Installation Failures Citrix endeavors to make installing XenClient Enterprise Engine a simple, pain-free process. Experience has shown there are a few common areas where issues may be experienced. Should you encounter an installation failure, please review the following list for possible reasons and solutions prior to contacting technical support.
Consider the following general troubleshooting techniques:
• Screen turns black with a blinking cursor during installation. To resolve this, verify that the machine has a compatible video card.
• Insufficient space to perform installation. • Unfamiliar partition table structure. To resolve this, replace the disk, install using the full disk, or
wipe the disk and reinstall. • Installation may spontaneously reboot for no apparent reason. Review the information in this
guide for specific resolutions to this uncommon problem. • Installation may display a message reading “Unknown Error”; in such cases use the bug
reporting mechanism within the Installer if it is available.
29
• XenClient Enterprise Engine downgrade is not supported; if you have to install an earlier version, uninstall the current version first.
• Use the latest version of XenClient Enterprise Engine. Visit the Citrix download site for the latest version.
• If installation from optical media fails, try USB, or vice-versa • Verify installation media before installing • If possible, try another computer; some of the issues described in this document are difficult to
troubleshoot (for example, corrupt memory); simply changing platforms may resolve some issues.
