Tag Archives: Citrix

Citrix always change default keyboard / input layout after login

Leave a reply

I’m using Chinese input layout in my VDI, so usually I delete all other input layout.
And I found that every time when I login to my VDI via company’s laptop, my VDI’s default keyboard input layout will be changed to English (US), and I have to remove it again and again.

At beginning I thought it’s a windows bug, so I spent lots of time to check MS article to fix the problem…No fix…

And today I found that this issue is caused by Citrix not by Windows… Citrix introduced a new feature named “keyboard layout synchronization” in version 7.16. You can refer to below link:

https://docs.citrix.com/en-us/citrix-workspace-app-for-windows/configure.html#keyboard-layout-and-language-bar

To disable this feature,

On client: use local keyboard layout. Receiver side: select Advanced Preferences > Local keyboard layout setting > No
On VDA disable the keyboard layout sync feature.
For this open registry editor and navigate to HKLM\Software\Citrix\ICA\IcaIme
Add a new DWORD key called DisableKeyboardSync and set the value to 1 and reboot the VDA

disable or enable Citrix License Management Service

Leave a reply
ctx_license_management_service.exe (-enable|-disable|-query)

Where:

-enable enables license management. The first upload to Citrix occurs seven days after you install the License Server.

-disable disables license management. We recommend that you use the License Management Service to manage your licensing environment.

-query displays the current configuration.

Citrix Netscaler VPX high CPU usage? almost 100%

Leave a reply

I’m running a Citrix Netscaler VPX in my lab, and I just noticed that even though there is no connection, the CPU usage for this VPX is 100%.

You can change this behavior by doing the following:

On the left, go to System > Settings.

On the right, in the bottom of the second column, click Change VPX Configuration Settings.

Change the CPU Yield drop-down to YES, and click OK.

After making this change, you can see an immediate drop-off in CPU consumption.

Understanding Citrix Performance Issues

Leave a reply

Bottleneck: provisioning services. Customers note there is excessive Network I/O and CPU utilization.
Bottleneck: vDisk fragmentation or server virtual instances. Customer notes there is excessive page file utilization and disk I/O.
Bottleneck: delays mounting new vDisks. Check for excessive Network and Disk I/O on delivery controllers.
Bottleneck: delivery controllers. Check for excessive historical CPU utilization.
Bottleneck: slow application enumeration. Check for excessive disk and network I/O on the data collectors.
Bottleneck: slow session creation noted within the director console: Check for historical CPU and Memoyr consumption, consider adding VCPU and memory when/where needed.
Bottleneck: higher than expected user logons. Check for high CPU and/or network utilization (not historical but may trend at random intervals). Add processing or new delivery controller if necessary to handle the expected loads.
Bottleneck: issues with local host cache (LHC). Disk and Page File I/O in excess can cause unanticipated issues with LHC. Alert and adjust when/where needed.
Bottleneck: Processor intensive apps. Check questionable servers for larger disk I/O and page file utilization. Consider adding more VCPU’s and/or memory to offset the demand on disk and page file.
Bottleneck: vDisk and/or Provisioning Services. Check for higher than normal CPU and/or Memory consumption as a deficiency will slow down the loading of vDisks and caching via Provisioning Services (PVS).
Bottleneck: Web interface authentication. Consider adding more memory and looking at network utilization trends. It may be necessary to either add more memory or to add an additional WI to your GSLB URL.
Bottleneck: slow PXE and vDisk. Check for memory and/or network utilization and consider addresssing depending on noted trends.
Bottleneck: target device latency. Check CPU and network I/O for spikes and/or trending issues.

Provisioning Services (PVS) and Daylight-Saving Time

Leave a reply

With daylight-saving time beginning at week’s end (March 8 at 2am), we got some issues that can occur with PVS delivered desktops and XenApp servers.

Some of the issues that occur as a result of the time change are:

Time not showing correctly in the Desktop or XenApp server,
Desktop failure to register with DDCs,
User inability to log on due to domain trust relationship issues caused by the VM/Domain time difference.

The Fix:

Open up your PVS delivered image(s) in read/write mode after the time change has occurred on Sunday.
Run “w32tm /resync /nowait” at the command prompt.
Set the image(s) back to read only, following your normal image preparation procedures.

Remember, you must reboot all PVS delivered desktops and servers after you make the above changes to ensure they receive the updated version.

Being proactive will help ensure a smooth Monday morning for all of your users!

More information on this issue can be viewed here: http://support.citrix.com/article/CTX200058

Citrix Error: The connection to *** failed with status 1030

2 Replies

In most situation, if you get this error, it means that there are some configuration errors in your Citrix environment. You can refer to below Citrix article for more information.

https://support.citrix.com/article/CTX124143

But, this week when we tried to renewal our netscaler certificate, we got a problem that:
1. Windows Machines works well with the new certificate. End users can start their VDIs with out any problem;
2. Windows Thin client which is running Windows Embedded XP can’t start VDI. They always got the error code’1030′
3. Some Linux thin client users can start their VDI, while some of them can’t. For who can’t start their VDI they got an error message said that S’SSL error’

Finally, after two days investigation, we fixed this issue.

1. Use Symantec SSL toolbox to scan the certificate installed on our server. We found below error message
SSL

It means that for some old client, they may get problem without the chain. So download the chain and put it into the certificate on Netscaler.

2. After we fixed the chain issue, our thin client still can’t connect. And we found that for the thin client which is running Citrix Receiver 13.1, it can connect. And then we checked Citrix Receiver version changelog and we found

New features in this release

    Native Smartcard authentication to StoreFront
    Session Reliability for robust HDX connection
    SHA-2 encryption for enhanced security
    Improved 64-bit packaging to enable access from 64-bit Linux distributions


https://www.citrix.com/downloads/citrix-receiver/linux/receiver-for-linux-131.html

Well, that’s the key point. For thin client have, they are still using citrix online plugin 11.2 or Citrix Receiver 13.0 for Linux.
So we changed our certificate to SHA1, and all works.

The next step is to upgrade Citrix Receiver to the latest version on all Thin Client and then deprecation SHA-1 certificate and moving to SHA-2.