Quickly learn tips, shortcuts, and common operations in the new Windows Powershell 3.0, Windows PowerShell Workflow, Windows PowerShell ISE, Windows PowerShell Web Access, Server Manager for Windows Server 2012 Release Candidate, WinRM, WMI, and WS-Man.
Download the guide here at Microsoft’s download center.
Desktop Registration fails even though the VDA is able to ping both the Domain Controller (DC) and Desktop Delivery Controller (DDC). The Virtual Desktop Agents (VDA) are listed as Unregistered in Desktop Studio or in the results, these VDAs are displayed with the Get-BrokerDesktop PowerShell command:
Continue reading “XD Registration Failure occurs when Port 3268 is blocked”
New Fixes in This Release
- 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.
- Administrators with “Machine administrator” privileges cannot view or create personal vDisk resources (“Pooled with personal vDisk” and “Streamed with personal vDisk”) in Desktop Studio.
Fixes from Replaced Hotfixes
- 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”
Installing and Uninstalling this Release
- 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:
- Copy the file to a shared folder on the network.
- Extract the compressed file and save the Broker_Service_X86.msi file on the computer you want to update.
- Run the .msi file.
- Restart the computer.
To uninstall this hotfix:
- From the Start menu, select Settings > Control Panel.
- In Control Panel, double-click Programs and Features .
- Highlight the hotfix you want to remove and click Uninstall.
- Follow the directions on-screen.
You can download the hotfix on the following pages:
In XenServer 6.0 a new feature Receive-Side Copy (RSC) is now enabled by default in Windows virtual machines with XenTools installed.
Receive-Side Copy moves the processing required for network traffic from Domain 0 (netback process) into the virtual machine (netfront process) thereby reducing the load on the control domain when you run large numbers of virtual machines.
In some scenarios, you might have to disable this feature to improve the virtual machine performance.
Known Issue: With Receive-Side Copy enabled a virtual machine virtual interface cannot count transmitted packets. For example, the following is an output for the ifconfig command for a Windows virtual machine that has transmitted a large amount of network traffic:
Windows 7 (64-bit)- vif4.0 RX packets:991371 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:32 RX bytes:41558972 (39.6 MiB) TX bytes:0 (0.0 b)
Note: Citrix is currently working on this issue.
To disable the Receive-Side Copy, complete the following procedure:
- Apply the following registry key to the Windows virtual machine: Note: You can copy the text and save it as a .reg file and then import the file into the registry. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINESYSTEMCurrentControlSetservicesxenvifParameters] “ReceiverMaximumProtocol”=dword:00000000
- Run the following command on the XenServer host, to monitor the ReceiverMaximumProtocol value. When the virtual machine restart the value must be 0. tail -f /var/log/messages | grep ReceiverMaximumProtocol
- Restart the virtual machine to apply the registry change and monitor the messages log to verify if the Receive-Side Copy is disabled.
- To re-enable Receive-Side Copy delete the ReceiverMaximumProtocol registry key and restart the virtual machine.
Read the original post on the Citrix knowledgebase here.