Updating Exchange 2010 OWA for Lync

Having been inundated with Lync work since it was released over a year ago, I’ll admit to having not paid a lot of attention to OCS.

Once area where OCS continues to play a part in Lync installations is the IM functionality we now enjoy through Exchange 2010 OWA. Those are actually OCS components you’re installing!

Accordingly, having just updated Lync to CU5, I thought I should scope the latest OCS updates for the Lync part of OWA.

As I referenced in my CU5 post, the Lync ServerUpdateInstaller.EXE didn’t find anything it wanted to install on my combo Hub/CAS/Mailbox/UM server.

I have however found one component that could do with a refresh.

image

Here’s the update to take the UCMA Redist to 3.5.6907.244. (January 2012). Or do as I do and just run the OCS ServerUpdateInstaller from here.

This will take your Web Service Provider to 3.5.6907.202 if you’re not already (as mine is). (May 2010).

image

A simple update for me, and here’s the result:

image

BTW, if you’ve not already performed the integration process, I’ve referenced it a few times in earlier posts:

Integrating Lync and OWA

UM service won’t start

Lync replicates its CMS to Exchange

Integrating Lync and Exchange 2010 SP1

 

– G.

Script to find Unused Numbers in Lync

Ståle Hansen has published a great PowerShell script that digs through the Lync CsUnassignedNumber list and mashes it against all of the possible uses of a number (including CsAnalogDevices, CommonAreaPhones, RGS, UMContacts and more) to report what numbers in a given number range are currently spare. It fills a yawning (and frustrating gap) in the Lync administrator’s toolkit.

We tend not to use the Unassigned Numbers feature here in Oz. Generally speaking, we’re happier letting you receive a free supervisory message from the carrier if you’ve dialled a vacant number, rather than charging you for the privilege of receiving a recorded announcement, a menu, or transferring you to an already overburdened reception.

foreach ($Serie in (Get-CsUnassignedNumber))

The real meat of Ståle’s script runs inside a loop that iterates through each entry in the Unassigned Numbers list, so it dawned on me that I could quite easily replace that with an array of my own, and then add a front-end menu so you could choose just what range you were interested in.

Continue reading ‘Script to find Unused Numbers in Lync’ »

Calling a busy Tenor port fails with SIP 503 instead of 486

The NET Tenor appears to have a bug in its “108 Routing” (a feature enhancement I wrote of here and here).

If you make a call to an FXS port that’s busy, the Tenor reports “SIP/2.0 503 Service Unavailable” instead of “SIP/2.0 486 Busy here”, and this is reflected back to the calling party. A call from my [Australian] Telstra mobile to a busy Tenor port results in me just hearing silence until I abandon the call, rather than the expected Busy tone.

Fix it in the UX

Should you happen to have a UX upstream, this is readily corrected with a “SIP To Q.850 Cause Code Override Table”:

image

Don’t forget to reference this new table in the Mediation Server’s Signaling Group (assuming you’re routing the Tenor’s calls through Lync). If you’re routing direct, you’d reference the table in the Tenor’s Signaling Group instead:

image

Fix it in the Tenor

Subsequent to implementing the above, the NET TAC confirmed the issue as localised to the “108 Routing” feature and present in both Tenor firmware P108-09-10 and P108-09-18. The fix within the Tenor is an amended “map.cfg” file that translates internal cause code 34 (“No Channel Available”) to 486/Busy: Download.

FTP to the Tenor, rename the existing map.cfg file to map.cfg.old and copy the new file across. If you’re not using Config Manager, Telnet to the Tenor, login and issue the commands “maint” and “debug reboot”. It will tell you the time and then restart itself. Once it comes up you should be sweet, receiving “SIP/2.0 486 Busy Here” when you next call a busy port.

 

– G.

PowerShell Filter command fails

Sometimes what seems an obvious PowerShell filter request is rejected. The parameter you’re seeking is visible when you get-user (Exchange) or get-csUser (Lync), but you’re still rejected.

The error message is the rather bleak and uninspiring:

Invoke-Command : Cannot bind parameter 'Filter' to the target. Exception setting "Filter": ""UMDialPlan" is not a recognized filterable property. For a complete list of filterable properties see the command help.”

But I don’t want to see the command help for a complete list of filterable properties – I want to filter on this parameter!</hissyfit>

Continue reading ‘PowerShell Filter command fails’ »

Decoding Lync’s Client-Side Error Messages

Some of Lync’s Client-side error messages don’t really explain the reason for the failure. Here are a few and what they might be indicating. I hope they make your life a little easier:

Instant Messages

“<username> could not be found and this message was not delivered”

Lync-CouldNotBeFound

1) There is no such user at the recipient’s domain. There’s an instance of OCS/Lync there, they have an Edge, but you’ve simply nominated an invalid user – or guessed their e-mail naming format wrong.

2) There *is* such a user at the recipient’s domain – but they’re not enabled for Federation. There’s an instance of OCS/Lync there & they have an Edge. [TBC]

3) There *may be* such a user at the recipient’s domain – but they don’t have open Federation and THEY don’t trust YOUR domain. [In this example, my lab domain is not Federated with Microsoft].

 

Continue reading ‘Decoding Lync’s Client-Side Error Messages’ »

Lync CU4 Database Update Error

My Topology here in the Lab started with a Standard Edition FE, and I later added an EE. Accordingly, the XDS is on the SE FE, which would be considered ‘unconventional’ in the outside world, and certainly highly undesirable if you’re aiming for high availability.

CU4 went on to the SE without any problems, but when I got to the EE server the Database Update failed with following error:

Continue reading ‘Lync CU4 Database Update Error’ »