Some Notes on the Machines

Spotted these recently. All of these are to be run in administrative Powershell. On one Server 2019 machine, these boosted overall throughput from 7-25M to 600-700M.

File server ( Microsoft docs here )

Set-SmbServerConfiguration -EnableMultiChannel $true -force
Set-SmbServerConfiguration -EnableOplocks $true -force
Set-SmbServerConfiguration -ServerHidden $true -force
Set-SmbServerConfiguration -IrpStackSize 20 -force
Set-SmbServerConfiguration -MaxMpxCount 4096 -force
Set-SmbServerConfiguration -MaxWorkItems 16384 -force
Set-SmbServerConfiguration -MaxSessionPerConnection 16384 -force
Set-SmbServerConfiguration -TreatHostAsStableStorage $true -force

Clients ( Microsoft docs here )

Set-SmbClientConfiguration -EnableBandwidthThrottling $false -force
Set-SmbClientConfiguration -EnableLargeMtu $true -force
Set-SmbClientConfiguration -EnableLoadBalanceScaleOut $true -force
Set-SmbClientConfiguration -EnableMultiChannel $true -force
Set-SmbClientConfiguration -EnableSecuritySignature $false -force
Set-SmbClientConfiguration -MaxCmds 16384 -force
Set-SmbClientConfiguration -MaximumConnectionCountPerServer 32 -force
Set-SmbClientConfiguration -OplocksDisabled $false -force
Set-SmbClientConfiguration -RequireSecuritySignature $false -force
Set-SmbClientConfiguration -UseOpportunisticLocking $true -force
Set-SmbClientConfiguration -WindowSizeThreshold 2 -force

-WindowSizeThreshold may be good to set to 4 or 8.

Set-SmbServerConfiguration -IrpStackSize 15 -force
Set-SmbServerConfiguration -MaxMpxCount 50 -force
Set-SmbServerConfiguration -MaxWorkItems 1 -force
Set-SmbServerConfiguration -TreatAsStableStorage $false -force

Set-SmbServerConfiguration -EnableBandwidthThrottling $true -force
Set-SmbServerConfiguration -MaxCmds 50 -force
Set-SmbServerConfiguration -WindowSizeThreshold 1 -force

After a cleared positive from a major tool, this seems like a good suspenders-and-belt second scan:

https://docs.microsoft.com/en-us/windows/security/threat-protection/intelligence/safety-scanner-download

Our lawnmower finally wouldn’t start this year. I suspect it needs electrical cleanup or something, but it’s an extremely heavy Menard’s special which was a gift from a friend of Sweet Lori’s, and I just didn’t want to put money or time into it. So I put money into a new Toro 21” battery-operated mower. And I am flatly amazed.

It is lighter than anything I know of comparable in gas, even though its construction is nice steel; its maintenance is hose it off and charge the batteries; it folds vertical for storage (it’s set up well for this, and no liquids, no hot parts…); there’s absolutely no lack of power; and it mows our whole yard in half a battery. It’s a Toro 60V (same as my very happy leaf blower bought last year), so I have two more batteries if I need them. We have wonderful neighbors who have mowed our yard before, so I’m going to have that kind of fun soon.

But the most intriguing part for me, was what happened when the mower pulled us to denser growth. Immediately that thing knew it and increased the power output. The first and second time it happened I thought something might be wrong, but no, it knows, and it drives that power up and down according to need of the moment, immediately, no hesitation at all. (This is why well-implemented brushless motors are a very good idea.) For ages, some gas mowers have had “regulators” that are claimed to do the same thing, and I’ve used a number of them, but they’re nothing like this. It was “vroom!!!” and then wonder and look to see what was going on, and only then, “Oh, now isn’t that nice!” The only slight “gotcha” is that overall result tends to pull the walker occasionally, but for me that’s almost more of a plus than anything, it keeps me going at a good pace; I tend to be a slacker at mowing!

It was also interesting to see the result. I do the mulching thing, and not bagging or shooting, because I flatly don’t want the bother and the bags. Every other mulching mower I have ever seen work, leaves some larger bits as it addresses denser growth. Not this one. I walked around the whole yard after I was done, I had had the mower set on quite short, and I saw absolutely zero sign of cuttings. Zero. Amazing.

100 Kbps is more than enough.

…is often like a flying carpet in a hurricane.

There is some definite undocumented mystery concerning Volume Shadow Services in Windows. In general we are told to use VSSADMIN to do maintenance, and it does a lot, and helps a lot. But recently there was a Server 2012 R2 machine using 280G of space for System Volume Information on C:, and after CHKDSK and various DISMs it still was using 280G. So I tried removing all orphan shadows with VSSADMIN, and it found one and removed it; almost zero change comparatively. And then I searched a little deeper.

DISKSHADOW is built into Windows 2012 R2 and later, and earlier too I think, not sure how early. It may be a successor to VSHADOW which was an SDK add-on to 2003. Regardless, DISKSHADOW is a command-line environment of its own sort of like NSLOOKUP and DISKPART (!), not a simple command, can run a script of its own commands, and one of its commands is:

DELETE SHADOWS ALL

Now VSSADMIN DELETE SHADOWS /ALL deletes all orphan shadows, all VSS shadow copy sets which Windows knows are good to delete. The above within DISKSHADOW is a different animal altogether: it deletes them all. And does not appear to report anything to event logs (!). And definitely frees up a whole lot of space. And also, definitely not least, is flagged as infection activity by certain high-test super-anti-malware tools, when run! That was amazing, a Windows built-in being run with one of its own recommended commands, flagged. But I’ll think that that means this is to be used only when very needed. There may be gotchas I don’t know about yet.

As I write, the System Volume Information on this C: drive has been shrunken 290 (two hundred ninety) gigabytes, and everything is still running fine. There were originally 522 (five hundred twenty-two) shadow copies hanging out there of many different sizes, and DISKSHADOW was able to delete them all, all server services appear AOK.

DTX download:
https://www.storagecraft.com/downloads/diagnostic-tool-xplatform

DTX run:
https://support.storagecraft.com/s/article/How-To-Gathering-diagnostics-for-StorageCraft-Support?language=en_US

Enable ImageManager verbose logging:
https://support.storagecraft.com/s/article/Enable-Verbose-logging-for-ImageManager-6-6-and-later?language=en_US

In general Virtual Machine Queues are often disabled on Hyper-V hosts, to solve network slowness. However, if we go here:

HKLM\SYSTEM\CurrentControlSet\Services\VMSMP\Parameters

and add DWORD BelowTenGigVmqEnabled and set it to 1, or TenGigVmqEnabled for 10G, we can enable Virtual Machine Queues and get great speed indeed.

If this is going on, there is more than likely to be a malfunctioning sensor or two. In this situation you’ll need this:

https://www.techpowerup.com/download/techpowerup-throttlestop/

to get the machine to run at good speed. Do be careful with temperatures.

Microsoft is heavily using something called GeoIP, to optimize Internet data routing for its services, including Skype, Office 365, and all of the others.

All of the code below is within ‘nslookup’, running in CMD on Windows.

The way this works, basically, is different IP sets are reported by DNS lookups, depending on the upstream DNS server being polled. So if, like many right now, you were using Google’s DNS (8.8.8.8 and 8.8.4.4) on your LAN, and did nslookup on the recommended test hostname, outlook.office365.com, you would see this:

> outlook.office365.com
Server:  google-public-dns-a.google.com
Address:  8.8.8.8

Non-authoritative answer:
Name:    outlook-namsouth2.office365.com
Addresses:  2603:1036:0:26::2
          2603:1036:102:90::2
          2603:1036:404:a4::2
          2603:1036:102:107::2
          2603:1036:102:b8::2
          2603:1036:404:11b::2
          2603:1036:404:3f::2
          2603:1036:3:12e::2
          2603:1036:102:3e::2
          2603:1036:404:11c::2
          40.97.170.162
          40.97.30.130
          40.97.170.178
          40.97.142.18
          40.97.41.98
          40.97.162.130
          40.97.154.66
          40.97.166.178
          40.97.117.242
          40.97.119.178
Aliases:  outlook.office365.com
          outlook.ha.office365.com
          outlook.office365.com.g.office365.com

>

But on the other hand, if you were using OpenDNS (208.67.220.220/222.222), you would see this:

> outlook.office365.com
Server:  resolver1.opendns.com
Address:  208.67.222.222

Non-authoritative answer:
Name:    outlook-namsouth4.office365.com
Addresses:  2603:1036:d01:2::2
          2603:1036:101:2::2
          2a01:111:f400:31ab::2
          2603:1036:902:a3::2
          2603:1036:906:4d::2
          2603:1036:405:2::2
          2603:1036:405:15::2
          2603:1036:404:67::2
          2603:1036:100::2
          40.97.142.18
          40.97.41.98
          40.97.162.130
          40.97.154.66
          40.97.166.178
          40.97.117.242
          40.97.119.178
          40.97.170.162
          40.97.30.130
          40.97.170.178
Aliases:  outlook.office365.com
          outlook.ha.office365.com
          outlook.office365.com.g.office365.com

>

The most important thing to observe in the above, is that the IP set is different. And if you try pings from your test PC to each of the above IPs, you will notice major differences. In recent testing, most of Google’s results ping much slower (higher, in milliseconds) than OpenDNS’s. But we found OpenDNS’s pings noticeably slower than our current known best of breed, Level3 (209.244.0.3/4):

> outlook.office365.com
Server:  resolver1.level3.net
Address:  209.244.0.3

Non-authoritative answer:
Name:    outlook-namsouth.office365.com
Addresses:  2603:1036:404:16::2
          2603:1036:404:b6::2
          2603:1036:102:16::2
          2603:1036:405:29::2
          2603:1036:906:4f::2
          2603:1036:d00::2
          2603:1036:102:8f::2
          2603:1036:405:4a::2
          2603:1036:4:4c::2
          40.97.133.130
          40.97.132.194
          40.97.125.114
          40.97.132.226
          40.97.126.50
          40.97.31.50
          40.97.164.146
          40.97.136.194
          40.97.166.34
Aliases:  outlook.office365.com
          outlook.ha.office365.com
          outlook.office365.com.g.office365.com

>

We have also noticed that the lists of IPs do not correspond to names, i.e., outlook-namsouth3 does not return the same IP list each time. So there is a lot of highly complex geographically-centered IP routing by DNS, going on, by Microsoft, and Level3 seems to cooperate best.

The upshot is, if you see any Microsoft cloud-based services being slow, hesitating, freezing up, or losing connection regularly, switch your LAN’s DNS forwarders to Level 3, and you may well knock the problem out most easily. CloudFlare’s DNS works as well if not better.