RSS Subscription 148 Posts and 2,107 Comments

Enabling QoS for Lync Server 2010 – Part 2

Welcome to Part 2 on how to Enable QoS for Lync Server 2010. The purpose of this multi-part article (first part for QoS on Lync Client and second part for QoS on Lync Server) is to lay everything out in a concise manner to help you, the reader, understand how to enable QoS.  Keep in mind that this article is only for the ability to enable QOS, it is not a comprehensive guide on all the various dynamic ports available in Lync to lock down your firewalls.  For that, you can check out my other article here. Second of all, the question may arise, why and when would you want to enable QoS.  Audio and Video are synchronize traffic that can be affected by jitter, delay, and packet loss on an IP Network.  Lync has been designed to work without QoS but Lync Administrators can choose to enable both Lync endpoints as well as servers to mark Differentiated Services Code Point (DSCP) values on audio and video packets.  This ensures that audio/video packets get prioritized on a network that is enabled for Differentiated Services (DiffServ).

To better understand DiffServ and its affect on the network, please check out the excellent blog article written by fellow Lync MVP Jeff Schertz at the following URL: http://blog.schertz.name/2011/08/lync-qos-behavior/

Part 1

Part 2

Server QOS

General Procedure for Server QoS

In Part 1, we talked about Windows Vista/7 vs Windows XP.  Windows 7 and Windows Vista utilize Policy based QoS and Windows XP used QoS based on the Packet Scheduler.  For Lync Servers, you’ll always use Policy based QoS since Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2 which both utilize Policy based QoS.  For Server based QoS, we can configure Conferencing Servers, Application Servers, and Edge Servers (which will use QoS based on the destination port rather than the source port as everything else does).

Client to Server Port Configuration for Conferencing Servers and Application Servers

Client to Server Port ranges are out of the box different for all modalities except for Application Sharing. The default ports for a Conferencing Server are as such:

  • Audio: 49152 to 57500
  • Video: 57501 to 65535
  • Application Sharing: 49152 to 65535

At least 40 ports minimum are required for Application Sharing.  We will specify a 8,348 port range that is unique from other ports.  Ultimately, we will set Application Sharing to use the following ports:

  • Application Sharing: 40803 to 49151

To set this, we will run the following command:

Set-CsConferencingServer -Identity <ConferencingServer:FQDN of Lync Pool or A/V Server/Pool FQDN> -AppSharingPortStart 40803 -AppSharingPortCount 8348

Configuring an Application Server is identical.  The only difference is that you use the Set-CSApplicationServer command instead of the Set-CSConferencingServer.  Make sure to include these ports in the QoS Policies for Edge Servers as you will learn later.

Client to Server Port Configuration for Dedicated Mediation Servers

A Mediation Server of course only handles Audio since it’s job is to transcode RTAudio to G.711.  The default ports for a Mediation Server are as such:

  • Audio: 49152 to 57500

No Changes to this port range will be required.  If the Mediation Server is collocated on a Front End Server, no changes will need to be done as you can see the Audio Port Range for a dedicated Mediation Server is the same as the Audio Port Range for a Front End Conferencing Server.

Edge Server Policy Configuration

An Edge Server doesn’t get configured per se.  But the policy that you create is based on a destination port (rather than source port like client peer to peer or client to server).  The destination port configuration in the QoS Policy is configured based on the client peer to peer ports you defined in Part 1 of this article series as well as the client to server ports you defined in this Part 2 of this article series.

So if we take a look at everything we’ve done so far, we have the following peer to peer configuration from Part 1 of this article series:

  • Audio: 20000 to 20039
  • Video: 20040 to 20079

And we have the following client to server configuration from Part 2 of this article series:

  • Audio: 49152 to 57500
  • Video: 57501 to 65535
  • Application Sharing: 40803 to 49151

The Edge QoS Policy will need to have several QoS Policies configured to handle each modality (Application Sharing not as critical as Audio/Video but can be enabled) for peer to peer (Audio/Video) and client to server (Audio/Video).  Additional QoS Policies may be needed depending on Application Servers in the environment and whether they have any different port ranges from your Peer to Peer or Client to Peer port configurations.

Configuring Policy Based QOS in Group Policy for Windows 2008 and/or Windows 2008 R2 for a Conferencing Server

As stated previously, Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2.  Both Windows 2008 and Windows 2008 R2 utilize Policy Based QOS which allows a wider variety of options for configuring QoS.

In the below example, we will show how to create the Policy-based QoS for Audio.  Once finished, be sure to also create Policy-based QoS policies for Video.  The DSCP Value for Audio will be 46 and the DSCP Value for Video will be 34. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS Right-Click and choose Create new policy.

In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for audio is typically 46.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Because there are multiple applications that will stamp DSCP Values, we will choose All Applications. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Click Next.

On  the following screen, choose TCP and UDP.  In our information above we stated the default audio port range is 49152 to 57500 and does not need to be changed.  Because of this, our source port range will 49152 to 575000 specified as 49152:57500.

Let’s go ahead and set the DSCP Value for Video with a DSCP value of 34. Right-Click Policy-based QoS and choose Create new policy. In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for video is typically 34.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Because there are multiple applications that will stamp DSCP Values, we will choose All Applications. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Click Next.

On  the following screen, choose TCP and UDP.  In our information above we stated the default video port range is 57501 to 65535 and does not need to be changed.  Because of this, our source port range will 57501 to 65535 specified as 57501:65535.

If you would like Client to Server QoS for Application Sharing, feel free to also create a new QoS Policy that provides DSCP Values for the port ranges specified for Application Sharing.  If you made this port range contiguous with Video, feel free to modify your Video QoS Policy to add the ports for Application Sharing if you are fine with also using a DSCP value of 34.

Now go ahead and restart your Lync Conferencing Servers so they pick up the changes. After Group Policy have applied the settings, you should see the following settings within the registry:

Configuring Policy Based QOS in Group Policy for Windows 2008 and/or Windows 2008 R2 for a Dedicated Mediation Server

As stated previously, Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2.  Both Windows 2008 and Windows 2008 R2 utilize Policy Based QOS which allows a wider variety of options for configuring QoS.

In the below example, we will show how to create the Policy-based QoS for Audio only.  The DSCP Value for Audio will be 46. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS Right-Click and choose Create new policy.

In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for audio is typically 46.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Since this is Policy-based QoS, we will want to take advantage of only tagging traffic that the Mediation Server uses utilizing the executable MediationServerSvc.exe.  So make sure you choose the “Only applications with this executable name” and specify MediationServerSvc.exe. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Click Next.

On  the following screen, choose TCP and UDP.  In our information above we stated the default audio port range is 49152 to 57500 and does not need to be changed.  Because of this, our source port range will 49152 to 575000 specified as 49152:57500.

Now go ahead and restart your Lync Mediation Servers so they pick up the changes. After Group Policy have applied the settings, you should see the following settings within the registry:

 

Configuring Policy Based QOS in Group Policy for Windows 2008 and/or Windows 2008 R2 for an Edge Server

As stated previously, Lync Server 2010 can only be installed on Windows 2008 or Windows 2008 R2.  Both Windows 2008 and Windows 2008 R2 utilize Policy Based QOS which allows a wider variety of options for configuring QoS.

In the below example, we will show how to create the Policy-based QoS for Audio.  Once finished, be sure to also create Policy-based QoS policies for Video.  The DSCP Value for Audio will be 46 and the DSCP Value for Video will be 34. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS Right-Click and choose Create new policy.

In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for audio is typically 46.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Since this is Policy-based QoS, we will want to take advantage of only tagging traffic that the Edge Server uses utilizing the executable MediaRelaySvc.exe.  So make sure you choose the “Only applications with this executable name” and specify MediaRelaySvc.exe. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Alternatively, you can change the Source IP Address to the internal IP of your Edge.  Click Next.

On  the following screen, choose TCP and UDP.  In our information above we stated the default audio port range is 49152 to 57500 and does not need to be changed.  Because of this, our source port range will 49152 to 575000 specified as 49152:57500.

I will not display the remainder of the QoS Policy configuration for the Edge as I’m sure by now, you are a master at configuring QoS Policies for Lync.  The remainder of the three QoS Policies will look as such:

Peer to Peer Video:

  • Policy Name: Lync Edge Peer to Peer Video
  • DSCP Value: 34
  • Only applications with the following executable name: MediaRelaySvc.exe
  • Specify Outbound Throttle Rate is Unchecked
  • Source IP: Your Internal Edge IP (Our example is 10.10.10.50/32)
  • Destination Port Range of 20040:20079

Client to Server Audio:

  • Policy Name: Lync Edge Conferencing Audio
  • DSCP Value: 46
  • Only applications with the following executable name: MediaRelaySvc.exe
  • Specify Outbound Throttle Rate is Unchecked
  • Source IP: Your Internal Edge IP (Our example is 10.10.10.50/32)
  • Destination Port Range of 49152:57500

Client to Server Video:

  • Policy Name: Lync Edge Conferencing Video
  • DSCP Value: 34
  • Only applications with the following executable name: MediaRelaySvc.exe
  • Specify Outbound Throttle Rate is Unchecked
  • Source IP: Your Internal Edge IP (Our example is 10.10.10.50/32)
  • Destination Port Range of 57501:65535

After all QoS Policies are created, reboot the Lync Edge Server.  You should see the following registry changes:

Share

Enabling QoS for Lync Server 2010 – Part 1

There’s a doc available by Microsoft on how to enable Quality of Services (QoS) in Lync which you can find here.  The purpose of this multi-part article (first part for QoS on Lync Client and second part for QoS on Lync Server) is to lay everything out in a concise manner to help you, the reader, understand how to enable QoS.  Keep in mind that this article is only for the ability to enable QOS, it is not a comprehensive guide on all the various dynamic ports available in Lync to lock down your firewalls.  For that, you can check out my other article here. Second of all, the question may arise, why and when would you want to enable QoS.  Audio and Video are synchronize traffic that can be affected by jitter, delay, and packet loss on an IP Network.  Lync has been designed to work without QoS but Lync Administrators can choose to enable both Lync endpoints as well as servers to mark Differentiated Services Code Point (DSCP) values on audio and video packets.  This ensures that audio/video packets get prioritized on a network that is enabled for Differentiated Services (DiffServ).

To better understand DiffServ and its affect on the network, please check out the excellent blog article written by fellow Lync MVP Jeff Schertz at the following URL: http://blog.schertz.name/2011/08/lync-qos-behavior/

So, let’s dive into my version of how to enable QoS.  Shall we?

Part 1

Part 2

Client QOS

Windows 7 versus Windows XP

Windows Vista and Windows 7 utilize Policy based QOS. Policy based QOS has the benefit that you can restrict the QoS application at the application level.  For Lync, this would be communicator.exe. Windows XP uses separate QOS Group Policy Options that do not allow you to restrict the DSCP values at the application level.  This means that all applications that utilize the Audio/Video ports we configure for Audio/Video will get DSCP markings stamped.

Peer to Peer Port Configuration

All client port ranges need to be changed as they are all overlapping by default.  Client Media traffic by default utilizing ports 1024 to 65535 when doing Peer to Peer. To specify the client media port ranges, Set-CSConferencingConfiguration must be used. The port ranges for each modality must not conflict with another modality. Also, it is highly recommended to ensure that when each modality is locked down to its own port range that all ports are contiguous as this will make configuring Group Policy later on a bit easier as you will see later on in the article.

The command used to enable the ability to lock down peer to peer client ports is Set-CsConferencingConfiguration with the ClientMediaPortRangeEnabled set to 1.  When enabled, clients will use the specified port range for media traffic. When disabled (the default value) any available port (from port 1024 through port 65535) will be used to accommodate media traffic.  Because we want to lock down the peer to peer ports, we must run the following command:

Set-CsConferencingConfiguration -ClientMediaPortRangeEnabled 1

Once this command is run, we can go ahead and start locking down our ports.  Now keep in mind, all these commands are provided to the clients via in-band provisioning.  This means that once our client signs in, they will start using these locked down port ranges and it does not require any Group Policy Object to be created (at least not for locking down ports) and pushed down to your clients.

The following commands are where we finally choose the amount of ports and at what port each modality starts.  The commands are:

  • Application Sharing:
    Set-CSConferencingConfiguration -ClientAppSharingPort <beginning of port range (5350 by default)> -ClientAppSharingPortRange <extent of port range, at least 4 (40 by default)>
  • Audio:
    Set-CSConferencingConfiguration -ClientAudioPort<beginning of port range> -ClientAudioPortRange <extent of port range, at least 20 (40 by default)>
  • Video:
    Set-CSConferencingConfiguration -ClientVideoPort <beginning of port range> -ClientVideoPortRange <extent of port range, at least 20 (40 by default)>
  • File Transfer:
    Set-CSConferencingConfiguration -ClientFileTransferPort <beginning of port range> -ClientFileTransferPortRange <extent of port range, at least 20 (40 by default)>
  • Communicator 2007 R2:
    Set-CSConferencingConfiguration -ClientMediaPort <beginning of port range> -ClientMediaPortRange <extent of port range, at least 40>

Note: -ClientMediaPortRange is used for Office Communicator 2007 R2 Clients. The reason why this uses 40 is because this setting includes all modalities as Office Communicator 2007 R2 did not split apart each modality into their own separate switches.  Being able to break up each modality is a feature of Lync.

An example of a properly defined command with the minimum port requirement in one big switch is as follows:

Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 20 -ClientVideoPort 20020 -ClientVideoPortRange 20 -ClientAppSharingPort 20040 -ClientAppSharingPortRange 4 -ClientFileTransferPort 20044 -ClientFileTransferPortRange 4 -ClientMediaPort 20048 -ClientMediaPortRange 40

An example of a properly defined command with the default port range is as follows (this is the example we will use going forward when configuring Group Policy):

Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 40 -ClientVideoPort 20040 -ClientVideoPortRange 40 -ClientAppSharingPort 20080 -ClientAppSharingPortRange 40 -ClientFileTransferPort 20120 -ClientFileTransferPortRange 40 -ClientMediaPort 20160 -ClientMediaPortRange 40

Configuring Policy Based QOS in Group Policy for Windows Vista and/or Windows 7 clients

As stated previously, Windows Vista and Windows 7 clients utilize Policy Based QOS which allows a wider variety of options for configuring QoS.  For example, you can specify that only communicator.exe should tag x ports.

In the below example, we will show how to create the Policy-based QoS for Audio.  Once finished, be sure to also create Policy-based QoS policies for Video.  The DSCP Value for Audio will be 46 and the DSCP Value for Video will be 34. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Windows Settings > Policy-based QoS Right-Click and choose Create new policy.

In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for audio is typically 46.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Since this is Policy-based QoS, we will want to take advantage of only tagging traffic that communicator.exe uses.  So make sure you choose the “Only applications with this executable name” and specify communicator.exe. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Click Next.

On  the following screen, choose TCP and UDP.  In our example above we used the Set-CSConferencingConfiguration command with the ClientAudioPort 20000 -ClientAudioPortRange 40 switches.  Because of this, our source port range will 20000 to 20039 specified as 20000:20039 since our ClientAudioPortRange was 40.

Let’s go ahead and set the DSCP Value for Video with a DSCP value of 34. Right-Click Policy-based QoS and choose Create new policy. In the new Policy, give it a name and specify the DSCP Value.  DSCP Values for video is typically 34.  Make sure the Outbound Throttle Rate check box is cleared.  Click Next.

Since this is Policy-based QoS, we will want to take advantage of only tagging traffic that communicator.exe uses.  So make sure you choose the “Only applications with this executable name” and specify communicator.exe. Click Next.

On the following screen, make sure you leave the defaults as “Any source IP address” and “Any destination IP Address.”  Click Next.

On  the following screen, choose TCP and UDP.  In our example above we used the Set-CSConferencingConfiguration command with the ClientVideoPort 20040 -ClientAudioPortRange 40 switches.  Because of this, our source port range will 20040 to 20079 specified as 20040:20079 since our ClientVideoPortRange was 40.

Now go ahead and restart your Lync clients so they pick up the changes. After Group Policy have applied the settings, you should see the following settings within the registry:

Also, if you are in Workgroup Mode and notice that DSCP Values are not being applied, you may have to apply the following registry key:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\QoS]“Do not use NLA”=”1″

Configuring QOS Policies in Group Policy for Windows XP clients

As stated previously, Windows XP Clients (it’s the same for Windows Server 2003) cannot use policy-based QoS.  Instead, it uses QoS Policies based on the QoS Packet Scheduler.  To install the QoS Packet Scheduler on Windows XP or Windows Server 2003, please proceed with the following steps:

Go to Control Panel > Network Connections > Right-Click Network Interface > Choose Properties. Then Choose Install.

Make sure to choose Service.  Click Add.

Choose QoS Packet Scheduler as the Network Service.  Click OK.

Now it is time to go into Group Policy. The DSCP Value for Audio will be 46 and the DSCP Value for Video will be 34. Open up Group Policy (in my examples, I am using Local Computer Policy but in a real production environment you would be using Group Policy at some level in your Domain Hierarchy) and navigate to Computer Configuration > Administrative Templates  > Network > QoS Packet Scheduler.

The section we will be working with is, “DSCP value of conforming packets.”  You do not need to modify “DSCP value of non-conforming packets.” And the two options within “DSCP value of conforming packets” we will be working with is:

  • Controlled load service type (For Video with a DSCP Value of 34)
  • Guaranteed service type (For Audio with a DSCP Value of 46)

Let’s go ahead and set the DSCP Value for Video (Controlled load service type).  Go ahead and open “Controlled load service type.”  Choose Enabled and set the DSCP to 34. Then click OK.

Let’s go ahead and set the DSCP Value for Audio (Guaranteed service type).  Go ahead and open “Guaranteed service type.”  Choose Enabled and set the DSCP to 46. Then click OK.

After Group Policy have applied the settings, you should see the following two settings set within the registry:

Now hop on your Lync Server and open the Lync Management Shell and type the following command:

Set-CsMediaConfiguration -EnableQoS $true

This command should set your Windows XP and/or Windows Server 2003 machine with the following registry key:

Configuring QOS for Lync Phone Edition

Configuring Lync Phone Edition QoS is really simple and there’s really only one step.  By default, the DSCP Value is set to 40 which is not typical for voice DSCP. We can see the default value by running the following:

Get-CsUCPhoneConfiguration

Identity             : Global
CalendarPollInterval : 00:03:00
EnforcePhoneLock     : True
PhoneLockTimeout     : 00:10:00
MinPhonePinLength    : 6
SIPSecurityMode      : High
VoiceDiffServTag     : 40
Voice8021p           : 0
LoggingLevel         : Off

To set this value to 46, run the following command (leaving -Identity blank will modify the global settings):

Set-CsUCPhoneConfiguration -VoiceDiffServTag 46

Surprisingly, that’s all there is to it for enabling QoS to Lync Phone Edition.  That is of course other than rebooting your Lync Phone which is required.

As an alternative to DSCP value, you can utilize 802.1p for Lync Phone edition.  This setting is effective only for networks in which switches and bridges are 802.1p-capable.  The minimum value for this property is 0 and the maximum is 7.  The default value is 0.

To enable 8021.p you can run the following command (leaving -Identity blank will modify the global settings):

Set-CsUCPhoneConfiguration -Voice8021p <value>

Conclusion

In this Part 1 on how to enable QOS for Lync Server 2010, we took a look at how to enable QOS for Lync clients.  In Part 2, we will take a look at how to enable QoS for for Lync 2010 servers.

Share

Reordering Lync 2010 Dial-In Conferencing Numbers

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):

Set-CsDialInConferencingAccessNumber -Identity “sip:DialInSIPAddress@domain.com” -Priority 0

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

Get-CsDialInConferencingAccessNumber

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.

Share

Lync 2010 – Deploy First Standard Edition Server Option?

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.

Share

Lync Server 2010 Monitoring Server Reports Read-Only Group

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!

Share

Lync Server 2010 – Cannot Connect to Sharing Server

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.

Share

Configuring Lync DHCP using Cisco DHCP Servers (VLAN and PIN Auth)

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:

Sub-Option 1 Sub-Option 2 Sub-Option 3 Sub-Option 4 Sub-Option 5
01 Length Data 02 Length Data 03 Length Data 04 Length Data 05 Length Data
  1. Compile Sub-Option 1 from DHCPUtil.exe output:
  2. Length of data is hex value for (number of characters of Data) divided by 2 ( # of chars / 2 )

  3. Compile Sub-Option 2 from DHCPUtil.exe output:
  4. Sub-Option2
    02 Length of data Data
    02 05 6874747073
  5. Compile Sub-Option 3 from DHCPUtil.exe output:
  6. Sub-Option3
    03 Length of data Data
    03 0B 6578616D706C652E636F6D
  7. Compile Sub-Option 4 from DHCPUtil.exe output:
  8. Sub-Option4
    04 Length of data Data
    04 03 343433
  9. Compile Sub-Option 5 from DHCPUtil.exe output:
  10. 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:

Sub-Option1 Sub-Option2 Sub-Option3 Sub-Option4 Sub-Option5
01 Length Data 02 Length Data 03 Length Data 04 Length Data 05 Length Data
010C4D532D55432D436C69656E7402056874747073030B6578616D706C652E636F6D040334343305252F4365727450726F762F4365727450726F766973696F6E696E67536572766963652E737663

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

Share

Next »