Error “The tools ISO must be ejected from all running VMs in the pool” While installing XenServer hotfix.


1) Find out out all the VDI which are related to tools ISO

#xe vdi-list | grep -B2 tools

Except the vdi which has name-label xs-tools.iso, no other VDI should have Virtual block devices attached to it.

2) To figure out that run the following command against each VDI

#xe vdi-list uuid=<UUID from step1> params=vbd-uuids

If any of the above except vdi with name-label xs-tools.iso return a VBD, we need to remove that object which holds that VBD

#xe vbd-list uuid=<UUID from step2> params=all

This will tell you which one is holding the VBD. In one case, it was a snapshot, which was destroyed using

#xe snapshot-destroy= UUID

Related:

  • No Related Posts

Running Add-PvsDeviceToDomain commandlet from PowerShell without any parameter causes unexpected behavior.

This problem has already been identified by Citrix and is currently working towards fixing the same in the future releases.

The only work around available for now is to use a Parameter along with the PowerShell Commandlet – “Add-PvsDevicesToDomain”, which are as below:

-Guid or DeviceId [<Guid[]>]

GUID of the Device to Add to the Domain.

-Name or DeviceName [<String[]>]

Name of the Device to Add to the Domain.

-DeviceMac [<PvsPhysicalAddress[]>]

MAC of the Device to Add to the Domain.

-CollectionId [<Guid[]>]

GUID of the Collection to Add all Devices to the Domain.

-SiteViewId [<Guid[]>]

GUID of the Site View to Add all Devices to the Domain.

-FarmViewId [<Guid[]>]

GUID of the Farm View to Add all Devices to the Domain.

-FarmViewName [<String[]>]

Name of the Farm View to Add all Devices to the Domain.

-CollectionName [<String[]>]

Name of the Collection to Add all Devices to the Domain.

-SiteViewName [<String[]>]

Name of the Site View to Add all Devices to the Domain.

-Domain [<String[]>]

Domain to add the Device(s) to. If not included, the first Domain Controller found on the Server is used.

-OrganizationUnit [<String[]>]

Organizational Unit to add the Device(s) to. This parameter is optional. If it is not specified, the device is

added to the built in Computers container. Child OU’s should be delimited with forward slashes, e.g.

“ParentOU/ChildOU”. Special characters in an OU name, such as ‘”‘, ‘#’, ‘+’, ‘,’, ‘;’, ‘>’, ‘=’, must be

escaped with a backslash. For example, an OU called “commaIn,TheMiddle” must be specified as

“commaIn,TheMiddle”. The old syntax of delimiting child OU’s with a comma is still supported, but deprecated.

Note that in this case, the child OU comes first, e.g. “ChildOU,ParentOU”.

-SiteId [<Guid[]>]

GUID of the Site.

-SiteName [<String[]>]

Name of the Site.

-Confirm [<SwitchParameter>]

The impact of this operation is “low”. If -Confirm is specified, the operation will be confirmed.

$ConfirmPreference can be set to “low” to have confirmation without the Confirm parameter.

-Object [<PvsObject[]>]

Object: will use the DeviceId, CollectionId, SiteViewId or FarmViewId.

Related:

Importing Computer structure causes Ghost console to crash.

I need a solution

Hi,

I’ve run into an issue with our exported Computer file structure causing ghost to crast when importing. 

I’ve determine the root cause to the problem and a temporary workaround however this is not a solution.

We had a catastrophic failure on our ghost server after an upgrade in October 2019.  After a clean rebuild we started exporting the tasks and computer structure on a regular basis weeklybi-weekly basis.  Our January export of the computers structure when imported crashes the console part way through.  After manually digging around I’ve determined the problem to be 4 systems in different containers have no NIC listed.  In the console it states that the NIC are disabled.  In the exported file they are identified by having “<nics/>” which basically indicates no NIC.

                                <name>aaaTNTLIB-104</name>

                                <computer_name>aaaTNTLIB-104</computer_name>

                                <serial_num>CY09aaaa</serial_num>

                                <uuid>{4C4C4544-aaaa-3010-8039-C3C04F305132}</uuid>

                                <UAC>1</UAC>

                                <nics/>

                                <grouppath>

                                                <group>aaaton</group>

                                                <group>Tlib</group></grouppath></computer>

If I remove them from the exported file, it will import properly.

For now, I deleted those system from the console and they added themselves properly with their working NIC’s.  Now the export file will import fine, however there is no dynamic group rule I could come up with to detect such systems before an export.

Has anyone run into this before? 

Using Symantec Ghost Suite Ver3.3 R3  (Build 2642)

Running on MS Server 2016.

Thanks,

  Ed White

0

Related:

PVS XenDesktop Setup Wizard not using HomeServer affinity from XenServer Template when creating VMs

To resolve this issue:

1. Change the name of the storage to “Local storage”

2. After changing the storage name it may appear as “Local storage on Host” as in the image below.

User-added image

3. Or it may appear as just “Local storage” as below

User-added image

4. The store should appear as “Local storage” Only, in the list on the left.

User-added image

5. We need to check the other-config (MRW) setting for local storage is populated correctly

  • Copy the UUID of the local storage
  • Open the hosts console
  • Type in the following, pasting the uuid in to where it says sr-uuid: xe sr-param-list uuid=<sr-uuid>
  • Scroll down and check the section that says “other-config”. If its blank as below we need to set it correctly
User-added image

6. To set the other-config correctly do the following:

  • Copy the UUID of the local storage
  • xe sr-param-set other-config:i18n-original-value-name_label=”Local storage” uuid=UUID
  • xe sr-param-set other-config:i18n-key=”Local-storage” uuid=UUID
Home server affinity is broken if the local storage name is changed to anything other than "Local Storage".After changing the storage name to "Local storage" please refer to CTX225019 for updating your host connection.Note:  If your host connection was created prior to 7.13 you will need to recreate the host connection.

Related:

  • No Related Posts

Workspace App for Windows – Your apps are not available at this time – Issue when installing Citrix Receiver in not elevated/per-user install mode

Solution 1:

Deleting/resetting the local Windows profile.

Solution 2:

If an user installs Citrix Receiver/Workspace App (not elevated/per-user install) and then uninstall it using Receiver Clean-up Utility (running as an administrator/elevated), while the regular user is still logged in and has their profile loaded.

The below is a high-level list of Receiver related entries that may be left behind in the registry, verify them and clear the registries:

  • HKCUSoftwareClasses* – File Associations and COM object registrations
  • HKCUSoftwareClassesAppID* – AppID registrations
  • HKCUSoftwareClassesApplications* – More app registrations
  • HKCUSoftwareClasses* – COM object registrations
  • HKCUSoftwareClassesCLSID* – MANY COM class object GUIDs
  • HKCUSoftwareClassesWOW6432NodeCLSID* – MANY COM class object GUIDs (32-bit)
  • HKCUSoftwareClassesInterface* – MANY interface name to interface ID mappings
  • HKCUSoftwareClassesWOW6432NodeInterface* – MANY interface name to interface ID mappings (32-bit)
  • HKCUSoftwareClassesMIMEDatabaseContent Type* – x-ica MIME types
  • HKCUSoftwareClassesPROTOCOLSFilter* – Protocol filter handlers
  • HKCUSoftwareClassesRecord*
  • HKCUSoftwareClassesTypeLib*
  • HKCUSOFTWAREMozillaPlugins* – Firefox plugin registrations
  • HKCUSoftwareMicrosoftInstallerProducts – MSI installer product codes

For reference:

You may have to clear the entries as shown in the below screenshot:

Caution:

Incorrectly editing/deleting the registry may render your system inoperable – requiring the re-installation of Windows. Please take a backup of the registry key hive before editing/removing keys.

Related:

Devices getting software not assigned to them

I need a solution

This has been a ongoing random issue for about 1 1/2 now, these devices are not assigned to the filter nor any policies for the software yet the agent installs the software. We thought maybe it was dup GUID so we turned on the policy to correct GUID and that did find devices but the fact we have dup GUID is even odder, our imaging is doing sysprep and some of these dupe GUID on Mac devices that we don’t image, people have non-mac software beeing assigned to them  If our devices didn’t not get sysprepred we would having a whole ton of other issues and it would be more then just the 50 or so devices that showed.

Open a ticket but I have run out of ideas of what is even causing this or where to start, use to blame it on someone adding devices to filters by mistake but audits show those filters are not even updating

0

Related:

  • No Related Posts

Citrix Hypervisor Export Running VM – Export snapshot to file through CLI

Find the VM that you want to backup: xe vm-list

Snapshot the VM, see https://docs.citrix.com/en-us/xencenter/7-1/vms-snapshots-take.html

Find the snapshot to export by listing snapshots and their corresponding VMs: xe snapshot-list params=uuid,name-label,snapshot-of

Set the snapshot to be exportable: xe snapshot-param-set is-a-template=false uuid=<snapshot uuid>

Export the snapshot to a file: xe vm-export uuid= filename=<snapshot uuid>

Later, it can be imported: xe vm-import filename=<path> preserve=true force=true sr-uuid=<uuid> (xe sr-list to find the sr uuid)

Related:

Citrix Hypervisor Export Running VM – Export snapshot to file

Find the VM that you want to backup: xe vm-list

Snapshot the VM, see https://docs.citrix.com/en-us/xencenter/7-1/vms-snapshots-take.html

Find the snapshot to export by listing snapshots and their corresponding VMs: xe snapshot-list params=uuid,name-label,snapshot-of

Set the snapshot to be exportable: xe snapshot-param-set is-a-template=false uuid=<snapshot uuid>

Export the snapshot to a file: xe vm-export uuid= filename=<snapshot uuid>

Later, it can be imported: xe vm-import filename=<path> preserve=true force=true sr-uuid=<uuid> (xe sr-list to find the sr uuid)

Related: