Some notes to Paul's example.
First, if you're applying such a policy to an interface, where you're working with its native "speed/bandwidth", you don't need the parent shaper policy (and policy will work better w/o a shaper).
Second, don't know if still true for latest CBWFQ on 4K ISRs, but the priority implicit policer only engages if there are packets in the LLQ. I.e. It may be possible for the LLQ class to obtain 100% available bandwidth. If this is not desired, you might want to add an implicit policer to either drop at or below the bandwidth setting, or transmit at or below the bandwidth setting. The latter will provide you stats such that you can determine bandwidth usage possibly before LLQ actually starts to drop packets.
Lastly, you might consider using a non-LLQ class for your sharepoint traffic or, if supported, using priority tier 2. Either to insure you have a "place" to direct VoIP traffic, if you ever need to support it.
BTW, an example of using non-LLQ, but achieving similar results, would be something like:
policy-map QOS_child
class MS-Sharepoint
bandwidth percent 99 !99% may not be needed - 1) again, FQ in class-default, alone, might work for you - 2) a lower dequeuing ratio might work fine too
(shape or police) average percent 20
class class-default
bandwidth percent 1
fair-queue
NB: "bandwidth percent 99", in class MS-Sharepoint, doesn't preclude other traffic from using its bandwidth, it just insures dequeuing priority is in the ratio of 99:1. Also, it provides an option to "shape" excess rather than only dropping it. (You can also use FQ in this non-LLQ class - which can be of benefit in there is more than one SharePoint flow, and there is one or more "hogging" bandwidth in that class.)
Also BTW:
I see you marked Paul's answer as a solution, because he provided an example? In the future, if you also want an example, I suggest you mention that too in your OP or follow-up posts.
