Frequent invalid SIP requests

Problem
Partners receiving a large number of errors in the Edge Server event log like below

Solution
The cause seems to be Lync still sending discovery packets every 10 minutes.
If federation is allowed, add the SIP domain to the allowed list, if blocked - add the SIP domain to the blocked list.
This will be followed by a final event entry stating that the problem has been resolved

Event ID 31137 - Unable to remove\add Agent from Response Group

Recently I came across a situation where an Agent assigned to a response group had their SIP address changed by an administrator. Suddenly calls to this RGS were misbehaving, also their were 2 errors on the Lync FE server Event ID 31137 and 31138

Event ID 1400 - UM Server

I recently set up Lync 2010 at our offices and ran into a snag with Exchange 2010 SP2 UM voice mail integration. The symptom was the following error in Exchange 2010 UM:

The following UM IP gateways did not respond as expected to a SIP OPTIONS request.

Additional symptoms were that Lync client are unable to call voice mail and users are unable to leave a message for Lync users.

The Culprit

There are 2 possibilities here...
#1 - And perhaps the most common issue. 
The Subject Name of the Certificate assigned to UM MUST be equal to the FQDN of the UM Server.

The certificate assigned to the Exchange UM Server Role was not using its own FQDN as the Subject Name (SN), instead the SN was mail.domain.com. Sometimes I come across deployments where the self signed cert is added as the host name and not the FQDN, this too results in the same error.

Resolution
Re-issued a cert with the FQDN of the UM server as the subject name.

#2
The UM IP gateway in Exchange 2010 which is set up by running the ExchUCUtil.ps1 script doesn't have a port listed in the configuration. This can be viewed by running:

Get-UMIPGateway | fl

Resolution

Run Set-UMIPGateway -Port 5061

Event ID 14499 - Federation Issue

Just recently I can across this issue TWICE!
Thats enough to warrant another glass of...never mind, a post on the blog will have to suffice ;-)

Federation was failing and I got the following error message in the event log on the Edge Server I was building...

Running a S4 and SIPStack trace on the Edge also reported a 504 error between the two environments but most interestingly the highlighted error.

This alluded to the real issue, the new Edge server was unable to resolve the federation partners Edge Server discovered address.

Ahhh...gotta love DNS issues

Event ID 41025 - Conferencing Edge Server -

I was wondering about an elusive and very intermittent desktop sharing issue via the Edge Server. The only evidence of wrong doing was the Event Log on the Front End Server. The log was looping through Event ID 41025 and 41026 every 2 to 3 seconds!!!

Surely that's not normal...

The BPA showed no evidence either. Used a simple telnet test from the FE to the CE over ports 8057 and 5062. All working.

Searching for Event ID 41025 on TechNet I found a post quoted below

"For the 41024, 41025, 41026 loop of errors, the issue was tracked down to a strange certificate issue.

On the Edge External Nic I had used one vendor's for the UCC certificates (GoDaddy), as well I used that same vendor for the certificates on Exchange, TMG, and on the FE server Nic BUT for the internal facing edge NIC I had used a different vendor (RapidSSL) as I already had it.

I replaced the certificate from the one vendor with essentially the same thing but issued from the same vendor as all the other certificates in the deployment (GoDaddy)"


Ok, probably a good idea to check the cert assignments on the Edge Server. Turns out that I was using the same GoDaddy cert on the internal and external interfaces. Mmm...

Started to wonder if the FE was happy with that as the internal servers all used an internal CA. Two choices, either replace the Edge internal cert with one from the internal CA or export the Edge GoDaddy cert and import to the FE Personal Store. 

I went with option 2 and voila, Event ID 41025 gone!!!

Event ID 47068 - CMS Issue

If you ever see the following Error in Event log
Event ID 47068 GetAndPublish web service failed

Recently I was deploying a new Lync 2010 environment, here is where the issue started..the customer decided that they would provide a SQL 2012 backend for the CMS (even though not supported). This meant that mid deployment we had to change the backend database, only thing is that the SQL backend was removed prior to detaching from the Lync FE. 

I ran the usual install database which completed without any errors, checked the databases and all looked fine.

When I fired up the first user I got the screen shot below

I could search for users and found them but no presence updates at all. A tell tale sign that the RTCDyn database isn't playing nice.

Checking the FE I found this error below, didn't take too much notice of it at first. Then wondered why it was the LS User Services??

Digging deeper I also found this one below, not too many of them either

Lync is telling the client that it doesn't trust the query to the database for the client to find presence info etc.

OK, so how do you re-authenticate\attach the cert to a database that reports no errors when deploying?

Powershell Of Course!

Since it was a new install I wasn't too concerned about re-installing the CMS

#uninstall
unInstall-CsDatabase -CentralManagementDatabase -SqlServerFqdn <SQL-FQDN>

#Re-install default
Install-CsDatabase -CentralManagementDatabase -SqlServerFqdn <SQL-FQDN>

Re Published the Topology and then Ran Setup and finally it all started working