Thomas.Poett@TEAMS (MVP Teams and Cross-Tenant Migration Specialist)

Lync is quiet strict in certificate validation. If you assign a non compatible certificate to Lync it will run into serious issues. This is most likely happen if you are using dedicated certificate for each Lync service. Especially the Lync WebServiceInternal certificate cannot be requested correctly, neither with Lync Wizard nor with the Request-CsCertificate command. Here the problem is that both methods are requesting a certificate with a Subject Name of the Internal Web Services rather than the POOL FQDN. Lync BUG: The remote certificate is invalid according to the validation procedure. reason="The web ticket is invalid." ;faultcode="wsse:InvalidSecurityToken",Replace=false In both, the TechNet and Help File the correct certificate is described. Therefore you need a valide process of requesting the correct certificate. If you have a consolidated certificate for all services, this is issue is not present, because the Subject Name responds to the POO

I came across a funny problem. I customer complained if a federated call was initiated the call always dropped after exactly 31 seconds. What we could figure out was this error message. SIP/2.0 504 Server time-out ms-client-diagnostics : 52085;reason="Dialog does not exist" So I continued the analysis and traced the calls. With the wonderful tool SNOOPER, I was able to get a see the "Call Flow Windows", which is really a very helpful visualization of the exact package flow. I saw now the SIP Session was initiated correctly. BUT I figured out, the PRACK message was not acknowledge, so the ACK 200/OK was missing. Even the message was send correctly the target host. "This is a kind of early media." The Voice stream is established, but need to be reconfirmed in case some port/ parameter should be changes/ optimized. Since the ACK is missing, truly the Lync Server must think the call has ended and actively dropped it. This all is happened on the

Before we start with the Lync 2013 Reverse Proxy solution design and setup guide. I want to keep some supportability statement in mind. By today, the date of writing this blog, Microsoft has to supported solutions. 1. Microsoft TMG (Thread Management Gateway) - if the TMG was purchased before the EOL date. 2. Microsoft IIS ARR (Internet Information Server Application Request Routing) A third solution, the Microsoft Web Application Proxy introduced with Windows Server 2012 R2 is not jet supported. This is due to the reason that WAP has a problem with multiple SIP Domains, meaning here: I cannot handle requests other than for the primary SIP domain, especially the MEET simple URL. The configuration guide here runs through the entire process from the ISS ARR Installation and setup. The guide concentrates on Windows Server 2012 R2. Therefore we need to understand the installation process for IIS ARR first. ARR cannot simply installed by download the MSI package, rather than using t