Category: Citrix

Citrix IME might not be set as active IME automatically at the VDA side while using Local IME in Chinese, Japanese, or Korean.

For example, when users enable the keyboard layout options of dynamic sync and Local IME and start a VDA session with Japanese IME, the IME at the VDA side should be switched to Citrix IME automatically.

However, when the issue occurs, Microsoft IME would be set instead:

Failed to load featured products content, Please try again .

Failed to load featured products content, Please try again .

Failed to load featured products content, Please try again .

Citrix Virtual Apps and Desktops administrators can configure HDX to get better network throughput over high latency connections. Configuring the right number of buffers used to send the data, can make HDX use all the available bandwidth over high latency connections.

Refer to Citrix Documentation – Optimize HDX bandwidth over high latency connections

SD-WAN Orchestrator

1) Login to SD-WAN Orchestrator

2) Navigate to All Sites > Quality

In above, we can see from the results of our Underlay Paths that 2 out of the 6 paths is reporting with 0% Up Time.

We can further confirm similar findings by getting site-level detail. Select the impacted site, for the default Availability reports for both Download and Upload paths. From the results, we can see that there is a Member Path establishment issue on the Internet and LTE WAN links between the sites. The issue is only in the Upload path direction, whereas the Download path direction is GOOD.

The Interfaces table is valuable to quickly identify activity on the interfaces, in addition to Errors caused by speed/duplex miss-negotiation. We can see in this case no errors, however, Interface 2 is not sending or receiving any packets.

If Errors are encountered on the Interface reports, Speed/Duplex should be investigated.

Configuration > Diagnostics > PING

Ping, Traceroute and Packet Capture options can be used for troubleshooting.

Configuration > Diagnostics > Traceroute

Configuration > Diagnostics > Packet Capture

In packet capture, if there is no traffic received from peer SD-WAN though it was sent. That means packets getting lost in transit. Verify the routes configured on underlay network devices.

When a new link is added, the following verification steps should have already been conducted:

1. Tested the speed of the new link.

2. Ensured a valid IP address is used (if it is an Internet link then go to www.whatsmyip.org, or other similar sites).

Next, work through the layers to troubleshoot this issue.

Layer 1

Verify the Ethernet settings by going to Configuration > Appliance Setting > Network Adaptors > Ethernet tab.

As shown in the following screenshot, the interfaces are set to auto-negotiate. It will indicate what the ports have negotiated. Configured ports 1/1 and 1/3 have negotiated to 100Mb/Full, while port 1/2 has negotiated to 1000Mb/Full. If a connected port has been hard-coded to 100/Full and SD-WAN Virtual WAN has been set for auto-negotiate, you might see 100Mb/Half. The ports are operating in half-duplex because of duplex mismatch and can reduce performance and hence must be resolved immediately.

Go to Monitoring > Statistics > under Show, select Ethernet from the drop-down list. Verify if there are any interface errors.

Examine the interface settings on all applicable external devices (switch, firewall/router).

Layer 2

Go to Monitoring > Statistics > under Show, select ARP from the drop-down list. Verify if there is an ARP entry for each Gateway and also verify if the ARP entry is on the correct interface. Verify the gateway IP address from the configuration file or from Configuration > Virtual WAN > View Configuration > under View, select WAN links from the drop-down list.

In the following example, a gateway for the DEAD path is 180.0.0.1. The gateway is not responding because there is no MAC address in the table and the State column reports “REPLY_PENDING.”

Layer 3

The next step is to capture packet traces at both the appliances (MCN and Client). Prior to taking a packet trace, you will have to understand what IP address is in the frame. A description of an Intranet versus Internet follows:

Intranet (MPLS)

The IP addressing of the frame is going to be SD-WAN Virtual WAN MCN-VIP <–> Client VIP.

Review Configuration > Virtual WAN > View Configuration > under View, select Paths from the drop-down to identify the IP addressing for the MPLS path.

Internet

The Internet path can be defined as a public IP address or as behind a NAT device. If defined behind a NAT device, the SD-WAN Virtual WAN configuration can be defined with either a static IP address or in a learning mode. In learning mode, the MCN will learn what public IP address the Client uses. In either case, the user should know what IP and public IP’s are before collecting the packet capture. The MCN must be statically defined so that the public IP address will be in the SD-WAN Virtual WAN configuration file. The Client static IP address is defined in the configuration file.

For learned IP address on the MCN, review Monitoring > Statistics > under Show, select WAN link from the drop-down. This page will show the learned IP address for the clients in the network. If there is no entry for the client, verify if the SD-WAN Virtual WAN configuration is defined for learning mode and the Client SD-WAN Virtual WAN is sending frames for this WAN link.

Go to Configuration > System Maintenance > Diagnostics > Packet Capture tab and ensure that the correct interface is selected. Determine this from the ARP entry for the WAN Link gateway which provides the port that the gateway was learnt on.

Ensure that the traffic is being sourced from each appliance with the correct source and destination IP address. Verify router, NAT statements and/or port-forwarding rules. If there is a misconfigured NAT statement, both appliances will source the packets to the proper destination. At the site with the misconfigured NAT statement, however, the traceroute will likely fail after the first hop.

If the SD-WAN Virtual WAN is connected to a switch prior to the router/firewall, ensure VLAN settings are correct. If access to routers is available, perform ping and traceroute on the path to ensure IP addresses are reachable.

Always take database backup before making any changes as editing the database manually can leave it unstable.

• Look for the entries for the deleted machine in MonitorData.Machine table in monitoring database using following query and make a note of the ID of the Deleted machine

SELECT * FROM [<MonitoringDBName>].[MonitorData].[Machine] WHERE Name Like ‘%Name of Machine%‘

• Make a note of the MachineID of the Deleted machine and remove the reference of the machine from MonitorData.Session Table first using the below SQL Statement:

Delete * FROM [MonitorDB].[MonitorData].[Session] WHERE MachineId = ‘DeletedMachineId’

• Then use the below SQL statement to remove the reference of the Deleted VDA’s using the MonitorData.Machine table using the MachineID copied earlier from Monitordata.Session table.

DELETE FROM [MonitorDB].[MonitorData].[Machine] WHERE ID = ‘DeletedMachineID’

Always take database backup before making any changes as editing the database manually can leave it unstable.

• Look for the entries for the deleted machine in MonitorData.Machine table in monitoring database using following query and make a note of the ID of the Deleted machine

SELECT * FROM [<MonitoringDBName>].[MonitorData].[Machine] WHERE Name Like ‘%Name of Machine%‘

• Make a note of the MachineID of the Deleted machine and remove the reference of the machine from MonitorData.Session Table first using the below SQL Statement:

Delete * FROM [MonitorDB].[MonitorData].[Session] WHERE MachineId = ‘DeletedMachineId’

• Then use the below SQL statement to remove the reference of the Deleted VDA’s using the MonitorData.Machine table using the MachineID copied earlier from Monitordata.Session table.

DELETE FROM [MonitorDB].[MonitorData].[Machine] WHERE ID = ‘DeletedMachineID’

Always take database backup before making any changes as editing the database manually can leave it unstable.

• Look for the entries for the deleted machine in MonitorData.Machine table in monitoring database using following query and make a note of the ID of the Deleted machine

SELECT * FROM [<MonitoringDBName>].[MonitorData].[Machine] WHERE Name Like ‘%Name of Machine%‘

• Make a note of the MachineID of the Deleted machine and remove the reference of the machine from MonitorData.Session Table first using the below SQL Statement:

Delete * FROM [MonitorDB].[MonitorData].[Session] WHERE MachineId = ‘DeletedMachineId’

• Then use the below SQL statement to remove the reference of the Deleted VDA’s using the MonitorData.Machine table using the MachineID copied earlier from Monitordata.Session table.

DELETE FROM [MonitorDB].[MonitorData].[Machine] WHERE ID = ‘DeletedMachineID’