QoS in Windows Server 2012 (Part 3)

by [Published on 23 Oct. 2012 / Last Updated on 23 Oct. 2012]

This article continues the discussion of QoS by demonstrating the procedure for creating a QoS policy.

If you would like to be notified when Brien Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the other parts in this article series please go to

Before I Begin

Before I get started, I need to point out that Windows Server 2012 has not yet been officially released as of the writing of this article. As such, the information and screen captures that I am providing are based on a pre-release build. Although unlikely, it is possible that Microsoft could make changes to QoS by the time that Windows Server 2012 is eventually released.

Policy Based QoS

In Windows Server 2012, QoS is implemented through the use of group policy settings. Microsoft refers to this as Policy Based QoS. You can access the QoS portion of the Group Policy Editor by navigating through the Group Policy Editor’s console tree to Computer Configuration | Windows Settings | Policy Based QoS, as shown in Figure A.


Figure A: QoS is implemented through the Group Policy Editor.

It is worth noting that a QoS policy can be created at either the computer level or at the user level (or both). It is generally preferred to implement QoS policies at the computer level.

Creating a QoS Policy

You can create a new QoS policy by right clicking on the Policy Based QoS container and selecting the Create New Policy command from the shortcut menu. When you do, Windows will launch the Policy Based QoS Wizard, which you can see in Figure B.


Figure B: QoS policies are created through a wizard.

As you can see in the figure above, the first step in creating a QoS policy is to enter a policy name. You can call the policy anything that you want, but the name should be something descriptive.

The next option gives you the opportunity to specify a DSCP value. DSCP is an acronym standing for Differentiated Services Code Point. In spite of its rather cryptic sounding name the DSCP value’s job is actually quite simple. The value that is assigned here designates the policy’s traffic priority.

You might have noticed in the figure that the DSCP field has a default value of zero. The DSCP can be set to a value ranging from zero to 63. The higher the value, the higher the traffic priority. Therefore, a default QoS policy has the lowest possible priority.

When you assign a DSCP value to a QoS policy, you are essentially creating a queue for outbound network traffic. By default the traffic passing through the queue is not throttled. QoS only limits the traffic when bandwidth contention becomes an issue. In those types of situations lower priority queues yield to higher priority queues.

In some situations it is possible that a high priority queue could choke out a lower priority queue if a large amount of traffic passes through the higher priority queue. That being the case, the dialog box shown in the figure above gives you the opportunity to throttle the queue’s outbound traffic. Doing so implements a bandwidth cap that prevents the queue from consuming an excessive amount of bandwidth. The throttle rate can be specified in terms of either kilobits per second or megabits per second.

When you click Next, you are given the opportunity to specify the traffic stream to which the QoS policy should apply. Rather than requiring you to identify traffic by TCP/IP port numbers, the QoS policy is designed to be bound to specific applications. If you look at Figure C for instance, you can see that the new policy will apply to all applications by default.


Figure C: QoS policies can be assigned to individual applications.

If you want to bind the QoS policy to a specific application then all you have to do is specify the name of the application’s executable. In some cases however, there might be multiple applications on a system that use duplicate executable file names even though the applications themselves are different. In those types of situations you can specify the path to the application. If a path is required then you should use environment variables (such as %ProgramFiles%) whenever possible.

Your other option for binding the new QoS policy to a traffic stream is to use the policy to regulate HTTP traffic. In doing so, you must specify a specific URL or domain. That way the QoS policy will only regulate traffic for that specific site or Web application rather than applying to all HTTP traffic. Of course if your goal is to put a bandwidth cap on Web browsing then you always have the option of binding the policy to Internet Explorer.

Click Next and you will be prompted to specify the policy’s source and destination, as shown in Figure D.


Figure D: You can specify a source and / or a destination address for the policy.

Often times QoS policies need to have a granular scope. Imagine for example that your goal was to regulate the traffic produced by applications on one specific server. The problem with doing so is that QoS policies are really nothing more than group policy settings. Therefore, if you were to simply create a QoS policy within the Default Domain Policy then that policy would apply to all of the computers (or users) in the domain.

You could resolve this problem by segmenting your Active Directory into a series of organizational units, but that gets complicated and can be difficult to manage. It is much easier to use the dialog box shown in the figure above to specify source and / or destination addresses.

Specifying a source address effectively limits the policy so that it only applies to the specified source computer. As an alternative you can specify an IP address range so that the policy will apply to a specific subnet rather than to an individual computer.

The destination option allows you to apply the policy only to traffic that is destined for a specific computer or a specific subnet. If you need even tighter granular control then you have the option of specifying both a source and a destination address so that only the traffic flowing between designated hosts is regulated.

The wizard’s final screen, which you can see in Figure E, gives you tighter control over the types of traffic that are regulated. Here you can specify TCP and UDP port numbers for both the source and destination. You can use this as an alternative to specifying an application to which the policy should be bound.


Figure E: You can bind the QoS policy to specific port numbers.

Conclusion

In this article, I have shown you the basics of creating a QoS policy in Windows Server 2012. In Part 4 I will show you what the new policy looks like and I will talk about some advanced QoS options.

If you would like to be notified when Brien Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the other parts in this article series please go to

Advertisement

Featured Links