Pages

Saturday, April 27, 2013

You’ve successfully installed the Lync 2013 client on your Citrix XenApp6.5 servers but noticed that when you launch the published application through the Web Interface portal, it crashes with the following output:

Friday, April 26, 2013

A common problem that many Citrix administrators come across is when an Active Directory GPO is configured to present a security banner to users who log onto domain joined servers or workstations. The problem this poses is that applications published on Citrix XenApp servers will present a window with this security warning to users and will require them to interactively acknowledge the message by clicking on the OK button before the application begins to launch:

One of the ways around this is to block the policy all together by using the Block Inheritance option for an OU where the Citrix XenApp servers are placed but if doing so means having to reapply various policies that are inherited, creating a new GPO to disable the security banner may be more desirable. As simple this task may seem, I’ve been asked quite a few times on how to do this so the following outlines the steps required.

Begin by either creating a new policy or editing an existing one is applied to the XenApp server computer objects. Edit the policy and navigate to:

The question I often get asked is how can I disable this policy if the only option is to select Define this policy setting in the template:

Looking at the policy settings would lead many to believe that by enabling the policy and not defining a message may present users with a blank window to confirm but this is actually not the case so proceed with enabling both settings but not enter any content:

Once this policy has been set and applied to the XenApp servers, proceed with executing gpupdate /force on the servers then try to launch an application again.

Wednesday, April 24, 2013

You’ve configured federation between two Lync Server 2013 environments and noticed that one of the organizations can send instant messages and see presence information but the other one cannot. The following is the organization that can send instant messages and see presence:

While the other company displays a globe indicating that the user is a federated contact and is able to receive messages, presence information is labeled as “unknown”:

An attempt to send a message to this federated contact will display spinning dots:

ms-diagnostics: 1046;reason="Failed to connect to a federated peer server";fqdn="sip.lyncWorkingDomain.bm";peer-type="FederatedPartner";winsock-code="10060";winsock-info="The peer did not respond to the connection attempt";source="sip.lyncNOT-WorkingDomain.bm"

ms-diagnostics: 1046;reason="Failed to connect to a federated peer server";fqdn="sip.lyncWorkingDomain.bm";peer-type="FederatedPartner";winsock-code="10060";winsock-info="The peer did not respond to the connection attempt";source="sip.lyncNOT-WorkingDomain.bm"

ms-diagnostics: 1046;reason="Failed to connect to a federated peer server";fqdn="sip.lyncWorkingDomain.bm";peer-type="FederatedPartner";winsock-code="10060";winsock-info="The peer did not respond to the connection attempt";source="sip.lyncNOT-WorkingDomain.bm"

Solution

After reviewing the logs, I decided to test the port connectivity from the Edge servers and noticed that the Edge server for the organization that wasn’t able to send messages or see presence information was unable to telnet to the federated partner’s Edge server SIP URL via port 5061 even though it was able to connect via 443. This began to make sense as the problematic organization could see the globe indicating the contact was a federated partner but was unable to message or see presence information. A quick change in the firewall rule and confirming that the Edge server for the problematic organization was able to connect via port 5061 corrected this problem.

Thursday, April 18, 2013

I’ve recently been asked quite a few times in over the last few months on how to properly request and issue certificates for VMware View servers ever since the later versions of 5.x began throwing warnings when servers are using their default self-signed certificates and not a certificate that is issued by a trusted certificate authority such as an internal Microsoft Enterprise CA or a public CA such as GoDaddy, Verisign, etc. I’ve always suggested using a public CA simply because mobile devices don’t natively trust certificates issued by an internal CA and because it’s not a domain joined device, there is really no automated way to place the internal CA’s certificate into the trusted store. With that being said, if you don’t have any mobile or non-domain joined devices in your environment, you can use an internal Microsoft Enterprise CA for your View connection server certificates. The following demonstrates the process:

Upon successfully deploying your View Connection servers (both internal and external), you will noticed that the dashboard lists all of them with an error:

… and clicking on the server object will display the error:

Name: <serverName>

Version: 5.1.2

Status: Server’s certificate does not match the URL.

SSL Certificate: Invalid

Connections: 0

Before I begin demonstrating using a Microsoft Enterprise Root CA to issue the certificates, note that the official VMware View documentation for obtaining SSL certificates can be found in the following URL:

With the location of the official documentation out of the way, the certificate I intend on issuing will contain the common name:

vdi.domain.com

… and the following SAN entries:

vdi.domain.internal

vdi

svrvmvc01.domain.internal

svrvmvc01

svrvmvc02.domain.internal

svrvmvc02

svrvmvce01.domain.internal

svrvmvce01

svrvmvce02.domain.internal

svrvmvce02

By requesting a certificate with all of these names, I can simply use one certificate for all of my servers (2 internal and 2 external View connection servers). I get asked a lot about why I like putting the NetBIOS name in certificates any reason is that I’m quite lazy when it comes to typing in the URL for servers as I tend not to use the FQDN in most cases unless my laptop is not a part of the domain or if the DHCP servers do not issue the suffix for a domain. While I can’t speak for others, my guess is that there are probably others like me out there and since we don’t pay extra for having additional SAN entries when issuing certificates from an internal private CA, why not put them in? What’s also important to note is that Certificate Authorities (CAs) have accepted worldwide guideline changes and will no longer issue SAN SSL Certificates that are not in a legitimate FQDN format as of November 2015. I found out about this a few weeks back when trying to issuing a 3 year GoDaddy certificate with NetBIOS names so keep that in mind when planning your certificate.

Begin by logging onto one of your View Connection server, open the MMC console and add the Local Computer store’s Certificate snap-in:

Right click on the Certificates node under Certificates (Local Computer) –> Personal –> Certificates and select All Tasks –> Request New Certificate:

Click on Next:

Select Active Directory Enrollment Policy and click Next:

Note how I have a Web Server Exportable certificate template in the list which is a duplicate of the Web Server template but with the Private Key is Exportable enabled. The reason why this is important is because we will need to export this certificate to other servers so proceed with select the certificate and click on the More information is required to enroll for this certificate. Click here to configure settings. link:

The following Certificate Properties window is where we enter the information required for the certificate:

You don’t necessarily have to fill in all of the attributes but the following are the fields that I usually fill in:

E = tluk@domain.com

CN = vdi.domain.com

OU = IT

O = Company

L = Hamilton

S = Hamilton

C = BM

Adding SAN entries is simply selecting the DNS as the Type under the Alternative name section:

With the Subject tab for the Certificate Properties filled out, proceed with clicking on the General tab and type in vdm as the Friendly name. Note that this field MUST contain vdm or your View connection servers will not use this certificate.

Clicking OK in the window above will complete issuing of the certificate to the server:

With the certificate now in the local computer store, test the certificate by restarting the VMware View Connection Server service:

Log back into the administration console:

Note how the server with the certificate is now labeled with a green square indicating the error is gone:

Note that if you continue to see a red square complaining about the certificate, check the certificate properties and ensure the friendly name has the string vdm:

Now that we’ve confirmed the certificate works, proceed with exporting the certificate with the private key:

Make sure you export the private key:

Export as a PFX file:

Then copy the PFX file to the other VMware View Connection servers and import it:

Restart the services on the server:

Note that it may also be necessary to restart the other servers as well to update the error:

Hope this helps anyone looking for information on using a Microsoft Enterprise CA to issue certificates for VMware View connection servers.