Tag: XD 5.6

Monitor blanking does not consistently occur in XenDesktop 5.5 and 5.6

Symptoms

Monitor Blanking does not consistently occur on XenDesktop 5.5 and 5.6 when connecting to a physical computer using HDX 3D Pro. This would result in the user sitting at the console of the VDA being able to see what is being done inside the ICA session.

Cause

This is a limitation in XenDesktop 5.5 and 5.6 and is a known issue.

Resolution

Upgrade to XenDesktop 5.6 Feature Pack 1 and use the Remote PC feature, which has been tested with consistent monitor blanking.

Read the original post here.

Hotfix for Citrix XenDesktop 5.6 broker service

New Fixes in This Release

  1. When using Concurrent User (CCU) licensing, the licenses might fail to check-in, eventually resulting in a shortage of licenses. The administrator is required to restart the Desktop Delivery Controller or the license server to return it to the original state. The issue occurs when there is a mismatch in the search result while using the case-sensitive string comparator. As a result, the record of the licenses might not be found while releasing the license.

    [From XD560BrokerSvcWX86002][#LA0971]

  2. Administrators with “Machine administrator” privileges cannot view or create personal vDisk resources (“Pooled with personal vDisk” and “Streamed with personal vDisk”) in Desktop Studio.

    [From XD560BrokerSvcWX86002][#LA1722]

Fixes from Replaced Hotfixes

  1. Note: This is a feature enhancement that requires you to install both a Broker Service and a Broker Service PowerShell Snap-in hotfix that contains Fix #LA0754.

    Description: Failure of a hypervisor or a loss of connectivity between the hypervisor and the Broker renders an active session inaccessible, and attempts to reconnect to the session fail. For shared desktops, and in the common case where a user is entitled only to a single desktop from a group, the user effectively loses all access to that desktop group, even if other machines in the same group (but on a different hypervisor) are available for use. For large hypervisors in a data center, such loss of a hypervisor can cause a large scale reduction of availability of XenDesktop that requires significant operator intervention to remedy.

    With this feature enhancement:

    • a new session can be brokered from the existing infrastructure
    • sessions orphaned as a result of hypervisor failure or of a loss of connectivity can be enumerated and terminated from the console

    Background: This feature enhancement adds a new “hidden” attribute to every session. With the “hidden” attribute set to “false” (default), XenDesktop behaves entirely as in earlier releases. To avoid a loss of desktop availability in the event of hypervisor failure, the Broker automatically marks a session as hidden (“hidden” = “true”) the moment a user attempts to reconnect to that session. With the session marked hidden this way, the Broker continues with the session launch as if no session was found to which to reconnect. Provided sufficient desktops are available, a new session is created on a different desktop – even if the user’s entitlement to that resource would ordinarily be exhausted.

    • To enumerate orphaned sessions, use the PowerShell command “Get-BrokerSession -Hidden $true”
    • To revert all hidden sessions to their visible state, use the PowerShell command “Get-BrokerSession -Hidden $true | Set-BrokerSession -Hidden $false”

    [From XD560BrokerSvcWX86001][#LA0754]

Installing and Uninstalling this Release

Notes:

  • This release is packaged as a .zip file containing the replacement Broker_Service_X86.msi file. For more information about deploying msi files, see Microsoft article 884016 or visit the Microsoft Web siteand search on keyword msiexec.
  • To install this hotfix successfully, servers must not have registry modification restrictions in place.
  • This hotfix might or might not prompt you to restart the server when the installation or uninstallation is complete. You must restart the server for the installation to complete.
  • If the need arises to restore the original settings and functionality provided by this hotfix, you must uninstall the hotfix before reinstalling it according to the installation instructions below.

To install this hotfix:

  1. Copy the file to a shared folder on the network.
  2. Extract the compressed file and save the Broker_Service_X86.msi file on the computer you want to update.
  3. Run the .msi file.
  4. Restart the computer.

To uninstall this hotfix:

  1. From the Start menu, select Settings > Control Panel.
  2. In Control Panel, double-click Programs and Features .
  3. Highlight the hotfix you want to remove and click Uninstall.
  4. Follow the directions on-screen.

You can download the hotfix on the following pages:

Dedicated VM shuts down and remains powered off, even though logoff behavior “ShutdownDesktopsAfterUse” is set to false

Dedicated Virtual Machine shuts down and remains powered off, even though Logoff behavior ShutdownDesktopsAfterUse is set to false.

Cause

The problem occurs after updating the master image of a Dedicated type catalog using the PowerShell SDK commands listed under CTX129205 – How to Update the Master Image for Dedicated and Pooled Machine Types using PowerShell SDK Console.

Changes applied to the master image of a Dedicated Catalog should only affect new machines created from the image and those changes does not apply to the existing machines in that catalog.

The problem occurs because the update process assigns the new updated image to all the Virtual Machines in the catalog, marking the existing ones with the ImageOutOfDate flag. Once the flag is enabled for the Virtual Machine, it shuts down after logging off with the attempt to start to the newly assigned image. At this point, the flag is always enabled since Dedicated machines cannot change to a different image.

Resolution Continue reading “Dedicated VM shuts down and remains powered off, even though logoff behavior “ShutdownDesktopsAfterUse” is set to false”

How to Resize Personal vDisk

This article describes how to resize the Personal vDisk (PvD).

Requirements

XenDesktop 5.6

Procedure

The following points should be kept in mind while resizing the PvD:

  • A PowerShell script is included in this release that allows you to resize existing personal vDisks in a catalog. The script iterates through the machines in the catalog, changing the size where possible. Resizing takes effect the next time the machines are turned on.
  • You cannot resize Windows XP machines hosted on VMware ESX using the script.
  • Do not use the script to manage existing environments in other ways. Use Desktop Studio or Provisioning Services for other management operations.
  • Before following this procedure, determine the current size of the personal vDisks and choose a new size. In addition, the following PowerShell snapins must be installed on the computer running the script:

the following procedure to resize the PvD:

  1. Put the machines in the catalog into maintenance mode.
  2. Locate the script resize-personal-vdiskpool.ps1 in the SupportToolsScripts folder of the full or upgrade image.
  3. At a command prompt, run the script and select the catalog whose personal vDisks you want to resize. If a script error occurs, dismiss it by running Set-ExecutionPolicy RemoteSigned.

    Note: If you do not have full administrator rights in Desktop Studio and you are using a 64-bit system, run the script from a 32-bit PowerShell administrator command prompt.

  4. Accept the defaults for the storage location and, if displayed, the decision on thin provisioning.
  5. The script displays these properties, which you should not change.
  6. Enter the new size for the personal vDisks. The minimum is 3 gigabytes (GB). Additional space may be required for user applications and data.
  7. When prompted, confirm the selections you made.
  8. Enter the administrator’s user name and password.
  9. Wherever possible, the personal vDisks in the catalog are resized and the machines they are attached to is restarted. When disk preparation is complete, the machines shut down. This process might take several minutes to complete.

    Note: The script lists the machines whose vDisks cannot be resized. Check the power state of these machines, and rerun the script to complete the resizing operation on the entire catalog.

You can read the original KB article here.