Issue: Some of the citrix VDIs are powered off in vcenter automatically. Logs show that citrix powered off these machines. OR When users try to login to their VDI, it throws an error. Powerstate for all the VDIs in citrix site show as unknown.

Analysis and Solution:

when  citrix tries to power on a VDI, it should be brokered through a citrix delivery controller (Lets say DDC1). If this delivery controller has any issue from contacting the vcenter, it will report this VDI state as unknown and power off that VDI.

If your hypervisor environment doesnt have any issue, quick solution is to try enabling and disabling maintenance mode on the hosting url in citrix studio.

Solution:

Run below command on your delivery controller:

Get-BrokerHypervisorConnection

Output shows all your hosting connections. Check the PreferredController name and State parameters in the output. If any server shows state as unavailable, login to that delivery controller and restart “citrix broker service” and “citrix host service” services. Run tests on all your storage resources in hosting tab in studio and make sure all tests are successful.

Other Solutions from https://support.citrix.com/article/CTX131267:

Warning! Back up the XenDesktop database before completing these actions.

1. Open DDC using the PowerShell console and run the following commands to display all machine IDs of the virtual machines from the hypervisor.

   1 2 3

   asnp Citrix* $ErrorActionPreference=Continue Get-ChildItem -Path XdHyp:\ -force -recurse | ?{ $_.IsMachine } | Out-File –Filepath c:\xdhyp.txt

2. The xdhyp.txt output file contains the correct machine IDs from the hypervisor. Open that file and press Ctrl+F or Edit > Find. Search for the name of the Virtual Machine, in this case, the name of the Virtual Machine is PVS0003.

   Example output

   PSPath : Citrix.Host.Admin.V1\Citrix.Hypervisor::XDHyp:\Connections\XenServer\PVS0003.vm PSParentPath : Citrix.Host.Admin.V1\Citrix.Hypervisor::XDHyp:\Connections\XenServer PSChildName : PVS0003.vm PSDrive : XDHyp PSProvider : Citrix.Host.Admin.V1\Citrix.Hypervisor PSIsContainer : True Name : PVS0003 FullName : PVS0003.vm ObjectType : Vm Id : 7d1d6004-5319-7a7e-59cb-2662e212a3e5 IsContainer : True IsMachine : True IsSnapshotable : True ObjectPath : /PVS0003.vm FullPath : XDHyp:\Connections\XenServer\PVS0003.vm IsSymLink : False AdditionalData : {}

   Note: The machine ID is as follows:
   Id : 7d1d6004-5319-7a7e-59cb-2662e212a3e5.
   Your result will vary.

3. Run the following command:
   Get-BrokerMachine -PowerState Unknown This identifies the machines that have the unknown power state.+ Note the “HostedMachineId “ from the output.+ Now comparing the “ID” from Step1, and the “HostedMachineId “ from this step, You’ll find that the IDs are different.+ Correct “Id” is from the Step-1  and incorrect value is present in Database (from step-3)

   • We can also verify the same by Browsing the below tables in SQL site database and confirming the values.

   Chb_Config.Workers » HostedMachineId »

   DesktopUpdateManagerSchema.ProvisionedVirtualMachine » VMId »

4. Run the following command to change the XenDesktop Database’s record for the machine ID to match the Hypervisor’s Machine ID:Set-BrokerMachine -MachineName ‘MyDomain\MyMachine’ -HostedMachineId  [machine ID from preceding output]. This corrects the HostedMachineId for the problem machines using the ID that was retrieved from xdhyp.txt.

5. Check Desktop Studio or Desktop Director and refresh the list of results.
   The power state must now match the state indicated in the hypervisor.

Note: It might be necessary to restart the Citrix Broker Service on all DDCs and/or restart the virtual machine.

Solution 2

Understanding of the Broker > Hypervisor communication:

• The Broker service runs on every Delivery Controller in the site (DDC). It has many subcomponents, one of which is the Hosting Management sub-component.

• The broker service must communicate to the Hypervisor using the VM/Machine ID

• The UUID/Machine ID of the VM can be obtained by running “Get-BrokerMachine” cmdlet from any of the DDC’s in the site.

•  It needs to match with the BIOS file of the VM on the hypervisor to be managed properly by DDC’s on the Site. Get-BrokerHypervisorConnection

• If the Certificate is updated on the VSphere server the same needs to be updated on all the DDC’s on the Site. Certificate mismatch can also cause the Broker to change the power states to “Unknown” and Hypervisor connection state to “Unavailable”.

• If there is a Host/VSphere Server which is put under maintenance or is down for any reasons, the Broker will change the Power state to “Unknown” and Hypervisor connection state to “Unavailable”.

• If there is an issue with broker service on one controller, broker service from another controller will serve as the Preferred controller to control the Power and pool for the site.

Steps to remediate the situation if the issue occurs:

• If there is a network or VMware host issue which has corrected itself, the broker service won’t be able to re-establish the communication on its own if the disruption is for a longer period of time. In that case, the broker service needs to be restarted on all the DDC’s in the site.
• Alternatively, you may run the command below cmdlet on any of DDC’s using Power Shell.
• Update-HypHypervisorconnection – LiteralPath “The Actual Path of hypervisor Connection”
• -LiteralPath of the Hypervisor connection can be obtained by running the below cmdlet on PowerShell of any DDC.

1
2

cd Xdhyp:
cd ./Connections

• for instance: Update-HypHypervisorConnection -LiteralPath “XDHyp:\connections\Connection”
• Alternatively, you may do the following using Studio to update the connection:

Click on Hosting tab on Studio -> Right click the connection -> Click on Edit Connection -> Without making any changes click on OK.

Solution 3

Remove the affected virtual machines from the Desktop Group in Desktop Studio and add them again.

NOTE: Removing machines from an MCS catalog cannot be reversed. Once the VM is removed you will only be able to add that machine to a catalog of the “Manual” type. (This catalog type was called as “Existing” type in XenDesktop 5.x.  It is referred to as “Manual” in XenApp and XenDesktop 7.x.)

Solution 4

Ensure the SCVMM console version and hotfix level, installed on the DDCs, is the same version and hotfix level as the SCVMM server.

For example: Install the upgraded version of the SCVMM Console, version 8, KB3097539 on both controllers, which matched the SCVMM server hotfix level.

Solution 5

1. Run “Get-BrokerHypervisorConnection”, and check the output for Hypervisor state,
2. If for any hypervisor connection the state is, anything else then ON or OFF,
3. Then try to put that connection in maintenance mode for few secs and then turn off the maintenance mode again.

Solution 6

1. Restart the Citrix Site services on all the DDCs. Note: This may result in momentary disruptions of new connections, however current sessions are not affected.

• Open PowerShell as admin and run the following commands:
  • Get-Service Citrix | Stop-Service -Force*
  • Get-Service Citrix | Start-Service*

Solutions from: https://support.citrix.com/article/CTX131267