Documentation at
https://docs.microsoft.com/en-us/powershell/module/netqos/new-netqospolicy
says -ThrottleRateActionBitsPerSecond would enter the value as bytes per second. Example 4: 10 MB would result in limit of 80,000,000 bits per second.

In reality this will set: ThrottleRate : 10.486 MBits/sec

Note! Not 10 megabits per second, but 1.0486 times that, nearly 5% difference.
This is a potentially very bad bug because limits would be set as the highest rate of traffic. Someone trying to set limits per whole available bandwidth might end up going 5% over the available bandwidth and result in network traffic congestion.

And it makes setting actual limits a difficult exercise when one needs to be subtracting 5% of every limit value. Talk about code not documenting itself.

What makes me think this is a Powershell bug is that when setting bandwidth limits with gpedit.msc it will set the limits properly - in BYTES per second, without any extra multipliers.

So powershell went double wrong somewhere, confusing bytes for bits and then multiplying it with 1.0486 for added damage.

Observed with: Windows Server 2019 17763.1217
Powershell version 5.1.17763.1007

On my VPN server, I run "set-vpnauthprotocol -rootcertificatenametoaccept $RootCACert", with $RootCACert containing the public certificate of our internal root CA. After running this command (and after restarting the server) I run get-vpnauthprotocol to confirm that the certificate was updated, but find it set to a different certificate than the one I provided. This different certificate has the same name, but all other attributes are different.

Even though a certificate object is required for the 'rootcertificatenametoaccept' parameter, it only uses the name of the certificate provided, then searches for a certificate matching that name in the computer's local root store. If multiple certificates with the same name exist in the root store, it can select the wrong one.

Because of this, when a client presents a certificate for authentication, the VPN server sees that the certificate was not signed by the certificate set in the vpn auth protocol, and rejects the connection.

Hi all,

I understand there is an issue with Windows Server 2019/Windows 10 1809 however I was wondering if Microsoft are aware of any problems regarding the Firewall rather than the systems handling of user files.

Recently I setup a Server 2019 VM (1.5GB Dynamic RAM, 2 Allocated Cores, 36GB Drive space, 3GB NIC Team) and installed the NPS and RDS Gateway role onto it however I noticed that despite the NPS role adding the standard firewall rules for port 1813 and 1812 they do not seem to be working.

I have confirmed that with an exception allowing port 1812 through or disabling the firewall allows authentication requests to reach the NPS server however when these are removed and the default rules are left they are blocked.

I have performed an SFC scan and DISM scan/repair however no issues have been detected
I have also spun up a new Server 2019 and Server 2016 server to compare and the 2019 server has the same issue whilst the 2016 server has no problems with just the default rules and no exceptions/extra.

If anyone has any suggestions or information I would be extremely great-full as currently I'm not sure what seems to be the cause

Hi,

I'm trying to understand how RSS works and while experimenting, I found out that when Convervative RSS Profile is used with 1 RSS Queue, Indirection Table stay the same, with two processors. Is that correct behavior?

I'm asking, because when I choose other RSS Profile (for example Closest or ClosestStatic), number of the processors in IndirectionTable always match NumberOfRecaiveQueues.

Is that mean that I have some bad version of Powershell/Windows/Drivers or is it correct??

Can anyone help with that?

I've used Set-NetAdapterRss cmdlet to set things up.

Name : test0
InterfaceDescription : Intel(R) Ethernet Converged Network Adapter X550-T2
Enabled : True
NumberOfReceiveQueues : 1
Profile : Conservative
BaseProcessor: [Group:Number] : 0:0
MaxProcessor: [Group:Number] : 0:26
MaxProcessors : 14
RssProcessorArray: [Group:Number/NUMA Distance] : 0:0/0 0:2/0 0:4/0 0:6/0 0:8/0 0:10/0 0:12/0 0:14/0 0:16/0 0:18/0 0:20/0 0:22/0 0:24/0 0:26/0
IndirectionTable: [Group:Number] : 0:0 0:2 0:0 0:2 0:0 0:2 0:0 0:2
...

"netsh trace" and/or NetEventPacketCapture lacks capable packet filtering. A lot of secure and change managed environments do not [easily] allow the installation of packet capture tools for collecting network data, like Wireshark (or the now defunct netmon and Message Analyzer).

The two built-in packet capture tools in Windows, "netsh trace" and NetEventPacketCapture, can only filter packets by IP address, MAC, and protocol. This makes collecting a targeted trace, sometimes needed when collecting traces on sensitive networks or when other data floods the ETL, impossible.

This is a request to add, at a minimum, the ability to filter packets by TCP port and UDP endpoint. Ideally, Windows inbox packet filtering should be on par with the industry standard tcpdump(*nix)/npcap(Wireshark for windows) filter format.