Subscribe via Email

Subscribe via RSS/JSON


Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Get-WindowsUpdateLog SymSrv.dll error

Starting with Windows 10 and Server 2016 Microsoft isn’t providing a WindowsUpdate.log file any more. Instead we have to run a cmdlet to generate it manually.

On my Server 2016 the cmdlet gave the following error:

I checked the path “C:\Program Files\Windows Defender” and there’s no “SymSrv.dll” file present there. That’s because I had removed the Windows Defender feature from my Server 2016 install (we use Sophos, so no need really for Windows Defender). Who thought removing Windows Defender would break this cmdlet?

If I check the module “C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1” sure enough it looks for this DLL and tries to copy it:


Well, workaround is simple. Copy this DLL from any other 2016 machine (or search through the “C:\Windows\WinSxS\” folder on the same machine and copy it from there) to “C:\Program Files\Windows Defender” and the cmdlet will work. 

Or … enable the Windows Defender feature and disable it from Settings. 

[Aside] Windows Update tools

Wanted to link to these as I came across them while searching for something Windows Updates related.

  • ABC-Update – didn’t try it out but looks useful from a client side point of view. Free.
  • WuInstall – seems to be a client and server thing. Putting it here so I find it if ever needed in future. Paid.
  • Windows Update PowerShell Module – you had me at PowerShell! :0)
    • A blog post explaining this module. Just in case.

Go through a group of servers and find whether a particular patch is installed

Patch Tuesday is upon us. Our pilot group of server was patched via SCCM but there were reports that 2012R2 servers were not picking up one of the patches. I wanted to quickly identify the servers that were missing patches. 

Our pilot servers are in two groups. So I did the following:

The first two lines basically enumerate the two groups. If it was just one group I could have replaced it with Get-ADGroupMember "GroupName"

The remaining code checks whether the server is online, filters out 2012 R2 servers (version number 6.3.9600), and makes a list of the servers along with the installed date of the hotfix I am interested in. If the hotfix is not installed, the date will be blank. Simple. 

Oh, and I wanted to get the output as and when it comes so I went with a Width=20 in the name field. I could have avoided that and gone for an -AutoSize but that would mean I’ll have to patiently wait for PowerShell to generate the entire output and then Format-Table to do an autosize. 

Update: While on the Win32_QuickFixEngineering WMI class I wanted to point out to these posts: [1], [2]

Worth keeping in mind that Win32_QuickFixEngineering (or QFE for short) only returns patches installed via the CBS (Component Based Servicing) – which is what Windows Updates do anyway. What this means, however, is that it does not return patches installed via an MSI/ MSP/ MSU. 

IE 11 update fails due to prerequisite updates (KB2729094)

IE 11 update requires the following prerequisite updates – link.

Even after installing those (most of which are already there) IE 11 install will complain and fail. The log files are in C:\Windows\IE_.main.log.

In my case I was getting the following error (seems to be the same for others too):

Thing is I already had this hotfix installed, so there was nothing more to do. Found this useful support post where someone suggested running the hotfix install and side-by-side launching the IE install. Might need to do it 2-3 times but that seems to make a difference. So I tried that and sure enough it helped.

That post is worth a read for some other tricks, especially if you are sequencing this via SCCM. I found this article from Symantec too which seems helpful. Some day when I am in charge of SCCM too I can try such stuff out! :)

Update (from Herbert Hall, who emailed me this):

Rename the KB2729094 to KB2729094_amd64.msu

Start the install for IE11. When the folder for the install is created in C:\temp hurry and copy the file in there. This made it work for me.

Fixing a Windows Server that was stuck on “Preparing to configure Windows”

This is something that I fixed a few months ago at work but didn’t get a chance to blog about then. Coz of the gap I might not post much verbosely about it as I usually may.

The situation was that we had a Windows Server 2012 R2 that was stuck on a “Preparing to configure Windows” loop. I didn’t take a screenshot of it but you can find an example of it for Windows 7 here. All the usual troubleshooting steps like automatic repairs and last known good configuration etc didn’t make a dent. The problem began after the server was rebooted following Windows Updates so I focused on that. Here’s what I did to fix the server:

  1. I rebooted the server and pressed F8 before the Windows logo screen.
  2. This got me to the recovery options screen, where I selected the option to get a command prompt.
  3. Next I found the drive letter that corresponds to the C: drive of the server. This was through trial and error by typing each drive letter and find the one with the Windows folder.
    1. In my case the drive letter was E: so keep that in mind while viewing the screenshots replace. Replace with the drive letter you find.
  4. I entered the following command to get a list of all Windows updates, both installed and pending. 1
  5. The output was as below. 2
  6. I noted the names of the updates that were in a “Staged” state and uninstalled them one by one. 3
  7. Then I exited the command prompt. This rebooted the server and it was stuck at the following screen for a while. 4
  8. I stayed on this screen for about 15 mins. The server rebooted itself and stayed on the screen again, for about 10 mins. After this it proceeded to the login screen and I could login as usual. :)

Windows Update on remote machines

I mentioned yesterday that one can Windows Update a machine via script located at c:\Windows\System32\en-US\WUA_SearchDownloadInstall.vbs. It’s easy, just run via the following command on at machine:

I thought of taking it one step ahead and running on remote computers via PSExec. So I coped the script to the C:\ of all my servers (it’s only present in Server Core by default) and executed it via PSExec:

That worked – sort of. I got a list of updates and I selected to download and install them all, but it just seemed to hang after that. I know the script (and even Windows Update GUI) is slow in general so I gave PsExec a long long time to complete, but that didn’t help.

Side by side I was searching for any PowerShell alternative to this script and came across this one. Compared to the VBScript technique it has an advantage (apart from being in PowerShell!) that I can control the “install updates” and “reboot” behaviors via switches. So all I needed to do was run something like this from a command-prompt window to install all available updates on a machine and then reboot:


Thought I’d try run this remotely via PsExec but this time I got a lot of errors:

Looking more into this I came across an MSDN article about using Windows Update Agent (WUA) remotely. Turns out the CreateUpdateDownloader method that’s erroring above – which from it’s name sounds like the method responsible for downloading updates – is not allowed to be called remotely. Looking at the VBScript too, it has a section like the below where it hangs, so that explains why I couldn’t run that script either remotely.

I found some more PowerShell scripts that updates Windows machines – for example this and this. All of them use the same methods and so don’t work remotely. The blog post talking about the last script goes into more detail on an alternative method though. The trick is to create a scheduled task with the PowerShell script and run that on demand remotely. Since it runs locally, the PowerShell script will then succeed! I am yet to try it out but it seems like a reasonable workaround. Can deploy it via a GPO after all to all my machines.

From that post though I noticed the author creates the scheduled task as the LOCALSYSTEM account. So I re-ran PsExec but this time told it to execute the command as the remote LOCALSYSTEM account. And that worked! So now I can run a command like this

Or this

And am able to update a machine remotely. Nice! I prefer the PowerShell method as it lets me reboot the machine too without any prompt.

Notes of Windows Update (wuauclt)

Had to update some of my Windows Server Core servers. Just writing these as a note to my future self.

The Windows Update command is wuauclt. I can never get that command name (except that it starts with “wu”, short for “Windows Update”) so I always go into c:\windows\system32 and type “wu” followed by a couple of TABs).

The command doesn’t have any output or help switches. Here’s a post with a list of switches. In my experience none of the switches return any output, even if you enter the wrong switch. Some of the legit switches like /showWindowsUpdate and /showWUAutoScan return an error on Server Core – possibly because the UI doesn’t exist.

To check for new updates the following switch works: /detectNow.

To update the WSUS server with the client’s status the following switch supposedly works: /r /ReportNow.

Windows Update has a log file located at c:\Windows\WindowsUpdate.log. It’s a useful file. For instance, after I applied a policy to change all my domain servers to point to the new WSUS server I could browse this log file to see the results. I could also see on my Server Core installs an error along these lines: “Can not perform non-interactive scan if AU is interactive-only”. This error is because I had set the Windows Update GPOs to be interactive but Server Core didn’t have a GUI for interactive operations.

For Server Core the easiest way to check for updates is via SConfig. Open it and select option 6 (Download and Install Updates). This just runs another script – located in c:\Windows\System32\en-US – called WUA_SearchDownloadInstall.vbs. So one could really run a command like this on Server Core:

That’s all for now!