Automated Windows Updates with PowerShell and PowerCLI

Holy cow it’s been a while!  Real life must be catching up with me or something, I am not sure.  Anywho, I’ve had this issue where I have never felt comfortable automating Windows Updates on my servers in case the worst should happen.  Seems like a reasonable concern right?  Well I finally got over it, did some digging, and found a suitable solution that I am comfortable with.

It really is quite simple.  I hijacked some PowerShell modules from Technet Script Center (found here) and then did some work with the PowerCLI module from VMware to take a snapshot prior to the updates.  Once it is done taking a snapshot of a VM (I pull them from an array) it will begin updates, and restart as needed.  I do not delete the snapshots in an automated fashion at this time, I just check everything is still good when I get in the office in the morning and then remove them all with PowerCLI (assuming there is no issues) as seen below:

Since I said I run this while I’m sleeping, I obviously just have it set up with Task Scheduler running with a service account I created with access to all the necessary servers and my vCenter environment.  Without further ado, I give you what I have coined “UpdateAutoPilot” below:



Server 2016 WSUS Clients: Windows Update Client failed to detect with error 0x8024401c.

So I just got done deploying WSUS on Server 2016 and everything seemed to be going fine.  Got my client side targeting rocking and a rolling, got the automatic update check time interval shortened up (I prefer 12 hours to the 22 hour default), and all the other nonsense.  A few machines report in no problem so I decide to add in all the servers for one of my customers.  And so down the rabbit hole I went.

About two of the ten machines I added would actually report in.  The eight that did not would show up in the MMC console, in the appropriate Computer Group, but would not report their status.  I went to one such client and was faced with this error: Windows Update Client failed to detect with error 0x8024401c.  I went and checked out the log at C:\Windows\SoftwareDistribution\ReportingEvents.txt and found essentially the same thing (see below).

I did some digging around and followed all the troubleshooting steps from Microsoft’s Support Page to no avail.  At long last I stumbled upon this serverfault article.  Granted the client machines I was working with were Server 2016 and the article pertains to Windows 10, but in the end the kernel isn’t all that different so I figured it applied.  As the answer recommended I made the following changes to the IIS App Pool on the WSUS box:

I wasn’t out of the woods yet, it was still only working intermittently; I went from two reporting in successfully to four.  So I started digging around the boxes that were not working and noticed that BITS was set to manual.  I’ve found this is normal on Server 2016 (strangely), but I said “Hey, let’s try getting that running and try reporting in.”  Sure enough that did the trick.  Checked for updates successfully and reported in seconds after running wuauclt /reportnow.

It’s been a couple days since and I’ve added a few hundred client machines with no issues.  Updates are running smooth (knock on wood).

Windows Server 2008R2 Update KB3161949 Causes SMB Issues

I have had this issue plaguing my help desk for a while now without being able to find the root cause.  Eventually, they convinced me it wasn’t the two particular MFP’s having issues (I have dozens deployed with no issues) and I started digging.  I came across the issues with KB3161949 while I was digging and saw that these two MFP’s hadn’t worked since I installed that update (let’s just make it easy and say until I came around WU’s were never done on servers).  Anywho, I just followed the instructions from the technet article, bounced the box, and when we tested the next morning it was right as rain.


Value Name: AllowNBToInternet
Type: Dword
Value: 1
Default value of the flag: 0