 © Rakhesh Sasidharan
|
Posted: May 7th, 2017 | Tags: windows update | Category: Windows | § 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:
|
|
Copy-Item : Cannot find path 'C:\Program Files\Windows Defender\SymSrv.dll' because it does not exist. At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\WindowsUpdate\WindowsUpdateLog.psm1:56 char:5 + Copy-Item -Path $SYMSRV_DLL_PATH -Destination $WORKDIR -Force -Er ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ObjectNotFound: (C:\Program File...nder\SymSrv.dll:String) [Copy-Item], ItemNotFoundExce ption + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.CopyItemCommand |
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:
|
|
# Dependencies $TRACERPT_EXE_PATH = "$SYSTEM32\tracerpt.exe" $DBGHELP_DLL_PATH = "$SYSTEM32\DbgHelp.dll" $SYMSRV_DLL_PATH = "$env:ProgramFiles\Windows Defender\SymSrv.dll" ... Copy-Item -Path $SYMSRV_DLL_PATH -Destination $WORKDIR -Force -ErrorAction Stop |
Bugger!
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.
Posted: April 20th, 2017 | Tags: windows update | Category: Asides, Windows | § 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.
Posted: March 19th, 2017 | Tags: get-wmiobject, windows update, wmi | Category: PowerShell, Windows | § 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:
|
|
"SCCM_Pilot_ManualReboot","SCCM_Pilot_AutoReboot" | %{ Get-ADGroupMember $_ } | ?{ Test-Connection $_.name -Quiet -Count 1 } | ?{ (Get-WmiObject Win32_OperatingSystem -CN $_.name).Version -eq "6.3.9600" } | ft @{Label="Name"; Expr={$_.name}; Width=20}, @{Label="KB4012204"; Expr={(Get-WmiObject Win32_QuickFixEngineering -cn $_.name -Filter "HotFixID='KB4012204'").InstalledOn}} |
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.
Posted: February 22nd, 2017 | Tags: internet explorer, windows update | Category: Windows | § 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):
|
|
00:47.689: ERROR: WMI query for Hotfixes timed out. Query string: 'Select HotFixID from Win32_QuickFixEngineering WHERE HotFixID="KB2670838" OR HotFixID="KB2729094"' Error: 0x00040004 (262148). |
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.
|
|
01:20.216: ERROR: WMI query for Hotfixes timed out. Query string: 'Select HotFixID from Win32_QuickFixEngineering WHERE HotFixID="KB2729094"' Error: 0x00040004 (262148). 01:20.965: INFO: Download for KB2729094 initiated. Downloading http://go.microsoft.com/fwlink/?LinkID=258385 -> KB2729094_amd64.MSU. 01:21.511: INFO: Waiting for 1 prerequisite downloads. 01:36.034: INFO: Prerequisite download processes have completed. Starting Installation of 1 prerequisites. |
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! :)
Posted: April 27th, 2016 | Tags: dism, windows update | Category: Windows | §
Posted: August 9th, 2015 | Tags: powerhell, vbscript, windows update, wuauclt | Category: Windows | § 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:
|
|
cscript.exe c:\Windows\System32\en-US\WUA_SearchDownloadInstall.vbs |
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:
|
|
psexec \\my-server01 cscript.exe "c:\WUA_SearchDownloadInstall.vbs" |
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:
|
|
powershell.exe c:\WSUS.ps1 y y |
Neato!
Thought I’d try run this remotely via PsExec but this time I got a lot of errors:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
Downloading Updates... Exception calling "CreateUpdateDownloader" with "0" argument(s): "Access is deni ed. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))" At C:\WSUS.ps1:62 char:1 + $Downloader = $UpdateSession.CreateUpdateDownloader() + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [], MethodInvocationException + FullyQualifiedErrorId : ComMethodTargetInvocation The property 'Updates' cannot be found on this object. Verify that the property exists and can be set. At C:\WSUS.ps1:63 char:1 + $Downloader.Updates = $UpdatesToDownload + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : PropertyNotFound You cannot call a method on a null-valued expression. At C:\WSUS.ps1:64 char:1 + $Null = $Downloader.Download() + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: (:) [], RuntimeException + FullyQualifiedErrorId : InvokeMethodOnNull Installing Updates... Exception calling "CreateUpdateInstaller" with "0" argument(s): "Access is denie d. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))" At C:\WSUS.ps1:90 char:5 + $Installer = $UpdateSession.CreateUpdateInstaller() + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : NotSpecified: (:) [], MethodInvocationException + FullyQualifiedErrorId : ComMethodTargetInvocation <snip> |
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.
|
|
Set downloader = updateSession.CreateUpdateDownloader() downloader.Updates = updatesToDownload downloader.Download() |
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
|
|
PsExec.exe \\my-server01 -s powershell.exe c:\WSUS.ps1 y y |
Or this
|
|
PsExec.exe \\my-server01 -s cscript c:\WUA_SearchDownloadInstall.vbs |
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.
Posted: August 8th, 2015 | Tags: servercore, windows update, wuauclt | Category: Windows | § 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:
|
|
cscript.exe c:\Windows\System32\en-US\WUA_SearchDownloadInstall.vbs |
That’s all for now!
|
