Elan Shudnow's Blog

In Lync Server 2010 we can utilize Dial-In Conferencing Phone Numbers so both users utilizing the Lync Client End-Points can join these meetings using an IP Network and Telephony Users can join the same meeting via a Telephone utilizing the Public Switched Telephony Network (PSTN).

As you can see, we can define multiple Dial-In Conferencing Phone Numbers in the Lync Control Panel within the Conferencing Section.

Now before we understand how to reorder Dial-In Conferencing Numbers, we must first understand how different users can have different numbers get displayed when they create a Lync Online Meeting.  When we create a Dial-In Conferencing Number, one of the requirements is to set a Region.

Now in order to be able to add a Region, the Region must be created ahead of time.  And that is done through your Enterprise Voice Dial-Plans.  You need to do this even if you have not deployed Enterprise Voice.  By default, there is only one Dial Plan called Global.  So all users in the organization by default would fall under the Global Dial Plan.

If we go into this Global Dial Plan, we can set the name of our Dial-In Conferencing Region.   Now when we create a Dial-In Conferencing Number, “Chicago, Illinois USA” will be an option.

If you use only the Global Dial Plan, all users when creating an Online Meeting will see all Dial-In Conferencing Numbers that are associated with this Region.  In an environment where you have multiple Dial Plans (example would be USA, Germany, China), you can set the USA Dial Plan’s Dial-In Conferencing Region to USA, the Germany Dial-In Conferencing Region to Germany, and the China Dial-In Conferencing Region to China.  Users that are in the USA would then be assigned to the USA Dial Plan, users that are in the Germany Dial Plan would be assigned to the Germany Dial Plan, and users in China would be assigned to the China Region.

Now keep in mind, all three of our numbers have the “Chicago, Illinois USA” Region associated with them which is associated with the Global Dial Plan.  This means that when any user in the organization goes to create an Online Meeting, they will see the following in the Online Meeting template.

Now going back to our previous USA/Germany/China example, if a user was in the Germany Dial Plan which had a Region of Germany, you would assign the Germany Dial-In Conferencing Numbers to the Germany Dial Plan.  When they create an Online Meeting, only the Germany Dial-In Conferencing Numbers would be displayed.   However, if this user happens to travel to the USA and wants to invite USA people to a Lync Online Meeting button, that user has an option in Outlook called Meeting Options.

If they click Meeting Options, you can see that this Germany user would be able to choose the location that most users will dial in from.  The German User would be able to select a USA based Region and then all phone numbers in the Meeting Template would have all Dial-In Conferencing Numbers that are associated with that USA based Region.

But let’s say you don’t like the order in which the numbers are being displayed in the Meeting Template. You can easily change a specific Dial-In Conferencing Numbers Priority by utilizing the following command (Priority 0 would be this Dial-In Conferencing Number on Top of the Online Meeting Template in Outlook):

You can easily see what the SIP Addresses are of your existing Dial-In Conferencing Numbers by utilizing the following command:

Once you change the Priority Orders in which the numbers are displayed, keep in mind that the Dial-In Conferencing Number that has a Priority of 0 will also be displayed in the “Join Information and Meeting Options” link when joined into a meeting with the Lync 2010 client.  The Dial-in number displayed is always the Dial-In Conferencing Number that has the priority of 0.

Elan Shudnow :: Sep.28.2011 :: Lync 2010 :: 23784 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F09%2F28%2Freordering-lync-2010-dial-in-conferencing-numbers%2FReordering+Lync+2010+Dial-In+Conferencing+Numbers2011-09-29+02%3A59%3A17Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2378

General Information

When you’re first installing Lync Server 2010, there’s some confusion out there as to why you would or wouldn’t choose the option, “Deploy First Standard Edition Server” option.  Every Lync 2010 Server in your deployment will hold a copy of your Lync Server 2010′s topology configuration called the Central Management Store (CMS).  These copies are located in a SQL 2008 Express instance called rtclocal on each Lync Server 2010 Server.  A very good post on the CMS can be read here.  The purpose of this article is not to explain what the CMS is, but how you go about utilizing the setup process of Lync to deploy the CMS if your first pool is a Standard Edition Server or an Enterprise Pool.

To help understand the difference, I wanted to preface the remainder of my post with a couple images that were taken from Jen’s excellent CMS post which I linked to in the above paragraph.

This first image shows how the CMS database is placed in the first Enterprise Edition Pool.  With this setup, we can see we have two Front End Servers (FE1 and FE2) which are collocated within the same Enterprise Pool.  Each of these servers have SQL 2008 Express which contain the rtclocal instance that contains a copy of the Master CS on the BE SQL Server which would be a SQL Standard or SQL Enterprise. A key thing to note here, is that the SQL BE Server has only one instance called rtc.  From a CMS standpoint, this rtc instance contains the master xds database.  The xds database is the cms database.  This rtc instance also holds your other Lync databases: cpsdyn, lis, rgsconfig, rgsdyn, rtc, rtcdyn, rtcab, rtcab1, and rtcdyn.

al

This second image shows how the CMS database is placed in the first Standard Edition Server.  The key difference here, is we can see that on this first Standard Edition Server, we see two instances; rtclocal and rtc.  We can see, that because we do not have a dedicated BE server as we would in an Enterprise Edition Server, we collocate that dedicated rtc instance on the SE Server which will hold the same databases that the rtc instance would on the first Enterprise Edition Pool; the master xds database, cpsdyn, lis, rgsconfig, rgsdyn, rtc, rtcdyn, rtcab, rtcab1, and rtcdyn.  But this SE Server will also have the same rtclocal instance that Enterprise Edition FE Servers would have that would contain a copy of the xds instance.  Because of this, from a CMS standpoint, the first SE Server would contain two instances; one with the master xds and one with the replica xds.  Any subsequent Standard Edition Front End Servers (and any other Lync Server 2010 Server in the environment) would only have the rtclocal database holding a copy of the master xds as there can only be one Pool (Standard Edition Pool or Enterprise Edition Pool) that can hold the master CMS role.

It is possible, however, to move the CMS Master role to a new pool after the fact in case you deployed a Standard Edition Front End first such as a Pilot and then later deploy Enterprise Edition Pools such as when determining the pilot is a success and going full production. A very good blog article that explains this process can be read here.

Let’s take a look at how we accomplish the setup if our first Front End will be a Standard Edition and how it differentiates with an Enterprise Edition Front End.

Standard Edition Setup

Now when running setup.exe for Lync Server 2010, one of the deployment options you can see is “Prepare first Standard Edition Server.”

You will only want to run this option when you are deployment the first Lync Server 2010 Standard Edition Server in your deployment and you don’t already have any Lync Server 2010 Enterprise Edition Front End Servers.

What the Prepare first Standard Edition server does is simple.  It creates the rtc instance if it does not exist already and it creates the xds master database within the rtc instance.  This creates a Service Connection Point (SCP) record in Active Directory that allows any future deployment options to know how to locate the CMS information.  Taken from Jen’s blog article, “The SCP is an object in Active Directory created under the path of the following Distinguish Name (DN), CN=Topology Settings, CN=RTC Service,DC=<domain>, of type msRTCSIP-GlobalTopologySetting. This object contains the msRTCSIP-BackEndServer attribute, which specifies the FQDN of the master and the instance name of the SQL Instance. All tools use the SCP to locate and connect to the CMS master.”

If you ever wondered how the Topology Builder automatically knows how to find and download Topology Information, the Topology Builder queries this SCP record, uses the msRTCSIP-BackEndServer attribute, contacts the FQDN of the master, and downloads the topology information.

Now because the rtc instance has been created with the xds database, when you go to run the actual install, you will see “Install Local Configuration Store” which will install the rtclocal instance which contain a copy of the master xds database.  The regular databases will still be installed in the rtc instance.

Enterprise Edition Setup (Read the Standard Edition section first to fully understand this section)

Now when deploying the first pool in your Lync Server 2010 deployment happens to be an Enterprise Edition Pool, you won’t bother with the “Prepare first Standard Edition server” option. When taking a look at the first Standard Edition Front End, you can see we needed to create the rtc instance first with the master xds.  The same thing happens with the Enterprise Edition but in a different fashion.  Because this is an Enterprise Edition Pool, you will be using a SQL Standard or SQL Enterprise.  During the Topology Builder process, you need to define your SQL Server unlike a Standard Edition Deployment.  When publishing your Enterprise Edition Pool, at that time your rtc instance is being created on your SQL Server as well as the xds database.  Just like with the Standard Edition deployment, the SCP record in AD is getting created.

Now when running the Setup below and choosing “Install Local Configuration Store,” the Setup Process is creating the rtclocal instance (SQL  2008 Express) local to that Enterprise Edition Front End Server and then goes out to the master xds database that is on the SQL Standard or SQL Enterprise Server, and then creates a copy of that xds database on the Enterprise Edition Front End Server.

Elan Shudnow :: Jun.16.2011 :: Lync 2010 :: 221133 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F06%2F16%2Flync-2010-deploy-first-standard-edition-server-option%2FLync+2010+-+Deploy+First+Standard+Edition+Server+Option%3F2011-06-16+14%3A08%3A33Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2211

During the installation of a Lync Server 2010 Monitoring Server, one of the provided steps is to deploy your Lync Server 2010 Monitoring Server Reports to a SQL Server Reporting Services URL.  Afterwards, you can specify a Read-Only Group that you want to grant read-only access to the Monitoring reports.  This Read-Only Group is an optional step if you are the only administrator who will have access to view these reports.

The problem is, what if down the road, you decide that you now have a team that you want to be able to view these reports.  The OCS 2007 R2 Monitoring Reports had an option to grant users access to view the reports.  The Lync Server 2010 Monitoring Reports no longer has this option.  The provided  Lync documentation does not provide you guidance other than, “You can also configure the read-only group directly in SQL Server Reporting Services” which really isn’t much of a help.  Typically, your SQL guys can take care of this after the fact.  But, I was a bit curious (I’m not a SQL expert but I know my way around a bit) so I decided to figure this out on my own.

So let’s have a look, shall we?  Go ahead and open up Reporting Services Configuration Manager.

The part we are interested in is the Report Manager URL.  The Web Services URL will show you the URL you specify in the Lync Installation Wizard when deploying your Monitoring Server Reports.

When selecting Report Manager URL, you’ll see the URL on the right side of the screen.

Go a head and click on that URL you see in the Figure above.  You’ll now see the following screen.

Go ahead and click on LyncServerReports.  You’ll now see the following screen.

Go ahead and click on Properties you see in the above Figure.  Just make sure you’re in the context of LyncServerReports.  You’ll now see the following screen.

Click on Security which will provide you with the following screen.

Now, before I add anything here, let’s make sure that I am refused Access when I try to login to the Monitoring Server Reports with a specific account.

So now, let’s get back to SQL Reporting Services.  Go ahead and click on New Role Assignment.  Go ahead and Assign a Group Name and choose Browser. Keep in mind that this group will have be pre-created before SQL Reporting Services will accept the input.  Once done, choose Ok.

You’ll now see the group has successfully been added.

On my client that I previously tried to connect with but got Access Denied, I give it another shot and go to the following URL:

http://SQLServer/ReportServer_REPORTING?%2fLyncServerReports&rs:Command=ListChildren

I get right in!  Success!

Elan Shudnow :: May.06.2011 :: Lync 2010 :: 22627 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F05%2F06%2Flync-server-2010-monitoring-server-reports-read-only-group%2FLync+Server+2010+Monitoring+Server+Reports+Read-Only+Group2011-05-06+16%3A07%3A14Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2262

The Issue and the Troubleshooting that Ensued

I recently encountered the following issue when a remote user were to try to upload a PowerPoint Presentation while internal users had no problems.

Immediately, I thought that this was an issue with the reverse proxy.  For those that don’t know what the role of a reverse proxy server is in Lync Server 2010, the Reverse Proxy handles the following traffic for remote users:

• Enabling external users to download meeting content for your meetings.
• Enabling external users to expand distribution groups.
• Enabling remote users to download files from the Address Book service.
• Accessing the Microsoft Lync Web App client.
• Accessing the Dial-in Conferencing Settings webpage.
• Accessing the Location Information Service.
• Enabling external devices to connect to Device Update web service and obtain updates.

As we can see in red above, the Reverse Proxy is used for meeting content externally.  I did two things to troubleshoot whether it was the client hitting the reverse proxy and having it not function correctly.  The first thing was that I loaded up Network Monitor on my client.  What I saw is, when I would add a new distribution list to my contact list which is a function of the reverse proxy, I properly saw in the trace the client make a request out to the public IP of our Reverse Proxy Server.  Because of this, I knew the Reverse Proxy was functioning just fine, especially since I could also access our Simple URLs (dialin.domain.com and meet.domain.com from the outside).  But when I tried uploading a PowerPoint Presentation in an Online Meeting, I never saw a call go out to the Reverse Proxy.

So I went onto our Reverse Proxy Server which is Microsoft Forefront Threat Management Gateway (TMG).  I wanted to see anything that came into it with my Client IP Address.  I went to the Logs & Reports and modified the filter

Once at the bottom of the dialog, choose Filter By IP and set the Value to your Public IP Address.  You can easily obtain your Public IP on your client machine by going to www.whatismyip.com.  Once done, choose Update.  Your filter will now look as such:

Once ready to start logging, choose the Start Query Option.

When I started the Query, I saw absolutely no traffic for Web Conferencing PowerPoint Presentations at all. This verified the client was really not even getting to the point of trying to communicate with the Reverse Proxy, especially since the Network Monitor logs didn’t even see the request try to go out.

At this point, I was at a bit of a loss and went back to basic troubleshooting more and sometimes, we often overlook the basics. I tried the other Web Conferencing functionality on the client.  What I noticed is, I got the same exact errors even when trying to utilize polling or whiteboarding.  Bingo.  It’s a Web Conferencing Edge problem, not something with the client to the Reverse Proxy.

I looked at our Web Conferencing Edge and noticed two errors (neither of which you will find any information online about them… I guess I am the lucky one):

First Event Log Entry (more common)

Log Name:      Lync Server
Source:        LS Web Conferencing Edge Server
Date:          5/4/2011 5:42:28 PM
Event ID:      41990
Task Category: (1023)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      lyncedge.domain.com
Description:
Failed to verify client cookie

Over the past 44 minutes Lync Server has failed to validate cookie presented by the clients 5 time(s). The last such client which failed validation was “22.33.44.55:50307″.
Cause: This can occur if the Web Conferencing Server and Web Conferencing Edge Server machine time(s) are out of sync. This can also be the result of a client attempting to connect to Web Conferencing Server without having the appropriate permissions.
Resolution:
Check to make sure that the Web Conferencing Server and Web Conferencing Edge Server machines and verify that the connection came from a trustworthy client. This could indicate an attack being by a rogue client.
Event Xml:
<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event”>
<System>
<Provider Name=”LS Web Conferencing Edge Server” />
<EventID Qualifiers=”50175″>41990</EventID>
<Level>2</Level>
<Task>1023</Task>
<Keywords>0×80000000000000</Keywords>
<TimeCreated SystemTime=”2011-05-04T22:42:28.000000000Z” />
<EventRecordID>20548</EventRecordID>
<Channel>Lync Server</Channel>
<Computer>lyncedge.domain.com</Computer>
<Security />
</System>
<EventData>
<Data>44</Data>
<Data>5</Data>
<Data>22.33.44.55:50307</Data>
</EventData>
</Event>

Second Event Log Entry

Log Name:      Lync Server
Source:        LS Web Conferencing Edge Server
Date:          5/4/2011 5:11:03 PM
Event ID:      41993
Task Category: (1023)
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      lyncedge.domain.com
Description:
Failed to process data received from the client

Over the past 599 minutes Lync Server has disconnected clients 1 time(s) as a result of invalid data being received on client connections. The last such client which was disconnected is “22.33.44.55:46361″.
Cause: Failed to process data received from the client
Resolution:
Check and make sure that the connection came from a trustworthy client.
Event Xml:
<Event xmlns=”http://schemas.microsoft.com/win/2004/08/events/event”>
<System>
<Provider Name=”LS Web Conferencing Edge Server” />
<EventID Qualifiers=”50175″>41993</EventID>
<Level>2</Level>
<Task>1023</Task>
<Keywords>0×80000000000000</Keywords>
<TimeCreated SystemTime=”2011-05-04T22:11:03.000000000Z” />
<EventRecordID>20543</EventRecordID>
<Channel>Lync Server</Channel>
<Computer>lyncedge.domain.com</Computer>
<Security />
</System>
<EventData>
<Data>599</Data>
<Data>1</Data>
<Data>22.33.44.55:46361</Data>
</EventData>
</Event>

The Fix

Simple. I tried restarting the Web Conferencing Edge Service but had the same issue.  I then restarted the Web Conferencing Service on the Front End.  The issue was resolved.  It’s apparently an issue where the Web Conferencing Edge Service had problems talking to the Web Conferencing Service on the Front End for client persistence and the services just needed to be restarted.

Elan Shudnow :: May.05.2011 :: Lync 2010 :: 22566 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F05%2F05%2Flync-server-2010-cannot-connect-to-sharing-server%2FLync+Server+2010+-+Cannot+Connect+to+Sharing+Server2011-05-05+14%3A05%3A11Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2256

I recently had a project where all DHCP Servers were Cisco switches.  During the configuration, we noticed that a certain DHCP Configuration worked on certain Cisco switches but not the rest but a configuration was found that worked on all switches.  More on the specifics in the VLAN section below.  In this article, I will show you how to figure out how to configure the 120 and 43 options on a Cisco switch as well as how to configure the VLAN ID using the two different methods mentioned above. Thanks to Dave Howe from Microsoft for helping out with the PIN Authentication Settings for Cisco DHCP.

PIN Authentication Settings

STEP 1

Run DHCPUtil.exe to find out hex data values for DHCP Options 120 and 43

C:\Program Files\Microsoft Lync Server 2010\> DHCPUtil.exe -sipserver  pool01.contoso.com

Sip Server FQDN:  pool01.contoso.com

Certificate Provisioning Service URL:  https://pool01.contoso.com:443/CertProv/CertProvisioningService.svc

Option 120: 00076578616D706C6503636F6D00

Vendor Class Identifier: MS-UC-Client

Option 43 (for vendor=MS-UC-Client):

Sub-Option 1 <UC Identifier>: 4D532D55432D436C69656E74

Sub-Option 2 <URL Scheme>: 6874747073

Sub-Option 3 <Web Server FQDN>: 6578616D706C652E636F6D

Sub-Option 4 <Port>: 343433

Sub-Option 5 <Relative Path for Cert Prov>: 2F4365727450726F762F4365727450726F7669736

96F6E696E67536572766963652E737663

STEP 2

Build DHCP Option 120 hex value for Cisco DHCP using DHCPUtil.exe output info

Option 120 = hex 00076578616D706C6503636F6D00

STEP 3

Build DHCP Option 43 hex value for Cisco DHCP using DHCPUtil.exe output info

Note:  Format of DHCP Option 43 hex value:

1. Compile Sub-Option 1 from DHCPUtil.exe output:

Length of data is hex value for (number of characters of Data) divided by 2 ( # of chars / 2 )

2. Compile Sub-Option 2 from DHCPUtil.exe output:

Sub-Option2
02	Length of data	Data
02	05	6874747073

3. Compile Sub-Option 3 from DHCPUtil.exe output:

Sub-Option3
03	Length of data	Data
03	0B	6578616D706C652E636F6D

4. Compile Sub-Option 4 from DHCPUtil.exe output:

Sub-Option4
04	Length of data	Data
04	03	343433

5. Compile Sub-Option 5 from DHCPUtil.exe output:

Sub-Option5
05	Length	Data
05	25	2F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663

STEP 4

Combine the five Sub-Option values to build the DHCP Option 43 hex value for Cisco DHCP:

Compiled DHCP Option 43:

VLAN ID Settings with PIN Authentication Settings

There are a few ways to make this work:

• Link Layer Discovery Protocol (LLDP)
• Two different ways to make it work on DHCP.  DHCP is what this article will cover.

Now let’s say we have two VLAN IDs: 208 (Data) and 209 (Voice) on the same ports.  The idea here is swap the phone from the Data VLAN to the Voice VLAN. As stated earlier, we found two methods in configuring the VLAN ID Settings.  The first I will show is how it worked on a switch that supported LLDP – Catalyst 4507R – SUP-IV IOS version (cat4500-ENTSERVICESK9-M), Version 12.2(54)SGI.  The second is how it worked on the switch that was not LLDP Capable – Catalyst 6513 SUP720 (S72033_rp-PK9SV-M), Version 12.2(18)SXD7 – or higher.  Thanks to my client for enduring the painful process of figuring out the below and providing me with information and explanations on what he did to get the Cisco DHCP configured for VLAN ID as well as the switch information provided which you can see in the first two comments in this article.

LLDP Switch Data Scope (Comments in Red)

ip dhcp pool Data14_Lync (VLAN 208)

option 10 hex 00d0 (Decimal 209)

option 60 ascii “CPE-OCPHONE”

LLDP Switch Voice Scope (Comments in Red)

ip dhcp pool Voice14_Lync (VLAN 209)

option 10 hex 00d0 (Decimal 209)

option 60 ascii “CPE-OCPHONE”

option 43 hex 010C4D532D55432D436C69656E7402056874747073030B6578616D706C652E636F6D040334343305252F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663

option 120 hex 00076578616D706C6503636F6D00

Non-LLDP Switch Data Scope (Comments in Red)

When we noticed the LLDP Switch Scope configuration wouldn’t work on a non-LLDP Switch, we tried running this on Windows DHCP.  My client sniffed the traffic and found that Windows DHCP had some 43 option information passed back to the client for the VLAN ID information.  So what we did in option 43 is specify an option 10 sub-option.  The oa is the sub option. The 02 is the length of the data field divided by 2.  The 00d1 is the hex value of the data vlan.

ip dhcp pool Data14_Lync

option 43 hex 0a0200d1

Non-LLDP Switch Voice Scope

ip dhcp pool Voice14_Lync

option 120 hex 00076578616D706C6503636F6D00

option 43 010C4D532D55432D436C69656E7402056874747073030B6578616D706C652E636F6D040334343305252F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663

Elan Shudnow :: May.02.2011 :: Lync 2010 :: 222213 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F05%2F02%2Fconfiguring-lync-dhcp-using-cisco-dhcp-servers-vlan-and-pin-auth%2FConfiguring+Lync+DHCP+using+Cisco+DHCP+Servers+%28VLAN+and+PIN+Auth%292011-05-03+01%3A11%3A03Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2222

General Information

With Lync 2010, there are a couple ways to handle non-DID users.  Our company uses both Lync 2010 for Enterprise Voice as well as Nortel CS1000 for other users.  Our Nortel CS1000 is configured so when you send it  improperly formatted Caller ID, it will send it out to the PSTN with the main DID number of our officelocation.  In Lync 2010, you can have users that are Enterprise Voice enabled but do not have a DID.  That are some disadvantages to not having a TEL URI such as the inability to set a Conferencing PIN when logging into your Dial-In Conferencing Web Page.

An important thing to understand is when a user is dialing out to the PSTN Gateway Object in Lync 2010, there is a SIP Invite Message that gets sent out to the Gateway.  The SIP Invite Message will be constructed differently depending on whether a user has a DID specified in the TEL URI or whether that TEL URI is blank.  Let’s take a look at how both messages are constructed.

SIP Invite Messages

User with DID:

INVITE sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone SIP/2.0
FROM: “Shudnow, Elan”<sip:+13129998888@collocatedFEMediation.internalAD.domain.com;user=phone>;epid=AA4B5C1773;tag=d73f8df627
TO: <sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone>

User without DID:

INVITE sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone SIP/2.0
FROM: “Test, Elan”<sip:etest@internalAD.domain.com>;epid=AA4B5C1773;tag=d17641157b
TO: <sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone>

As can be seen, the big change between the user with the DID and without the DID is that the FROM field for a DID user displays the user’s E.164 formatted DID that is defined in the TEL URI whereas the user without the DID has their SIP Address defined instead of a DID.  This means that, even if a user does not have a DID defined in the TEL URI but is still enabled for Enterprise Voice, their phone call requests will still go out to the gateway.

What to do?

Well, in Lync 2010, there are two options:

1. Configure our gateway to handle the user’s that have their Caller ID (Calling ID) in the form of a SIP Address instead of a telephone number and send it out to the PBX.  As stated earlier, our PBX will see this and change it to the main office DID. This solution requires you to configure your PBX to do this as well as your gateway to take the SIP Address into consideration from a Caller ID (Calling ID) perspective.
2. Configure a new Voice Policy, Phone Usages, and Voice Routes that utilize the new Supress Caller ID feature to rewrite Caller ID for any user that is utilizing those routes.  Hence the need for new routes that have new phone usages assigned to the as well as a new voice policy that uses those phone usages.  You will then take this new voice policy and assign it to all non-did users.

For each option, there are some pros and cons.  As has been stated, Option #1 requires configuration on the PBX and the Gateway.  Option #2 has more configuration required on Lync itself and if you ever assign a non-DID user a DID, this user would need to be moved to the Lync Voice Policy that does not supress Caller ID.

Option #1 Configuration (Modify PBX/Gateway)

I will show how to configure the Voice Gateway (in this case, a NET UX2000 gateway) but not the PBX.

When taking a look at the Translation rules on our NET UX, you can see how we are handling E.164 calls coming in from Lync and sending it off to our Nortel.  We have a Called Address/Number (how the TO: field is specified in the SIP Invite from Lync) and a Calling Address/Number (how the FROM: field is specified in the SIP Invite from Lync).  In our translation rule, Lync is sending the TO: in E.164 format so the NET takes anything with the + and 11 digits, strips the +, and sends just the 11 digits to our Nortel. For the Calling Address Number, we take anything that has + as the starting digit, and sends the Caller ID information to our Nortel without the +.  Because of this, the Nortel will retain the original Caller ID and all is well.

But, what about non-DID users?  How can we configure our UX2000 to translate anything with Caller ID as a SIP Address and pass it off unchanged to the Nortel so it can rewrite it with the main office’s DID?  Well, it’s easy.  We just have to create an entirely new Translation rule since we can’t have more than one Calling * specified in a given Translation Rule.

As we can see in our new Translation Rule, we didn’t modify the Called Address/Number.  This stays the same because the TO: field doesn’t change between a DID and a non-DID user as can be seen above in the SIP Invite Messages section.  What does change between the DID and Non-DID user is the FROM: field.  Because of this, we need to change the Calling field.  In this Translation Rule, instead of choosing Calling Address/Number, we change the gateway to utilize Calling Numbering Type.  We choose H.323 ID or SIP as the Input Field Value.  For the Output to Nortel, we still specify Calling Numbering Type and choose the value as Unknown.  Now anything the gateway has a FROM: field specified as a SIP Address instead of a DID formatted in E.164, it’ll send it off as is to the Nortel which will then change the Caller ID to the office’s main DID number.

Option #2 Configuration (Lync Caller ID Supression)

What if Option #1 won’t work for you?  Your gateway guy doesn’t want to do it, your PBX guy doesn’t want to do it, your PBX can’t do it, etc…  Well, Lync 2010, again, provides a new option which previously didn’t exist in Office Communications Server 2007 or Office Communications Server 2007 R2.

In order to do to do this, we will need to create 3 new things:

1. Lync Voice Policy
2. Lync Phone Usages
3. Lync Voice Routes

By itself, Phone Usages don’t do anything.  They are only the secret sauce that links a Voice Policy to a Route.  If we take a look at our Lync Route, we can see the new option for Supressing Caller ID with a specific phone number. In this case, let’s assume +13125556666 is our main office DID.

In the above screenshot, we can also see that we have an Associated PSTN usage record of Non-DID.  We also have a Voice Policy assigned called Non-DID users.  For our DID users, they will be in a different Voice Policy that utilizes a Voice Route that does not have Supress Caller ID enabled.

If you decide to use this configuration, any non-DID users will have their FROM: field modified to +13125556666 once they are moved into the Non-DID Users Voice Policy.  Their SIP Invite message will now look this:

INVITE sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone SIP/2.0
FROM: “Test, Elan”<sip:+13125556666@collocatedFEMediation.internalAD.domain.com;user=phone>;epid=AA4B5C1773;tag=d57257363e
TO: <sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone>

So with Option #2, we will end up with the following:

DID Users

• DID Voice Policy
• DID Phone Usage assigned to DID Voice Policy
• DID Phone Usage assigned to DID Voice Route with no Caller ID Suppression linking the DID Users to the DID Voice Routes

Non-DID Users

• Non-DID Voice Policy
• Non-DID Phone Usage assigned to the Non-DID Voice Policy
• Non-DID Phone Usage assigned to the DID Voice Route with Caller ID Suppression linking the Non-DID Users tot he Non-DID Voice Routes

For more information on Phone Usages and Voice Policies, see this excellent article written by Ken Lasko here.

Elan Shudnow :: Mar.03.2011 :: Lync 2010 :: 21642 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F03%2F03%2Flync-2010-enterprise-voice-did-vs-non-did-users%2FLync+2010+Enterprise+Voice+DID+vs+Non-DID+Users2011-03-04+03%3A27%3A38Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2164

One of the new features in Lync 2010 is the ability to provide Lync clients enhanced privacy controls.  What this provides is the ability for Lync users to restrict their presence to users who are in their contact list.  By default, this feature is not enabled.  You may think to yourself, why?  Well, it’s because OCS 2007 R2 users can connect to Lync Server 2010 if the Client Policies allow for it.  Communicator 2007 R2 does not provide the capability to set these enhanced privacy controls.  It is because of this, you will want to make sure all users are utilizing Lync 2010 in the organization prior to enabling Enhanced Privacy Controls.  If for whatever reason, you have enabled enhanced privacy controls for a user, and they happen to downgrade to Communicator 2007 R2, these privacy settings are lost which is why it is important to restrict the ability for Communicator 2007 R2 users to be able to connect to Lync Server 2010.

To check what the current configuration is set at, we can run the following command:

We can see the EnablePrivacyMode is configured to False.

In the Lync 2010 client options, we see there are no options to prevent anybody from seeing our presence if they are not on our contact list.

But let’s say our Client Policies are preventing Communicator 2007 R2 clients from connecting.  We can set Privacy Mode to true.  Keep in mind, in order for Response Group Agents to receive Response Group calls, they will need to add their Response Group Agents to their contact list.  The Response Group workflow creation process creates a Response Group contact object in Active Directory.  Because of this, there is nothing special you have to do.  It will be as simple as utilizing the search feature in Lync 2010 just like you were trying to find any other user, and adding the Response Group user/contact to the Response Group agent’s contact list.

Now to enable Enhanced Privacy mode, we run the following command:

Because Lync 2010 clients retrieve this mode through in-band provisioning, it will be necessary for Lync 2010 clients to log off and log back in.

Once users have logged back in, we can go back to the Lync 2010 options, go to status, and we see some new options.

We can now see the options look different.  By default, only people in the user’s contact list will be able to see their presence.

To illustrate what this looks like, I have two users:

• Elan Shudnow
• Elan Test

On the Elan Test account, I have Elan Shudnow added to the contact list.  But Elan Shudnow is showing up as Offline.  In fact, Elan Shudnow is actually set to Available.  Elan Shudnow just doesn’t have Elan Test as a contact.

I will now go ahead and add Elan Test as a contact to the Elan Shudnow account. Once doing so, I immediately see Elan Shudnow’s presence go to Available without doing a single thing on the Elan Test account.

Elan Shudnow :: Feb.07.2011 :: Lync 2010 :: 214216 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F02%2F07%2Flync-2010-enhanced-privacy-controls%2FLync+2010+Enhanced+Privacy+Controls2011-02-07+14%3A15%3A48Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2142