Richard Parmiter

Virtualisation blog and Knowledge Base

  • You are here: 
  • Home

Dell DRAC – Reset

Posted on July 18th, 2011

The Dell DRAC remote management capability often breaks in my experience, and the following can be done to reset it.

  • SSH to the DRAC address using Putty (or a similar SSH app)
  • Login using DRAC credentials
  • Run the following command:
    • racadm racreset

The DRAC component will be reset and should remove any issues with it..

Tags: , , , ,
Filed under Uncategorized | No Comments »

Move VM from Hyper-V to XenServer

Posted on January 7th, 2011

There is a way to move a virtual machine from Hyper-V to XenServer without the need for XenConvert.

On Hyper-V do the following:

  • Power off the VM
  • Backup or migrate to a CIFS share
  • The backup or CIFS share will include the VHD files for the hard disks (one VHD per virtual hard disk)

On XenServer do the following:

  • Create a new VM with the correct configuration (CPUs, RAM, NICs etc) and correct number of Hard Drives.
  • Modify the name of the virtual disks: storage tab, select disk, properties, change name to be something unique (for example TEST or VM-C-Drive or VM-D-Drive). Do this for each disk.
  • Use the cli determine the SR uuid and vm disks uuid
  • > xe sr-list (note the uuid of the correct storage repository)
  • > xe vdi-list name-label=VM-C-Drive (or however named above) – (Note the UUID of each disk)

Copy the VHD files to the XenServer storage volume

  • Using WinSCP or similar copy to the following location (using the sr uuid determined above)
  • /var/run/sr-mount/{SR-UUID}/


  • The VHD files have the filename of the uuid of the virual disk as determined above.
  • Rename 0r delete the first hard disk assigned to this VM (the filename with the uuid of the VM-C-Drive disk)
  • Rename the Hyper-V disk 1 to the same filename {Disk1-uuid}.vhd
  • Repeat the process for each disk

Now you can power on the VM and it will boot from the hard disks copied from Hyper-V.

This seems like a lot of steps but it is pretty quick to do and means that XenConvert is not required (as was not possible in my case). The VM will configure the new devices during the first boot, reboot and then be ready to use.

Tags: , , , , , ,
Filed under Citrix XenServer | 2 Comments »

Wyse Xenith Configuration file

Posted on September 16th, 2010

The Wyse Xenith thin client device can be automatically configured. A DHCP entry can be configured to point the device to a url where is picks up an .ini file with the options set.

Here is a sample xen.ini file:

;*                  Sample INI file (rename to xen.ini)                 *
;*      (Refer to Admin Guide for additional list of supported INIs)    *
;*                                                                      *

;; Wyse Xenith will only replace local engine if an upgrade is available


;; Specify a default domain to show at login page
;; (remove ‘;’ to enable)


;; Specify timezone on client (in case of timezone passthrough)

TimeZone=”Greenwich Mean Time” ManualOverride=yes daylight=yes Start=030507 End=100507 TimeZoneName=”GMT Standard Time” DayLightName=”GMT Daylight Time”
TimeServer=MyTimeServer1,MyTimeServer2 TimeFormat=”24-hour format” DateFormat=”dd/mm/yyyy”

;; You can choose to configure the location of XenDesktop server here
;; instead of using DHCP Option Tag #181
;; (remove ‘;’ to enable)


This is added in the following file structure


The following additional folders can also be added



IIS is configured as per the admin guideto add the MIME types for .ini and . files as text/plain.

More details can be found here: CTX125881 & Wyse #15508

Filed under Uncategorized | No Comments »

Speed up the launch of the XenDesktop Delivery Services Console (DSC)

Posted on September 2nd, 2010

Sometimes the Delivery Services Console takes a long time to launch. This is due to a .NET delay in the authenticode signature component as described in Microsoft Article Q936707.

The following config file can be added to speed up the lauch of the Delivery Services Console.

  • mmc.exe.config

Ensure the contents of the file contain the following:

<?xml version=”1.0″ encoding=”utf-8″?>
<generatePublisherEvidence enabled=”false” />

Copy this file to the following locations:

  • 32-bit server – c:\windows\system32
  • 64-bit server – c:\windows\sysWOW64

Tags: , , , , , , , ,
Filed under Citrix XenApp, Citrix XenDesktop | 5 Comments »

Use a different name for the XenDesktop Controllers Group

Posted on August 24th, 2010

During the initial instalation of XenDesktop, an Active Directory Controllers group is created and populated with the DDC servers in the farm. This group is named ‘controllers’.

For any subsequent installation of XenDesktop a new controllers group is added for each XenDesktop installation with a different name based on controllers – such as ‘ControlA0D3’

If there will be multiple XenDesktop instances in the same Active Directory it may be best to use a controllers group that reflects the business unit, project name or farm name to destinquish it from the others.

The process to do this is detailed in the following Citrix Article: CTX120451

However, the following points are worth noting when following this article.

  • Create a new group in the same OU as the original ‘controllers’ group called: <farm_name>_Controllers
  • Add the DDC controller objects to this group
  • Enable advanced features in the ‘Active Directory Users and Computers’ tool (View | advanced features)
  • Right click the new group | properties | Attribute Editor
  • Locate the objectGUID entry

NOTE: you need the GUID as displayed here. If you open the entry by double clicking to copy/paste the value this mirrors some sections of the GUID as detailed in the Citrix article mentioned above.

  • When entering the GUID into the registry key it needs to be in the format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  • Restart all DDC servers
  • Run the AD Configuration wizard again from one DDC and it will now use the GUID entered in the regkey as the controllers group rather than the default. It appears to also update the SCP information with the details of the new group.

This registry key does not need to be applied to the virtual desktops as they get information about the controllers groups from the AD SCP configuration, which has just been updated from the AD config wizard.

Restarting the virtual desktops (VDA agents) now gives a sucessful registration with the farm.

Note: don’t forget to also update the settings for ‘Access this device over the network’ to include the new controllers group if this applies in your configuration.

Tags: , , , , , ,
Filed under Citrix, Citrix XenDesktop | 1 Comment »