Some Notes on the Machines

This method uses Powershell module PsWindowsUpdate.

First, a complete script which gets the module in and updates everything available from Microsoft, including patches and drivers and firmware:

#begin script
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Set-Executionpolicy RemoteSigned -Scope Process -Force
Install-PackageProvider -Name NuGet -Force -ErrorAction 'SilentlyContinue' > $null
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
If (Get-InstalledModule -Name PsWindowsUpdate -ErrorAction 'SilentlyContinue') {
	Update-Module -Name PSWindowsUpdate -Force
} Else {
	Install-Module -Name PSWindowsUpdate -Force
}
Import-Module PSWindowsUpdate
Install-WindowsUpdate -AcceptAll -AutoReboot
# end script

Next, the bits. We do need to install and keep up a module.

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Set-Executionpolicy RemoteSigned -Scope Process -Force
Install-PackageProvider -Name NuGet -Force -ErrorAction 'SilentlyContinue' > $null
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
If (Get-InstalledModule -Name PsWindowsUpdate -ErrorAction 'SilentlyContinue') {
	Update-Module -Name PSWindowsUpdate -Force
} Else {
	Install-Module -Name PSWindowsUpdate -Force
}
Import-Module PSWindowsUpdate

Then we can check the list of available updates:

Get-WindowsUpdate

And then we probably want to actually do updates. There are good reasons and multiple methods to be careful. Alas, thus far, there does not appear to be a way to install updates a given number of days after release, e.g., 30, so as to give Microsoft time to respond to issues. Here is a glancing overview of what we do have:

Install-WindowsUpdate -NotCategory "Drivers","Service Packs","FeaturePacks" -NotTitle "preview" -AcceptAll 

Install-WindowsUpdate -NotCategory "Drivers","Service Packs","FeaturePacks" -NotTitle "preview" -AcceptAll -IgnoreReboot

Install-WindowsUpdate -AcceptAll -AutoReboot

Install-WindowsUpdate -NotKBArticleID KB1234567 -AcceptAll

Install-WindowsUpdate -NotKBArticleID KB1234567 -AcceptAll -IgnoreReboot

Install-WindowsUpdate -AcceptAll -NotKBArticleID "KB1234567,KB7654321"

Reset-WUComponents

Get-Command -Module PSWindowsUpdate

The Powershell below, calls all of the tools listed for it here.

#begin script

if (([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
    {
    "Running elevated; good."
    ""
    } else {
    "Not running as elevated.  Starting elevated shell."
    Start-Process powershell -WorkingDirectory $PWD.Path -Verb runAs -ArgumentList "-noprofile -noexit -file $PSCommandPath"
    return "Done. This one will now exit."
    ""
    }

Set-ExecutionPolicy Bypass -Scope Process -Force

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls -bor [Net.SecurityProtocolType]::Tls11 -bor [Net.SecurityProtocolType]::Tls12;

Import-Module BitsTransfer

$ps_script_list = @(
    'mma-appx-etc.ps1',
    'RunDevNodeClean.ps1',
    'wt_removeGhosts.ps1',
    'TweakDrives.ps1',
    'TweakSMB.ps1',
    'OWTAS.ps1',
    'OVSS.ps1',
    'CATE.ps1',
    'TweakHardware.ps1',
    'TweakMemTCP.ps1'
    )

$wco = (New-Object System.Net.WebClient)

ForEach ($ps_script in $ps_script_list) {
	$download_url = "https://github.com/jebofponderworthy/windows-tools/raw/master/tools/$ps_script"

	""
	"--- Downloading $ps_script... ---"
	Invoke-WebRequest -Uri $download_url -Outfile ".\$ps_script"

	$run_script = ".\$ps_script"

	& $run_script
	Remove-Item ".\$ps_script"
	}

$wco.Dispose()

#end of script

It’s built into most OEM installs of Windows 10 and 11, and can often be installed. On server builds it’s touch and go.

To see if you have it, try winget list from CMD or Powershell.

One good way to test it, is to install Microsoft .NET framework (SDK) 6, thus, from administrative Powershell:

winget install --id Microsoft.DotNet.Runtime.6 --silent --accept-source-agreements

I learned just now that if you add other seemingly valuable options to the one above, e.g., --scope machine, at least while running as SYSTEM, it will fail citing package not found. So you’ll want to test carefully.

Here’s one proven just now for 7zip (there’s a “search” option in winget to get the ID):

winget install --exact --id 7zip.7zip --accept-package-agreements --silent --scope machine

Here’s one for Google Chrome, needs a bit of extra:

winget.exe install --exact --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements --scope machine

And here’s a way to upgrade everything Winget can upgrade. There are some systems to not use this on, e.g., anything with some Autodesk products:

winget upgrade --all --include-unknown

If you do want to use it from the SYSTEM account, in scripting, it gets interesting. You’ll want to first run the below, and then winget will run as expected.

# Function to find the path to winget.exe
function Find-WinGet-Path {
    # Get the WinGet path (for use when running in SYSTEM context).
    $WinGetPathToResolve = Join-Path -Path $ENV:ProgramFiles -ChildPath 'WindowsApps\Microsoft.DesktopAppInstaller_*_*__8wekyb3d8bbwe'
    $ResolveWinGetPath = Resolve-Path -Path $WinGetPathToResolve | Sort-Object {
        [version]($_.Path -replace '^[^\d]+_((\d+\.)*\d+)_.*', '$1')
    }
    if ($ResolveWinGetPath) {
        # If we have multiple versions - use the latest.
        $WinGetPath = $ResolveWinGetPath[-1].Path
    }

    # Get the User-Context WinGet exe location.
    $WinGetExePath = Get-Command -Name winget.exe -CommandType Application -ErrorAction SilentlyContinue

    # Select the correct WinGet exe
    if (Test-Path -Path (Join-Path $WinGetPath 'winget.exe')) {
        # Running in SYSTEM-Context.
        $WinGet = Join-Path $WinGetPath 'winget.exe'
    } elseif ($WinGetExePath) {
        # Get User-Context if SYSTEM-Context not found.
        $WinGet = $WinGetExePath.Path
    } else {
        Write-Output 'WinGet not Found!'
        Stop-Transcript
        exit 1
    }

    # Return WinGet path
    return ($WinGet -replace '\winget.exe','')
}

Function Add-PathVariable {
    param (
        [string]$addPath
    )
    if (Test-Path $addPath){
        $regexAddPath = [regex]::Escape($addPath)
        $arrPath = $env:Path -split ';' | Where-Object {$_ -notMatch 
"^$regexAddPath\\?"}
        $env:Path = ($arrPath + $addPath) -join ';'
    } else {
        Throw "'$addPath' is not a valid path."
    }
}

Add-PathVariable (Find-Winget-Path)

Installing has been even more interesting. I’ve tried a lot of things. The below worked very well just now on Server 2019. There may be one extra module install in it, will test when it comes up again.

#Begin winget installation

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Force > $null

Function PrepareModule {
	param( [string]$ModuleName )

	"Preparing Powershell environment: Getting online " + $ModuleName + " info..."
	$OnlineModuleInfo = Find-Module $ModuleName -Repository PSGallery
	"Preparing Powershell environment: Getting local " + $ModuleName + " info (if exists)..."
	$LocalModuleInfo = Get-InstalledModule $ModuleName -ErrorAction SilentlyContinue > $null

	If ($OnlineModuleInfo.Version -ne $LocalModuleInfo.Version) {
		"Preparing Powershell environment: Removing old " + $ModuleName + " (if exists)..."
		Uninstall-Module -Name $ModuleName -ErrorAction SilentlyContinue > $null
		"Preparing Powershell environment: Installing new " + $ModuleName + "..."
		Install-Module -Name $ModuleName -Repository PSGallery
		"Preparing Powershell environment: Importing new " + $ModuleName + "..."
		Import-Module -Name $ModuleName
		}
}

"Setting up to use Powershell Gallery..."
Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force
Set-PSRepository -InstallationPolicy Trusted -Name PSGallery

PrepareModule("NuGet")	

Install-Script -Name winget-install 

#End winget installation

Older hosted Exchange mailboxes, are starting to fail Autodiscover in newer Outlook installs. Below is a registry fix which gets them working. Apply the change and then reboot, then try it again.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Outlook\AutoDiscover]
"ExcludeHttpsRootDomain"=dword:00000001
"PreferLocalXML"=dword:00000000
"ExcludeHttpRedirect"=dword:00000000
"ExcludeHttpsAutodiscoverDomain"=dword:00000001
"ExcludeScpLookup"=dword:00000001
"ExcludeSrvRecord"=dword:00000001
"ExcludeExplicitO365Endpoint"=dword:00000001

Try this:

winget install microsoft.edgewebview2runtime --force

For a long time the standard was, contact your S1 support and receive a removal tool. The sweeper can still be found, but only old versions among rare people that held onto it, and it does not always work. This works sometimes:

SentinelOneInstaller_windows_64bit_v22_2_4_558.exe --clean_only --dont_preserve_config_dir --dont_preserve_agent_uid -t xyzpdqxyzpdq

You’ll want the latest .exe, not the above version. And if this is not an agent from your own console, in the place of xyzpdqxyzpdq, try “1”, or omit the -t … altogether. Sometimes works outside of safe mode, sometimes works inside.

This seems to be able to help. It does take down New Outlook and New Teams and any other Webview app first.

taskkill /f /im msedgewebview2.exe
$ResolveWingetPath = Resolve-Path "C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe"
    if ($ResolveWingetPath){
           $WingetPath = $ResolveWingetPath[-1].Path
    }
$ENV:PATH += ";$WingetPath"
winget install microsoft.edgewebview2runtime --force --accept-package-agreements --accept-source-agreements

This command line will upgrade many things:

winget upgrade --all --include-unknown

So we have a PC that is Azure-joined, not AD, not standalone. Domain admin is obvious. And we can set PC-local admin using domain admin. But how do we give an Azure user local admin rights? Well, the simplest is in administrative Powershell:

net localgroup Administrators /add "AzureAD\userupn@domain.com"

where userupn@domain.com is the UPN of the user, the user’s login into Azure/365. Note that the text AzureAD is not the domain name, it is literal characters as you see it here. In other words, a breakage of historical syntax!

Sometimes Windows’ relationship with 365, or a user’s profile, or just a user on a PC or terminal server, will not log into 365. This appears to be the result of corruption of cached credentials.

The most straightforward way is probably to nuke all User/Windows/Azure relationship and recreate. As written, this would probably be very bad on a terminal server, because it will nuke the relationship for all users and all profiles. So far, no per-user commands identified.:

Remove 365 accounts from “Access Work and School”, then run these:

dsregcmd /debug /cleanupaccounts

dsregcmd /debug /leave

from administrative CMD, and also from SYSTEM (paexec or psexec can do this), then reboot, then remove from Access Work and School if still there, then set up user relationship(s) again.

But today we have a report that dsregcmd /status did something, unknown, which fixed one terminal server user. Not sure what. Next time I plan to run many tests with this info:

ss64.com/nt/dsregcmd.html

And if you see error CAA5021, do this:

Search for Manage user certificates in the search bar and open it from Best match. Then navigate to Current User\Personal\Certificates and make sure the MS-Organization-Access and MS-Organization-P2P-Access entries are deleted.

No reboot needed for that last.