Device Updates (firmware upgrade) with Lync 2010

I connected Aastra 6725ip phone this morning. The phone arrived with RTM firmware. Because I know Cumulative Update 1 for Phone Edition is out, I will install it on my lab server, provision my first phone as Test Device and later, approve the update for all units in my environment.

We have three product lines (besides many other devices) that looks like a phone and work like a phone. Those are Aastra 6721ip and Aastra 6725ip; Polycom CX700 and LG-Nortel IP Phone 8540; and Polycom CX500, Polycom CX600, and Polycom CX3000. Complete up to date list can be found here: 

http://technet.microsoft.com/en-us/lync/gg278164

Back to our task. The update for each product line can be found here:

Lync 2010 Phone Edition for Aastra 6721ip and Aastra 6725ip http://support.microsoft.com/?kbid=2493724

Lync 2010 Phone Edition for Polycom CX700 and LG-Nortel IP Phone 8540 http://support.microsoft.com/?kbid=2493722

Lync 2010 Phone Edition for Polycom CX500, Polycom CX600, and Polycom CX3000 http://support.microsoft.com/?kbid=2493723

I personally like to keep the bits (model and firmware version, that is) in order and achieved. This is because as my previous experience shows, one never know if for some reason a quick downgrade will not be necessary.

First, I will create floder on my C:\ name PhoneEditionUpdates. Then sub-folder for each manufacturer, each model and each FW version. This is how my folder structure looks at the end:

Next, visit each link, download, run and unpack each update package in the appropriate folder.

Next step is to get the web servier identity (this is – if I have more than one pool, I must decide where the update will be installed. To do so, I will run “Get-CsService” cmdlet. In this case, “WebServer:fe.drago.local”

Now I can construct my command:

Import-CsDeviceUpdate -Identity "service: WebServer:fe.drago.local" -FileName C:\PhoneEditionUpdate\Aastra\Aries\7577.0107 \UCUpdates.cab  -WhatIf

***Above is an example of “WhatIf” parameter in Lync Management Shell. We are humans, thus making mistakes all the time. WhatIf checks the outcome of our command without actually executing it. Something is wrong in the above… Ah, the path contains white space.

After correcting it, I see the command will be executed correctly.

I will remove -WhatIf from the end and run it again. Only this time, I will add the “-Verbose” parameter. I want to see management shell in action.

 Let’s verify the import in Control Panel

So far, so good. Because if this was Production environment, rushing and approving the updates would create a chaos for short period of time (phones reboot “without reason” as the end user would see it), I will create Test Device, which will be upgraded now, I will test the functionality and if satisfied, will approve the update tonight, after close of business. This way my user will come tomorrow morning (well, it is Saturday, so, Monday morning) and continue business as usual (and so will the US Congress, LOL)

When we create Test Device, actually we approve the pending updates to THIS device only. Lync, unlike OCS, receives inband provisioning which includes update URL and software version. All I have to do now is to connect the phone and leave it idle for 10 minutes or so. I expect to see the device reboot by itself and have software version 7577.0107.

To approve the updates for all devices, select all and Approve them from Action menu.

Analog Phone support with Lync 2010

In some cases, we must retain certain analog phones in our otherwise VoIP environment. Let’s configure Analog Device support in our Lab.

This task requires the following steps:

1. Configuring Gateway in our Lync Topology
2. Configuring the Gateway (AudioCodes MP-114 in this case) to work with Lync
3. Create contact Analog Device object in Lync.

As we can see, no mediation server is associated.

At this point, TB detects our topology is not valid.

Let’s associate the gateway with our co-located mediation.

***Note that I will use TCP and also the default ports to make it simple.

Now Lync is “happy” and we can publish the topology.

***ALERT! Always pay attention if there is a message from TB. In this case I am reminded two things – I must run “local setup” i.e. Lync Server Deployment Wizard on the front end (because the mediation is co-located and we just enabled TCP. Lync Mediation, as its predecessor OCS R2 Mediation, does not support dynamic change of ports thus the service must be restarted in order to star the listener on the new/changed port.

After completing the above steps, I will now move to AudioCodes (a.k.a. AC) gateway.

 

Refer to the AC documentation as of how to access the device for first time. Once done, the first step is to provision an IP address which we will use in conjunction with Lync.

 

Next, we will set “Use default Proxy” to “Yes” if it is “No” as in this case

At this point, proceed to “Proxy Set Table” and configure our “Proxy” (Mediation Server FQDN or IP address).

***Note that here I specified the port number. This is because above, we set Lync Mediation to listen on port 5068.

Navigate to “Sip General Parameters” and modify the following:

1. Enable Early Media – Enable
2. Fax Signaling Method – G.711 Transport
3. SIP TCP Local Port – 5066

***This is because in our Topology, we specified Gateway Listening port = 5066

Navigate to “EndPoint Phone Number” and enter the phone number for this analog device. I will use “fake” number for our test. The reason I use 14785552020 and not E.164 is because in the previous post I instructed Lync to remove “+” from any outbound routing.

 

Navigate to “Hunt Group Settings” and configure as follow:

Make sure “Max Digits in Phone Num” is bigger than the phone number you intend to dial out.

***MP-114 have two FXS ports i.e. we could have as many as two analog phone connected to it, furthermore we want the phones to be discovered “By Dest Phone Number”

 

Go to “IP to Trunk Routing” and modify as shown:

Let’s now create our Analog Device contact:

New-CsAnalogDevice -LineUri tel:+14785552020 -DisplayName "My Test Analog Device" -RegistrarPool fe.drago.local -AnalogFax $False -Gateway 10.8.0.11 -OU "ou=Telecommunications,dc=drago,dc=local"

 

This should be sufficient to test our Analog Phone.

From the analog phone, dial 14785554040 (the number of my Lync User 2). 

From Lync client, dial 14785552020 (the analog device phone number).

This is very simple setup. There are more advanced features like TLS inmplementation, FXO ports configuration etc, but for now our POC was successful.

04/24/2011 ***Update: see this post:

http://www.lynclog.com/2011/04/mp-114-pre-configured-boardini-for-lync.html

for pre-configured BOARD.INI file and this:

http://www.lynclog.com/2011/04/mp-124-pre-configured-boardini-for-lync.html

  for MP-124

Strip “+” from RequestURI - Lync 2010

Recently I ran to interesting case – a colleague from another organization uses SIP Trunk provider who does not “like” E.164 number format, thus had problem with outbound calls and Lync user Caller ID presentation. While stripping “+” is now made easy with the new “Trunk Configuration” feature in Lync…

***Note the simple RegEx. Because Lync uses E.164 format, the number will always begin with “+” and we remove 1 “digit”, thus the number sent in TO header to the trunk/gateway will be non-RFC 3966 compliant.

...the problem was that while we sent non -RFC 3966 compliant TO header, FROM header still contains "+": FROM: "Drago Totev"<sip:+14785550001@fe.drago.local;user=phone>;epid=754CB7883F;tag=48b2223f97, and since the provider cannot handle it, as a result, the called party sees "Anonymous" as Caller ID.

Fortunately, Lync Management Shell cmdlet “Set-CsTrunkConfiguration” can resolve this issue.

First, we run “Get-CsTrunkConfiguration”. In this example, because I have not created new trunk, only the default – Identity “Global” is presented.

***Note the parameter “RemovePlusFromUri” is currently set to “False”. It is important to understand the fact setting this to “True” will force Lync to convert ANY E.164 in the RequestURI header to non-RFC 3966 compliant.

In the case above, we run “Set-CsTrunkConfiguration -Identity "Global" -RemovePlusFromUri $true”

Now my FROM header is non-RFC 3966 compliant.

FROM: "Drago Totev"<sip:14785550001@fe.drago.local;user=phone>;epid=754CB7883F;tag=4