First a story, and by story I mean rant:
So I know QoS and Microsoft are like oil and water. As much as they would beg to differ they don’t really want to know about the network layer they run on. They would just like to assume we all have 10Gbe links everywhere including to the desktop. Therefore who would ever need QoS, right?
Well I have news for you *psst* it’s a secret. THAT’S NOT HOW THE NETWORKS OF 2013 WORK! Alas the networks of today in the common enterprise are lucky to get gig to the desktop. It’s 10/100 to the desktop with gigabit up-links to the distribution layer and maybe 10Gb to the core. Add to this most enterprises don’t just reside in one building, they often span multiple, spread over geographic distances often lacking in bandwidth. Which means, wait for it….we need quality of service. [su_pullquote]“We need Quality of Service.”[/su_pullquote] Thankfully Microsoft to their credit over the years has gotten better at recognizing that such a statement is reality and has provided us some options.
Now for the back story about Microsoft QoS
So in a perfect world the picture to the right would be reality. Developers including Microsoft would use the handy-dandy API which would then allow them to classify the type of traffic their application will be sending. For example in the case of Exchange 2010 UM it should specify it’s RTP traffic as “SERVICETYPE_GUARANTEED” which in turn the packet scheduler can then mark as EF before it hits the wire. All we as admins would need to do is ensure that QoS packet scheduler was turned on and specify in the GPO the DSCP value for “SERVICETYPE_GUARANTEED” traffic. What a nice world that would. And to be honest in some cases that is reality. But for some reason at least in my recent experience with Exchange 2010 UM this is not the case.
Okay it’s Broken Now What?
Thankfully because of Microsoft we’re not out of options yet. In typical MS fashion they’ve given us more than one way to accomplish the same thing. This is where Policy-based Quality of Service (QoS) comes in. Since the application isn’t telling the packet scheduler what type of traffic it wants to send it goes out as DSCP 0 or best effort. Which is very sad panda for voice over congested WAN links. So our next option is to do the work of a developer for them. We can create a GPO utilizing the Policy-based Quality of Service (QoS) in which we will tell it any UDP network traffic from the UMWorkerProcess.exe (the process which makes RTP traffic for Exchange UM) should be marked as DSCP 46 EF. When this traffic hits the QoS Packet Scheduler it will be passed through as it’s already been tagged and out to the wire it will go, where our properly configured network gear will honor and queue as needed.
This in turn means Exchange UM won’t sound horrible and our users can find something new to complain about, like the fact they have to talk to Exchange UM. Picture guide of how to do the above coming soon.