Failed Machines Test

Using this test, administrator can figure out how many machines of which type are currently in a state of failure. The names of these machines and the precise failure state they are in presently can also be ascertained.

Target of the test : A controller in a Citrix Virtual Apps/Desktops Site 7.x

Agent deploying the test : An internal agent

Outputs of the test : One set of results for each delivery group configured for the site.

Configurable parameters for the test
Parameter	Description
Test Period	How often should the test be executed.
Host	The IP address of the host for which the test is being configured.
Port	The port number at which the specified Host listens to. By default, this is 80.
Controller IP Address	To monitor a site and pull metrics on its performance, the eG agent communicates with a delivery controller in that site. If the target site contains only one controller, then, you need to configure the Controller IP Address parameter with the IP address of that controller, so that the eG agent can use that controller for monitoring the site. Note that in this case, if the controller stops functioning for any reason, the eG agent will not be able to monitor the site any longer. Some sites may be configured with multiple delivery controllers to ensure high-availability, and to optimize and load-balance user connections. When monitoring such a site, you have the option of configuring the Controller IP Address parameter with a comma-separated list of controllers. For instance, the list should be in the following format: 192.160.1.10,198.160.1.11,198.160.1.12. In this case, the eG agent checks the availability of each configured controller at run time, picks the controller that is up and running at that time, and communicates with that controller for collecting metrics on site performance. This way, you can ensure that the non-availability of a single controller, does not impact site monitoring.
Controller Port	Specify the port number of the delivery controller in the site with which the eG agent should communicate for collecting performance metrics.
Username and Password	To connect to a delivery controller and pull out metrics from it, the eG agent requires Farm Administrator rights. In order to configure the eG agent with Farm Administrator privileges, specify the credentials of the Farm Administrator in the Username and Password text boxes. This user should also be assigned the Allow log on locally privilege on the Citrix Virtual Apps/Desktops Site 7.x host. The steps for assigning the Allow log on locally privilege are explained in the Pre-requisites for monitoring the Citrix Virtual Apps/Desktops Site 7.x topic.
Confirm Password	Confirm the Password by retyping it here.
Fully Qualified Domain Name	Here, specify the fully-qualified name of the domain to which the specified controller belongs.
SSL	Indicate whether/not the controller used for metrics collection is SSL-enabled. By default, this flag is set to Yes.
Report by Machine Type	If you want the results of this test to be grouped by machine type – i.e., grouped into Desktop OS Machines and Server OS Machines – then set this flag to Yes. If not, set this flag to No.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measurements made by the test

Measurement

Description

Measurement Unit

Interpretation

Machines that failed to start

Indicates the number of machines in this delivery group that failed to start.

Number

A high value for these measures is a cause for concern. Use the detailed diagnosis of each of these measures to know which machines failed to start and which ones are stuck on boot.

A machine may fail to start or get stuck on boot owing to any of the following reasons:

Cause	Description
Hypervisor Reported Failure	The hypervisor reported an error
Agent Shutdown	The VDA experienced a graceful shutdown
Agent Suspended	The VDA is in hibernation or sleep mode.
Power Off	The VDA did not shut down gracefully.

To know what action to take against each of the reasons discussed above, use the table below:

Cause	Action
Hypervisor Reported Failure	Escalate to hypervisor support team to review hypervisor settings
Agent Shutdown	Power on the VDA if it should not be off based on existing power management policies. Review any errors in the event logs.
Agent Suspended	Take the VDA out of hibernation mode if it should be active. Consider disabling hibernation for XenApp/XenDesktop VDA’s via power settings.
Power Off	If the VDA is supposed to be powered on, attempt to start the VDA within Studio and validate it boots up and registers correctly. Troubleshoot any boot or registration issues. Review the event logs on the VDA once it is back up to help determine the root cause of the shutdown. Review the hypervisor activity logs for information related to the VDA machine.

Machines stuck on boot

Indicates the number of machines that are stuck on boot.

Number

Unregistered machines

Indicates the number of machines in this delivery group that are not registered with the controller.

Number

A high value for this measure is a cause for concern. In such situations, refer to Troubleshooting Unregistered Machines to know the probable causes for this anomaly and tips for troubleshooting it.

Use the detailed diagnosis of this measure to identify the unregistered machines.

Maximum load

Indicates the number of machines in this delivery group that have violated their maximum load limit.

Number

This measure applies only to Server OS Machines.

Ideally, the value of this measure should be low. If this measure reports a high value, then use the detailed diagnosis of this measure to identify the loaded machines.

To know what could have caused this problem condition, use the table below:

Cause	Description
Hypervisor Reported Failure	The hypervisor reported an error
Send settings failure	The Broker failed to send settings and configuration data to the VDA. As part of the hard registration process, the Broker gathers and sends settings and configurations to the VDA. If the Broker is able to gather the data, but is unable to send it, hard registration fails and this failure reason results.
Session Prepare Failure	The Broker failed to notify the VDA to prepare to host a session. When a user requests a connection to a VDA and the VDA is hard registered, the broker notifies the VDA to prepare to be contacted by a receiver instance. If the call fails, the VDA is forcibly deregistered, resulting in this failure.
Session Audit Failure	The broker failed to complete an audit of the sessions that are running on the VDA.

Machines that failed to start recently

Indicates the number of machines that failed to start during the last measurement period.

Number

Use the detailed diagnosis of this measure to identify the machines that failed to start in the recent past. For the reasons for this failure and how to fix it, refer to the Interpretation for the Machines that failed to start measure.

Machines stuck on boot recently

Indicates the number of machines that stuck on boot during the last measurement period.

Number

Use the detailed diagnosis of this measure to identify the machines that stuck on boot in the recent past. For the reasons for this failure and how to fix it, refer to the Interpretation for the Machines stuck on boot measure.

Recently unregistered machines

Indicates the number of machines that were not registered with the controller during the last measurement period.

Number

Use the detailed diagnosis of this measure to identify the machines that were not registered with the controller in the recent past. For the reasons for this failure and how to fix it, refer to Troubleshooting Unregistered Machines.

Machines that reached maximum load recently

Indicates the number of machines that violated their maximum load limit during the last measurement period.

Number

Use the detailed diagnosis of this measure to identify the loaded machines in the recent past.

Troubleshooting Unregistered Machines

There are many reasons why a machine may not be registered with the controller. The table below lists these reasons and also discusses how to fix them:

Cause	Description	Action
Hypervisor Reported Failure	The hypervisor reported an error.	Escalate to hypervisor support team to review hypervisor settings
Agent Shutdown	The VDA experienced a graceful shutdown	Power on the VDA if it should not be off based on existing power management policies. Review any errors in the event logs.
Agent Suspended	The VDA is in hibernation or sleep mode.	Take the VDA out of hibernation mode if it should be active. Consider disabling hibernation for XenApp/XenDesktop VDA’s via power settings.
Power Off	The VDA did not shut down gracefully.	If the VDA is supposed to be powered on, attempt to start the VDA within Studio and validate it boots up and registers correctly. Troubleshoot any boot or registration issues. Review the event logs on the VDA once it is back up to help determine the root cause of the shutdown. Review the hypervisor activity logs for information related to the VDA machine.
Agent Address Resolution Failed	The Controller was not able to resolve the VDA’s IP address.	Verify that the VDA machine account exists in AD. If not, create it. Verify that name and IP address of the VDA machine in DNS are correct and alter if needed. If a widespread issue, validate the DNS settings on the Controller(s). Verify DNS resolution from the Controller by running the nslookup command.
Agent Rejected Settings Update	Settings, such as Citrix policies, were changed or updated but there was an error in sending the updates to the VDA. This may occur if the updates are incompatible with the installed VDA version.	Upgrade the VDA if necessary Review whether the updates that were applied are supported with the VDA version.
Agent Wrong Active Directory OU	An Active Directory discovery misconfiguration occurred. The site-specific OU (where the site controller information is stored in AD) configured in the VDA registry is for a different site.	Ensure the Active Directory configuration is correct, or check registry settings. This only applies if AD OU-based discovery is used for registration as described here.
Single Multi Session Mismatch	The VDA machine's operating system type is not compatible with the Machine Catalog or Delivery Group.	Add the VDA to the correct machine catalog type or Delivery Group containing machines with the same operating system.
Agent Not Contactable	A communication issue occurred between the Delivery Controller and the VDA	Verify the DDC and VDA can successfully communicate via ping. If not, resolve any firewall or network issues. Refer to the additional troubleshooting steps listed in Troubleshooting Virtual Desktop Agent Registration with Controllers in XenDesktop, as these are common problems that cause communication issues between the DDC and the VDA.
Contact Lost	The Controller lost connection with the VDA. This may likely be caused by network disruptions.	Verify that the Citrix Broker service is running on the DDC and the Desktop Service is running on the VDA. Start each if stopped. If already started, restart the Desktop Service on the VDA to restart the registration process and validate the VDA registers successfully. Confirm the DDCs configured for the VDA are accurate via the details in the Application event log. Verify the DDC and VDA can successfully communicate via ping. If not, resolve any firewall or network routing issues.
Broker Registration Limit Reached	The DDC has reached the configured maximum number of VDA’s that are allowed to concurrently register to it. By default, the DDC allows 10,000 concurrent VDA registrations.	If this error is seen, consider adding Controllers to the site or creating a new site. Increasing the number of VDAs allowed to concurrently register with the DDC via the HKLM\Software\Citrix\DesktopServer\MaxWorkers registry key is also possible. Please see here for more details. Note that increasing this number may require additional CPU and memory resources for the DDC server.
Empty Registration Request	The registration request sent from the VDA to the DDC was empty. This may be due to a corrupt VDA software installation.
Invalid Registration Request	The VDA made a registration request to the broker, but the content of the registration request is corrupt or invalid.
Missing Agent Version	When registering with the broker, the VDA reports its Citrix Broker Protocol version to the DDC. This failure reason appears if the VDA fails to communicate the Citrix Broker Protocol version.
Missing Registration Capabilities	The VDA version not compatible with the Delivery Controller.	Restart the Desktop Service on the VDA to restart the registration process and validate the VDA registers correctly via the Application event log. Reinstall the VDA software if the issue is impacting all machines.
Functional Level too Low for Catalog	The machine catalog is set to a higher VDA version than the installed VDA version.	Verify whether the VDA’s machine catalog functional level is lower than or equal to that of the VDA, and downgrade the machine catalog to be lower than or equal to that of the VDA if necessary.
Functional Level too Low for Delivery Group	The delivery group is set to a higher VDA version than the installed VDA version.	Verify whether the VDA’s delivery group functional level is lower than or equal to that of the VDA, and downgrade the delivery group to be lower than or equal to that of the VDA if necessary.
Settings Creation Failure	The Broker failed to construct a set of settings and configurations to send to the VDA. As part of the hard registration process, the Broker gathers and sends settings and configurations to the VDA. If the Broker is unable to gather the data, hard registration fails and the VDA becomes deregistered.	Check the event logs on the Delivery Controller for any errors. Restart the Broker service if a specific issue is not evident in the logs. Once the Broker service is restarted, restart the Desktop Service on the affected VDA(s) and validate they successfully register.
Soft Registered	The VDA software has been installed and configured to point to the Delivery Controllers, but it is not yet fully configured. This is usually caused by the machine not being part of a machine catalog and delivery group.	Verify the VDA is part of a machine catalog and delivery group. Add to the appropriate catalog and group if not a member already. In Studio, validate whether the machine is currently Registered or not and/or has an active session or not. If currently registered and (optionally) hosting a session, this error can be ignored. If the machine is unregistered, restart the Desktop Service on the VDA to force re-registration and validate in the Application event log that the VDA successfully registers. Troubleshoot any errors.
Hard Registration Pending	The VDA is not yet fully set up for hosting sessions. The machine experienced issues while transitioning from a soft registered state to a hard registered state.
Incompatible Version	The VDA cannot communicate with the Controller due to a mismatch in the Citrix protocol versions. This is due to incompatibility between the VDA and Controller versions.	Align the VDA and Controller versions.
Inconsistent Registration Capabilities	The VDA cannot communicate its capabilities with the Broker. This may be due to incompatibility between the VDA and Controller versions. The registration capabilities, which change with each version, are expressed in a form that does not match the registration request.
Unsupported Credential Security Version	The VDA and DDC are not using the same encryption mechanism.
Send Settings Failure	The Broker failed to send settings and configuration data to the VDA. As part of the hard registration process, the Broker gathers and sends settings and configurations to the VDA. If the Broker is able to gather the data, but is unable to send it, hard registration fails and this failure reason results.	If limited to a single VDA, restart the Desktop Service on the VDA to force re-registration and validate the VDA registers successfully via the Application event log. Troubleshoot any errors seen. If widespread, restart the Citrix Broker service on the Delivery Controller.
Session Prepare Failure	The Broker failed to notify the VDA to prepare to host a session. When a user requests a connection to a VDA and the VDA is hard registered, the broker notifies the VDA to prepare to be contacted by a receiver instance. If the call fails, the VDA is forcibly deregistered, resulting in this failure.
Session Audit Failure	The broker failed to complete an audit of the sessions that are running on the VDA.