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.

Finding a virtual machine in VMware vSphere by the MAC address

I recently had to troubleshoot an issue within a Citrix XenDesktop environment hosted on VMware vSphere 5.1 where one of the DDC (Desktop Delivery Controllers) appeared to have an IP conflict with another VM:

So the good news is that I have the MAC address of the conflicting device: 00-50-56-91-33-B4 but the bad news is that when I look this MAC address on a MAC finder site such as:

http://www.coffer.com/mac_find/

… I get the following result:

Great, it’s a VMware device and I have over hundreds of VMs hosted.

As there isn’t a way to list VMs or search via MAC addresses in the vSphere Client, I had to resort to using PowerShell.  I’m not much of an expert with PowerShell cmdlets since I don’t really use them on a daily basis so I dug up one of my old posts:

Bulk changing port group settings for virtual machines in vSphere 5 with vSphere PowerCLI
http://terenceluk.blogspot.com/2012/02/bulk-changing-port-group-settings-for.html

… which gave me the cmdlet:

Get-VM -Location “XenDesktop VDI Master Images” | Get-NetworkAdapter

The cmdlet gave me a starting point to

Get-VM | Get-NetworkAdapter | Where {$_.MacAddress -eq “00:50:56:91:33:b4”}

Unfortunately as shown in the screenshot above, this cmdlet gives me all of the network details of the offending VM but not the name of it.  The way around this is to use the Format-List (or FL for the short form) cmdlet to list all of the properties for the VM including the name as shown here:

Note that the name of the VM is the value for Parent.

How to determine what version of Citrix XenDesktop is installed in an environment

I’ve noticed recently that I’ve been asked about how to determine what version of Citrix XenDesktop is installed in an environment so I thought I’d quickly write a post to demonstrate this.  First off, I don’t think there is a way to determine the version in Desktop Studio as I’ve been unable to find this information in the past when I browsed through the GUI so the way to do it is to use the PowerShell cmdlet:

Get-BrokerController

**Note the ControllerVersion field listing the DDCs as version 5.6.4.11.

Taking this version number and searching it in Google with the word Citrix appended to it should return the hotfix update Citrix article and as shown in the following screenshot, this version is Update 4:

Alternatively, if you’re interested in reviewing what version a hotfix update is, you can navigate down towards the bottom of the webpage and locate the Component Versions heading to determine what version the hotfix is:

**Note that the 2 screenshots above is Update 7.

Citrix XenDesktop Desktop Studio Dashboard displays the message: “Upgrades for some services are available.” and “Services can be upgrade on the following controller:”

I’ve been asked a few times in the past about why the following message:

Upgrades for some services are available.

Services can be upgrade on the following controller:

<controllerFQDN>

Learn more about this upgrade

… is sometimes displayed in the Dashboard of Citrix Desktop Studio when upgrading an administrator has completed upgrading, say, all of the DDCs in a XenDesktop environment:

Some administrators have gone as far as telling me they’ve ran the PowerShell cmdlet:

Get-BrokerController

… and can confirm that the ControllerVersion is listed as being the same:

While this may seem obvious, of all the times I’ve been asked to look at this, the reason as to why this message is displayed is because not all of the hotfix update packages have been ran on the listed DDC:

If you were to only run the first 3 packages and not the last 4, the version number may indicate the DDC has been upgraded when in fact it is still missing packages for the hotfix update.