Some Notes on the Machines

Does not seem to have a web page of its own, it is linked from others:

http://aka.ms/diag_printer10

Very informative:

https://support.hp.com/us-en/document/c05195282

and linked therein, a printer matrix:

https://support.hp.com/us-en/document/c04658195

It is far from clear what is going on, but here’s what I think I know:

• Lots of services are being created in Windows 10, 2016, and 2019 fitting the descriptions below.
• Many of these, but not all, have names with “_a1b2c” at their right-hand ends, where the characters and numbers are what look like non-random machine-readable strings, five characters long so far.
• Many of these, but not all, have been svchost.exe items, not standalone services.
• There are a variety of service names associated, including (on just this one machine) CaptureService_b8bc7, “Clipboard User Service_b8bc7”, “Connected Devices Platform Service”, “Connected Devices Platform Service_b8bc7”, “CredentialEnrollmentManagerUserSvc_b8bc7”, and many more. Of the list in this item, only the last is a standalone service, not a svchost item.
• There are a variety of svchost item names associated, including BthAppGroup, LocalService, and UnistackSvcGroup. In particular, the UnistackSvcGroup items can be googled, but thus far, it appears not known for what they are used.

Some of these services cannot be deleted with the SC command; some can. If one changes permissions in registry items, they all probably could. But the question remains, what are they for, what are our valuable computing resources being taken for? Thus far, no one has reported anything not working when they are stopped and/or deleted. We may be looking at infrastructure Microsoft is laying in our own machines before our eyes, for new software they will send.

As per the docs:

msiexec /qn /package ShadowProtect_SPX-6.8.4-5_x64.msi IACCEPT=STORAGECRAFT.EULA

This command, run from one domain controller, replicates to all of the others set up for this:

repadmin /syncall /AdeP

There’s an automatic “backoff” feature of Windows Indexing from Vista onward, which causes it to slow down and stop depending on other load. This can prevent Indexing from working altogether when load is high and/or searchable datasets are very big. To fix this, change this registry entry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Search\Gathering Manager\DisableBackoff

to a numeral 1. You will probably have to change the owner of “Gathering Manager” to Administrators in order to do so. After this change is made, restart Windows Indexing.

Great info:

https://www.laptopmag.com/articles/move-onedrive-folder

There are several attempts, this one I have found to be by far the most reliable:

https://fastcopy.jp/en/

In an administrative Powershell, all of the following. Some OSes will not have all of them, just ignore any errors. Yesterday (10/23), on an older machine running Windows 10 with 8G RAM and a 1/2T platter drive, SATA bandwidth was showing a tad less than 1 megabit in Resource Monitor; afterwards, 10 megabit. Most gains have not been so high.

Enable-MMAgent -ApplicationLaunchPrefetching
Enable-MMAgent -ApplicationPreLaunch
Set-MMAgent -MaxOperationAPIFiles 8192
Enable-MMAgent -MemoryCompression
Enable-MMAgent -OperationAPI
Enable-MMAgent -PageCombining
Set-Service sysmain -StartupType Automatic
Start-Service sysmain

The last two enable and start the service, if necessary. The service is called Superfetch in services.msc, but very clearly, it does a whole lot more than drive fetching. It is not clear how the observed drive bandwidth increase is achieved. One theory has it that, with appropriate configuration, the service reorders OS disk reads and writes for maximum sequentiality, minimum seeks.

Here’s a great place to start:

Get-CimInstance -Class Win32_OperatingSystem | ForEach-Object -MemberName Caption

This gets profoundly useful strings like “Microsoft Windows 10 Enterprise”. If you need the numeric version, the best so far has been:

(Get-ItemProperty -Path c:\windows\system32\hal.dll).VersionInfo.FileVersion

which, right now on this machine, gets us “10.0.18362.387 (WinBuild.160101.0800)”. And for the Windows 10 build:

(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion' -Name ReleaseID -ErrorAction Stop).ReleaseID

which gets “1903”. All of these are fast, do not depend on systeminfo, and appear to be nice and reliable.