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.