RoOCS

Lync new INVITE behavior when calling (invite by phone) PSTN Numbers into a Conference

AlexBacanel — Fri, 01 Jul 2011 08:22:00 GMT

It has been a while since we last posted something new to our blog, but we are back.

I wanted to start a new tread regarding new or changed features and behavior in Lync 2010 as opposed to Office Communications Server 2007 R2.

Based on our customers feedback the behavior has been changed when inviting a PSTN Number from a Lync meeting, the change of behavior might need some configuration of your Gateway/PBX if you are migrating your Mediation Server from Office Communications Server 2007 R2 to Lync.

We have seen numerous issues with billing in Office Communications Server 2007 R2 when dialing out from a meeting, this is because in R2 when you were dialing out from a meeting, the call was initiated by the meeting service and not by the user itself, the result of this was that a generic INVITE Message was being sent to the Gateway with an anonymous caller ID and no way to identify the User actually making the call.

Some customers that were using a SIP Trunk and where the billing was done based on DID could so not make any outbound calls from the Meeting as the SIP TRUNK/Gateway was refusing Anonymous Calls.

In Lync we now have a new behavior, the call is still made by the Conferencing Service but this time the Conferencing Service got smarter, it no longer sends a plain anonymous Invite to the Gateway but identifies the user making the call and uses this users Number to make the call.

Here are a few examples of the behavior.

SIP INVITE to Gateway in R2 when a PSTN User was invited to an existing meeting

22d:22h:57m:22s INVITE sip:+402681230001@10.165.213.38;user=phone SIP/2.0

FROM: ;epid=8327676970;tag=6811c6f52b

TO:

CSEQ: 12 INVITE

CALL-ID: 42c9c8d7-3390-4e01-a01f-51c70c368f71

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 192.168.0.4:59804;branch=z9hG4bK45caa86

CONTACT:

CONTENT-LENGTH: 324

SUPPORTED: 100rel

USER-AGENT: RTCC/3.5.0.0 MediationServer

CONTENT-TYPE: application/sdp; charset=utf-8

ALLOW: ACK

Allow: CANCEL,BYE,INVITE,PRACK,UPDATE

v=0

o=- 18 1 IN IP4 192.168.0.4

s=session

c=IN IP4 192.168.0.4

b=CT:1000

t=0 0

m=audio 60152 RTP/AVP 97 101 13 0 8

c=IN IP4 192.168.0.4

a=rtcp:60153

a=label:Audio

a=rtpmap:97 RED/8000

a=rtpmap:101 telephone-event/8000

Notice how the FROM Field (FROM: ;epid=8327676970;tag=6811c6f52b) Contains no E164 Number, just a Username of the User that initiated the meeting and the conf tag, this is displayed here because the conferencing service initiated the call.

As you can imagine, most PBX/Gateways will have no idea who or what testuser@vonfluxenberg.tk is as they are designed to work with E164 Numbers and not SIP Addresses. At best they would treat this as an Anonymous call but PBX’s or SIP TRUNKS that rely on DID for Billing would just simply decline the call…. Not very fun for some.

SIP INVITE to Gateway in Lync 2010 when a PSTN User was invited to an existing meeting

22d:22h:55m:2s INVITE sip:+402681230001@10.165.213.38;user=phone SIP/2.0

FROM: ;epid=79D93FDA4B;tag=5b1fb1ee8

TO:

CSEQ: 2392 INVITE

CALL-ID: 9fcf1195-2ec7-4039-a4e6-1ba12bbb8c7c

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 192.168.2.2:56229;branch=z9hG4bK336c7520

CONTACT:

CONTENT-LENGTH: 335

SUPPORTED: 100rel

USER-AGENT: RTCC/4.0.0.0 MediationServer

CONTENT-TYPE: application/sdp

ALLOW: ACK

Allow: CANCEL,BYE,INVITE,PRACK,UPDATE

v=0

o=- 4 1 IN IP4 192.168.2.2

s=session

c=IN IP4 192.168.2.2

b=CT:1000

t=0 0

m=audio 52548 RTP/AVP 97 101 13 0 8

c=IN IP4 192.168.2.2

a=rtcp:52549

a=label:Audio

a=sendrecv

a=rtpmap:97 RED/8000

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16

a=rtpmap:13 CN/8000

a=rtpmap

As opposed to the example before, notice how the SIP Invite from the Lync 2010 Server contains in the From Field (FROM:sip:+49891242666@vflync.vonfluxenberg.tk;user=phone>;epid=79D93FDA4B;tag=5b1fb1ee8) a telephone number and no longer the SIP User Name as in R2, this will make SIP TRUNK Providers that rely on DID’s for billing very happy as they can now charge you for the Conference Calls but it can help in other scenarios also.

Hope you have found this information helpful and we promise to be back soon with more tips and tricks on LYNC and OCS.

On the path from LCS 2005 to Lync 2010, something went wrong...

Sorin Duta — Mon, 24 Jan 2011 03:16:00 GMT

Disclaimer: you cannot migrate from LCS 2005 to Lync 2010 directly. To do this, you must first migrate from LCS to OCS 2007 (R1 or R2) and then from OCS 2007 (R1 or R2) to Lync.

I had a problem the other day about a migration from LCS 2005.

The scenario was the following: an LCS environment was to be migrated to OCS 2007 R2 and then to Lync. The migration was done according to https://technet.microsoft.com/en-us/library/dd819973(office.13).aspx, but during the global settings move (https://technet.microsoft.com/en-us/library/dd819962(office.13).aspx) something went wrong: KB 911996 was not correctly installed (not all files were updated) and when the RTC Service object was deleted from the CN=Schema,DC=domain,DC=com, LCS couldn't start anymore and the migration was compromised.

In this situation, there are 3 things to take into consideration:

1. You don't really need to move the RTC objects from Schema to Configuration: this change was done in OCS in order to improve performance. Lync doesn't use AD that much (most of the data will be in SQL), so if you don't have a pressing business need to move the RTC objects to the Configuration partition, don't do it!

2. If you decide to move the objects, verify that KB 911996 is correctly installed. Check that all the files mentioned in the KB were updated before moving anything.

3. If the move went wrong, unless you re-install LCS or restore the AD, there isn't much you can do to get LCS running again.

Ok, so you're in the situation 3 and decided to skip the migration and install Lync directly. I have still to check if the user's contacts can be recovered (and will update this post once I tried it). If you don't care about the contacts (although you should), here's how you can move directly to Lync (this is not a supported migration path, but rather a fresh Lync install after a disaster).

0. Back up your AD (in case anything goes wrong - the next step in this is not supported by Microsoft, so if anything goes wrong, you're probably on your own).

1. Delete the RTC Service objects from AD.

2. Install Lync normally, as if it was a fresh install.

3. After the Lync install is finished (and you've tested the functionality with some new test users), you're ready to activate the users for Lync. You won't be able to do it from the Lync console, although you will be able to see them in the console as legacy users.

4. To activate a user for Lync, you must first remove all the information regarding the old server. You can do this by running in the Lync Powershell console Disable-CsUser "User Name". You must have rights for editing the AD user properties in order to do this operation.

5. After the user has been disabled, it can be acticvated for Lync as if he/she was a new user.

6. You must deploy the Lync 2010 client! Communicator 2005 will probably not work with Lync.

Remote Call Control in LYNC

AlexBacanel — Tue, 28 Dec 2010 06:04:00 GMT

A short, how-to, about RCC and LYNC.

RCC remains mostly the same in LYNC as it was in OCS 2007 and OCS 2007R2, the setup and configuration phase have changed a little, actually the only way to set-up RCC in LYNC is with PowerShell. The set-up however follows the same logic as before, set-up a static route, set-up authorization for that route and enables the user for Remote Call Control.

As before you can set-up the connection via TCP or TLS, depending on your implementation, for this example we will use TCP as it is easier to trace and configure, TLS is more or less the same.

Firstly we will go into PowerShell and Get-CsStaticRoutingConfiguration, by default this should be empty, remember this is for the global level but should you want to check a particular site just put in the -identity argument.

https://technet.microsoft.com/en-us/library/gg398754.aspx

You should get something like:

This means there is no static route associated to your Pool on a Global Level

What we need to do is to create a static route as needed and attach it to the StaticRoutingConfiguration on the Pool Level. A colleague of mine told me we can add the first command as a variable for the second one so what I did, and it worked, was the following.

Here is how you create Static Route: https://technet.microsoft.com/en-us/library/gg398265.aspx

New-CsStaticRoute -TcpRoute -destination -port -matchuri

Here is a short description of the command and the variables:

-TcpRoute = creates a route via TCP, alternatively you may user -TLSRoute to set-up a Static Route that uses TLS

-destination = this is the IP or FQDN of your RCC Gateway

-port = this is the Port that your device will listen on

-matchuri = this is the domain you will route to the Gateway, remember the @ is set automatically so when you put in the domain name don't use @, ex.-matchuri "rcc.local"

So now that we've got the Static Route down let's see how we attach it to the Pool, as I told you before I used it as a variable and assigned it to the Set-CsStaticRoutingConfiguration

https://technet.microsoft.com/en-us/library/gg398724.aspx

$1= New-CsStaticRoute -TCPRoute -Destiantion 192.168.0.200 -Port 5062 -MatchUri "rcc.local"

Set-CsStaticRoutingConfiguration -Identity Global -route @{Add=$1}

And then to check if everything has been applied correctly Get-CsStaticRoutingConfiguration, notice that now under the Global Identity we have our Route applied.

===========================================================================================================================

Ok, so the routing part is over, the next thing to do is to authorize the CSTA GW on the Pool, this is the same as the Authorized Hosts part in OCS 2007 and OCS 2007 R2. There are two ways to do this, PowerShell or topology builder.

Since we started out with PowerShell let's continue with it.

My Gateway is 192.168.0.200, and as we discovered in the above we are connecting to it via TCP on Port 5062.

So in the above command we have created a Trusted Application pool called RCC connected to our LYNC Pool and the trusted Gateway is 192.168.0.200, also you have to give in the SITE ID, the default ID for the first site is 1 but you can get the site id by typing in the command Get-CsSite. https://technet.microsoft.com/en-us/library/gg398185.aspx

Don't worry about the fact that you have the command ComputerFQDN and you actually type in an IP, this is not a problem, you might get a warning saying this computer was not found in your AD but you can safely ignore it. As far as I can see this is only needed if you want your configuration replicated to this pool, as we actually have a RCC Gateway there is nothing to replicate.

We also gave in the options to TreatAsAuthenticated and to ThrottleAsServer, you might remember these options from OCS 2007 time.

Ok, so we are almost there, there is one more step additional to the ones from 2007 Time, and that is we must register a TrustedApplication on this TrustedApplicationPool. In order to do this we have to hed back to PowerShel

https://technet.microsoft.com/en-us/library/gg398259.aspx

New-CsTrustedApplication -ApplicationId RCC -TrustedApplicationPoolFQDN "192.168.0.200"-Port 5062 -EnableTcp

TheApplicationID can be anything so no need to worry about that, just name it something that defines the Application you are using, in our case we named it RCC.

TrustedApplicationPoolFQDN we will provide here the same IP or FQDN as we did for theTrustedApplicationPool in the step above, again don't mind the command name you are allowed to give in an IP.

We have a Port Option again, use the port you defined in the definition of the Static Routes and very important for TCP Applications EnableTcp, by default the TrustedApplication will use TLS.

So there you go run this command, you might get some warning regarding UCMA and TCP but you can ignore this for TCP based applications like RCC.

If you want to check out if the setting was recorded just use Get-CsTrustedApplication you should get something like

==================================================================================================================================

Now the good news, the PowerShell part is over, you may use PowerShell to enable the Users but I think it is easier with the GUI, so let's head to the Lync Control Panel.

In the Control Panel we go to Users, remember you need the user to be created in AD before you are able to enable him for LYNC.

I usually do it like this but you can chose another way, so on the User Menu, don't try to search for the user directly as you won't find him if he is not LYNC Enabled, you could use the LDAP Search if you want. What I do is I go to Enable Users, and then click Enable Users:

Here we go to Add and Search for the AD User, my users name is RCC User

Then just enable him for LYNC and assign him to the Pool you want.

On the same page if we scroll down are the Telephony options, here is where we need to configure our users Phone Number and RCC Gateway SIP Domain.

When you chose "Remote Call Control" under Telephony Options you also get a second drop down menu called "Line Server URI", this is the RCC Gateway Username and Domain part.

Notice the Line Uri matches the Phone Number Assigned to the RCC Gateway.

The Line Server URI has two parts, the user part, this should be configured on the Gateway and the domain part that this Gateway supports, this is the same as the one we configured on the Static Routes and TrustedApplicationPool and will be the part used to route the SIP Messages to the RCC Gateway.

You can then select all the Policy Settings needed for your domain.

Then just click Enable User in the top Part and we are almost done.

Now, we created a static route for your RCC Gateway, created a Trusted Application Pool and a Trusted Application and we enabled the user for RCC, all we need to do now is to log-on with the user on a LYNC Client and check out if it works J

So if your Lync Client looks like this, with no error in the bottom right part and you have the Call forwarding information on the left then you should be OK, and you should be able to make RCC Calls.

=====================================================================================================================================================================================

At the time this Blog was created no RCC Gateway Manufacturer had been certified for LYNC, this should happen soon and the results will be posted on our Microsoft Unified Communications Open Interoperability Program webpage https://technet.microsoft.com/en-us/office/ocs/bb735838. Check this out for news regarding supported RCC Gateways and IP PBX as well as IP Gateways for LYNC.

===============================================================================================================================================================

Happy New Year from the Microsoft Romania Office Communications Server / LYNC Team (Microsoft Romania GTSC) – Engineer IT your Way –

Exchange UM Play on Phone Tips and Tricks

AlexBacanel — Fri, 24 Dec 2010 04:15:00 GMT

Today I want to talk to you about an Exchange UM Feature that crosses the boundaries between Outlook, Exchange and Office Communications Server/Lync.

Play on Phone

What is it and what does it do?

Well it gives the end user the possibility to listen to his Voicemail from any phone, be it a Communicator a PBX Desk phone or even a Mobile Phone.

Unlike the Exchange UM Subscriber Access that pretty much does the same thing when accessed via phone, the Play on Phone feature initiates the call from Outlook or Outlook Web App , rings your phone and plays the specific message you selected.

It is very useful in case you are using a desk phone and don’t have a headset on your pc, and maybe don’t want to play the message from your Girlfriend or Wife on the PC Speaker for everybody to hear… so what do you do.

Click the Play on Phone button on the Voicemail you have in your Outlook Inbox and listen to the Voicemail on the Phone.

Now for all you Exchange UM Admins out there, setting up Play on Phone is pretty much straight forward but there are a few things to watch out for. Options that if configured wrong might cause some nail biting moments in front of your console.

Here are a few tips and tricks to a plesant Play on Phone experience.

There are a few scenarios possible out there using Exchange UM, with OCS/LYNC Integration or with PBX/Gateway integration. The main difference between the two is how UM will route the call, in the first scenario it will pass it on to the OCS/Lync Front End Server who in turn will send it to the Mediation Server and then to the Gateway/PBX and from there to your phone or the second scenario where the call is directly forwarded by Exchange UM to the Gateway/PBX and from there to your phone.

From Exchange UM Point of view the call is pretty much the same so for our article we will consider the simple scenario; Exchange UM directly connected to a Gateway/PBX

Note: The configuration is the same for Exchange UM 2007 and Exchange UM 2010 so no need to worry about that.

How Play on Phone Works

Ok let’s spend a few moments discussing the call flow when making a call via Play on Phone, this will help you when troubleshooting possible issues.

1. When the User clicks the Play on Phone Icon on his Voicemail form Outlook a RPC over HTTPS request is send to the Exchange CAS on the Unified Messaging Virtual Directory.

2. The CAS Server upon receiving the request from the client will query the users profile for the DialPlan assigned to it. The DialPlan is set in the Users Profile under msExchUMRecipientDialPlanLink.

3. After getting the DialPlan, the CAS Server need to do a second query to determine on what UM Server this DialPlan is set. It will query the DialPlan Object found in step 1 and look at the Attribute msExchUMServerDialPlanBL. msExchUMServerDialPlanBL will contain a list of all the UM Servers associated with the Dial Plan.

4. Additionally the CAS Server maintains a Cashed List of the Available UM Servers, the cashed list is updated every 5 minutes and if a UM Server goes offline it will be marked as such.

5. The CAS Server then forwards the request to the UM Server and the UM Server creates the SIP INVITE to the Gateway => Your Phone should ring J

Tip: Make sure you have selected Integrated Windows Authentication under the Unified Messaging Virtual Directory on the CAS Server, otherwise the request might fail or the user might get a authentication pop-up.

Tip: If you are using Exchange UM 2007 and have only few requests a day for the Play on Phone feature, this might happen in smaller companies; the IIS Application Pool under which Unified Messaging Virtual Directory is running under (MSExchangeUMAppPool) might go into a sort of sleep mode and stop listening to requests. There are two things that you can do here, implement a script to restart the App Pool every 24Hours or you may change the App Pool to MSExchangeServicesAppPool.

MSExchangeServicesAppPool is used by the EWS Virtual Directory and has more requests so it will never go into sleep.

Don’t need to worry about this in Exchange 2010, the App Pool for Unified Messaging Virtual Directory has been changed.

Trick: To check to what DialPlan a User is connected to you may use ADSIEDIT to check the user properties, look for an Attribute called msExchUMRecipientDialPlanLink.

You can do the same to check to what UM Server this DialPlan is connected to, look for the DialPlan in ADSIEDIT and under the DialPlan you will have an attribute called msExchUMServerDialPlanBL where the UM Servers are listed.

Configuration:

Now that we got the basic flow down let’s see how we make it all happen.

Well mostly Play on Phone relies on settings and features already present, only a few tweaks are necessary to ensure it actually works.

The Discovery Part is done using the Auto discovery Feature of Outlook that should already be set-up during Exchange Deployment, and the Virtual Directory Part is done when you actually Deploy Exchange UM.

For more information on Autodiscovery check out my previous post on “How to Integrate Office Communicator 2007 R2 32bit with Microsoft Outlook 2010 64bit Edition”

https://blogs.technet.com/b/roocs/archive/2010/09/23/how-to-integrate-office-communicator-2007-r2-32bit-with-microsoft-outlook-2010-64bit-edition.aspx

Server Side Configuration:

On the Server Side you need to make sure you have enabled the “Allow outgoing calls through this UM IP Gateway” on the Gateway object connected to your DialPlan. This will allow callers to make outgoing calls through this object, by default it is not selected and is a very common issue reported by Customers.

Then on the DialPlan connected to your user make sure you create “Dialing Rule Groups”, to allow callers to make outbound calls to specific number ranges.

(This example is of our test environment Gateway DialPlan, we are using an Audiocodes MS-114 Gateway, and I chose to let any internal Extension and any E164 Number through)

Also connected to every DialPlan you have at least one Policy, you might chose to use more policies in order to assign specific rights to users, this is the place where you can chose who gets to call an external number from the Play on Phone or just an internal PBX Extension number.

So go to the UM Mailbox Policy Tab and chose the Policy for the DialPlan you are configuring, by default there will be a Policy Called “DialPlanName Default Policy” in our case Audiocodes Default Policy.

On the main page you have more options for different UM Features, chose what you need but if you want Play on Phone make sure you select “Allow Play on Phone”.

On the Dialing Restrictions Tab you have the option to select the “Dialing Rule Groups” you previously configured on the DialPlan for this particular Policy, as you can see we have been generous and allowed the users to call any number but if you want to restrict international or national dialing, this is the place to do it.

Tip: The Dialing Rule Groups are number masks, it is a sort of number normalization if you want, for more information about UM Number Normalization check out Sorin’s post “Number normalization for inbound calls in Lync” https://blogs.technet.com/b/roocs/archive/2010/12/23/number-normalization-for-inbound-calls-in-lync.aspx

Well this should be most of the Configuration needed for the Play on Phone option on the Server Side only thing left is to set-up the client.

Client Side Configuration:

On Outlook, we are using Outlook 2007 for this example but Outlook 2010 is pretty much the same, there is not a whole lot of configuration needed. If you have auto discovery set-up correctly and authentication works then you should see the following:

Go to Tools and Options and go to the Voice Mail Tab

This is the first time you will see if you configured everything correctly, especially the authentication and discovery part.

Tip: If you get a message saying, “Could not Contact your Exchange Unified Messaging Server”when clicking the Voice Mail tab then check the Auto discovery and the Authentication on the IIS Server, most likely something is not right.

If you get the configuration window it means you configured everything correctly and it should work. So in this menu you have your Voicemail Options, Subscriber Access Number and a Play on Phone Number, now this is the default number the User has under his EUM Setting, it is the number you selected when enabling the user for UM. Don’t worry about it is populated by default but this does not mean it is the only number you can dial.

Tip: If you have Office Communications Server 2007 R2 or LYNC 2010 and the User has a SIPURI, the default Play on Phone number will be your SIP URI, ex: sip:ocsuser@>

So if we have this sorted let’s head for the Inbox and check out a Voicemail!

NOTE: Call the Number and leave a voicemail, in this way you will have an example to play with J

Here is our Voicemail from a PBX User, note that on the top of the Preview we have the button for Play on Phone. If we click this button we get a pop-up asking for a number do Dial, by default your EUM Number is Populated but as you can see you can change it and you also have a drop down menu to select previous dialed numbers.

Only thing left is to click Dial, if you get the error saying “Could not Contact your Exchange Unified Messaging Server” again check the Authentication and Autodiscovery stuff again and make sure that the Number you dialed complies with the Policy set-up in the previous steps. The number you enter has to match a Rule in the Dialing Rule Groups assigned to the Policy applied for your user. (This happened to me this morning when preparing for this post, I forgot to assign the Dialing Rule Groups to the Policy for my user and could not understand why it was not working ;) )

If you are lucky enough and you didn’t overlook some small setting or check box somewhere, always happens to me, your phone should ring and you should be able to hear your voicemail J

Well I hope this article helped you deploy Play on Phone or at least helped you out when troubleshooting an issue, I promise to come back next week with some information regarding fault tolerance and resiliency scenarios in Exchange UM but it is Christmas Eve here now and I Santa is waiting… I am hoping for a brand new Exchange UM this Year J

Merry Christmas and a Happy New Year from the Microsoft Romania Office Communications Server / LYNC Team (Microsoft Romania GTSC) – Engineer IT your Way –

Number normalization for inbound calls in Lync

Sorin Duta — Thu, 23 Dec 2010 03:33:00 GMT

Let's assume the following scenario: you have installed a Lync server and done the integration with Exchange UM. The Lync users have E.164 numbers in the format +403999XXXX, where XXXX is the user's extension. Exchange, however, only uses the extension.

Everything is working well in the Lync-UM integration, as the users are identified by their SIP URI, but you may notice one problem: if you configured an Auto Attendant on the UM server, you cannot use the AA to transfer the calls to Lync users.

The cause here is the following: the AA does not use the SIP URI when forwarding calls, so it will rely on the configured extensions. So, when placing a call, it will send an invite with something like sip:1234;phone-context=dialplan.fqdn. If the Lync server fails to normalize this, then the recipient will not be identified and the call will fail. You can see this in a SIP trace from the front-end server:

TL_INFO(TF_PROTOCOL) [1]24E8.158C::12/21/2010-15:30:10.465.0022e513 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(592))[3347992713]
>>>>>>>>>>>>Outgoing SipMessage c=[], 10.0.0.2:51388->10.0.0.2:5061
INVITE sip:1234;phone-context=user-default@contoso.com;user=phone SIP/2.0
FROM: ;epid=64F471FC5A;tag=128a9e7ef1
TO:
CSEQ: 30 INVITE
CALL-ID: 3dcad85d-c2d6-4180-b8e9-778301ad47cc
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 10.0.0.2:51388;branch=z9hG4bKf457f03e
CONTACT: ;isGateway
CONTENT-LENGTH: 2676
REFERRED-BY: ;ms-referee-uri="sip:39981235;phone-context=DefaultProfile@contoso.com;user=phone";ms-identity="MIIBJQYJKoZIhvcNAQcCoIIBFjCCARICAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHATGB8jCB7wIBATBNMD8xEjAQBgoJkiaJk/IsZAEZFgJncjEWMBQGCgmSJomT8ixkARkWBnNpZWJlbjERMA8GA1UEAxMIU2llYmVuQ0ECCh4beXEAAAAAA4UwCQYFKw4DAhoFADANBgkqhkiG9w0BAQEFAASBgC/Fp32BxFF6M7SYMM304neVA2C81mbnFh4toUCM74OcQH3IIoW/DKdoDcmwPk7spwVecw0x1grgtzstSP4bLhnIBVYA4uBca7b3ONkEebPEcaRsDRCJwrfRLjCry02Q4wq+y/qFRwWVOJHBuxPDlSoPkEFhFNg4PZsHeBU7SoLs:Tue, 21 Dec 2010 15:30:07 GMT";ms-identity-info="sip:exum.contoso.com:5065;transport=Tls";ms-identity-alg=rsa-sha1

TL_INFO(TF_PROTOCOL) [3]24E8.2548::12/21/2010-15:30:10.474.0022f2e0 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(686))[3347992713]
<<<<<<<<<<<], 10.0.0.2:51388<-10.0.0.2:5061
SIP/2.0 404 No matching rule has been found in the dial plan for the called number.
FROM: ;epid=64F471FC5A;tag=128a9e7ef1
TO: ;tag=C1856874B6392E5EFF84353526BD353C
CSEQ: 31 INVITE
CALL-ID: 3dcad85d-c2d6-4180-b8e9-778301ad47cc
VIA: SIP/2.0/TLS 10.0.0.2:51388;branch=z9hG4bKf457f03e;ms-received-port=51388;ms-received-cid=222900
CONTENT-LENGTH: 0
SERVER: TranslationService/4.0.0.0
ms-diagnostics: 14006;reason="Unable to find a potentially matching regex";source="Lync.contoso.com";CalledNumber="1234";ProfileName="DefaultProfile";appName="TranslationService"
------------EndOfIncoming SipMessage

There are two options to make this scenario work:

1. Normalize numbers on the Exchange server

2. Normalize numbers on the Lync server (this may also be useful if the calls to extensions are made by something other than an Exchange server).

Here's how:

1. For the Exchange normalization:

a) On the Exchange diaplan, open the dialplan properties. Go to the "Dialing Rule Groups" tab, and click Add (use the In-Country/Region Rule Groups, as this is done for local clients).

b) Name your rule as you see fit and add the following: Number mask = XXXX (use one X for each digit in the extension - in this example I have 4 digit extensions); Dialed number = XXXX (in this example, I used +403999XXXX).

c) Go to the Auto Attendant properties and open the Dialing restrictions tab. Add the previously created rule to the AA (you'll need to do this for all the AAs that dial Lync user extensions).

d) This is it. After this, Exchange will use E.164 numbers when forwarding calls. There are two things to note: 1) These rules will be applied to all the numbers dialed by the AA, and 2) they will not apply to the operator extension (the operator extension cannot be set with E.164, so that one will continue to fail).

2. Setting up normalization for inbound calls in Lync.

When a call comes in to the Lync server, it will try to normalize it using the General dialplan (it will identify it in the logs using the simple name "Default Profile"). In this case, the normalization is as easy as adding normalization rules to the General dialplan: you can do this either using the console (the process is described on Technet, so I'm not going to detail it here) or using the Powershell.

For Powershell, you need to run the following (in the simplest form):

New-CsVoiceNormalizationRule -Identity Global/MyNewRule -Pattern '^(\d{4})$' -Translation '+403999$1'

The pattern in this example takes strict 4-digit extensions and the translation prefixes these extensions with +403999. For a broader description of the normalization rules there is a great blog post from Mino - The UC Guy

Reverse Name Lookup failing between dialplans after migrating to Exchange UM 2010

Sorin Duta — Sat, 30 Oct 2010 10:55:00 GMT

Let's imagine the following scenario: You have an Exchange 2007 UM deployment with a couple of dialplans and just added a 2010 UM server in the domain.

You create a new dialplan on the new server and migrate a test user both to the new server and the new dialplan. This is a common scenario if you have OCS integration: for PBX integration, you would just add the new server to the existing dialplan and voilà, it works; for OCS, though, you need to have a new dialplan on the new server. Let's also suppose you are using extensions on your server and that you have disabled the heuristic AD search on the dialplans (AllowHeuristicADCallingLineIdResolution=$False). The server should still identify the callers based on their proxyAddresses or msRTCSIP-Line, right? (https://technet.microsoft.com/en-us/library/dd351203.aspx) Well, yes, but not quite, and this is why:

0. If your normalization works or the caller ID is E.164 compliant and if the msRTCSIP-Line attribute is correctly configured, then you're good to go.

1. If the caller is from the same dialplan as the callee, then no problem, he/she will be identified immediately: the server searches the AD for users with the attribute proxyAddresses set to "eum:;phone-context=".

2. If the caller is from another dialplan, then the key word in 2010 is "equivalent dial plan" - in Exchange 2010 the property "EquivalentDialplanPhoneContexts" is introduced. What this does is simply tell the server to append "phone-context=" (with each of the FQDNs specified in this list) to the caller's phone number when searching for the caller in the AD usign the proxyAddresses attribute. The catch here is that setting a single dialplan (e.g. your new Exchange 2010 dialplan) with this setting won't do anything - for the equivalence to work, two equivalent dialplans need to be paired by putting each of them in the other's EquivalentDialplanPhoneContexts list. For the 2007 server, this means upgrading the dialplan (to upgrade a dialplan simply perform a modification on it from an Exchange 2010 console or shell).

There are a couple of downsides in upgrading the dialplan, but depending on your environment they may not be a problem:

- Once upgraded, you can no longer edit the object from an Exchange 2007 console/management shell (you can only do it from Exchange 2010).

- All calls must be routed to the Exchange 2010 server, which will handle redirection if the user is still on a 2007 server. This should present no problem if the 2007 servers are at least SP2 and the calls comes from the PBX, but it will be a problem (will stop working) if the dialplan accepts calls from an OCS environment.

Regarding this last point, the behavior with the OCS dialplans is the following: when migrating from Exchange 2007 to 2010, you need to have two dialplans - one on the 2007 server and one on the 2010 server, with the calls to the 2007 users sent through the 2007 server and the calls to the 2010 users sent to the 2010 server. This is because the OCS server will not accept the redirection done by Exchange 2010, so upgrading the dialplan and routing the calls to the 2010 server is not an option in this scenario. As a consequence, the 2007 dialplan handling the calls from OCS will need to rely on the other RNL options (msRTCSIP-Line or heuristic search) and not on the proxyAddresses for resolving caller names from the other dialplans.

Sorin

How to Integrate Office Communicator 2007 R2 32bit with Microsoft Outlook 2010 64bit Edition

AlexBacanel — Thu, 23 Sep 2010 07:17:00 GMT

If you find yourself in the situation where you have Microsoft Outlook 2010 64bit Edition Installed together with Communicator 2007 R2 you will find that without the proper Exchange Configuration you will not have access to your Outlook Contacts and your Presence in Communicator will not be synchronized with your Calendar or OOF Events.

In a 1:1 installation, meaning Outlook and Communicator both, 32bit, Communicator relies on Outlook to get the Presence and OOF information as well as Local Contacts. It does this by connecting to the mapi.dll, but more on this in a later chapter.

Here is how to get Presence, OOF and Contact Information synchronized with your 32bit Communicator even if you have Outlook 64bit or no Outlook at all.

Firstly you will need to update Communicator to 3.5.6907.0083 (https://support.microsoft.com/KB/976135), you need to do this because an automatic mechanism was added to Communicator to enable it to fall-back on a direct Exchange Connection when it is unable to connect to Outlook.

*Note: You will still get the Outlook Integration Error but you can ignore it as you should have the functionality, the error message is meant to inform you that you are not connecting via Outlook.

In Communicator CU6 3.5.6907.0206 (https://support.microsoft.com/KB/2028888) the behavior was changed and the Error message does not appear anymore if you fall-back to an Exchange Connection.

Well after you have installed Communicator CU4 or CU6 all the work on the Communicator/OCS side is done; now we need to check your exchange CAS Server and the method you use for autodiscover.

The guys in the Exchange Team took a few moments to explain the workings of the autodiscover process… as it goes we have two options to get the autodiscover XML.

Outlook usually employs the SCP method and gets the CAS Server address buy LDAP Query, when you are in your corporate network. When you are outside the organization and a connection to the DC is not possible, Outlook will try to connect using the Exchange Web Services. In order to identify the Web Services it employs several look up methods, here is a KB Article describing the process in detail:

https://support.microsoft.com/kb/940881

Coming back to our Problem, Communicator will not be able to identify the SCP in AD so it will always employ the second method and it will use Exchange Web Services. So all you need to do to enable Communicator Integration with your Exchange Server is to create a SRV Record pointing to your Exchange CAS Server or create a DNS Host A record [autodiscover.] pointing to the same CAS Server or HLB.

Now we got the discovery method covered, the next step is to create a certificate and assign it to the IIS Server on the CAS. The certificate has to be created by a CA that your Local Client trusts, no SELF-SIGNED Certificates allowed hereJ.

Request a Certificate from the CA of choice, internally you could potentially get one from your internal CA, but if you are using OWA you will need to assign a Public Certificate for the Servers designated for external connections.

The Certificate will typically have a SN with the Server name and some SAN like mail.,apart from the usual SN and SAN, used by Exchange, you will need to add another SAN to this certificate with the fqdn autodiscover.

Assign this Certificate to your IIS, do an IISRESET if the services are started and you should be up and running.

Communicator should at this stage be able to resolve the autodiscover. and get the XML with the EWS URL that is used to get the Availability (AKA Free-Busy) and OOF information as well as Local Contacts stored in your Outlook Profile.

*NOTE: You will need to set your URL in Exchange to FQDNs that are accessible from any location in and outside your network in order to have overall coverage for your Communicator integration.

More Information on how to How to Configure Exchange Services for the Autodiscover Service can be found under https://technet.microsoft.com/en-us/library/bb201695(EXCHG.80).aspx

Hope you’ll have fun using this feature, I know I was very happy when I got it working J, also feel free to post comments on what subjects you would like us to blog about or thoughts on our blogs.

Alex B (Microsoft Lync Engineer)

Installation of Group Chat doesn't go beyond the database setup screen.

Sorin Duta — Mon, 23 Aug 2010 09:07:00 GMT

I thought I'd start with a bit of information about a problem I've seen during the OCS Group Chat installation. There aren't many problems that I've found, but the ones may appear can give someone a headache, so here goes:

When installing the Group Chat server, it's pretty much Next-Next-Next, except for the SQL database setup... You have to create the database check the database collation, add the service users, etc (detailed steps can be found here: https://technet.microsoft.com/en-us/library/dd441340(office.13).aspx).

And then you start the server deployment: choose the components, install the files, all of this goes well usually (unless you're missing some pre-requisites). In the second stage, of the setup, the server configuration starts: enter the SQL server name and instance, click Next and ... nothing happens.

Some generic logs which you can check if the GC installation fails:

If the installation fails before the server configuration screen (before you get asked for the SQL database URL/instance): MgcServer.log

If the installation fails after starting the server configuration: ServerConfigTool.log

In the latter, the messages may or may not be self explanatory. In this case, they are... not. What we see is the following (the part in < > is translated from French, so the English message may be slightly different):

ERROR |20100310-09:48:25.905| 1: | SctDataAccess.GetSchemaVersion | SQL Error while determining DB schema version, compliance=. Exception Microsoft.Rtc.Internal.Chat.Server.ServerCommon.Exceptions.DatabaseException: [121]

ServerConfigTool.exe Error: 0 : ERROR |20100310-09:48:25.909| 1: | Program.HandleThreadException | Caught unhandled thread exception:[121]

Microsoft.Rtc.Internal.Chat.Server.ServerCommon.Exceptions.DatabaseException: [121]

Of course, the object is not there yet, because the database hasn't been populated. However, the log doesn't complain about finding the server, so this is a pointer to the fact that it reaches the server, but can't modify it. Why? The general idea is that there may be something wrong in the commands sent to the server. Check the database collation first (needs to be SQL_Latin1_General_CP1_CI_AS).

In this case, the collation was OK, but one strange thing was that although the log was in English, the error messages were in French. Language compatibility problem? It could make sense, as I've already seen a couple of cases where the user's settings prompted the server to use comma (,) as a decimal separator, whereas in English we (they) use dot (.). You could change the entire server to EN-US, but in this case the solution was the following: the user doing the install, who also has an account on the SQL server, was set on the database as French, causing the misinterpretation of some of the installation/configuration program's commands. We went to this account's properties in SQL management studio and change the default language to US English. The rest of the install went smoothly. :)

To set the user language, go to the SQL Management Studio, on the GC instance. Under Security->Logins right click the user name and choose "Properties" (this will probably be in your local language, so you'll have to find the equivalent options). Under the General page, you have "Default Language" - set that to English.

To check/set the collation, in SQL Management Studio, again in the GC instance, expand Databases, right click the Group Chat database, and choose "Properties". Under the Options page you can change the collation (the collation is also visible under General, if you only want to check it).:

Sorin