Purpose:
This post is to assist in the resolution of right mouse clicks not being recognized on certain published apps when the endpoint device has multiple monitors that are different display sizes.
Symptom:
When the user launches a published application and is unable to right mouse click on certain portions of the application. I had this issue when the user would move the published app to their secondary monitor (in my case it was the left monitor) then one specific portion of the application would not recognize the right click of the mouse. However if the published app was moved to the primary monitor (right monitor) then it would behave correctly.
Resolution:
What ended up fixing the issue was changing the display settings so that the left monitor was the primary monitor then adjusting the users Start Menu and Desktop icons to the right monitor. Once we did that the published app would recognize the right clicks on both monitors.
SageLike Post ID: SL0016
Applies to:
Windows 7 at least
This was my first encounter with this issue. I'll update this post if the issue comes up in other OS's
March 30, 2017
March 29, 2017
Windows 10 Win + G Pop Up Citrix Receiver Launching Apps/Desktops
Purpose:
To fix the Win + G Popup when launching Citrix apps/desktops from Windows 10 Machines with the latest patches.
Symptom:
When launching published apps or desktops from a Windows 10 OS a green popup windows briefly appears prompting to press Win + G for the game bar or for the search bar.
Resolution:
Open Registry Editor (Run > regedit)
Navigate to HKEY_CURRENT_USER\System\GameConfigStore
Set the value of DWORD "GameDVR_Enabled" to 0
Go to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
Create key "GameDVR".
Create DWORD 32bit called "AllowGameDVR" and set to 0
Restart your computer.
Cause:
By default Windows 10 has the DVR function enabled.
SageLike Post ID: SL0015
Applies to:
Windows 10 - Both endpoint devices and VDI's
References:
https://support.steampowered.com/kb_article.php?ref=6239-DZCB-8600#appreg
To fix the Win + G Popup when launching Citrix apps/desktops from Windows 10 Machines with the latest patches.
Symptom:
When launching published apps or desktops from a Windows 10 OS a green popup windows briefly appears prompting to press Win + G for the game bar or for the search bar.
Resolution:
Open Registry Editor (Run > regedit)
Navigate to HKEY_CURRENT_USER\System\GameConfigStore
Set the value of DWORD "GameDVR_Enabled" to 0
Go to HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\
Create key "GameDVR".
Create DWORD 32bit called "AllowGameDVR" and set to 0
Restart your computer.
Cause:
By default Windows 10 has the DVR function enabled.
SageLike Post ID: SL0015
Applies to:
Windows 10 - Both endpoint devices and VDI's
References:
https://support.steampowered.com/kb_article.php?ref=6239-DZCB-8600#appreg
March 15, 2017
Citrix PVS - After Reverse Imaging Unable To Change Computer Name
Purpose:
Show the steps taken after reverse imaging a W2K8R2 Citrix PVS Target Device to fix the inability to rename the server and add back to the AD Domain
Symptom:
After the reverse imaging process is done, the machine removed from the domain, rebooted, name changed and rebooted again the name of the server doesn't change and the ability to add the machine back to the domain is grayed out.
Resolution:
In the registry navigate to the below location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName
There are 2 subkeys called ActiveComputerName and ComputerName and within each of there are valumes called ComputerName. Verify that both have the new computer name.
On my issue the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerName\ComputerName value had the old computer name. I renamed the key and then restarted the computer.
Cause:
Computer account not updating correctly
SageLike Post ID: SL0014
Applies to:
Citrix Provisioned Target Devices
Windows Server 2008 R2
Windows 7
Maybe others but these are the OS's that I've had issues with.
References:
http://discussions.citrix.com/topic/283685-after-reverse-image-unable-to-change-computer-name/
Show the steps taken after reverse imaging a W2K8R2 Citrix PVS Target Device to fix the inability to rename the server and add back to the AD Domain
Symptom:
After the reverse imaging process is done, the machine removed from the domain, rebooted, name changed and rebooted again the name of the server doesn't change and the ability to add the machine back to the domain is grayed out.
Resolution:
In the registry navigate to the below location:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName
There are 2 subkeys called ActiveComputerName and ComputerName and within each of there are valumes called ComputerName. Verify that both have the new computer name.
On my issue the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ComputerName\ActiveComputerName\ComputerName value had the old computer name. I renamed the key and then restarted the computer.
Cause:
Computer account not updating correctly
SageLike Post ID: SL0014
Applies to:
Citrix Provisioned Target Devices
Windows Server 2008 R2
Windows 7
Maybe others but these are the OS's that I've had issues with.
References:
http://discussions.citrix.com/topic/283685-after-reverse-image-unable-to-change-computer-name/
March 1, 2017
XenDesktop The Registration Was Refused Due To No Reason Provided
Purpose:
This post addresses a XenDesktop VDA registration issue with an obscure registration error.
Symptoms:
XenDesktop VDA's will not register to XD Controller and receives the below errors in the event log
The VDA registration process results in a error, Event ID 1023, with a message
"The Citrix Desktop Service was refused a connection to the delivery controller 'xdcontroller.domain.local' (IP Address 'xxx.xxx.xxx.xxx').
The Server or Desktop VDA may have been running for quite some time before this error appears and it seems to be linked to an HDX policy update
Resolution #1:
Ultimately this turned out to be a policy update issue. These machines were migrated from a XD 5.6 environment to a 7.x environment. After the HDX policy update the VDA would not accept the policy update and would fail to register to the controller. The ultimate fix was to determine where all the group policies are stored on the machine when it does do the application of the group policy. I found these directories: C:\ProgramData\Citrix\GroupPolicy & C:\ProgramData\CitrixCseCache:
First stop the Citrix Group Policy Engine (citrixcseengine). Then delete the contents of these directories (you’ll need administrative rights to do this), run a gpupdate /force and then perform a reboot.
After the reboot the registration of the server and the application of the HDX policies applied correctly
Resolution #2
Use the Citrix VDA Removal Utility to completely remove the VDA then reinstall the VDA. This will wipe out all of the settings and configs on the server and reapply everything
https://support.citrix.com/article/CTX209255
Cause:
It seems like the updated HDX policies were conflicting with the ones cached on the local machine. Clearing out the cache and forcing an update addressed the issue.
SageLike Post ID: SL0013
Applies To:
XenDesktop VDAs that were migrated from XenApp 6.5 or XenDesktop 5.6 environments to XenDesktop 7.x
Windows 7
Windows 2008 R2
XenApp
XenDesktop
This post addresses a XenDesktop VDA registration issue with an obscure registration error.
Symptoms:
XenDesktop VDA's will not register to XD Controller and receives the below errors in the event log
The VDA registration process results in a error, Event ID 1023, with a message
"The Citrix Desktop Service was refused a connection to the delivery controller 'xdcontroller.domain.local' (IP Address 'xxx.xxx.xxx.xxx').
The registration was refused due to 'No Reason Provided'."
The Server or Desktop VDA may have been running for quite some time before this error appears and it seems to be linked to an HDX policy update
Resolution #1:
Ultimately this turned out to be a policy update issue. These machines were migrated from a XD 5.6 environment to a 7.x environment. After the HDX policy update the VDA would not accept the policy update and would fail to register to the controller. The ultimate fix was to determine where all the group policies are stored on the machine when it does do the application of the group policy. I found these directories: C:\ProgramData\Citrix\GroupPolicy & C:\ProgramData\CitrixCseCache:
First stop the Citrix Group Policy Engine (citrixcseengine). Then delete the contents of these directories (you’ll need administrative rights to do this), run a gpupdate /force and then perform a reboot.
After the reboot the registration of the server and the application of the HDX policies applied correctly
Resolution #2
Use the Citrix VDA Removal Utility to completely remove the VDA then reinstall the VDA. This will wipe out all of the settings and configs on the server and reapply everything
https://support.citrix.com/article/CTX209255
Cause:
It seems like the updated HDX policies were conflicting with the ones cached on the local machine. Clearing out the cache and forcing an update addressed the issue.
SageLike Post ID: SL0013
Applies To:
XenDesktop VDAs that were migrated from XenApp 6.5 or XenDesktop 5.6 environments to XenDesktop 7.x
Windows 7
Windows 2008 R2
XenApp
XenDesktop
Subscribe to:
Posts (Atom)