Lync: Presence information is missed in Outlook

One day I noted Presence information is no longer available in my Outlook.

I tried to apply KB https://support.microsoft.com/en-us/kb/2726007 but that did not help

Resolution: it turned out Cisco Jabber installed recently switched  “DefaultIMApp” under HKEY_CURRENT_USER\Software\IM Providers to “Cisco Jabber”. I changed it back to “Lync” (without quotation) and presence is back

Lync 2013: Multi-user IM conferencing issue (really Certificate chain issue)

 

Our IT guys called me seeking for support with a weird issue. Multi-user IM conferencing starts to fail. I checked and see an attempt to start “Meet now” failed too with error on connection to conferencing server.

On Client side it gives Error 500 (source ID 239).

In Event Log of Front end Server I saw Event ID 32042 from LS User Services:

“Invalid Incoming HTTPS Certificate”

 

I checked the certificate and it looked perfectly fine, not expired and with a proper chain.

Next day most contacts in Lync Client were observed in “Updating…” state. Not good.

 

Resolution:

We deployed a Microsoft KB 2901554 to fix SChannel Authentication Provider on Windows Server 2012 R2

Next I Run the following Power Shell command (one line):

Get-Childitem cert:\LocalMachine\root -Recurse |Where-Object {$_.Issuer -ne $_.Subject} | Format-List * | Out-File c:\computer_filtered.txt

to figure out if there are any intermediate certs in Trusted Root certificate folder as recommended in this article

And found one certificate in the wrong container. I moved it in Intermediate Certification Authorities and restarted Lync Services. After that the issue seems to be resolved.

Lync: Request certificate for Reverse Proxy

First of all, Microsoft has an article for that.

But, the article did not work for me – Entrust needed additional fields (like Country, Locality) filled and for some reasons all my CSRs had 1024 key request even though I put 2048 in MMC Wizard.

Finally I decided to do it old way, via .inf file and certreq tool.

here is .inf file I created:

Note: the CSR requests SHA-1 certificate. Microsoft supports SHA-1 until 2017. You can tweak it to request SHA-2 cert.

PKI: How to clean faulty Certificate Request

I recently needed to update an Entrust certificate on my Lync Reverser Proxy. Lync does not have a Wizard to generate CSR so I used Microsoft KB https://technet.microsoft.com/en-us/library/gg429704(v=ocs.15).aspx to generate it. Unfortunately KB does not say you need to add Country, Locality and other information and CSR generated failed on Entrust. I added information, but in this case CSR failed because of key length – it has 1024 even though I put 2048. so I end up with several faulty CSRs. How to clean them out? Google search brought me some powershell scripts. Looked a bit too complex. Finally I found an answer on ExpertExchange.

You can basically use certificates MMC (local machine store) and delete unwaneted CSRs there. After that remove CSR files from location where you saved them.

Lync: Script: Get-CsConnections.ps1 – See User Connections, Client Versions, Load Balancing in Lync Server

An old script, but never saw it before for some reasons – it allows to see Client versions and user distribution per Front-end Server. I use it during FE updates, to be sure there is no user connected to an updated FE.

original is here

 

Lync: Wireshark and Netmon plugins for STUN troubleshooting on Lync Edge server

James Cussen published a useful plugin for Wireshark network analyzer. You can use Microsoft Network Monitor, it has Lync plugin pack too.

 

Wireshark plugin: http://www.mylynclab.com/2014/05/microsoft-lync-wireshark-plugin.html

 

Microsoft  NetMon Lync plugin pack: http://www.microsoft.com/en-us/download/details.aspx?id=22440

Lync 2013: Front end server start fails

One of my Lync 2013 FE did not start after update to August 2014 CU.

The error pointed to certificate:

 

Event Id: 14397:

A configured certificate could not be loaded from store. The serial number is attached for reference.

Extended Error Code: 0x800B0109(CERT_E_UNTRUSTEDROOT).

—————————————————————————————————

Event Id 14646:

A serious problem related to certificates is preventing Lync Server from functioning.

Unable to use the default outgoing certificate.
Error 0x800B0109(CERT_E_UNTRUSTEDROOT).
The certificate may have been deleted or may be invalid, or permissions are not set correctly.
Ensure that a valid certificate is present in the local computer certificate store. Also ensure that the server has sufficient privileges to access the store.

——————————————————————————————————

details page (for Event Id 14397) shows the certificate number. I tried to find it using PowerShell

Get-ChildItem -Path CERT: -Recurse | FT Subject, SerialNumber | FindStr <NUMBER FROM EVENT VIEWER>

It returned an empty string. So I rerun it without |findstr … and checked output. Naturally I saw one of cert number is similar to whatever was in event id  BUT

1. it was backward and

2. each two bytes were changed in place

It is confusing, eh? so I will try to give an example:

Number in Event viewer:    ABCDEFGH12

Certificate number: 12GHEFCDAB

After that I found the certificate in question – it is my pool cert which works just fine of my first FE server…

I checked the certificate using Cert MMS – it looked ok and fully trusted. Trusted root – GeoTrust Global CA was on its place.

Resolution: An intermediate certificate (GeoTrust SSL CA – G2) was not under “Intermediate Certification Authorities”. I copied it from my first server store to the second one and restarted the front-end on the second server. It started successfully this time.

Communicator Web Access (CWA) and Lync 2013–still works!

 

I find CWA much more convenient to use than OWA (with Lync integration). That is why I was happy to see CWA for OCS 2007 R2 is still working with new and shiny Lync 2013!

In my co-existence scenario (Lync 2010 – Lync 2013) I repointed legacy CWA to my new Lync 2013 pool (OCS  2007 R2 CWA allows that) and have web client up and running!

 

As you can see even Skype integration expected to be available in the next month seems to be working (via MSN federation I guess):

Note: do not forget to update CWA with latest OCS 2007 R2 CU!

Lync: Mobility

I am testing migration from Lync 2010 Enterprise Edition to Lync 2013 Standard Edition. One of thing which does not work is Lync 2013 Mobile for users already migrated to the new server. Let’s put it this way – it works when a user is outside of my internal WiFI network.

 

When the same Client is on internal network that is what I see in the Client logs:

 

</ReceivedResponse> 2013-05-07 16:51:51.796 Lync[2000:3540] INFO TRANSPORT CHttpRequestProcessor.cpp/266:Sending event to main thread for request(0x4c0cb18) 2013-05-07 16:51:51.796 Lync[2000:3540] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/605:UrlRedirectAndTrustResolver complete with url = http://lyncdiscoverinternal.mydomain.com/, Hops = 1, status = E_BadGateway (E2-3-35) 2013-05-07 16:51:51.796 Lync[2000:3540] INFO APPLICATION CTransportRequestRetrialQueue.cpp/692:Response received for req. UrlTrustResolver(04C0CB18): E_BadGateway (E2-3-35) (RemoteNetworkPermanentError); Done with req.; Stopping resend timer 2013-05-07 16:51:51.796 Lync[2000:3540] INFO APPLICATION CUcwaAutoDiscoveryGetUserUrlOperation.cpp/393:CUcwaAutoDiscoverGetUserUrlOperation::onEvent received.  Status = E_BadGateway (E2-3-35), url = http://lyncdiscoverinternal.mydomain.com/ 2013-05-07 16:51:51.796 Lync[2000:3540] INFO APPLICATION CUcwaAutoDiscoveryGetUserUrlOperation.cpp/224:UcwaAutoDiscoveryGetUserUrlOperation completed with url = http://lyncdiscoverinternal.mydomain.com/?sipuri=sip:alex.ig@mydomain.com, userUrl = , status = E_BadGateway (E2-3-35) 2013-05-07 16:51:51.796 Lync[2000:3540] INFO APPLICATION CUcwaAutoDiscoveryService.cpp/1476:AutoDiscovery: Falling back to probing external urls 2013-05-07 16:51:51.797 Lync[2000:3540] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/77:Starting CUrlRedirectAndTrustResolver with url = https://lyncdiscover.mydomain.com/?sipuri=sip:alex.ig@mydomain.com, maxHops = 10 2013-05-07 16:51:51.797 Lync[2000:3540] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/201:CUrlRedirectAndTrustResolver::processUrl called with url = https://lyncdiscover.mydomain.com/, hopCount = 0, maxHops = 10 2013-05-07 16:51:51.797 Lync[2000:3540] INFO APPLICATION CUrlRedirectAndTrustResolver.cpp/605:UrlRedirectAndTrustResolver complete with url = https://lyncdiscover.mydomain.com/, Hops = 0, status = S0-0-0 2013-05-07 16:51:51.797 Lync[2000:3540] INFO TRANSPORT CCredentialManager.cpp/164:getSpecificCredential for serviceId(4) returning: credType (1) signInName (alex.ig@mydomain.com) domain () username (alex.ig@mydomain.com) password.empty() (1) compatibleServiceIds(4) 2013-05-07 16:51:51.797 Lync[2000:3540] INFO TRANSPORT TransportUtilityFunctions.cpp/638:<SentRequest> GET https://lyncdiscover.mydomain.com/?sipuri=sip:alex.ig@mydomain.com Request Id: 04C0DD08 HttpHeader:Accept application/vnd.microsoft.rtc.autodiscover+xml;v=1

 

I tried http://lyncdiscoverinternal.mydomain.com from my Browser and received the following configuration:

{"_links":{"self":{"href":"https://lync02.mydomain.com/Autodiscover/AutodiscoverService.svc/root?originalDomain=mydomain.com"},"user":{"href":"https://csweb-ext.mydomain.com/Autodiscover/AutodiscoverService.svc/root/oauth/user?originalDomain=mydomain.com"},"xframe":{"href":https://csweb-ext.mydomain.com/Autodiscover/XFrame/XFrame.html}}}

 

So I decided to add a record for my external web site to my internal DNS and point it to my Lync 2013 server. Same error.

Resolution: On Internal DNS I pointed csweb-ext.mydomain.com to Reverse Proxy listener, so basically I sent my internal Wifi Clients via Proxy instead of route them directly to Lync. For some reasons that resolved the issue and Lync Mobile works now for internally connected and externally connected users.

 

Note: my domain name in logs is changed.

Lync: Entrust Certificates

 

Bumped into an article on Entrust site showing how to put their certificate chain correctly to a Lync Server: http://www.entrust.net/knowledge-base/technote.cfm?tn=8447