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:
- http://blogs.pointbridge.com/Blogs/mcgillen_matt/Pages/Post.aspx?_ID=70
- http://social.microsoft.com/Forums/en/communicationsservercapacityplanning/thread/aa506001-0b67-46ce-a6be-ca9522fd6a0e
- http://social.technet.microsoft.com/Forums/en-US/ocscapacityplanning/thread/0cd5eb12-1a07-4946-95cf-66645f4f9f75/
- http://social.technet.microsoft.com/Forums/en-US/ocsmonitoring/thread/8438f788-15a0-48ff-be53-b57cdd993197/
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):
Type in WBEMTest to open up Windows Management Instrumentation Tester:
Click on the Connect button:
Make sure the Namespace field has root\cimv2 entered and then click on the Connect button:
Click on the Query button:
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:
Double click on the MSFT_SIPPoolConfigSetting instance:
The Object editor window will be presented:
Scroll down and locate the ServerQoSEnabled property:
Click on the Edit Properties button:
As shown in the editor below, the value is set to False by default:
Edit the value and type in TRUE and then click on the Save Property button:
You’ll be brought back to the following window:
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:
Clicking on the Close button will bring you back out:
Clicking on the Exit button will close the Windows Management Instrumentation Tester.
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):
Type in WBEMTest to open up Windows Management Instrumentation Tester:
Click on the Connect button:
Make sure the Namespace field has root\cimv2 entered and then click on the Connect button:
Click on the Enum Classes button:
Leave the Superclass name box blank, and then click OK:
Locate the class name MSFT_SIPMediationServerConfigSetting in the Query Result window and double-click on the entry:
The following window will be presented:
Make sure you do not make the mistake of simply scrolling down to locate the QoSEnabled property as shown in the following screenshot:
What you should do is to click on the Instances button:
Double click on the MSFT_SIPMediationServerConfigSettingInstanceID instance entry:
The following window will be presented:
Locate the QoSEnabled property in this window:
Change the default value of FALSE:
… to TRUE and then click on the Save Property button:
You’ll be brought back to the following window:
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:
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------------------------------------------------------------------------------------------
Proceed with closing the windows:
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:
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
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:
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:
Navigate to the Voice tab of the Front End Properties and click on the Configure… button for Advanced options:
Change the Voice QoS value to 40 and exit out of the configuration window:
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:
If you do need to install the QoS Packet Scheduler, it will look something like the following:
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:
- Controlled load service
- 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:
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:
The same goes for the Guaranteed service type setting because you’ll find that the default is Not configured:
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:
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:
Post a Comment