Some Notes on the Machines

NETBIOS is a very legacy protocol, security of it is very poor. Substantial performance gains by disabling it have been noticed, because when active it broadcasts to every single NIC on its LAN, creating NIC and switch contention. Also, a large proportion of security violation exploits use it, so disabling becomes a very good idea in general. The only exceptions occur when there are needs to do SMB sharing with very old machines, machines all long out of support. By default, it is still active on all current Microsoft Windows operating systems.

The following turns off NETBIOS over TCP/IP, for each NIC:

Get-CimInstance -ClassName 'Win32_NetworkAdapterConfiguration' | Where-Object -Property 'TcpipNetbiosOptions' -ne $null | Invoke-CimMethod -MethodName 'SetTcpipNetbios' -Arguments @{ 'TcpipNetbiosOptions' = [UInt32](2) }

And another to get rid of all WINS entries, if present (sorry, no CimInstance code yet):

Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled='True'" | Invoke-WmiMethod -Name SetWINSServer -ArgumentList @('','')

We can also script the uncheck of LMHOSTS lookups:

$nicall = [wmiclass]'Win32_NetworkAdapterConfiguration'
$nicall.enablewins($false,$false)

All together then:

Get-CimInstance -ClassName 'Win32_NetworkAdapterConfiguration' | Where-Object -Property 'TcpipNetbiosOptions' -ne $null | Invoke-CimMethod -MethodName 'SetTcpipNetbios' -Arguments @{ 'TcpipNetbiosOptions' = [UInt32](2) }

Get-WmiObject Win32_NetworkAdapterConfiguration -Filter "IPEnabled='True'" | Invoke-WmiMethod -Name SetWINSServer -ArgumentList @('','')

$nicall = [wmiclass]'Win32_NetworkAdapterConfiguration'
$nicall.enablewins($false,$false)

If Microsoft DHCP is in use, DHCP can tell clients to do this:

learn.microsoft.com/en-us/troubleshoot/windows-server/networking/disable-netbios-tcp-ip-using-dhcp

Below is another script, to reenable the protocols, though it does not try to put back any WINS server IPs that may have been deleted, and it cannot override Microsoft DHCP:

Get-CimInstance -ClassName 'Win32_NetworkAdapterConfiguration' | Invoke-CimMethod -MethodName 'SetTcpipNetbios' -Arguments @{ 'TcpipNetbiosOptions' = 0 }

$DisableLMHosts_Class=Get-WmiObject -list Win32_NetworkAdapterConfiguration
$DisableLMHosts_Class.EnableWINS($true,$true)

Microsoft is loading Windows with gaming bits and other things which take resources. The last two builds of 10, and 11, have ‘winget’, which make it quite easy to remove other things:

Get-ProvisionedAppxPackage -Online | `
Where-Object { $_.PackageName -match "xbox" } | `
ForEach-Object { Remove-ProvisionedAppxPackage -Online -AllUsers -PackageName $_.PackageName }
winget uninstall "Phone Link"
winget uninstall "Movies & TV"

There are machines with (say) 16 gigabytes of RAM, where Task Manager shows 97% or more memory in use, but the numbers don’t add up even close to 16G. The first step is to get RAMMap:

learn.microsoft.com/en-us/sysinternals/downloads/rammap

and study the Use Counts tab list. There may be more than one cause, but the one I’m looking at, shows most of my RAM used by “Driver Locked”. Microsoft says updated drivers will fix it. Will continue this article when I have data. Current references:

learn.microsoft.com/en-us/answers/questions/128755/driver-locked

learn.microsoft.com/en-us/windows-hardware/test/assessments/windows-assessment-console

learn.microsoft.com/en-us/windows-hardware/get-started/adk-install

At least on this office LAN, this is helping. Not clear whether it helps everywhere and all.

In Regedit, go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces

You’ll notice several GUIDs. These are all of the network interfaces Windows knows about, virtual, Bluetooth, whatnot. You’ll want to try adding the below to any of them that you use.

TCPAckFrequency = 1

Technically this is called “disabling delayed ACK”. It seems to be helping me a lot for all accesses, including SMB, intranet, and Internet.

One can disable using UI and registry, but the processes still run and take more RAM than is obvious in Task Manager. Removal takes this:

Get-AppxPackage -Name MicrosoftWindows.Client.WebExperience -AllUsers | Remove-AppxPackage -AllUsers

This one has a lot of very nice performance tweaks, and a defrag within that seems to do a good job, though one cannot defrag an SSD, only TRIM.

www.wisecleaner.com/wise-care-365.html

Run it like this from administrative CMD, in two steps. In the first step just check everything off. The second step runs it all. Cleans a whole lot more than any other way, and after you do the first step, the second step stays put, the number is actually the maximum index of sets of cleanup that you can keep around for future semi/automatic use.

Cleanmgr /sageset:65535 

Cleanmgr /sagerun:65535

Recently it was discovered that a Windows server was running very slow because the Security log’s maximum size was set to 40 gigabytes. Here is a Powershell bit which will look at all event logs, set their max size to 2.5M if set larger, and clear them. Seems to free up a nice healthy dollop of performance in general.

wevtutil el | Foreach-Object {
	$LogObject = Get-WinEvent -ListLog $_
	If ( $LogObject.MaximumSizeInBytes -gt 2500KB ) {
		"$_ has max set to larger than 2.5M.  Setting to 2.5M."
		$LogObject.MaximumSizeInBytes = 2500KB
		$LogObject.SaveChanges()
		}
	wevtutil cl $_
	"$_ cleared."
}

There are times when an operation, a software install or configure perhaps, will error with “Cannot open log for source ———-. You may not have write access.” The below will do the above, and also give read/write to every local admin.

wevtutil el | Foreach-Object {
	wevtutil sl $_ "/ca:O:BAG:SYD:(A;;0x1;;;SY)(A;;0x5;;;BA)(A;;0x1;;;LA)(A;;0x3;;;LA)"
	$LogObject = Get-WinEvent -ListLog $_
	If ( $LogObject.MaximumSizeInBytes -gt 2500KB ) {
		"$_ has max set to larger than 2.5M.  Setting to 2.5M."
		$LogObject.MaximumSizeInBytes = 2500KB
		$LogObject.SaveChanges()
		}
	wevtutil cl $_
	"$_ cleared."
}

The security string is written in something called SDDL. Some more info:

https://itconnect.uw.edu/wares/msinf/other-help/understanding-sddl-syntax/

Recently a number of things have come to light together, the combination of which is remarkable.

1. The System Volume Information folder, on very many slow Windows machines, has a lot of junk files within, files that serve no purpose. These are called “orphan shadows”.
2. Orphan shadows occur when the RAID or other drive capability of a Windows machine, cannot keep up with demands on the Volume Shadow Services (VSS) subsystem of Windows, and/or has to abandon an effort in midstream. VSS is used by a huge variety of Windows and application operations.
3. The best-understood examples of events causing orphan shadows, are hard poweroffs in the middle of many different operations large and small. Another is when block-level backups fail.
4. Other examples are simultaneous heavy demands which are too high for the RAID or drive capability. For instance, if demands on RAID are already fairly high, a large database request happening at the same moment as the incremental for a backup will cause one or both to fail, and will create orphan shadow(s) for one or both.
5. As orphan shadows build up, they take more and more space in System Volume Information, and when SVI has more than 20 gigabytes or so of these things, all VSS operations get slower and slower, presumably because the VSS system has to choose to bypass all of the orphans over and over again.
6. SVI has been seen to rise to hundreds of gigabytes, sometimes taking hours to clear.

The short-term step, to get things working, is to clear SVI. On a client OS, this is done thus:

vssadmin delete shadows /all

On a server OS, we do the above, and then we also run diskshadow, and within that little environment, we do:

delete shadows all

Alternatively, we can replace all of the above steps with:

wmic shadowcopy delete /nointeractive

One situation has been seen thus far, where the above two do not do the job, where SVI remains huge. No standard solution has been identified for this as of yet. Up until now, the symptoms have been clear and obvious, but causality a lot more mysterious, and we have often alleviated the situation via removal of OEMware, BIOS, firmware, and driver updates, and use of tweaking tools. On a server, one can remove Windows Defender:

Uninstall-WindowsFeature Windows-Defender

and this helps a lot (solved one big problem so far) on server, but not on a client OS, Microsoft doesn’t allow it. Also, methods to disable bits of Windows Defender on client OS have been disallowed increasingly, as build upgrades have been given.

One step which has helped is to CHKDSK /F the volumes and reboot, and then try the standard cleanout steps again.

Just today, some VSS tweaks have manifest:

https://docs.microsoft.com/en-us/windows/win32/backup/registry-keys-for-backup-and-restore?redirectedfrom=MSDN#maxshadowcopies

specifically this:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VSS\Settings
DWORD MaxShadowCopies

and this:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VolSnap
DWORD MinDiffAreaFileSize

but it will be a while of testing before any confidence is available as to how to use these to help. Thus far, MaxShadowCopies of 8 and MinDiffAreaFileSize of 128 seems to be helping.

Appears excellent on the desktop.

http://www.puransoftware.com/Puran-Defrag.html