Windows Update Error 0x80244022

Trying to patch one of my administrative servers and was receiving that error message. Server is 2016 standard, domain-joined, and there is WSUS in the environment along with the associated GPO’s for WSUS use.

Looks like this error is/was received due to the fact that my WSUS server was experiencing some issues.

  • Log into WSUS
  • Open IIS Manager
  • Navigate to Server Name > Application Pools
  • Find WsusPool
  • Start (or restart) this pool

In my case the pool had stopped due to an issue encountered when running a WSUS cleanup script. Starting it and then re-running the update check (retry button), yielded much better results.

Powershell Remote Windows Updates

Current employer has 3 forests, 3 domains, and 2 WSUS servers. During Covid (operationally speaking anyway), we’re in a 95% work-from-home status. One of our WSUS servers at some point in time decided to fill up its disks with updates. At another point in time, no one on the team thought it would be a good idea to setup monitoring or alerting for this system. Yay. Long story short, I have a love/hate relationship with WSUS.

For on-prem systems it works fairly well. GPOs put systems into specific groups (Workstations, Servers, Pilot Groups, etc), and an-eventually-implemented naming convention will allow IT Personnel to easily identify DEV, ADM, and PRD systems at a glance. Approving updates, pushing updates, and reporting updates all works.

What doesn’t work, however, is the automatic installation of updates. This post will turn into 2 posts: 1) Server-related, and 2) Workstation-related. The workstations, especially those that are remote, aren’t patching themselves on the regular. Probably because the users don’t VPN in often (or long enough) AND whomever set WSUS rules up didn’t specify an install-by required date for updates. Users are lazy and don’t like to reboot (myself included), so this just compounds the issue.

However, this post was more for the Server updates path. WSUS was setup to download patches, but the GPO for servers indicates that at no time will the patches be installed on servers. The previous regime had used batchpatch for that purpose. I’ve used PDQdeploy – SSDD. But since I said “previous regime”, and the last member of that batchpatch crowd left over a year ago, we’ve been woefully underpatched since pre-Covid.

Enter PowerShell. Note: I may clean this up a bit, but for now it’s the messy workthrough.

On EVERY managed system you need to have the following pre-requisites:

  • An Administrator account
  • WSMan configured to allow the host(s)
  • WinRM configured
  • PSWindowsUpdate PS Module

  1. Open PowerShell as an Administrator
  2. winrm /quickconfig
  3. Set-Item WSMAN:\localhost\client\trustedhosts -Value *
  4. Install-Module -Name PSWindowsUpdate

If the PSWindowsUpdate fails to install it’s generally due to the fact that you’re running PS 5.2 or below and it’s failing TLS requirements to run NuGet. Enable strongencryption on powershell, restart powershell, and re-run the PSWindowsUpdate to continue.

  • Set-ItemProperty -Path 'HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord
  • Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -Name 'SchUseStrongCrypto' -Value '1' -Type DWord

Now we want to create the PS1 file. I located this in my C:\scripts directory on a domain controller because it’s easier that way.

$Server = Read-Host -Prompt 'Enter a Fully Qualified computername.domain.tld - or multiple computers separated by comma and space'
$Credential = Get-Credential
Invoke-WUJob -ComputerName $Server -Credential $Credential -Script {Import-Module PSWindowsUpdate; Install-WindowsUpdate -NotCategory 'Drivers' -MicrosoftUpdate -AcceptAll -IgnoreReboot -SendReport -PSWUSettings @{SmtpServer='YOURSMTPSERVER.DOMAIN.TLD';From='WSUS@YOURDOMAIN.TLD';To='ITUSER@YOURDOMAIN.TLD';Port=25} | Out-File C:\PSWindowsUpdateLog.txt -Append} -Confirm:$false -verbose -RunNow

I’ll eventually remove the credential ask (and hardcode one in) and also have it pull from a comma delaminated file listing all of the required servers. Perhaps I’ll have it ask “which domain” with selections 1 to 3, then “enter credentials for XYZ domain”.

From here we want to save that PS1 file and then run it from the domain controller. Right-click run with powershell. Follow along. I should note that I have the following auto-admin code at the top of the script:

Check for run as administrator
 param([switch]$Elevated)
 function Test-Admin {
     $currentUser = New-Object Security.Principal.WindowsPrincipal $([Security.Principal.WindowsIdentity]::GetCurrent())
     $currentUser.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
 }
 if ((Test-Admin) -eq $false)  {
     if ($elevated) {
         # tried to elevate, did not work, aborting
     } else {
         Start-Process powershell.exe -Verb RunAs -ArgumentList ('-noprofile -noexit -file "{0}" -elevated' -f ($myinvocation.MyCommand.Definition))
     }
     exit
 }

Look for updates to this post for the workstations or servers. Or not. I get lazy sometimes.

Gnome popos Linux

I was reflecting on my tech career just last night and I thought it best to give a bit of background.

I grew up on Macs – a Macintosh SE with an 8MHz processor, 1MB RAM, a 720KB floppy drive, and a 20MB SCSI 25-pin hard disk drive. Running OS 6.

From there we acquired a PowerMac 7100/80AV. Had a 80MHz processor, 16MB RAM, 700MB 50-pin SCSI hard disk drive, and a 1.4MB FDD. Oh and a 2x CDROM – I fondly remember the sounds this would make when trying to load Myst. We also successfully upgraded this to 24MB RAM and replaced the 700MB HDD with a 2.1GB version.

The first internet-connected Mac was next: the PowerMac G3 minitower. This featured a 233MHz processor, 32MB RAM, and a 4GB HDD. The CDROM was a 24x, and the FDD was still there. Ours came with a 100MB Zip drive too. We upgraded to 64MB RAM, added a 12x CD Burner, and replaced the HDD with a 20GB eventually. This came with OS 8, and we attempted to load OSX beta and it was Slow AF.

A buddy and I decided we wanted to try our hands at Linux – I acquired an AMD K6-2 350MHz with 32MB RAM and a 40GB HDD. Playing around with ISA and PCI network cards was fun (10/100). We originally ran Redhat as an internet router, but when the install broke (my fault, but that’s how I learned breaking/fixing), I replaced with Slackware Linux instead.

At this time I started College and I got 2 computers – the first was a PowerMac G4 dual 450Mhz with 128MB RAM, 30GB HDD, and an external Firewire 12x CDBurner. This also had a 100MB Zip Drive. Eventually upgraded to 3x 80GB HDD in RAID5 along with 512MB RAM. Came with OS9 which I upgraded to OSX. The second was a custom built AMD – Asus Board with an AMD Athlon Thunderbird running at 1.4GHz, 40GB HDD, 24x CD Burner, and 128MB RAM – I believe I upgraded it to 256MB at some point. Ran Windows 2000 on this.

I bought a used white iBook 500MHz 64MB RAM 20GB Drive somewhere along the way – it was pretty slow even for the time.

It gets a bit hazy here since I started building PC’s for family and friends.

I bought a used HP Laptop – maybe like an N810 or something? It was back when HP/Compaq merged.

I got a couple laptops for free – gateway tablet and a EeePC (Asus netbook).

ANYWAY, since I’m getting wordy and not actually accomplishing anything, I wanted to say this was now the 3rd time in my career that I’ve attempted to go “Full Linux” on my work computer. The first time ended poorly when I kept breaking the installation (Ubuntu 8.04), the second time I had a systemboard die, although I was cheating on that – Running Linux MX with virtualbox running Win10.

Now I’m running PopOS. I have a VM of Win10 just in case, but overall I’ve been happy as a clam just using the linux OS. Slack, Cisco VPN, RDP, Browser.. it just works for me.

The only problem I had – being my first GNOME GUI – was the lack of a task bar at the bottom. Easy fix:

https://extensions.gnome.org/extension/1160/dash-to-panel/

Date Last opened for all applications

Because several applications are paid separately (Visio is the example) from the rest of O365, and we were running low on licenses (and we also didn’t have a Software Audit tool installed), I had to find the quick and dirty (ie cheap and fast) way of finding out the information required.

It was easy to pull who had a license associated with their account. Just log into the Admin Portal admin.microsoft.com, navigate under Billing > Licenses > click on the product.

In my case it’s Visio Plan 2. Licenses 0 available, 32 assigned.

Powershell to the rescue

$name = $env:COMPUTERNAME
$path = "\\fileserver.domain.tld\share\subdir\" + $name + "_lastusedApp.csv"
Get-ChildItem -Path ${env:ProgramFiles(x86)} -Filter "*.exe" -Recurse | Get-ItemProperty | select name,lastaccesstime | sort -Property lastaccesstime | Export-Csv -Path $path -Encoding ascii -NoTypeInformation

Just need to run that remotely on the system. You can psexec or I was trying to use the invoke-command but was coming up with lack of rights to run remote scripts and didn’t need to look any further.

The .csv then shows a list of all installed applications and the last time they were opened. Unfortunately if someone never reboots their system (uptime over a year or so) and keeps the application(s) open that entire time, it’ll appear as though they haven’t “used” it in the last year. Just something to keep in mind.

Tinypilot KVM

I decided to get a tinypilot kvm device for testing purposes – it’s actually pretty neat. Sure I could have saved a few bucks by building it myself, but this way I save time and support someone else’s great ideas.

Anyway, to update the device, SSH to it (DNS name is generally tinypilot)

Login with tinypilot/flyingsopi

Run

/opt/tinypilot/scripts/upgrade && sudo reboot

Corrupt User Profile

Eventviewer was showing Event ID 1515 and I was logged in as with a temporary profile. No other user was experiencing this, so I went about fixing with REGEDIT.

  • Open Regedit
  • Start > Run > regedit
  • Navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\
  • Find any profiles with “.bak” in them
  • Delete the .bak entire subkey
  • Log off, log on

Windows Apps

So this all started because I was unable to open the Windows Security Center. It just wouldn’t open.

I tried to open SecHealthUI.exe directly (C:\Windows\SystemApps\Microsoft.Windows.SecHealthUI*\) and that failed out. Eventviewer showed Faulting application name: sechealthui.exe, faulting module name: KERNELBASE.dll. Someone wanted me to re-run the kernelbase.dll registry (regsvr32 kernelbase.dll) which doesn’t do anything unless you give yourself administrative privs to the kernelbase.dll file. And didn’t fix my issue anyway.

What did help me was re-installing all of the Windows Apps with the following powershell command:

  • windows key + x
  • Select Windows Powershell (Admin)
  • Get-AppXPackage -AllUsers | Foreach {Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"}
  • Profit

And, because this is entitled “Widnows Apps”..

  • Uninstall XBox Windows-related items
  • Select Windows Powershell (Admin)
  • Get-AppXPackage *xboxapp* -AllUsers | Remove-AppXPackage

Ramblings Of An IT Person