I just installed OpenSSH on a Windows-10 box we got for the lab. This is great - the documentation was clear, and I just used the Powershell method to quickly install and configure a Linux-style "sshd" server for this Windows-10 machine. We run mostly Linux machines, and were really pleased to see Windows-10 had scp pre-installed. But there was no "sshd" (we could scp and rsync to the box, but not log into to it.) But a quick google-search "how to enable sshd on Windows-10" took me right to the Microsoft documentation page, with a good detailed description of exactly how to do it using Powershell and the Get_Windowscapabilities option. Totally works.

Even had info on how to configure the firewall, and then query the firewall config to confirm it was set right to allow access. Tested from our Linux machines - its all good.

We ran the cygwin Linux-style utilities on some old Win-XP/sp3 boxes, and WINE on the Linux machines, so we have application interoperation. I just installed "vim" on this Windows-10 box, and it works fine.

Powershell is already very "Linux-like" - I moved over a bunch of WGNUPLOT stuff (Windows-GNUplot), and when I typed "WGNUPLOT", it would not run. But "./WGNUPLOT" ran fine (even though the doc. said to use the "." instead of the "./") But either slash works fine, and everything runs. And "ls" works. And so does "cat". But there is no "df" and I had to ask Dr. Google how the heck to query the "$PATH" ("$Env:PATH". I see....)

What is curious, is that one used to be able to query environment variables in Linux, by entering "set". But if you do that on a modern CentOS box, for example, you will get almost a terabyte of code thrown in your face, which is really silly and annoying.

So, as Linux is becoming more cryptic and difficult to use and navigate (systemd, for example), it seems Windows is becoming easier and more sane - by looking a lot like the lean & not-bloated Linux of many years back.

So, my simple suggestions is: Keep it up. Don't stop. Carry on.
A "df" would be nice. So would a real-time "top".

And since this is the "Networking" suggestion-box: Here is one:
How about a Linux-style, straightforward network management tool using some open Linux/Unix standard information - and inside a graphic display, using some industry-standard display technology like Tcl/Tk was supposed to be. Just something simple and clear and Unix-like which lets one see and maybe update a bunch of different machines - some Linux, some Windows, some Apple Macs.

No one sane wants to use store-bought software now, for obvious reasons. The recent "viruses inside your upgrades" is the new trend, and it will only get worse. You have to manage and roll-out your own code.
If you have a small shop - you can quickly get to 20 or 30 devices and/or machines - and they may all be different.

The Linux/Unix approach gives enough commonality so that some work can get done, and some communication can actually be made to occur. We had a ton of stuff on an old Windows XP/SP3 machine, and the only way we could get it to migrate over to a new Windows-10 box, was to run "scp -r". Nothing else would work, for various reasons.

So these Linux-like, open-standard utilities are just going to become more and more critical and useful, as the proprietary stuff becomes more fraught with risk, complexity and associated security problems. And as the migration back from cloud-computing solutions to the local, secure, firewalled office/enclave starts to gather steam, the need for open, clear, verifiable methods of moving information and getting stuff done will increase. Most of the work needed to create and maintain secure, verifiable and locally trusted computing enclaves has already been done - and it's been done with Unix/Linux open-source code.

So, your networking configurations are going to want to use that code, and that approach. And since you are most of the way there already, just keep moving in the direction that seems to be evident, and maybe I can get a nice little gui-type application that can let me manage my little cluster of machines, without having to pass around /etc/host files of IPv4 lists

I should be able to have an application that lets me schedule tasks and monitor and update a bunch of different machines easily. But I don't even have a program that can list which machines are up and operational on the local wi-fi and wirelinked LAN. Doubtless there are all sorts of proprietary solutions available - but thats just more grief and risk.

There should be simple, clear, open-standards methods that let me observe and inspect and verify operational integrity of all the devices in our enclave - and also monitor and verify the satellite like we are now using.

It should be as easy to use as OpenSSH and sshd and scp and rsync
. It should be as clear as IPv4 and as visible and as easy to list as the "ls -l" is in Linux.

There should be a Linux-type command for "List all the Wi-Fi devices connected to our routers" and "list all the wire-line linked machines, their current SHA256 hash-codes and IP numbers". And all this should work for Macbooks, Linux boxes, Windows machines, smartphones, laptops, and any other connected devices - such as security cameras and building-monitoring hardware (fire-alarms, rad-detectors, etc.).

Probably all this is available -but it is different for each class of technology. But it's the open stuff, built to common standards, that is the future. The "computing enclaves" will still be interconnected, but the connections will be monitored and tracked (as they probably are now already).

It's curious. I can run "top" on a single machine, and monitor the processes running - but there is no corresponding program to monitor the operation of a cluster of LAN-connected machines - or if there is, I cannot run this program on all the different hardware.

But once we get more Linux utilities like OpenSSH and sshd, then this will become possible. And that's the suggestion I am making - we need to move in that direction, because that is the only approach that can work. I want code that leverages the open-standard of the internet, for networked device and machine management - not some proprietary stuff that only works with one manufacturers' hardware.

- Mark Langdon, GEMESYS Ltd.

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

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

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

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