Some Notes on the Machines

The overall cause of buildup of orphan shadows in “System Volume Information” folders, is storage not being able to keep up with demand. If the situation is bad enough, this won’t help much, but it has helped in many instances. It’s three registry entries. Here’s Powershell code to get them in and engaged.

$NewMaxShadowCopies = 8
$NewMinDiffAreaFileSize = 128

# http://www.tomsitpro.com/articles/powershell_registry-powershell_command_line,2-152.html

function setupDWORD {
    param( [string]$regPath, [string]$nameForDWORD, [long]$valueForDWORD )

    ##############
    # Error out if cannot touch the registry area at all
    If ( !(Test-Path $regPath) ) {
        Try {
            New-Item $regPath -Force -ErrorAction SilentlyContinue
            }
        Catch {
            Write-Error ("Could not visit or create registry path " + $regPath)
            Return
            }
        }

    #############
    # If an existing registry entry exists, store its value to report later
    Try {
        $oldValueProperty = Get-ItemProperty -Path $regPath -Name $nameForDWORD -ErrorAction SilentlyContinue
        $oldValue = $oldValueProperty.$nameforDWORD
        }
    Catch {
        $oldValue = ""
        }

    #############
    # Report the changes to make
    Write-Output ("DWORD to write: " + $nameForDWORD)
    Write-Output ("at registry path " + $regPath)
    If ($oldValue -ne "") {
        Write-Output ("Original value is " + $oldValue)
        }
    else {
        Write-Output "No original present."
        }
    Write-Output ("New value is " + $valueforDWORD)

    ############
    # Report no changes to make, set new registry entry, or error out
	If ($oldValue -eq $valueforDWORD) {
		Write-Output "No change to make."
		""
		Return
		}
    Try {
        New-ItemProperty -Path $regPath -Name $nameForDWORD -Value $valueForDWORD -PropertyType DWORD -Force -ErrorAction SilentlyContinue > $null
        }
    Catch {
        Write-Error "Failed!"
        ""
        Return
        }

    "Succeeded!"
    ""
    }

setupDWORD "HKLM:\System\CurrentControlSet\Services\VSS\Settings" "MaxShadowCopies" $NewMaxShadowCopies

setupDWORD "HKLM:\System\CurrentControlSet\Services\VolSnap" "MinDiffAreaFileSize" $NewMinDiffAreaFileSize

setupDWORD 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows' 'DeleteStaleTaskCache' 1

""

"Restarting VSS..."

Restart-Service -Force -Name "VSS"

""

"Complete!"
""

This is a great way to get things removed where nothing else works.

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

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/

There have been many live CDs out there which have utilities to reset passwords on Windows. Unfortunately, many of them are long out of date and won’t work (or will do odd things) on recent hardware, and recent operating systems. This one:

https://www.supergrubdisk.org/rescatux/

was proven on 2022-12-21 to do well with the latest build of Windows 10.

Had a new one recently. A PC running Windows 10, up to date, was taking about 30 minutes to boot. Turning off Fast Startup seems to have fixed it. Reportedly this will do it:

powercfg /hibernate off

but I used a GUI method: Control Panel, Power Options, Choose what the power buttons do, Change settings that are currently unavailable, then unchecked “Turn on fast startup (recommended)”, then Save Changes.

The GUI method is reversible in GUI; the command-line method removed the GUI method from visibility.

Still not sure what the root cause of the situation is, or how to do prevention. But reportedly, a very large proportion of Windows users are in fact hibernating or similar, rather than turning off, and don’t know it, and this can cause Windows updates to fail and other issues related to networking.

Rather a handy tutorial:

www.tutorialspoint.com/how-to-change-pagefile-settings-using-powershell

This scenario is common, though not necessarily obviously so:

• Windows 8.1/2012R2 through 11/2022 is corrupt.
• DISM (DISM /Online /Cleanup-Image /RestoreHealth) won’t fix it, it reports needed data not available.
• The above DISM adding /Source:...INSTALL.WIM, where INSTALL.WIM resides on a mounted ISO of that Windows, even a freshly downloaded ISO, still fails due to needed data not available.

The fact is that #3 above occurs because freshly downloaded ISOs lack many Windows updates. This is not quickly resolvable, but it is very resolvable given some time. Using this method, we will fix corrupt Windows images. You’ll need many gigabytes of disk space to work with.

So. The first step is to decide which Windows version we’re going to create an up-to-date INSTALL.WIM for, to be used by DISM. For this example we’ll say 64-bit Windows Server 2016. The ISO can be had (at this writing) at this page.

Download that ISO, and unpack it. In the SOURCES folder at the root, there is a large file called INSTALL.WIM, 5.6 gigs at this writing. Create folder D:\Server2016WIM (or whatever works for you) and move that WIM into it.

You will need to go to the Properties of the INSTALL.WIM file, and uncheck “Read-Only”, for some reason.

Now we need a tool called wsusoffline. It downloads the updates which we are going to put in that INSTALL.WIM file. It comes from www.wsusoffline.net. Unpack the zip file and run UpdateGenerator.exe. Set it up like this:

Make sure the “USB medium” target directory is useful and handy, We’re not using USB for this, just a different folder on the same drive that the WIM is in. Click Start, and it will download, verify, and store a whole lot of Windows updates in that folder. The above setup does make a repository for every 64-bit Windows 10-class OS, including Server 2016 and 2019. 2022 isn’t available here yet, we can expect it to be in the next edition of wsusoffline.

Once that download is done, we need to see which install(s) are in that WIM file. We do this thusly:

CD \SERVER2016WIM
DISM /Get-WimInfo /wimFile:install.wim

In the ISO I just downloaded, there are four installs, Server 2016 Standard without (1) and with (2) GUI, and Server 2016 Datacenter without (3) and with (4). Because our server to be repaired is not bare-bones, we want to update 2 and 4 just in case. So we prepare,

D:
CD \SERVER2016WIM
MKDIR Mounted-WIM

and mount the WIM in index 2:

DISM /Mount-WIM /WimFile:INSTALL.WIM /index:2 /MountDir:Mounted-WIM

The above will take a little while. We study D:\wsusoffline-output (see the wsusoffline image above), and we find that the Windows 10-class updates are here:

D:\wsusoffline-output\w100-x64\glb

So when the mount is done, we run the updates, still with current directory as above:

DISM /image:Mounted-Wim /Add-Package /PackagePath:D:\wsusoffline-output\w100-x64\glb

and a lot of nonapplicable updates are reported as errors, and a lot of successful updates are also reported, in a long report stream. This happens because every patch for every build of 10, 2016, and 2019 are all in that one folder. DISM knows which ones it needs, and will report success for those. But it often does not get them all on the first pass. So it can be helpful to run it again. Successful DISM fixes have been had without the second run, and the second run does take time, but the second is necessary for full completion.

Then we unmount and commit the changes:

DISM /Unmount-Wim /MountDir:Mounted-Wim /Commit

And it’s done! That WIM is ready to be used to de-corrupt a Server 2016 machine. We just have to get that file (6.5 gigabytes just now) onto a folder on the server or a network share, make that folder or share the current directory, and run:

DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:Install.wim:2 /limitaccess

That’s index 2, index 4 may be needed if servers have roles only found in Datacenter. And after the DISM, some machines will need SFC /SCANNOW, because although DISM will bring in the needed items, it will not always put them everywhere they are needed.

If power is lost during the WIM procedures, you will probably have to run a cleanup and start over again. Check thus:

dism /get-MountedWiminfo

and cleanup thus:

dism /cleanup-wim

Reportedly, you may need to run those more than once. You may also have to delete subkeys in the registry here:

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WIMMount\Mounted Images

and reboot, and then delete and recreate the folder Mounted-WIM.

See:

www.winhelponline.com/blog/slipstream-windows-10-integrate-updates-setup-media-iso/

Don’t know yet if it works with Server, or even how well it works yet, but this looks very interesting, most especially for DISMing an existing machine.

So we have the situation where we have multiple network interfaces, possibly including wireless, and we want to set priority, so if one is connected, that one will be used. Here’s a good working procedure, all in Powershell.

1. Get list of interfaces with the Windows index number for each:

Get-NetIPInterface | ft ifINdex,InterfaceAlias,AddressFamily

Now we have a list of interfaces and names. Each interface device may have two listings, one for IPv6 and one for IPv4. What we want is the index numbers for the two. On one machine, “Ethernet” was index 12, and “Wifi” was 18, but there will be wide variation.

2. Priority is higher, for lower numbers. So if we want to set high priority for wired Ethernet when it’s present, we could set priority 10:

Set-NetIPInterface -InterfaceIndex "12" -InterfaceMetric "10"

3. and to make it stick and work predictably, we set Wifi to priority 100:

Set-NetIPInterface -InterfaceIndex "18" -InterfaceMetric "100"

This works well as of this writing. I imagine the URL will change in the future.

[Net.ServicePointManager]::SecurityProtocol = "tls12, tls11, tls"
md -Path $env:temp\edgeinstall -erroraction SilentlyContinue | Out-Null
$Download = join-path $env:temp\edgeinstall MicrosoftEdgeEnterpriseX64.msi
Invoke-WebRequest 'https://msedge.sf.dl.delivery.mp.microsoft.com/filestreamingservice/files/a2662b5b-97d0-4312-8946-598355851b3b/MicrosoftEdgeEnterpriseX64.msi'  -OutFile $Download
Start-Process "$Download" -ArgumentList "/quiet"