XenApp 6.5 published Lync 2013 client crashes when launched through Citrix Web Interface Server portal

Problem

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

Microsoft Lync has stopped working

Windows can check online for a solution to the problem.

Check online for a solution and close the program

Close the program

Continuing to click the View problem details displays the following:

Problem signature:

  Problem Event Name:                        APPCRASH

Application Name:                             lync.exe

  Application Version:                           15.0.4420.1017

  Application Timestamp:                     5067326f

  Fault Module Name:                          LyncDesktopViewModel.dll

  Fault Module Version:                        15.0.4420.1017

  Fault Module Timestamp:                  506732ae

  Exception Code:                                  c0000005

  Exception Offset:                                000401bf

  OS Version:                                          6.1.7601.2.1.0.18.10

  Locale ID:                                             1033

Additional information about the problem:

  LCID:                                                     1033

Read our privacy statement online:

http://go.microsoft.com/fwlink/?linkid=104288&clcid=0x0409

If the online privacy statement is not available, please read our privacy statement offline:

C:\Windows\system32\en-US\erofflps.txt

You’ve confirmed that your Citrix XenApp server has been patched with Hotfix Rollup Pack 1 for Citrix XenApp 6.5 for Microsoft Windows Server 2008 R2 found here:

http://support.citrix.com/article/CTX132122

Solution

While there may be various reasons that could cause this crash, what fixed the issue for me was to patch the Lync 2013 client with the February cumulative update patches found here:

Lync 2013 client update (v15.0.4454.1506)

x86 - http://www.microsoft.com/downloads/details.aspx?FamilyId=95804c44-9308-4dd0-a0dd-88087aca0812

x64 - http://www.microsoft.com/downloads/details.aspx?FamilyId=e440d931-41c1-4206-a864-82f0e706ca81

Office 2013 MSO update (v15.0.4454.1504 - required for February 2013 update)

x86 - http://www.microsoft.com/downloads/details.aspx?FamilyId=cef3ff2c-23bc-4b41-84f5-efd4a0e1b5f7

x64 - http://www.microsoft.com/downloads/details.aspx?FamilyId=76c7a4af-8952-450c-99a5-16d06248f2aa

I had the 32-bit Lync 2013 client installed so the two packages I downloaded are the following:

• lyncloc2013-kb2760512-fullfile-x86-glb.exe
• msores2013-kb2767852-fullfile-x86-glb.exe

Blocking security banner for Citrix XenApp Servers

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:

Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Local Policies –> Security Options.  The 2 settings we’re interested in are:

• Interactive logon: Message text for users attempting to log on
• Interactive logon: Message title for users attempting to log on

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.

Unable to send instant messages or view presence information for federated partner in Lync Server 2013

Problem

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:

… then subsequently fail with the message:

When contacting your support team, reference error ID 504 (source ID 239).

Troubleshooting information is available online, including best practices for using Lync.
Test
When contacting your support team, reference error ID 1 (source ID 0).

Troubleshooting information is available online, including best practices for using Lync.

A quick debugging session with the logging tool on the front end server of the user who is unable to send or see presence information will show the following:

TL_INFO(TF_PROTOCOL) [0]0C88.14F4::04/24/2013-22:53:16.498.0000358e (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2387.idx(196))[2663723319] $$begin_record

Trace-Correlation-Id: 2663723319

Instance-Id: 271E

Direction: incoming

Peer: svrgalyncedge01.ganet.internal:5061

Message-Type: response

Start-Line: SIP/2.0 430 Flow Failed

From: <sip:tluk@lyncNOT-WorkingDomain.bm>;tag=BE180080

To: <sip:tluk@lyncWorkingDomain.bm>;tag=0da93f28e3;epid=c0f4c0bf1f

Call-ID: 6c22e601bf384fbcb7aad1e83cf0ce57

CSeq: 2 NOTIFY

Via: SIP/2.0/TLS 10.99.1.33:54576;branch=z9hG4bK233B2AEC.2289D0E28FA1DC67;branched=FALSE;ms-received-port=54576;ms-received-cid=900

Content-Length: 0

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"

TL_INFO(TF_PROTOCOL) [0]0C88.14F4::04/24/2013-22:53:16.529.0000391f (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2387.idx(196))[3715596209] $$begin_record

Trace-Correlation-Id: 3715596209

Instance-Id: 271F

Direction: incoming

Peer: svrgalyncedge01.ganet.internal:5061

Message-Type: response

Start-Line: SIP/2.0 504 Server time-out

From: "Terence Luk"<sip:tluk@lyncNOT-WorkingDomain.bm>;tag=8831ef87b3;epid=5f9c85c89d

To: "Terence Luk"<sip:tluk@lyncWorkingDomain.bm>;tag=0d2e9aac10;epid=c0f4c0bf1f

Call-ID: 9ff1cec1aa4e45cb89a737719a3a64dd

CSeq: 8 INFO

Via: SIP/2.0/TLS 10.99.1.33:54576;branch=z9hG4bK80E90095.A9B38655901FAC69;branched=FALSE;ms-received-port=54576;ms-received-cid=900

Via: SIP/2.0/TLS 10.99.1.33:49485;ms-received-port=49485;ms-received-cid=400

Content-Length: 0

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"

TL_INFO(TF_DIAG) [0]0C88.14F4::04/24/2013-22:53:16.529.00003e8a (SIPStack,SIPAdminLog::WriteDiagnosticEvent:1198.idx(778))[3715596209] $$begin_record

Severity: information

Text: Response successfully routed

SIP-Start-Line: SIP/2.0 504 Server time-out

SIP-Call-ID: 9ff1cec1aa4e45cb89a737719a3a64dd

SIP-CSeq: 8 INFO

Peer: 10.99.1.33:49485

Data: destination=tluk@lyncNOT-WorkingDomain.bm

TL_INFO(TF_PROTOCOL) [0]0C88.14F4::04/24/2013-22:53:16.529.00003ee0 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2387.idx(196))[3715596209] $$begin_record

Trace-Correlation-Id: 3715596209

Instance-Id: 271F

Direction: outgoing

Peer: 10.99.1.33:49485

Message-Type: response

Start-Line: SIP/2.0 504 Server time-out

From: "Terence Luk"<sip:tluk@lyncNOT-WorkingDomain.bm>;tag=8831ef87b3;epid=5f9c85c89d

To: "Terence Luk"<sip:tluk@lyncWorkingDomain.bm>;tag=0d2e9aac10;epid=c0f4c0bf1f

Call-ID: 9ff1cec1aa4e45cb89a737719a3a64dd

CSeq: 8 INFO

Via: SIP/2.0/TLS 10.99.1.33:49485;ms-received-port=49485;ms-received-cid=400

Content-Length: 0

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.

Issuing certificates for VMware Horizon View 5.2 servers with Microsoft Enterprise Certificate Authority

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:

Obtaining SSL Certificates for VMware Horizon View Servers
http://pubs.vmware.com/view-52/index.jsp?topic=%2Fcom.vmware.view.certificates.doc%2FGUID-358E1A54-DDD7-4A76-B9CB-198E0F7F76D4.html

… another old KB article that is more specific to using a Microsoft CA to obtain a certificate can be found here:

Managing SSL Certificates in VMware View 5.1 using an internal Microsoft Certificate Authority (2020913)
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2020913

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.