Connecting to VMware View 5.1.2 desktop via PCoIP displays a black screen when in full screen

Problem

You’ve just added a new existing virtual machine into a VMware View pool and attempt to connect to it via the VMware View client but the following black screen:

What you notice is that if you restore the size of the VMware View client to a window instead of full screen, you are able to see the virtual desktop’s login screen properly.  Everything else works as expected when working in side this resized window:

You’ve confirmed that the resolution of the monitor you’re using which is 1920 x 1080:

… is either smaller or the same as the VMware View pool settings:

Note that the pool settings is configured with:

Max number of monitors: 2

Max resolution of any one monitor: 1920 x 1200

The settings for the virtual desktop indicates that VMware View has set the configuration to:

Number of displays: 2

Total video memory: 35.19

You notice that if you try to shutdown the virtual machine, change the video memory to 40MB, View would quickly change it back to 35.19MB.

Solution

What’s important to note is that it is expected behavior for View to change the video memory back to 35.19MB as that is the predefined settings for the monitoring configuration set in the pool and the only way to increase the memory for the desktops is to actually change the pool settings as such:

Max number of monitors: 4

Max resolution of any one monitor: 2560 x 1600

Once the pool settings are in, VMware View would reconfigure all of the desktops regardless of whether they’re powered on or off to the following settings:

Number of displays: 4

Total video memory: 125

What solved my issue was to increase the resolution in the pool settings to be higher than the resolution of monitor, wait till View has completed the changes to the video card, restart the virtual machine once so that the new video card settings are in effect, then shutdown the virtual machine and then power it back on.  Note that I’ve tried restarting the virtual machine multiple times but still received the black screen which I suspect is related to the description in the following KB:

Configuring PCoIP for use with View Manager (1018158)http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&docTypeID=DT_KB_1_1&externalId=1018158

I didn’t get to try restarting the virtual machine via the vSphere client but I believe it probably would have worked if I did.

Removing and adding a renamed desktop into a Citrix XenDesktop 5.6 Existing pool throws the error: “The computer domain\computername could not be imported because User domain\computername could not be found.”

Problem

You have a desktop in a Citrix XenDesktop 5.6 Existing pool that you need to rename so you proceed with the following:

1. Remove it from the existing desktop group
2. Delete it from the desktop catalog
3. Clone the virtual machine in vCenter to a new name so that the flat files corresponds to the virtual machine name
4. Log into the new virtual desktop and rename the Windows name
5. Restart the desktop
6. Right click on the same Existing catalog and select Add Machines
7. Select the newly cloned virtual machine

What you notice is that as you get to the prompt where you select a Active Directory computer account and select the new renamed computer account, you receive the following error:

The computer domain\computername could not be imported because User domain\computername could not be found.

Clicking the OK button displays another window with the error:

Sequence contains no elements

Solution

I’m not exactly sure why but this has happened to me twice over the past month and the resolution for both incidents was to restart the DDCs.  Once the DDCs are restarted, I am then able to add the machines with the new account.

Citrix XenApp and XenDesktop Pass-Through Authentication works with website authentication but not application or desktop authentication

To follow up with my previous post:

Connecting to Citrix XenDesktop 5.6 virtual desktops through a Web Interface configured with pass-through authentication fails after flashing a black screen
http://terenceluk.blogspot.com/2013/11/connecting-to-citrix-xendesktop-56.html

I finally found some time over the weekend to sit down and perform some uninterrupted troubleshooting to determine the root cause of why the environment’s pass-through authentication worked for authenticating the user through the Web Interface portal but does not work when launching an application where it would display the following prompt:

… or while launching a XenDesktop VDI (with the help of the registry key to disable enforce auto logon):

What ended up being the issue after combing through the configuration as I referenced an older blog post I wrote:

Lessons learned with Citrix Web Interface 4.6 Pass-Through Authentication
http://terenceluk.blogspot.com/2012/01/lessons-learned-with-citrix-web.html

… was that the Active Directory GPO with the Citrix pass-through authentication only had the Computer Configuration portion configured:

… but not the User Configuration.  Once I got the User Configuration portion configured, pass-through authentication began functioning as it should:

Hope this helps anyone out there who may come across the same symptoms in their environment.

Connecting to Citrix XenDesktop 5.6 virtual desktops through a Web Interface configured with pass-through authentication fails after flashing a black screen

Problem

Environment:

• 2 x Citrix Web Interface at version 5.4.2.59
• 2 x Citrix XenDesktop 5.6 DDCs at version 5.6 with Hotfix 7
• VDA Agent on VDIs at version 5.6.300
• Pass-through authentication is configured for website
• Client used to connect to Web Interface portal is joined to the domain

Symptoms:

• User is able to successfully log into the pass-through authentication page from the fat / thick client via URL directing to Web Interface website (no CAG)
• Clicking on the XenDesktop Dedicated Desktop icon briefly shows the Citrix Receiver launch with the progress bar at about ¼ then disappears
• The Desktop Viewer window appears to launch displaying a black screen (in some cases he may see an out of place username and password prompt displayed by the Windows 7 VDI)
• Within seconds, the black screen disappears and he is back to his fat / thick client’s desktop with the web page
• Continuing to click on the dedicated desktop or pooled desktop icons exhibit the same behavior
• Testing with a single or dual monitor setup exhibit the same symptoms
• Using his same credentials on the t610 in the same VLAN which is also configured for pass-through authentication does not exhibit the same behavior

Troubleshooting:

While reviewing the event logs on the virtual desktop that the user failed to log into, the following event ID 1620 warning followed by the event ID 1030 informational events were logged during the unsuccessful login attempts:

The details to those events are:

Event ID Warning: 1260

Log Name: Application

Source: Citrix ICA Service

Event ID: 1260

Level: Warning

ICA connection is cancelled because auto-logon is enforced and auto-logon failed. For more information, see http://support.citrix.com/proddocs/topic/online-plugin-121-windows/ica-sson-enable.html.

Event ID Warning: 1030

Log Name: Application

Source: Citrix Desktop Service 

Event ID: 1030

Level: Information

The Citrix Desktop Service detected that a user session has ended. Session 0:635200501869038107 for user 'domain\jsmith' has ended.

Clicking on the link provided in the warning (http://support.citrix.com/proddocs/topic/online-plugin-121-windows/ica-sson-enable.html) isn’t much help as it brings you to a:

404 page Not Found: The Requested Page Cannot Be Displayed

… that Citrix probably took off:

Troubleshooting Steps Tried:

Searching for the string provided 5 or 6 results with various suggestions such as:

1. Turning on Kerberos in the Citrix GPO ADM for the fat / thin clients <-- Did not work

2. Modify the Web Interface pass-through authentication page’s domain settings to use FQDN instead of NetBIOS <-- Did not work

3. Edit either the local policy or via GPO for the VDI’s: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment <-- I can’t see why we would need to change this as the issue is intermittent

4. Use the Get-BrokerSite cmdlet on a DDC to ensure that TrustRequestSentToTheXmlServicePort is set to True:

Solution

While I have yet to determine the root cause, the workaround solution I put in for this problem to buy me some more troubleshooting time was to add the following following registry key onto the VDI:

HKLM\SOFTWARE\Policies\Citrix

DWORD: EnforceAutoLogon

Value: 0

As per the following forum post, a Citrix engineer wrote the following:

http://forums.citrix.com/thread.jspa?threadID=284282

First off, in XD5, the default behavior when pass-through credentials aren't properly provided has changed. In XD4, you would get prompted to authenticate at the VDA Winlogon screen if SSON failed. In XD5, by default anyways, the VDA will drop the connection if credentials aren't properly received. To workaround this behavior, create a new DWORD value called 'EnforceAutoLogon' in HKLM\Software\Policies\Citrix, and set it to 0. This will change the VDA behavior to dump you back out to the Winlogon screen instead of just closing the connection.

So basically what’s happening here is that pass-through authentication isn’t working on the fat / thick client downstairs and the default behavior for XenDesktop 5 is to drop connections if the credentials aren’t passed over.  With the registry shown above set on the VDI, XenDesktop will not drop the connection but rather display the following:

Note that if you can’t update the catalog of a pool for whatever reason or perhaps unable to log onto dedicated VDIs because users are logged on, you can use a GPO assigned to the computer object to add this registry key in as such:

Hive: HKEY_LOCAL_MACHINE

Key Path: SOFTWARE\Policies\Citrix

Value name: EnforceAutoLogon

Value type: REG_DWORD

Value data: 0

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Not exactly the best solution but users who wonder why they need to retype their credentials is much better than users who are unable to connect.

Slow / jerky / lag scroll performance with Excel 2013 in Citrix XenDesktop 5.6

Problem

You notice that your virtual desktops in your Citrix XenDesktop 5.6 infrastructure exhibits extremely slow, jerky or lag when scrolling Excel 2013 spreadsheets.  You’ve tried installing the latest 5.6.300 VDA agent as well as the 7.0 and 7.1 VDA agents but it does not improve the performance.  Scrolling in a spreadsheet with rolls extending past the visible screen clearly lags in the sense that you can scroll up and down 3 or 4 times yet the spreadsheet doesn’t scroll until a few seconds later where it seemingly decides to take the last scroll input (i.e: you scroll up 5 times and down 6 times but only the last scroll downwards is captured):

Solution

I’m not sure if it’s the string I used to search for this issue but the returned results on Google did not point me to the following KB that had a solution to my issue:

Office 2013 Video Performance Issues with XenDesktop VDA
http://support.citrix.com/article/CTX139236

To fix this scrolling issue, simply click on the File tab in Excel:

Selection Options:

Click on the Advanced button:

Scroll down to the Display area and enable (check the checkbox) of Disable hardware graphics acceleration:

Alternatively, you can either create a GPO and apply it to the user account or create a GPO and apply it to the VDI computer account with Loopback set to merge.  The following is where the registry is located:

HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Graphics

**Note the DisableHardwareAcceleration DWORD

The following is what a GPO updating this registry would look like:

Key Path: Software\Microsoft\Office\15.0\Common\Graphics
Value Name: DisableHardwareAcceleration
Value type: REG_DWORD
Value: 1

Setting the “Microsoft Exchange server” autodiscover configuration in Outlook to ClientAccessArray object in Exchange Server 2010

Problem

You’ve created your ClientAccessArray object in your Exchange 2010 organization with the cmdlets:

New-ClientAccessArray
http://technet.microsoft.com/en-us/library/dd351149(v=exchg.141).aspx

Set-ClientAccessArray
http://technet.microsoft.com/en-us/library/dd351174(v=exchg.141).aspx

… and confirmed that the object is created properly with:

Get-ClientAccessArray

… but noticed that the autodiscover configuration for the Microsoft Exchange server field in Outlook is still pointing to one of the CAS servers you have configured in a Windows NLB cluster:

Solution

The reason why you may see this behavior is because the RpcClientAccessServer setting for the mailbox database the user is connecting to hasn’t been changed to use the ClientAccessArray object.  To determine this, use the following cmdlet:

Get-MailboxDatabase "Bermuda Mailbox Database" | FL Name,RpcClientAccessServer

To change this, use the following cmdlet:

Set-MailboxDatabase “Bermuda Mailbox Database” -RpcClientAccessServer casarray.domain.com

Once this property of the mailbox database has been set properly, Outlook clients configured with autodiscover should now use the ClientAccessArray object:

Note that existing clients already configured prior to this change will not be updated.

Lync 2013 client’s conversations list displays an exclamation mark with the message: “There are Exchange connectivity issues. Your conversation history cannot be retrieved.”

Problem

You’ve received complains from users that their Lync 2013 client’s conversations list displays an exclamation mark with the message:

There are Exchange connectivity issues. Your conversation history cannot be retrieved.

If the user navigates to File –> View Conversation History from the Lync 2013 client, Outlook is automatically launched and the conversation history (with content) is displayed.

Solution

A quick search on the internet shows a Microsoft rep suggesting the following:

This issue might be related to any of the situations below.

1. The computer time is different from the local time.
2. The Outlook credential is wrong.
3. The primary account in Outlook is not the same with the account that you sign in to Lync.
4. The Exchange Autodiscover is not working correctly.

What ended up being the issue at the environment I came across this was because they did not have an autodiscover.domain.com A record in their internal DNS and as soon as I created the record, the error went away.