Elan Shudnow's Blog

General Information

There’s two ways to migrate to Exchange 2010 UM:

• Full Upgrade
• Partial Upgrade

In a Full Upgrade scenario, you are doing a big bang migration for your Exchange 2007 UM users and moving them all to Exchange 2010 UM at the same time.  At the same time, you are replacing your Exchange 2007 UM Servers within your UM Dial Plan with Exchange 2010 UM Servers.

In a Partial Upgrade, you are going to  have Exchange 2007 UM Servers and Exchange 2010 UM Servers coexist within the same Dial Plan.

It is important to note how the call flows work in a Partial Upgrade Path.  You can see this documented very well here. In order for the Partial Upgrade process to work, the documentation clearly states, “When you install the first Exchange 2010 UM server and add it to an existing Exchange 2007 organization, you must add the Exchange 2010 UM server to an existing UM dial plan that contains Exchange 2007 UM servers. Then you must configure each IP gateway or IP PBX to send all incoming calls to the Exchange 2010 UM servers within the same UM dial plan.”

The key part to note is that you must configure each IP Gateway object that is in the Dial Plan to now send ONLY to Exchange 2010.  The problem with the article, is that it does state this clearly and does show example of call flows, but what isn’t really explained is what exactly is happening on the Back-End.  And that, is what I am here to explain.

The basic jist of it, is that Exchange 2010 will redirect the IP Gateway to Exchange 2007 where necessary.  But let’s say you have a PBX connected to a gateway which is connected to UM.  Exchange 2010 UM will always redirect the gateway for an Exchange 2007 user and the gateway will connect directly to Exchange 2007 UM.  The gateway never has to relay any information back to the PBX in this case so there are no considerations you have to make for the PBX here.  The only consideration you should make is to make sure that the gateway has been certified against Exchange 2010 UM before you decide to do your partial upgrade.  The certified gateway/IP-PBX for Exchange 2007 is here and the certified list for Exchange 2010 is located here.

With that said, the redirects from Exchange 2010 to Exchange 2007 work a couple different ways depending on the circumstances.  Thanks to Chun from Microsoft for providing me with these details that were documented in great detail.

There are two broad categories on how the redirection happens:

• Before UM 2010 accepts the invite, it knows the call is for an UM 2007 user (e.g., diversion exists and UM can tell that the call is for a 2007 user). In this case, we simply use 302 redirect.
• UM 2010 needs to accept the invite before it knows the call is for an UM 2007 user. E.g., someone calls into the subscriber access from a phone that we cannot resolve to a user. UM needs to answer the call first, and wait for the user to punch in the mailbox extension. In this case, UM will send a REFER to the gateway to cause the gateway to send a new INVITE to the same UM 2010 server. But in the REFER header, we stick in a couple of information which shows up in the new INVITE. The UM 2010 server sees this information, realizes it is for a 2007 user, and redirects the call to UM 2007.

Example

Now let’s take a look at a real life migration example from a procedural standpoint.  Let’s start off with not having Exchange 2010 yet.  We have our IP-PBX which is sending data to an IP Gateway which is then sending data to Exchange 2007.

We then build our Exchange 2010 Server, install Exchange 2010 UM Role on it, and we then add it to our Dial Plan which will then consist of both Exchange 2007 and Exchange 2010 UM.  Keep in mind, when using OCS as the IP-PBX, you must be on at least OCS 2007 R2 CU5 and Exchange 2010 SP1 to be able to allow Exchange 2010 UM SP1 and Exchange 2007 to be in the same Dial Plan.  The reason for this is Exchange 2010 SP1 introduces capabilities that allow OCS 2007 R2 CU5+ and/or Lync to be able to do a user lookup, determine if they’re on Exchange 2010 or Exchange 2007 and route to the appropriate Exchange Version (2007 or 2010) regardless if they’re in the same Dial Plan.

As can be seen above, we now have Exchange 2010 and Exchange 2007 in the same Dial Plan.  We have also started routing all traffic to Exchange 2010.  If the call is for an Exchange 2007  User, Exchange 2010 will redirect the IP Gateway to start talking to Exchange 2007 to service those Exchange 2007 users.

Elan Shudnow :: Jun.12.2011 :: Exchange 2010 :: 22729 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F06%2F12%2Fexchange-2007-um-to-exchange-2010-um-partial-upgrades-and-redirects%2FExchange+2007+UM+to+Exchange+2010+UM+Partial+Upgrades+and+Redirects2011-06-12+14%3A43%3A03Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2272

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 :: 22626 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 :: 214212 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

General Information

I just migrated a OCS 2007 R2 Edge on Windows Server 2008 last night to Lync Edge 2010 Edge on Windows 2008 R2.  All I can say is, it was a less than pleasant experience if you’re doing federation.  This is not a native Lync problem per se, but is more due to Windows 2008 R2; of course, this depends on your Outlook.

The migration process to migrate an OCS 2007 R1 Edge to Lync 2010 Edge is documented at the following URL:

http://technet.microsoft.com/en-us/library/gg425785.aspx

The migration process to migrate an OCS 2007 R2 Edge to Lync 2010 Edge is documented at the following URL:

http://technet.microsoft.com/en-us/library/gg398413.aspx

Note: The migration steps are in different locations.  The R2 migration documentation has you migrating federation and Media at the same time as an R2 Edge can do media for a Lync Pool.  The R1 migration documentation has you configuring Lync to use Lync Edge for Media while R1 Pool uses R1 Edge as an R1 Edge cannot do media for a Lync Pool.  Then, at a later time after all pools have been migrated, you cut over federation.

The Issue

The general issue is that Windows 2008 R2 has much fewer root certificates installed than does a Windows 2008 or previous operating system version.  In fact, Windows 2003 even has many more root certificates than Windows 2008. This doesn’t seem like a good trend going forward. Let’s take a look at a comparison between Windows 2003, Windows 2008, and Windows 2008 R2:

Windows 2003

Windows 2008

Windows 2008 R2

You can see, the amount of root certs has gone down drastically.  Now the problem is that when doing federated communication from our Lync 2010 Edge Server to other partners, the communication will occur using TLS.  This means the federated partner needs to contain the root certificate for our external edge certs and our Lync Edge needs to contain the root certificate for our federated partner’s external edge certs.  As you can see, Windows 2008 R2 doesn’t contain many root certs so this presents more risk for federated communication failures.  And… this is exactly what we saw.

What we actually saw is many of the following errors for many different federated organizations:

As we can see, we’re missing the root certs to communicate properly with our federated partners.  What to do?  Well… the solution is actually relatively simple.

Open up one MMC console but add 2 certificate snap-ins.  One is local on the Lync 2010 Windows 2008 R2 Edge and one is remotely connected to either a Windows 2003 or a Windows 2008 Server.  From the Remote 2008 or 2003 box, in the Trusted Root Certification Store, copy root certs (don’t cut as you still need them on the remotely connected machine) and paste into the Trusted Root Certificate Authorities store on your Lync 2010 Windows 2008 R2 Edge Server.

Afterwards, you will now have a Lync 2010 Windows 2008 R2 with the proper Trusted Root certificates in order to negotiated TLS with your federated partners.   One thing to keep in mind, you may still be missing a root cert after doing this.  You can still monitor 14428 event entries on your Lync 2010 Server 2008 R2 Edge and see what certificate vendor they are using.  Then go hunt down that root certificate on either a Windows 2008, Windows 2003 Server, or via the CA vendor’s website.

Elan Shudnow :: Feb.01.2011 :: Lync 2010 :: 216612 Comments »http%3A%2F%2Fwww.shudnow.net%2F2011%2F02%2F01%2Flync-2010-edge-utilizing-windows-server-2008-r2-federation-tls-issues%2FLync+2010+Edge+Utilizing+Windows+Server+2008+R2+Federation+TLS+Issues2011-02-01+21%3A16%3A52Elan+Shudnowhttp%3A%2F%2Fwww.shudnow.net%2F%3Fp%3D2166