Signing into Lync 2013 client presents the warning message: “Lync cannot verify that the server is trusted for your sign-in address. Connect anyway?”

I’ve been meaning to blog about an issue I noticed in environments with disparate namespaces (internal domain name is different than external) where no matter how I configured the DNS for the internal or public forward lookup zones, I could not get around the following warning message presented to users signing into Lync 2013 clients:

The connection to the server is encrypted.

View Certificates

Lync cannot verify that the server is trusted for your sign-in address. Connect anyway?

As noted in Jeff Schertz’s post:

http://blog.schertz.name/2012/12/lync-2013-client-autodiscover/

… the new Lync 2013 client now attempts to lookup the 2 new Lync Discover records introduced in Lync Server cumulative update 4 for supporting mobility clients:

• lyncdiscoverinternal.domain.com
• lyncdiscover.domain.com
• _sipinternaltls._tcp.domain.com
• _sip._tls.domain.com
• sipinternal.domain.com
• sip.domain.com
• sipexternal.domain.com

Prior to the introduction of the 2 new records when the first record that the Lync 2010 looks up was _sipinternaltls._tcp.domain.com, I was able to get around the mismatch between the sign-in address which uses the public domain that does not match the FQDN of the internal Lync front end server as described in my previous post:

Quick note about Lync Server 2010 automatic sign-in for environments with different external and internal domain names
http://terenceluk.blogspot.com/2011/04/quick-note-about-lync-server-2010.html

However, making the same change to the lyncdiscoverinternal CNAME record:

… so that it points to an A record that uses the public domain name:

… did not work.  So just as Jeff demonstrated on his blog, I went on to try doing traces with Wireshark as well.

Confirming Ordering of Lookup Records

First, I tested signing in with my Lync 2010 client and as expected, the order DNS records are as follows:

• _sipinternaltls._tcp.domain.com
• _sip._tls.domain.com
• sipinternal.domain.com
• sip.domain.com
• sipexternal.domain.com

Signing with the Lync 2013 client confirmed the 2 new records that are now ahead of the old ones:

• lyncdiscoverinternal.domain.com
• lyncdiscover.domain.com
• _sipinternaltls._tcp.domain.com
• _sip._tls.domain.com
• sipinternal.domain.com
• sip.domain.com
• sipexternal.domain.com

Testing in Production Environment

With the ordering of the records confirmed, I went ahead and tried signing into the Lync 2013 client and review the Wireshark packet captures which appeared to do the following:

The client queries the record lyncdiscoverinternal.domain.com:

Although I have a lyncdiscoverinternal CNAME set up the in public domain forward lookup zone, it looks like the Lync 2013 client still continues to query for the next lyncdiscover.domain.com record regardless of whether it receives a reply or not:

Another entry for the lyncdiscoverinternal query is shown in the packet capture:

Then as expected, the DNS server replies with a CNAME record for the initial query (0xeeb3) of lyncdiscoverinternal and as shown in the response, the CNAME record that the DNS responds with is the internal Lync server name with the public domain FQDN mapped to the internal IP address of the Lync front end server address:

Notice that the next entry is the DNS server responding with No such name for the lyncdiscover record query (0x3c75) which is expected because that record does not exist in the DNS server:

The next entry continues the DNS server to the Lync 2013 client response for the lyncdiscoverinternal query which continues to list the internal Lync server name with the public domain FQDN mapped to the internal IP address of the Lync front end server:

The next entry is what confuses me because the previous entries appear to suggest that the Lync 2013 client queries for lyncdiscoverinternal.domain.com, receives the CNAME record <name of Lync front end server>.publicDomain.com with the A record address pointing to the internal IP address but rather than attempting to sign into the server with the returned IP address, it continues to query the DNS server for the Lync server internal FQDN record:

<name of Lync front end server>.internalDomain.internal

I originally thought the Lync 2013 client was performing a reverse lookup of the previous CNAME record <name of Lync front end server>.publicDomain.com but the next entry shows that the client is clearly performing a query (0x5f56) for the internal FQDN of the Lync server:

From here, the client proceeds to sign into the IP address of the Lync server’s internal FQDN which brings us to the warning message shown at the beginning of this post.

Unfortunately, I’ve tried modifying the DNS records in different ways (i.e. using A records instead of CNAME records for lyncdiscoverinternal) but would continue to run into the same issue.  The only 2 ways I could think of was either to completely remove the lyncdiscoverinternal record so that the Lync client falls back to the _sipinternaltls._tcp.domain.com record but that means breaking the mobility clients that sign in while on the internal network.  The only option available that I could think of was to use the TrustModelData registry key to explicitly force the client to trust public domain.  More information about this registry key can be found in one of my previous posts here:

Location of the “TrustModelData: registry key for the Lync 2013 Client
http://terenceluk.blogspot.com/2013/02/location-of-trustmodeldata-registry-key.html

Note that I did all the tracing shown above probably more than 2 months ago so I may have forgotten a few items I noticed while writing this post now so please excuse any mistakes I may have made during the analysis.

Configuring vCenter role permissions for VMware vSphere 5.1 and VMware Horizon View 5.2 (View Manager and View Composer)

As some administrators may have noticed, VMware has made quite a few changes to vSphere 5.1 and I was a bit thrown off by the change to the layout of permissions while I configured the role for the VMware View service account because it doesn’t look like the VMware Horizon View 5.2 documentation was written for vSphere 5.1.  After browsing around the permissions available in vCenter 5.1 the change I noticed was that there is no longer the section Virtual Machine –> State as stated in the documentation:

http://pubs.vmware.com/view-52/index.jsp?topic=%2Fcom.vmware.view.installation.doc%2FGUID-467F552F-3034-4917-A985-B5E5FEC5C68F.html

These permissions in vCenter 5.1 have since been moved to Virtual Machine –> Snapshot:

Here is a screenshot of the old vCenter 5.0 Virtual Machine –> State option:

Seeing how I got a bit confused with this, I’m sure my colleagues are going to ask me about this so I thought I’d write this blog post so I can refer them to it.  First off, it’s important to note that there are 2 sets of permissions in the VMware Horizon View 5.2 documentation you need to be aware about that is listed in the following URL:

Configuring User Accounts for vCenter Server and View Composer
http://pubs.vmware.com/view-52/index.jsp?topic=%2Fcom.vmware.view.installation.doc%2FGUID-997107E5-F66D-494C-B2BA-A74977C7804C.html

The first one is:

View Manager Privileges Required for the vCenter Server User
http://pubs.vmware.com/view-52/index.jsp?topic=%2Fcom.vmware.view.installation.doc%2FGUID-A878F876-B359-42FC-9124-A1E34BFB3319.html

These permissions are only enough for you to configure View Manager to deploy virtual desktops that do not rely on the View Composer.  If you intend on deploying virtual desktops such as linked clones which requires View Composer then you’ll need to configure the additional permissions listed in the second URL:

View Composer Privileges Required for the vCenter Server User

http://pubs.vmware.com/view-52/index.jsp?topic=%2Fcom.vmware.view.installation.doc%2FGUID-467F552F-3034-4917-A985-B5E5FEC5C68F.html

With this clarified, the following are the permissions required to configure the role in VMware vCenter 5.1 for VMware Horizon View 5.2:

Datastore

• Allocate space
• Browse datastore
• Low level file operations

Folder

• Create folder
• Delete folder

Global

• Disable methods
• Enable methods
• System tag

Network

• Assign network
• Configure
• Move network
• Remove

Resource

• Assign virtual machine to resource pool
• Migrate powered off virtual machine

Virtual machine –> Configuration

• All items

Virtual machine –> Interaction

• Power Off
• Power On
• Reset
• Suspend

Virtual machine –> Provisioning

• Allow disk access
• Clone virtual machine
• Customize
• Deploy template
• Read customization specifications

Virtual machine –> Snapshot management

• Create snapshot
• Remove Snapshot
• Rename Snapshot
• Revert to snapshot

Hope this helps anyone out there looking for updated permission settings for configuring the role for the VMware Horizon View 5.2’s vCenter 5.1 service account.

Problems launching Citrix XenApp 6.5 applications through CAG VPX 50 with the error: “Unable to launch your application. Contact your help desk with the following information: Cannot connect to the Citrix XenApp server. There is no Citrix XenApp server configured on the specified address.”

Problem

Ran into an issue the other day where I would have no problems logging into a Citrix XenApp 6.5 environment published with a Citrix Access Gateway VPX 50 (NS10.0: Build 73.5.nc) but noticed that whenever I tried launching an application, the status bar would get stuck at the following point:

After a few seconds, the following message is displayed:

Unable to launch your application. Contact your help desk with the following information:
Cannot connect to the Citrix XenApp server. There is no Citrix XenApp server configured on the specified address.

This error is consistent with published XenApp 6.5 applications and XenDesktop 5.6 VDIs.  No errors were logged on the XenApp servers or the Web Interface servers.

Solution

What ended up being the problem was that the Secure Access settings for the XenApp Web Site configured on the web interface server was configured with Direct for the Access Method:

Once this was changed to Gateway direct, applications began launching properly:

Permissions required for Citrix XenDesktop 5.6 and VMware vSphere 5.1

As some administrators may have noticed, VMware has made quite a few changes to vSphere 5.1 and I was thrown off by the change to the layout of permissions while I configured the role for the XenDesktop service account because the only documentation available from Citrix that I could find was written for XenDesktop 5 and VMware vSphere 5.  After browsing around the permissions available in vCenter 5.1 the change I noticed was that there is no longer the section Virtual Machine –> State which would explain why when I made the attempt to assign the Create Snapshot, Remove Snapshot, Revert to Snapshot, I couldn’t find it:

http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-vmware-rho.html

These permissions in vCenter 5.1 have since been moved to Virtual Machine –> Snapshot management:

Here is a screenshot of the old vCenter 5.0 Virtual Machine –> State option:

I think it’s important to note that I ran into the same issue when configuring the permissions for a VMware View 5.1 environment a week ago as VMware hasn’t updated their documentation either.  Seeing how I’ve been doing XenDesktop deployments quite frequently, I thought it would be a good idea to blog the permission settings so I have something to reference to in the future.  Note that the permissions haven’t changed so that much of the following Citrix eDoc still applies:

Using VMware with XenDesktop
http://support.citrix.com/proddocs/topic/xendesktop-rho/cds-vmware-rho.html

Datastore

• Allocate space
• Browse datastore
• Low level file operations

Global

• Manage custom attributes
• Set custom attribute

I

Network

• Assign network

Resource

• Assign virtual machine to resource pool

Tasks

• Create task

Virtual machine –> Configuration

• Add existing disk
• Add new disk
• Change CPU count
• Change resource
• Memory
• Remove disk

Virtual machine –> Interaction

• Power Off
• Power On
• Reset
• Suspend

Virtual machine –> Inventory

• Create from existing
• Create new
• Register
• Remove

Virtual machine –> Provisioning

• Allow disk access
• Allow virtual machine download
• Allow virtual machine files upload
• Clone template
• Clone virtual machine
• Deploy template

Virtual machine –> Snapshot management

• Create snapshot
• Revert to snapshot

Hope this helps anyone out there looking for updated permission settings for configuring the role for the XenDesktop 5.6 service account.

Adding “exchangedelegation.domain.com” to Federation Trust via “Manage Federation” wizard throws the error: “Unable to reserve domain "FYDIBOHF25SPDLT.exchangedelegation…” in Exchange Server 2010 SP2

Problem

You would like to set up your Exchange 2010 with SP2 organization to federate with other domains so you go through the steps required by setting up one-time federation with Microsoft Federated Gateway, create the domain proof TXT records, add a new exchangedelegation.domain.com namespace to the Accepted Domains, then proceed to add it to the federated domains:

… but receive the following error:

Summary: 2 item(s). 1 succeeded, 1 failed.
Elapsed time: 00:00:18

Set-FederationTrust
Completed

Exchange Management Shell command completed:
Set-FederationTrust -RefreshMetadata -Identity 'Microsoft Federation Gateway'

Elapsed Time: 00:00:00

Set-FederatedOrganizationIdentifier
Failed

Error:
Unable to reserve domain "FYDIBOHF25SPDLT.exchangedelegation.domainusa.com" for Application Identifier "000000004001E502".  Detailed information: "Windows Live returned a domain reservation error.  Detailed information "DomainUnavailable: The specified domain is not available.".".

Windows Live returned a domain reservation error.  Detailed information "DomainUnavailable: The specified domain is not available.".

DomainUnavailable: The specified domain is not available.
Click here for help... http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.2.342.0&t=exchgf1&e=ms.exch.err.Ex703205

Exchange Management Shell command attempted:
Set-FederatedOrganizationIdentifier -DelegationFederationTrust 'Microsoft Federation Gateway' -AccountNamespace 'exchangedelegation.domainusa.com' -OrganizationContact 'administrator@domainusa.com' -Enabled $true

Elapsed Time: 00:00:17

You try to re-run the wizard again and you receive the following error:

Summary: 2 item(s). 1 succeeded, 1 failed.
Elapsed time: 00:00:02

Set-FederationTrust
Completed

Exchange Management Shell command completed:
Set-FederationTrust -RefreshMetadata -Identity 'Microsoft Federation Gateway'

Elapsed Time: 00:00:00

Set-FederatedOrganizationIdentifier
Failed

Error:
An error occurred while attempting to provision Exchange to the Partner STS.  Detailed Information "An unexpected result was received from Windows Live.  Detailed information: "MaxUriReached MaxUriReached: Same URI cannot be attached to different AppId on a single day.".".

An unexpected result was received from Windows Live.  Detailed information: "MaxUriReached MaxUriReached: Same URI cannot be attached to different AppId on a single day.".

MaxUriReached: Same URI cannot be attached to different AppId on a single day.
Click here for help... http://technet.microsoft.com/en-US/library/ms.exch.err.default(EXCHG.141).aspx?v=14.2.342.0&t=exchgf1&e=ms.exch.err.ExB5F48C

Exchange Management Shell command attempted:
Set-FederatedOrganizationIdentifier -DelegationFederationTrust 'Microsoft Federation Gateway' -AccountNamespace 'exchangedelegation.domainusa.com' -OrganizationContact 'administrator@domainusa.com' -Enabled $true

Elapsed Time: 00:00:01

Solution

Before I get to the cause of the problem, note that the second error received:

Error:
An error occurred while attempting to provision Exchange to the Partner STS.  Detailed Information "An unexpected result was received from Windows Live.  Detailed information: "MaxUriReached MaxUriReached: Same URI cannot be attached to different AppId on a single day.".".

… is simply because you tried to rerun the wizard with the same settings again within the 24 hour period. 

As for the initial error, a quick search on the internet will lead you to the following blog post on TechNet:

http://blogs.technet.com/b/hot/archive/2012/08/30/you-fail-to-configure-federation-in-an-exchange-server-2010-sp2-based-hybrid-environment.aspx

The problem with the post above is that the content of the blog references to a hybrid environment which initially threw me off because I wasn’t configuring a hybrid trust under the Hybrid Configuration tab:

Another KB that comes up when searching for the error is the following:

"Unable to reserve domain" error message if a federated domain name contains more than 32 characters in an Exchange Server 2010 environment

http://support.microsoft.com/kb/2770103

… which also references the “Hybrid Configuration wizard”.  Reading the contents of these 2 pages during troubleshooting left me wondering if I should be following the instructions or not seeing how I’m configuring a setting under the Federation Trust tab.  Furthermore, the KB’s solution is as follows:

To work around this issue, do not add "exchangedelegation" to the domain namespace or remove some characters from the domain name. Then, run the following command in Exchange Management Shell to create the federation trust: 

Set-FederatedOrganizationIdentifier -DelegationFederationTrust 'Microsoft Federation Gateway' -AccountNamespace 'Domain name less than 32 characters' -Enabled $true

What’s confusing is that I’m asked to either remove the whole “exchangedelegation” which is the 2nd TXT record commonly dedicated for domain delegation and the second suggestion to remove some characters from the domain name simply does not make sense seeing how companies don’t change their public SMTP domain names on the fly.

In hopes that I can help someone who runs into the same problem as me, the answer to this is indeed to shorten the domain name if it exceeds 32 characters even though we’re not creating a Hybrid Configuration.  The solution I used to shorten the domain while not having to remove characters from my domain name was to simply use exchdelegation.domain.com which shortened it enough to be under 32 characters.  The Manage Federation wizard completed successfully once I made this change:

Determining the Microsoft Enterprise CA (Certificate Authority) name and server name

I’ve found that there are plenty of times when I needed to determine the CA name and the server name of a Microsoft Enterprise Certificate Authority whether it’s because I’m using a tool that does not or cannot auto discover Enterprise CA information to request a certificate or because I wanted to browse the /certsrv website of the CA.  As some administrators may know, one way of determining this information is to use adsiedit.msc to browse the configuration container then navigate to Services –> Public Key Services then to the AIA or CDP nodes but what I find most people don’t know is that you can actually open the command prompt and execute the following command:

certutil -config - -ping

… executing the command above will bring up the following window:

Click on the OK button will output the following in the command prompt:

C:\Users\tluk>certutil -config - -ping
svrcert02.someDomain.internal\SomeName Re
Connecting to svrcert02.someDomain.internal\SomeName Re ...
Server "SomeName Re" ICertRequest2 interface is alive (15ms)
CertUtil: -ping command completed successfully.

With this information, you can either take the FQDN of the server name and append it with /certsrv to get to the web page for enrolling or downloading certificates and/or fill in a CA path to request a certificate with serverFQDN\CA Name.