Windows 10 insider preview failed to install

I’m running Windows 10 insider preview on my basement computer at home, and sometime in the middle of summer it started failing to update to the latest release. I finally made some time to troubleshoot this last night and got it working.

During the install, it would get about 40% of the way through, and then fail with this error:

Windows could not configure one or more system components

After some sleuthing I discovered the log file for the upgrade could be found here: C:\Windows\Panther\NewOs\Panther, and I looked at the “setuperror.log” file.

In this, there were a couple of key errors noted:

0xd0000034 Failed to add user mode driver [%SystemRoot%\system32\DRIVERS\UMDF\uicciso.dll]

Failure while calling IPreApply->PreApply for Plugin={ServerPath="Microsoft-Windows-IIS-RM\iismig.dll"

Generic Command ErrorCode: 80004005 Executable: iissetup.exe ExitCode: 13 Phase: 38 Mode: Install (first install) Component: Microsoft-Windows-IIS-SharedLibraries-GC

I did come across a search hit when looking for the “uicciso.dll” error that spoke about IIS install failing with a Windows 10 update, and those two things seemed to correlate with the errors I was seeing in the logs.

I ran this DISM command to see the additional Win10 features that were installed, and noted a whole bunch that I don’t ever recall having put on manually, and certainly weren’t needed:

 dism /online /get-features /format:table

I collected a bunch, turned it into a removal command, ran them and restarted:

dism /online /disable-feature /FeatureName:SMB1Protocol-Server
dism /online /disable-feature /FeatureName:SMB1Protocol
dism /online /disable-feature /FeatureName:MSMQ-Server
dism /online /disable-feature /FeatureName:MSMQ-Container
dism /online /disable-feature /FeatureName:WCF-Services45
dism /online /disable-feature /FeatureName:WCF-TCP-Activation45 
dism /online /disable-feature /FeatureName:WCF-Pipe-Activation45 
dism /online /disable-feature /FeatureName:WCF-MSMQ-Activation45 
dism /online /disable-feature /FeatureName:WCF-TCP-PortSharing45 
dism /online /disable-feature /FeatureName:WAS-ConfigurationAPI
dism /online /disable-feature /FeatureName:WAS-WindowsActivationService 
dism /online /disable-feature /FeatureName:WAS-ProcessModel 
dism /online /disable-feature /FeatureName:IIS-RequestFiltering
dism /online /disable-feature /FeatureName:IIS-Security
dism /online /disable-feature /FeatureName:IIS-ApplicationDevelopment 
dism /online /disable-feature /FeatureName:IIS-NetFxExtensibility45
dism /online /disable-feature /FeatureName:IIS-WebServerRole 
dism /online /disable-feature /FeatureName:IIS-WebServer 
dism /online /disable-feature /FeatureName:NetFx4-AdvSrvs 
dism /online /disable-feature /FeatureName:NetFx4Extended-ASPNET45

After the restart I let the upgrade run, and it completed successfully!


Dell PowerEdge BIOS failed due to IPMI driver

I was updating the BIOS on a couple of Dell PowerEdge R620’s today and was presented with an error I hadn’t heard of before:

IPMI driver is disabled. Please enable or load the driver and then reboot the system.

This was very odd. A little bit of searching showed that there should be an IPMI driver service running in Windows, so I checked that:

Service 'ipmidrv (IPMIDRV)' cannot be started due to the following error: Cannot start service IPMIDRV on computer '.

Knowing this was a driver, I went to look in Device Manager, and was quite surprised to find this IPMI driver listed:

This is a Dell PowerEdge, I have no idea how this HP driver got installed – I’m not even convinced it wasn’t there prior to the other driver updates I was performing. In any case, this device wasn’t starting properly, and was preventing the service from starting. I uninstalled it and the driver:

Following this, the appropriate device appeared under “System Devices”:

Now I could start the service, and the BIOS update proceeded properly.

Powershell command as scheduled task

Here’s the syntax to use a PowerShell command in Task Schedule action, rather than a script:



Add Arguments:

-noninteractive -executionpolicy bypass -command &{Checkpoint-VM -Name pxetest -SnapshotName 2018-06-23-PreMaintenance}


The key here is the ampersand before the command – when I was missing that it would not run.



SharePoint library column missing

I’ve been working on migrating documents between document libraries in a SharePoint site, and have randomly struggled with an odd issue.

In the new destination library, I’ve configured a managed metadata column based on a term store, and made it mandatory. This column does not exist on the source library.

For the majority of my documents this has been working well – after moving or copying the document I set the column value with the quick-edit info pane. However, some of the documents have a blank value rather than showing “Required Information”:

click for bigger

When I view the properties of the document on the quick-edit pane, the column doesn’t appear at all!

The root cause is that these problem documents carried over their Content Type with them into the new library, and this content type does not have the managed metadata column added to it. However, it isn’t immediately clear this is what happened because the default setting on this library is to not manage Content Types individually.

To fix this, I went into the advanced library settings, and chose Yes for “Allow management of content types”:

Once I did this, the extra content type appeared in the settings page:

click for bigger

Now when I go back to my document and open the quick-edit pane, there is a new option to select Content Type, and I can set it back to the default:

This then updates the list and puts a “Required Information” block in that column, and allows me to fill it in.


AppAssure Agent service not started

I have found in recent experience that the Quest RapidRecovery/AppAssure agent service frequently fails to start within the default Windows service startup timer (30 seconds).

I don’t believe this is simply my environment, as Quest has a knowledge article specifically addressing the problem.

This issue poses a problem especially after Windows Updates maintenance windows, because our hundreds of virtual machines will reboot, leaving our monitoring system with hundreds of alerts of stopped services, and many failed backups.

Unfortunately, Quest’s recommendation to simply increase the services startup timeout is system-wide, and not something I was willing to apply in full across my entire environment.

My first thought was to utilize the Recovery options with the Windows service, but upon quick inspection its clear this is only for failed services, and a service that isn’t started does not fall into that category.

Instead I decided to set a GPO with a service preference, with service action set to “Start Service”. This way, every time Group Policy is refreshed, if the service isn’t running it will be started.

The GPO itself has a bit of logic to address the AppAssure/Rapid Recovery upgrade we’re going through right now, which results in a service name change for the agent.

To accomplish this, I created two separate service preferences, each with some item-level targetting for registry matching to ensure it only applies if that service does exist (to avoid spamming Event Logs). This takes advantage of the fact that the AppAssure Agent doesn’t record a product version in the registry:

AppAssure Service

  • Service Name = AppAssureAgent
  • Match if KeyExists HKLM\Software\AppRecovery\Agent
  • AND if not ValueExists HKLM\Software\AppRecovery\Agent\ProductVersion

Rapid Recovery Service

  • Service Name = RapidRecoveryAgent
  • Match if ValueExists HKLM\Software\AppRecovery\Agent\ProductVersion