Updating causing problems again!

Topic

New Reply

Hey Y’all,

I was recently updating an old Microsoft Surface Pro given to me by a friend who no longer wanted it as he had replaced the battery once but it only lasted another year. The machine works fine plugged in though.

I did a clean install of W10 Pro, undated it to the latest release, and then proceeded to load my PowerShell scripts to see what was on the inside. Much to my dismay I received this error message:

Get-WUSettings : Object reference not set to an instance of an object.
At G:\BEKDocs\Scripts\Dev-CMsLocalPCInfoW10-V-06-10-01.ps1:4527 char:18
+    $WUSettings = Get-WUSettings
+                  ~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Get-WUSettings], NullReferenc 
   eException
    + FullyQualifiedErrorId : System.NullReferenceException,PSWindowsUpdate.Ge 
   tWUSettings

Now this works fine on my other machines, or at least I thought so. So I started to investigate and couldn’t initially nail down the problem as all the necessary modules were loaded, namely PSWindowsUpdate! Finally, I tried it on my other machines with mixed results.

All machines running Win 10 Pro with the exception of the Tiny11 Pro Laptop.
Main Driver: DellXPS8920 – OK
Backup Test: DellXPS8700 – OK
Laptop Tiny11: Dell137000 – Failed!
Wife Laptop: Dell Inspiron – OK
Surface Pro 4: – Failed!

Note: the problem was manifested on Windows PowerShell & PowerShell Core 7.3.4.

After hours of beating my head on the keyboard I finally saw it!
All the working machines had PSWindowsUpdate 2.2.0.2.
Both the failing machines had PSWindowsUpdate 2.2.0.3!

Why the difference? Well that’s still a mistery as two machines one failed and one working were running Win 10 Pro Build 19045.2846.

While, another working machine had Win 10 Pro Build 19045.2728.

So just what triggers the update of these powershell modules? Could it be .Net updates? I looked at that and they are all over the place with no pattern between the machines. Ideas?

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

Replies

Let me ask a Powershell guy I know. I’m guessing the Tiny Win11 is part of it’s build process but the Surface one, not sure about that.

Susan Bradley Patch Lady/Prudent patcher

Reply | Quote

You wrote:

I did a clean install of W10 Pro, undated it to the latest release, and then proceeded to load my PowerShell scripts to see what was on the inside.

Where did the PS modules come from? If you did a “fresh” install-module on PSWindowsUpdate, without specifying a specific version, then it would load the current module – which is 2.2.0.3.

Windows updates do not update third-party PS modules.

Reply | Quote

There must be some way to blame it on Microsoft, Shirley?

Reply | Quote

I’ve chosen to delete a possibly inapproriate rejoinder to the previous post.

Reply | Quote

MBS,

Well, that got me to thinking… Possible solution…

Uninstall-Module -Name PSWindowsUpdate -Force
Install-Module -Name PSWindowsUpdate -RequiredVersion 2.2.0.2 -SkipPublisherCheck -AllowClobber

So that got the right module loaded, however it did not solve the problem in either WindowsPowerShell 5.1 or PowerShellCore 7.3.4.

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

Hey Y’all,

Here’s the latest and even more confusing testing results.

On the Tiny11 install I restored an Image from 3/22/2023. Now no more error messages, however the GPO settings page comes up with the titles but no values.

Ran Windows Update to get current with the same results.

Installed PowerShell Core 7.3.4 (a Windows Update option) with the same results.

Went into GPedit to see what the settings were but got errors that it could not
appv.admx
MidcrosoftEdge.admx
UserExpreienceVirtualization.admx

in the C:\Windows\PolicyDefinitions folder, however, they are clearly there?

I downloaded the admx.msi program from MS and reinstalled the files with the same result. Looks like I found a problem with Tiny11b2.

I have an Image of the Surface Pro from 4/7/2023 so that will be my project for tomorrow and see what happens.

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

Here we go again!

Brand new just out of the box Beelink Ser 5500u w/Windows 11 Pro.
I thought surely this would work but it’s not to “bee”, get it?, same error.
GPEdit works fine on this machine so that’s not the problem.

Installing the previous version of the PSWindowsUpdate module didn’t work either.

Grrrrrrrrrrrrrrr!

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

Good Morning, Afternoon, Evening, or Night,

I have found the problem,
Apparently PSWindowsUpdate does not like it when there is no updateserver url set at
“HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate\WUServer”
and
“HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate\WUStatusServer”
keep in mind that WUServer and WUStatusServer are not folders but are instead items of the folder WindowsUpdate in the registery

So if you were to remove one it would look like this:
Remove-ItemProperty -Path “HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate” -name “WUServer”
hope this helps!

Reply | Quote

@RetiredGeek

Ran into this issue myself today..

Carter/Guest, if you are still around as a guest and see this, thank you for posting the details as well.

From what I can tell, somewhere along the way of updates to PSWindowsUpdate, the developer/maintainer must have changed the way the modules “Get-WUSettings/Set-WUSettings” commandlets/functions work and introduced a issue/bug..

I found today that if any policy/config for WindowsUpdate exist in:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

or below in a sub key it seems… and the value named “UseWUServer” is not present at:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

The module’s function for reading the values encounters an error. Although there are policies that can be configured without configuring the use of a WSUS server, it appears that if  “UseWUServer” is not present (set to either 0 or 1, with 0 being to not use a WSUS Server and 1 being to use a WSUS Server) but any other setting is present, you will receive an error:

Object reference not set to an instance of an object.

Possibly the same issue noted in the GitHub issue for the module at the followin:
https://github.com/mgajda83/PSWindowsUpdate/issues/21

 

Reply | Quote

Mike,

Apologies for the late response. (In my business I had stopped checking back on this page for a response/questions you might have had)
I’m still here.

I tested this morning and confirmed your information regarding the key UseWUServer needing to be set.
I removed the keys for the “WUSever” and “WUStatusServer”, set the Key for “UseWUServer” to zero(0); Additionally, I also set a secondary key which I have recently been using: “RepairContentServerSource” to the value “00000002”.

In practice this is what I do in powershell:
Remove-ItemProperty -Path “HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate” -name “WUServer”; Remove-ItemProperty -Path “HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate” -name “WUStatusServer”; Set-ItemProperty “HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU” -name “UseWUServer” -Value 0 -Type DWord; Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing” -Name “RepairContentServerSource” -Type DWord -Value “00000002” -Force; Set-ItemProperty -Path “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing” -Name “CountryCode” -Value “US” -Type String; Restart-Service WaaSMedicSvc -Force; Restart-Service TrustedInstaller -Force; Restart-Service msiserver -Force; Restart-Service wuauserv -Force; Restart-Service UsoSvc -Force; Restart-Service bits -Force

The machines were able to pull updates successfully without any errors.

Reply | Quote