ADK 1703 Meets Server 2016

Tweet about this on TwitterShare on FacebookShare on LinkedInShare on Google+Email this to someone

[Update from Microsoft (May 30th, 2017): Good news! Microsoft has released a fix to replace the drivers signed with old certificates with newly signed drivers.  This should fix any unsigned driver errors in the installation of ADK.  You can read the update and download the files and instructions here.  In even betters news, Keith Garner has written and shared a script online that will automate the process of replacing the drivers that Microsoft outlines.  His script can be found here.]

As quickly as we are moving to get clients upgraded to Windows 10, Microsoft is moving just as quickly, recently releasing the Creators Update 1703. If you are looking to install Windows Assessment and Deployment Kit (ADK) for Windows 10 version 1703 on a Server 2016 Hyper-V virtual machine, you may encounter the following roadblock. The first, albeit vague, warning that something is wrong is during the installation of ADK, when the Program Compatibility Assistant prompt is presented stating that an unsigned driver could not be installed.

Once you close out of the prompt, the installation completes with no additional suggestion of a problem. In fact, you won’t be aware of the problem until you are in Microsoft Deployment Toolkit Workbench and ready to generate your first WinPE media. The process will fail with the error “Unable to mount the WIM, so the update process cannot continue”.

A quick Internet search led us to a TechNet article explaining that some of the files in the ADK installer are signed with an old certificate. Because Hyper-V machines are automatically configured to enable Secure Boot, these unsigned drivers are blocked from installation. The winmount.sys driver is one of those that are blocked, which prevents the generation of boot images. The article discusses using an older version of ADK or disabling Secure Boot as possible workarounds, but neither of these are ideal.  We disabled Secure Boot as our workaround, but luckily a day later Michael Niehaus posted this article, explaining that we can switch out the unsigned driver with a newly signed driver already in the OS.

Here is how to do this:


1. Launch regedit.exe

2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WIMMount

3. Select the ImagePath key and edit it

4. Replace the value with “system32\drivers\wimmount.sys”


Once this key is updated you can now go back into MDT and successfully generate a boot image. Happy imaging!

  • You’re my hero. This is exactly what was needed.