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

CX500 - Network error

As all blogs should, I'll start this one with a personal experience...

Just recently (sound familiar yet?)..

I had configured the CX500 as per usual as a common area phone. It signed in beautifully once I added the telephone number (without the + of course) and the accompanying PIN.

When I rebooted the phone it showed the boot cycle and then got stuck on a screen saying that there was no network detected. It then presented me with the configure device options as if it had forgotten the telephone number and PIN. Once I re-entered these it logged in as before.

Right so if I have a power outage my device isn't going to automatically login with the cached credentials...not good.

For giggles I first updated the firmware on the CX500, same behaviour. Checking the device I noticed that the DHCP request was going unanswered and the CX500 wasn't getting an IP..DHCP problem?? NO!

After much packet capturing and head scratching the culprit was discovered. The switch of course, a Spanning Tree Setting was delaying the DHCP request from reaching the DHCP Server. That should cause the error we are getting you may say...

The CX500 sends only 4 DHCP requests (in rather quick succession), normally 1 will suffice and get a response. In my case the delay injected by the switch prevented a timely answer. The CX500 then goes into "I give UP" mode, and then sits there waiting on the "credentials" page. Once the Credentials are re-entered further DHCP requests are sent.

Changing the switch port solved the issue.

PB

AD Contact Numbers not showing in Lync

Its always frustrating how Administrators don't have any standard format in which they add telephone numbers to user in AD.
Its even more frustrating when Lync WONT collect these numbers and send to the RTCAB database cause they aren't in E.164 format.

It is possible to add normalization rules for modifying numbers from AD to E.164 so that they are recognised by Lync and sent off to the Database.

If this happens the AddressBook Service will gladly distribute these to Lync user via GAL or WEB.

It will even distribute numbers that aren't in E.164 as long as they have a normalization rule in the "Company Phone Number Normalization Rules" text file that matches the format in AD (as per the Extension Example below)

So how does this work?
Simply create a txt file and copy to the Lync Share

....\LyncShare\1-WebServices-1\ABFiles\

Company_Phone_Number_Normalization_Rules.txt

Now populate the txt file with your rules as per the example below:

#Start
#
# Normalize 4-digit extension numbers from Active Directory into E.164
#
# Legacy extensions
#
(\d{4})
+643321$1
#Normalize NZ National Numbers from Active Directory into E.164
#+64$1
0([3-9]\d{7})
+64$1
#Normalize NZ Cell numbers from Active Directory into E.164
#+642$1
0(2\d+)
+642$1
#Extension Dialing for 8xxx range
(8\d{3})
$1
#End


To find further Active Directory Normalization failures navigate to the directory:
C:\LyncShare\1-WebServices-4\ABFiles\00000000-0000-0000-0000-000000000000\00000000-0000-0000-0000-000000000000\Invalid_AD_Phone_Numbers.txt

NB
Just be warned, this isnt validated so if you make any typos you wont find this reported

BUT you can test this by running the ABServer.exe -testphonenorm switch.
Simply run the ABServer .exe from the directory:-
C:\Program Files\Microsoft Lync Server 2010\Server\Core

Example


..\Program Files\Microsoft Lync Server 2010\Server\Core\ABServer.exe" -testphonenorm "021 123 4568"