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.

Active Directory domain authentication missing in a new VMware vCenter 5.5 installation

I’ve been asked several times over the past month about this so I thought it would be a good idea to write a quick blog post to point my colleagues to.

Problem

You’ve just completed the installation of vCenter 5.5 onto a Windows Server 2008 R2 server and noticed that you are unable to log on with your Windows local administrator account or a domain admin account.  The only way you’re able to log in is with the SSO’s vsphere.local domain’s administrator account:

vsphere.local\administrator

… or …

administrator@vsphere.local

While attempting to add permissions to vCenter:

You notice that you can select either the local Windows’ server’s accounts or the SSO domain but the Active Directory domain which this Windows server is joined to does not show up:

The results are also the same when you use the vSphere Web Client:

Solution

It’s important to understand that the SSO component in vCenter 5.5. has been rewritten with RSA database completely removed (remember how clumsey the install for 5.1 was?)  Another change is that vCenter by default does not automatically include Active Directory authentication for vCenter as SSO continues to mature so in order to authenticate with AD credentials, you’ll need to configure it by using the vSphere Web Client.  Begin by launching a browser and go to the following URL:

https://<vCenter Server IP or Name>:9443/vsphere-client

Log in and navigate to Single Sign-On –> Configuration –> Identity Sources and click on the + sign:

The Add identity source window is where you will configure authentication against other directories:

The one we’re interested in is the Active Directory (Integrated Windows Authentication) so proceed by selecting that radio button and fill out the appropriate fields:

You should now see the domain you’ve configured in the Identity Sources tab and should now be able to grant permissions to users and groups in that domain for authenticating:

I personally find this to be a great change as we’re now able to add different types of domain for authentication whether through Windows integrated or the other options such as:

• Active Directory as a LDAP Server
• Open LDAP

This evidently makes it easier for a hosting provider to configure a shared vCenter to authenticate against multiple directories.

Connectivity issues between Citrix XenDesktop DDC and virtual desktops causing intermittent connectivity issues and inability to connect

Problem

You notice that you are having connectivity issues between various virtual desktops where it would be in Ready status for a few minutes then switches to Unregistered.  Logging onto your Citrix XenDesktop virtual desktop shows the following event IDs logged:

• Warning Event ID 1014
• Warning Event ID 1002
• Warning Event ID 1017
• Warning Event ID 1022
• Warning Event ID 1012
• Warning Event ID 1048
• Information Event ID 0
• Warning Event ID 1001

Warning Event ID 1014

The Citrix Desktop Service lost contact with the Citrix Desktop Delivery Controller Service on server 'svrctxddc02.contoso.internal'.

The service will now attempt to register again.

Error details:

Exception 'There was no endpoint listening at http://10.2.1.21/Citrix/CdsController/IRegistrar that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.' of type 'System.ServiceModel.EndpointNotFoundException'

Warning Event ID 1002

The Citrix Desktop Service cannot connect to the delivery controller 'http://svrctxddc02.contoso.internal:80/Citrix/CdsController/IRegistrar' (IP Address '10.2.1.21')
Check that the system clock is in sync between this machine and the delivery controller. If this does not resolve the problem, please refer to Citrix Knowledge Base article CTX117248 for further information.
Error Details:
Exception 'Error occurred when attempting to connect to endpoint at address http://svrctxddc02.contoso.internal:80/Citrix/CdsController/IRegistrar, binding WsHttpBindingIRegistrarEndpoint and contract Citrix.Cds.Protocol.Controller.IRegistrar: System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at http://10.2.1.21/Citrix/CdsController/IRegistrar that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details. ---> System.Net.WebException: The remote server returned an error: (404) Not Found.
   at System.Net.HttpWebRequest.GetResponse()
   at System.ServiceModel.Channels.HttpChannelFactory.HttpRequestChannel.HttpChannelRequest.WaitForReply(TimeSpan timeout)
   --- End of inner exception stack trace ---
Server stack trace:
   at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)
   at System.ServiceModel.Security.SspiNegotiationTokenProvider.OnOpen(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
   at System.ServiceModel.Security.SymmetricSecurityProtocol.OnOpen(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
   at System.ServiceModel.Channels.SecurityChannelFactory`1.ClientSecurityChannel`1.OnOpen(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
   at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout)
   at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout)
   at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)
   at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.OnOpen(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
   at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
Exception rethrown at [0]:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at System.ServiceModel.ICommunicationObject.Open()
   at Citrix.Cds.BrokerAgent.ControllerConnectionFactory.AttemptConnection[T](EndpointReference endpoint, Boolean throwOnError, Boolean allowNtlmAuthentication, String connectUsingIpThisIpAddress, Boolean cacheFactory)' of type 'Citrix.Cds.BrokerAgent.ConnectionFailedException'..

Warning Event ID 1017

The Citrix Desktop Service failed to register with any delivery controller.
The service will retry registering with controllers in approximately 17 seconds.
Please ensure that at least one delivery controller is available for Virtual Desktop Agents to register with. Refer to Citrix Knowledge Base article CTX117248 for further information

Warning Event ID 1022

The Citrix Desktop Service failed to register with any controllers in the last 2 minutes.

The service will now try to register with controllers at a reduced rate of every 2 minutes.

Warning Event ID 1012

The Citrix Desktop Service successfully registered with delivery

controller svrctxddc01.contoso.internal (IP Address 10.2.1.20).

The endpoint address of the controller is http://svrctxddc01.contoso.internal:80/Citrix/CdsController/IRegistrar.

Warning Event ID 1048

The Citrix Desktop Service is re-registering with the DDC: 'NotificationManager:NotificationServiceThread: WCF failure or rejection by broker (DDC: svrctxddc01.contoso.internal)'

From here, you get another informational Event ID 0:

The description for Event ID 0 from source Self-service Plug-in cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

Self-service Plug-in started (user=Contoso\hleaback).

the message resource is present but the message is not found in the string/message table

Then the event ID 1001 warning:

The Citrix Desktop Service failed to obtain a list of delivery controllers with which to register.
Please ensure that the Active Directory configuration for the farm is correct, that this machine is in the appropriate Active Directory domain and that one or more delivery controllers have been fully initialized.
Refer to Citrix Knowledge Base article CTX117248 for further information.
Error details:
Exception 'The communication object, System.ServiceModel.Channels.ServiceChannel, cannot be used for communication because it is in the Faulted state.' of type 'System.ServiceModel.CommunicationObjectFaultedException'

The logs then repeat again.

On the actual Citrix XenDesktop DDC, you see the following event IDs logged:

• Warning Event ID 1060
• Warning Event ID 1039
• Information Event ID 1066

Warning Event ID 1060

The Citrix Broker Service failed to apply settings on the virtual machine 'VDI-HOLLY.contoso.internal'.

Check that the virtual machine can be contacted from the controller and that any firewall on the virtual machine allows connections from the controller. See Citrix Knowledge Base article CTX126992.

Error details:

Exception 'The request channel timed out while waiting for a reply after 00:00:59.9919992. Increase the timeout value passed to the call to Request or increase the SendTimeout value on the Binding. The time allotted to this operation may have been a portion of a longer timeout.' of type 'System.TimeoutException'.

Warning Event ID 1039

The Citrix Broker Service failed to contact virtual machine 'VDI-MARINA.contoso.internal' (IP address 10.2.1.51).
Check that the virtual machine can be contacted from the controller and that any firewall on the virtual machine allows connections from the controller. See Citrix Knowledge Base article CTX126992.
Error details:
Exception 'Client is unable to finish the security negotiation within the configured timeout (00:00:04.9989999).  The current negotiation leg is 1 (00:00:04.9989999).  ' of type 'System.TimeoutException'.

Information Event ID 1066

The Citrix Broker Service successfully determined the base settings needed for the Virtual Desktop Agent of machine 'VDI-HOLLY.contoso.internal'.

Solution

While there can be multiple reasons as to why these errors would be thrown, I’ve found that these generally point to communications issues between the Citrix XenDesktop DDC and the actual VDA agent (the virtual desktop).  I’ve seen time drift between the DDC and the VDA agent causing such an issue and lately, a duplicate IP address for the Citrix XenDesktop DDC on the network where the DDC is not completely offline but the VDA agent is able to sometimes successfully send traffic to the DDC and sometimes unable to.  If you to encounter these warnings and notice your VDI is listed as unregistered in the Desktop Studio, check that there are no issues between the subnets of your VDI and DDC, no port issues and certainly no IP conflicts.