Preventing a driver from automatically installing from Windows Update on Windows 10 (when it keeps reinstalling before you can run the driver blocking tool)

System Requirements:

  • Windows 10

The Problem:

Microsoft’s descent into Apple design and general irrelevancy continues unabated with design time decisions for Windows 10. Obviously when drivers get released onto Windows Update, they’re going to work for everyone. Obviously.

In my experience the main issue is with integrated chips from the large PC OEM’s (Dell, HP etc). The subtle modifications that they make in their own proprietary releases of their “2010” driver when do not necessarily directly map onto the generalised driver with the same PnP ID’s being detected from Windows Update.

In the last week I’ve had to deal with this no less than 8 time on 6 separate occasions. I, like most people in IT, have encountered this many times before however it has usually been with fairly large driver updates that require a reboot – prolific Windows 10 dual screen problems with Windows Update Intel HD Graphics drivers anyone?

So unlike previous Windows versions, there is no longer a way to stop Windows Update automatically installing updates immediately using the UI, you have to resort to group policy to have any chance of delaying it. In Windows 10 there is also no way to block certain updates if you do not want them / they don’t work.

Of course Microsoft’s business decision behind this end user horror is quite simple: Too many people blocked or are blocking KB3035583 (the Windows 10 installer update for Windows 7 and 8.x) preventing them from force feeding you Windows 10. They also want to de-fragment their ecosystem (I can empathise with this) and consequently they want to ensure that people are being spoon fed the latest feature updates as soon as possible under the new Windows feature release cycle.

Of course, if you get a bad update or a bad driver, now that there is no way to block it, you will uninstall it and it will simply come back.

The problem is exacerbated with small driver downloads (in the kilobytes range) that do not require reboots. In my most recent cases a 2009 HP Laptop Webcam. a 2010 HP Laptop Fingerprint reader and a 2008 Toshiba laptop touch screen driver. By the time that you have uninstalled the bad driver, rolled back to ‘no driver’/a working driver, run Windows Update to make Windows aware that there is a bad one available and then in turn run the Window Update Show/Hide Tool. Windows has already reinstalled the bad driver and as a consequence the WU Show/Hide tool is unable to give you the option to block the driver.

Bravo Microsoft. Bravo!

More Info

As eluded to above, the issue is one of timing. Windows 10’s brutal and where possible immediate desire to install anything that comes down the update channel is breaking the sequence necessary to correctly use the WU Show/Hide tool.

The required sequence is:

  1. Uninstall defective device, deleting the old driver
  2. Run Windows Update so that the local Windows Update Available Updates Catalogue shows an available driver update for that device
  3. <Windows Update should NOT do anything at this point>
  4. Run the Windows Update Show/Hide Tool
  5. Block the bad driver update
  6. Re-scan Windows Update to clear the update from the Available Updates Catalogue
  7. Install updates manually / after a sensible delay

In practice, at step 3 Windows Update – now aware that there is a driver waiting – is simply installing the bad driver again. This prevents you from running the WU Blocker tool. The problem is exacerbated by small updates (or fast Internet connections) because there isn’t a delay between Windows realising that there is an update and taking the time to download it before executing the Install.

This delay is useful for things like the Intel HD Graphics problem because the driver files is over 120MB and in many cases this gives you enough time to run the WU Blocker tool successfully.

The Fix

Yes, you can mess around with Group Policy to fix this – unless of course you are on a home edition. Yes, you can also modify the driver installation policy, however again this isn’t always desirable. So I present a simple way to solve this.

  1. Download the Windows Update Show/Hide (blocker) tool from KB3073930
  2. Open Windows Explorer at C:\Windows\SoftwareDistribution\Download
  3. Open en elevated command prompt and type:
net stop wuauserv
  1. Return to C:\Windows\SoftwareDistribution\Download and delete everything in the folder (but not the folder itself) – this deletes the installer cache for the driver
  2. Right click on the C:\Windows\SoftwareDistribution\Download folder itself, choose properties
  3. Open the security tab
  4. Click Edit to change permissions
  5. Select the SYSTEM account from the accounts list
  6. In the Deny column next to the permission for “Write” place a tick – JUST place a tick next to Write, that is all that is needed!
  7. Click OK twice to return to Windows Explorer – accepting any messages and warnings about Deny actions and system folders
  8. Go to device manager, uninstall the defective device – ensuring that you select the option to delete the driver along with it
  9. Run Windows Update
  10. Windows Update will now attempt to install the device, however it will fail with error code 0x80246007
  11. Now run the Windows Update Show/Hide Tool, block the update
  12. Return to Windows Update and re-scan for the update to flush it out of the available update list
  13. Go back to setup 5 and REMOVE the Deny Write permission tick to undo your changes
  14. Return to Windows Update and re-scan for updates. Windows Update should inform you that your device is up to date and will not attempt to install the driver

View: Windows Update Show/Hide Tool

Error 1635 from Microsoft Office Installer when installing from a SMB File Source

System Requirements:

  • Office 2007
  • Office 2010
  • Office 2013 (Enterprise)
  • Office 2016 (Enterprise)

The Problem:

You’re one of the lucky people who has access to a version of Office that doesn’t need to use the awful “Click to Run” to perform the install. You are trying to use SCCM, Group Policy, a BAT file or some other remote invocation method to deploy Office from a source repository on a SMB file share.

Office starts to install, the installation looks like it is working and even one or two app’s appear on the start menu… before it unexplainably performs a roll back and uninstalls itself leaving your machine with no Office installation.

If you check the log files (in %temp% or c:\users\<user>\AppData\Local\Temp by default) you will find a Windows Installer Error 1635 entry listed before it commenced the rollback.

More Info

Windows Installer Error 1635 is “This patch package could not be opened. Verify that the patch package exists and is accessible, or contact the application vendor to verify that this is a valid Windows Installer patch package”.

If you are using SCCM, then you are probably attempting to execute this through the NT System account or via local admin.

Obviously you’ve checked the share permissions, perhaps even enabled a Null Session Share to allow anonymous access to the share… and it still doesn’t work. The client script is obviously executing successfully because the setup programme loads and runs for 10 minutes or more quite happily before erroring out.

The Fix

Quite simply, save yourself a headache and script the process to call the Office setup.exe from the local machine rather than directly against the SMB Share. This will solve the problem. Something in line with the following will download the installer and files from the repository to the OS Temp directory, execute the installer process and then clean-up

mkdir C:\Windows\Temp\OfficeSetup

xcopy "\\server\share" "C:\Windows\Temp\OfficeSetup" /Y /E /V /C /Q /H /R

:: Pre-Install actions here

call "C:\Windows\Temp\OfficeSetup\setup.exe" <switches go here>

:: Post-Install actions here

rmdir "C:\Windows\Temp\OfficeSetup" /S /Q

Error 0x80070002 when attempting to backup a Hyper-V Virtual Machine using Windows Server Backup

System Requirements:

  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2

The Problem:

You backup, right? Of course you do! Only the cool people backup – and you are one of the cool people aren’t you?

…If only life was that simple.

So imagine for a moment that you are attempting to use VVS and WIndows Server Backup to backup a server. In particular a fully loaded Hypervisor running Windows Server 2012 R2 Datacentre in this case.

The backup process goes OK for the most part, but fails to complete on a number (but by no means all) VMs. The process fails with the following errors on Windows Server 2008 VMs, but not necessarily newer ones.

From Windows Server Backup:

Windows Server Backup “Failed” -or- “Completed with warnings” -or-“Backup failed to complete”

The component <VM Name>(Online) was skipped during the snapshot and will not be available for recovery. Error: The writer experienced a non-transient error. If the backup process is retried, the error is likely to reoccur

In the Hyper-V-VMMS\Admin log in Event Log:

‘<VM Name>’ cannot create the storage required for the checkpoint using disk E:\Virtual Machines\<VM Path>\Virtual Hard Disks\<VHD Filename>.vhdx: The system cannot find the file specified. (0x80070002). (Virtual machine ID <VM GUID>)

and…

Checkpoint operation for ‘<VM Name>’ failed. (Virtual machine ID <VM GUID>)

and…

Could not create backup checkpoint for virtual machine ‘<VM Name>’: The system cannot find the file specified. (0x80070002). (Virtual machine ID <VM GUID>)

and of course most helpfully…

The operation failed.

More Info

If you actually look at the backup file, you will see what looks to be a complete file set for the backup, however given that this error represents an error in VSS, you would not be advised to trust it.

As usual with Hyper-V error logs, the error message have little if anything to do with the actual issue and someone in the Microsoft Development team just needs to be shot for it… but I digress.

The odd think was that the issue was occurring on all of the Windows Server 2008 (R1) VMs, the Windows Server 2008 R2 and higher VMs were backing up correctly.

The Fix

So before I get into the issue I encountered, lets run past the generic fixes

  1. Check that you have enough disk space on the volume to perform the VSS. If your volume is sub-15%, try using the Hyper-V Manager to change the snapshot directory to another volume – plug in an external NTFS formatted hard drive if you have to.
  2. Check the permissions of the VHD stated in the error.
    icacls “C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\<VHD File>” /grant “NT VIRTUAL MACHINE\Virtual Machines”:F /TSource: Technet
    Source: System Center Central
  3. Ensure that Hyper-V is patched fully.
    Windows Server 20102 R2 users see: https://support.microsoft.com/en-us/kb/2920151
  4. Run chkdsk on the physcial volume on the Hypervisor and on the virtual volume in the VM
  5. Ensure that the Integration Service Components are at the latest version and that they VSS Writer module for it is enabled in the VM properties in Hyper-V Manager

Now the less well documented approaches

  1. Check that you can manually checkpoint/snapshot the VM while it is running.
    In Hyper-V Manager or in PowerShell, force a checkpoint on the VM and then delete it and wait for it to merge back. If this works, you are not having a physical VSS issue. If it fails, you need to troubleshoot this and not the WSB error.
  2. Live Migrate the VM off of the current server and onto a different Hypervisor, attempt the backup here, then bring it back to the original server and try again. This process will reset the permissions on the VM file set. If you cannot live or offline migrate the VM, the you need to troubleshoot this and not the WSB error.

My fix

In my case, the issue was to do with having the VM VHDX files split across a couple of different storage LUN/volumes. I usually move VM page files onto a dedicated partition on a dedicated spindle (usually an SSD) and leave OS and data volumes on larger arrays. This helps to keep the VMs running smoothly and keeps unnecessary paging operations off of parity checked storage volumes.

So imagine that the VM has the following file storage structure

Physical Hypervisor SSD (this is where the Page File’s live)
– D:\my-virtual-server-d-drive.vhdx

Physical Hypervisor Storage Array
– E:\Virtual Machines\<VM Name>\Planned Virtual Machines
– E:\Virtual Machines\<VM Name>\Snapshots
– E:\Virtual Machines\<VM Name>\Virtual Hard Drives\my-virtual-server-c-drive.vhdx
– E:\Virtual Machines\<VM Name>\Virtual Hard Drives\my-virtual-server-e-drive.vhdx
– E:\Virtual Machines\<VM Name>\Virtual Machines

It is actually this structure which breaks the WSB backup job. Contrary to the VSS event log error, the problem drive is NOT my-virtual-server-c-drive.vhdx it is actually my-virtual-server-d-drive.vhdx. The event log will actually log that the error was caused on the first drive attached to the system bus (I think).

If you weren’t too clever when you followed my advice above and live migrated all of the storage to the same location on a different Hypervisor, you probably found this out for yourself – the backup should have worked.

When you split the job back into separate LUNs, it fails again. The fix is oddly simple and continues to allow you to have split LUN storage if you wish. Change the file system structure to:

Physical Hypervisor SSD (this is where the Page File’s live)
– D:\<VM Name>\my-virtual-server-d-drive.vhdx

Physical Hypervisor Storage Array
– E:\Virtual Machines\<VM Name>\Planned Virtual Machines
– E:\Virtual Machines\<VM Name>\Snapshots
– E:\Virtual Machines\<VM Name>\Virtual Hard Drives\my-virtual-server-c-drive.vhdx
– E:\Virtual Machines\<VM Name>\Virtual Hard Drives\my-virtual-server-e-drive.vhdx
– E:\Virtual Machines\<VM Name>\Virtual Machines

Note the introduction of a folder on the D drive with the same name as the <VM Name> folder on the E drive. Do NOT shutdown the VM and move the storage there yourself, use the Hyper-V Manager or PowerShell processes to perform a “move” on the ‘storage only’ and just move the one drive. This will ensure that permissions are correct.

The next time that you run the backup, it will VSS correctly.

As for why it can do this on its own with Windows Server 2008 R2 or higher VMs, but not Windows Server 2008 or lower VMs… I have no idea although I suspect it to have something to do with the capabilities of the integration services components.

Edit: A post publish search on the issue reveals that I’m not alone in working this out
View: Technet

Error 0x80070490 or 0x00000490 when attempting to connect to a Printer queue on a Windows Print Server

System Requirements:

  • Windows Vista, 7, 8, 8.1,10
  • Windows Server 2008, 2008 R2, 2012, 2012 R2

The Problem:

I was having some problems automating the connection to a printer queue from a set of managed Windows 7 systems to foreign Windows Server managed SafeCom printer queue. The device in question was a generic follow-me Printing queue for Xerox Workcentre 7655 devices (not that it is especially relevant).

On opening the SMB share to the print server and connecting to the printer queue, the system would go off for 60 seconds before coming back with error 0x00000490 and no description.

Exploration of this error in event viewer under Event Viewer > Applications and Services > Microsoft > Windows > PrintService > Admin reveals:

Installing printer driver Xerox GPD PS V3.2.303.16.0 failed, error code 0x490, HRESULT 0x80070490. See the event user data for context information.

The only additional information available in the user data of any substance was either

Parse Inf
ProcessDriverDependencies failed

or

PerformInfInstallActions
ParseInf failed

More Info

I also tried the following recommendations from general troubleshooting/elsewhere:

  1. Attempting to manually install the driver didn’t help
  2. Using pnputil -d to delete the driver oemXX.inf didn’t help (i.e. clearing the driver out of C:\Windows\System32\DriverStore\FileRepository)
  3. Using pnputil -a to manually add the desired driver didn’t help
  4. Using the Print Management MMC snap-in to flush the driver out (including renaming any reference dll’s under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Print Processors\winprint to xxx.old and restarting the print server to allow the deletion of stuck print drivers) didn’t help
  5. Obtaining older and new drivers from Xerox didn’t help
  6. The Microsoft Printer Troubleshooter tool
    View: Fixing Printer Problems
  7. Enabling the Operational log under Event Viewer > Applications and Services > Microsoft > Windows > PrintService didn’t add anything significant to the troubleshooting process just:
    ParseInfAndCommitFileQueue
    PerformInfInstallActions failedProcessDriverDependencies
    FindLatestCoreDrivers failed
  8. Checking setupapi.app.log and setupapi.dev.log for errors under C:\Windows\inf did not show any errors, everything was reporting ‘success’

The Fix

In downloading and installing the older version of the print driver, event viewer was showing an identical error for the driver install to that shown when displaying the error for the install of the most up to date driver version, however comparing the source driver files to the destination files that appeared after repository injection in C:\Windows\System32\DriverStore\FileRepository revealed some slight differences in file dates, the print server was sending slightly modified versions of the driver compared to the vanilla Xerox source of the same version number (2015 file dates for a 2013 Xerox driver package).

Some sleuthing through monitoring tools ultimately presented the cause of the issue and ultimately its fix. Windows was downloading the driver package from the target foreign print server (with its modified files) and injecting it into the repository correctly. Immediately afterwards however it was going off to our internal, public driver repository (a SMB share on a build server) and finding additional copies of a compatible x64 Xerox driver, finding that they were newer and then attempting to use the newer driver.

Without the driver customisation’s (presumably part of the SafeCom suite configuration for follow-me printing) the print server was immediately rejecting the connection.

So the lesson from this experience was that even if you are explicitly telling Windows to use a specific driver version, if it can find a newer version in a driver search path, it will attempt to pick it up and use it instead. Remove any media with drivers (UFD, CD, DVD, Floppy) and check/modify you driver search paths for conflicting drivers as listed in:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\DevicePath