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,

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
...

When Server 2016 DNS Server has a delgation within a primary zone, CNAME records in that delegation result in queries to the delgation's name servers, not forwarders / root hints.
For example:

Primary zone: one.example
Delegation: foo.one.example, with nameserver ns.bar.com

In that delegated zone, there exists a record:

baz.foo.one.example IN CNAME other.two.example

two.example's zone, hosted by ns.somethingelse.com, has a record:
other.two.example IN A 1.2.3.4

From a client pointed at the DNS server, query baz.foo.one.example.

I would expect the server to query ns.bar.com for baz, receive a reply of other.two.example, and then query either two.example's nameserver, or use the default forwarders to do the same, resulting in a recursive resolution passed back to the client of 1.2.3.4.

What actually happens, in Server 2016, is that only the CNAME is returned. With debug logging enabled, the DNS server issues a query to ns.bar.com for other.two.example, and of course gets a REFUSED response.

In Server 2012 R2, with the same configuration, baz.foo.one.example is resolved recursively to 1.2.3.4.

I'm pretty sure the new behaviour is incorrect?

Thanks,
Rob

Writing a script to provision a machine - we first remove the IPAddress (and any default gateway), But sometimes there is no address. That;s fine - we just try/catch and move on, liike this:

Try {

Remove-NetIPAddress -InterfaceIndex $IfIndex `

                    -AddressFamily IPv4 `

                    -Confirm $false

}

Catch {Write-Verbose 'No IPAddresses found'}

But instead of the nice write-verbose message, we get a fatal error:
Remove-NetIPAddress : No matching MSFTNetIPAddress objects found by CIM query for instances of the ROOT/StandardCimv2/MSFTNetIPAddress class on the CIM server:
SELECT * FROM MSFT_NetIPAddress WHERE ((IPAddress LIKE 'False')) AND ((InterfaceIndex = 3)) AND ((AddressFamily = 2)). Verify query parameters and retry.
At line:3 char:5
+ Remove-NetIPAddress -InterfaceIndex $IfIndex `
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

+ CategoryInfo          : ObjectNotFound: (MSFT_NetIPAddress:String) [Remove-NetIPAddress], CimJobException

+ FullyQualifiedErrorId : CmdletizationQuery_NotFound,Remove-NetIPAddress

Please fix this cmdlet so it's trapping can be caught with a catch block.