Windows server 2012 r2 network speed to computer is limited to ~30mbps

Your understanding of the problem is generally correct, but the kind of solution you propose is VERY complicated to implement. The questions of "What is a client?" and "What is a connection?" come up, and can be difficult to answer well.

The more typical bandwidth-limiting strategy is something like this:

• Define the limit of the upstream bandwidth (say 1Mbit/sec)
• Optionally Reserve some amount of that bandwidth for "system administration" (say 64Kb/sec)
• Optionally "guarantee" a certain amount of bandwidth to a specific purpose (say 192Kb/sec for VOIP)
• Allow everyone to use the remaining bandwidth (768Kbit/sec).

VOIP may use more than 192Kbit/sec, so we may let it borrow from the "everyone" pool (or vice-versa). When the "everyone" pool is saturated start dropping packets just like we would if the upstream link were REALLY saturated (using, e.g. Random Early Detection to pick your drop victims.

Typically this is done on UPSTREAM traffic. Downstream traffic can be limited the same way, but you can't avoid link saturation from downstream traffic (the packets still have to come to your firewall before the drop decisions can be made, so they're still traveling down your wire. The result is a surge of traffic followed by a natural decay as the TCP protocol senses "link saturation" congestion and the remote side backs off its send rate until the packet loss stops).

Also note that this doesn't guarantee "fairness" to the client machines, except to the extent that Random Early Detection will drop packets "randomly" (randomly enough that it won't always be client A that gets packets dropped when the link is saturated). What you're counting on is that the "random" drops will naturally shape traffic to an extent that you don't have to worry about one client being starved out while another hogs all the bandwidth.

An out-of-the-box solution in your particular case might be to limit the bandwidth available for updates (presumably these come from known subnets, so limit those), but this is still subject to the caveats I mentioned above.

Alternatively, if you have hardware available, you can distribute your updates from a local server (WSUS, Local apt mirror, etc.) -- This would let you schedule those updates to be pulled locally during off-hours when nobody is using your network, and ultimately would save you a lot of bandwidth transferring individual updates for each machine.
Since the updates are already local it doesn't matter when the individual client machines pick them up - they're not going out to the internet, so as long as you aren't saturating your local network (pretty tough!) you won't suffer significant performance issues. The downside of course is you need to invest time and hardware in setting up the update server.

In comparing my settings between the two SQL servers, I spotted that accounts used to operate the services where different, changing them requested a server service restart, and this fixed the issue.

oh well.