Friday, February 11, 2011

Enabling DSCP Marking for OCS 2007 R2

Update Feb-16-2011:  Please have a look at a new post I wrote about the changes and items to check if network packet traces do not show DSCP markings: http://terenceluk.blogspot.com/2011/02/items-to-check-if-network-packets.html

It’s been a while since I’ve had to enable DSCP Marking for OCS 2007 R2 because most of the clients we’ve dealt with opts for segmenting the network with VLANs and using network device QoS but recently, as you have probably already guessed, we have a client who would like to try it out.  This client has recently moved more users over to OCS 2007 R2 and began experiencing intermittent call quality issues and although I’ve continually told them it’s most likely the design of their network, they’ve decided to give DSCP marking a shot.

Before I begin, please note that this post will only cover the instructions in this TechNet article: http://technet.microsoft.com/en-us/library/dd441192(office.13).aspx.  Here is a list of links that include further tweaks required to get things to work:

Notable mentions are the different registry changes for 32-bit and 64-bit operating systems as well as DSCP marking values.

For the purpose of the example, we’ll be using a front-end server for a Standard Edition Pool and a separate mediation server.

Enable QoS on Front-End Server

Start by logging into your OCS 2007 R2 front-end server and opening up a command prompt with elevated privileges (run as administrator):

image

Type in WBEMTest to open up Windows Management Instrumentation Tester:

image

Click on the Connect button:

image

Make sure the Namespace field has root\cimv2 entered and then click on the Connect button:

image

Click on the Query button:

image

In the Query window that pops up, type/paste in the following:

select * from MSFT_SIPPoolConfigSetting where backend="(local)\\rtc"

… click on the Apply button:

image

Double click on the MSFT_SIPPoolConfigSetting instance:

image

The Object editor window will be presented:

image

Scroll down and locate the ServerQoSEnabled property:

image

Click on the Edit Properties button:

image

As shown in the editor below, the value is set to False by default:

image

Edit the value and type in TRUE and then click on the Save Property button:

image

You’ll be brought back to the following window:

image

Make sure you click on the Save Object button before you click on the Close button or else the ServerQoSEnabled property variable you just changed will revert back to False:

image

Clicking on the Close button will bring you back out:

image

Clicking on the Exit button will close the Windows Management Instrumentation Tester.

image

Just to be safe, I would re-launch the Windows Management Instrumentation Tester to double check that the ServerQoSEnabled property variable has indeed been updated.

A restart of the services will be required but make sure you ensure that the QoS Packet Scheduler is installed and that Windows Group Policy settings are appropriately configured on each computer (shown later in this post).  What I would suggest is to continue with the steps on this post then restart the servers when everything is configured.

Enable QoS on Mediation Server

Begin by logging into your OCS 2007 R2 mediation server and opening up a command prompt with elevated privileges (run as administrator):

image

Type in WBEMTest to open up Windows Management Instrumentation Tester:

image

Click on the Connect button:

image

Make sure the Namespace field has root\cimv2 entered and then click on the Connect button:

image

Click on the Enum Classes button:

image

Leave the Superclass name box blank, and then click OK:

image

Locate the class name MSFT_SIPMediationServerConfigSetting in the Query Result window and double-click on the entry:

image

The following window will be presented:

image

Make sure you do not make the mistake of simply scrolling down to locate the QoSEnabled property as shown in the following screenshot:

image

What you should do is to click on the Instances button:

image

Double click on the MSFT_SIPMediationServerConfigSettingInstanceID instance entry:

image

The following window will be presented:

image

Locate the QoSEnabled property in this window:

image

Change the default value of FALSE:

image

… to TRUE and then click on the Save Property button:

image

You’ll be brought back to the following window:

image

Make sure you click on the Save Object button before you click on the Close button or else the ServerQoSEnabled property variable you just changed will revert back to False:

image

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

Note: If you run into the following error:

Number: 0x80041003

Facility: WMI

Description: Access Denied

See my previous post: http://terenceluk.blogspot.com/2011/02/unable-to-save-object-in-wbemtest-with.html

image

-------------------------------------------------------------------------------------------------------------------------------------------------------------------

Proceed with closing the windows:

image

As with the front-end server, just to be safe, I would re-launch the Windows Management Instrumentation Tester to double check that the ServerQoSEnabled property variable has indeed been updated.

A restart of the services will be required but make sure you ensure that the QoS Packet Scheduler is installed and that Windows Group Policy settings are appropriately configured on each computer (shown later in this post).  What I would suggest is to continue with the steps on this post then restart the servers when everything is configured.

Enable QoS on Communicator Clients

The following registry key is what we will need to create for all the communicator client desktops and laptops:

image

Copy the following lines into notepad and save it as a .reg file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RTC]

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RTC\Transport]

"QosEnabled"=dword:00000001

image

The easiest way, at least in my opinion, to push this out is to create a new GPO for the users.  I won’t go into the details of how to do that but will include some screenshots:

image

image

image

image

Once you’ve gotten the policy configured, test it out on an OU and check to see if the key is created for the users.

Enable QoS for OCS 2007 R2 Phone Edition Devices

Launch the Office Communications Server 2007 R2 administration console and open up the pool’s Front End Properties:

image

Navigate to the Voice tab of the Front End Properties and click on the Configure… button for Advanced options:

image

Change the Voice QoS value to 40 and exit out of the configuration window:

image

Verify / Install QoS Packet Scheduler on OCS 2007 R2 servers and clients

As indicated in the TechNet article:

By default, the QoS Packet Scheduler is installed on computers running Windows XP, Windows Vista, and Windows 2008. By default, the QoS Packet Scheduler is not installed on Windows Server 2003. Use the following procedures to determine whether the QoS Packet Scheduler is installed and, if not, install it.

Unless you have some policy in your domain that have gone ahead to uninstall the QoS Packet Scheduler or you have certain users who use Windows Server 2003 as their operating system, the service should already be there.  With that being said, I would still spend a bit of time to verify that the QoS Packet Scheduler is installed on a few desktops or laptops.

Open up the network connection’s properties that you will be using for communication to your OCS 2007 R2 environment and verify that the QoS Packet Schedule is listed as shown in the following 2 screenshots:

image image

If you do need to install the QoS Packet Scheduler, it will look something like the following:

image

image

image

Note that there are no services listed in the screenshot above because all the services has already been made available to this connection.

Verifying Group Policy Settings on Computers

The TechNet article actually states that as long as the:

  1. Controlled load service
  2. Guaranteed service type 

… are one of the following values:

  • Not configured.
  • Enabled with a nonzero value. To see the value, right-click the setting, and then click Properties.
  • Disabled.

… then DSCP marking should just work.  Assuming there isn’t another policy that has change the default settings, you should find the Controlled load service already set to Not configured:

image

If you would like to specify a value instead, simply enable the setting and either use the default value or enter a value that isn’t 0:

image

image

The same goes for the Guaranteed service type setting because you’ll find that the default is Not configured:

image 

image

image

If you do decide to set values for these settings, I would suggest to bundle these with the policy for adding the RTC registry key to communicator clients.

--------------------------------------------------------------------------------------------------------------------------------------------------------------------

Once you’ve had all of tasks required for DSCP marking configured, perform a Wireshark capture on your mediation server and have a look at the Internet Protocol –> Differentiated Services Field and you should see that voice packets are now marked as being Expedited:

image

Hope the series of screenshots and descriptions will help anyone out there who may not be familiar with some parts of the TechNet article and would like to see what the GUI looks like.

No comments: