When preparing a new Windows Server 2012 R2 system for a new ConfigMgr 2012 R2 site, I ran into an error installing the Windows ADK.  In this case it is version 10; however, I believe the same scenario would apply to 8.1 Update, 8.1, 8, etc.

The installation appears to be working, then performs a rollback with the following error:

Windows ADK installing features
Image path is [\??\C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\DISM\wimmount.sys // Could not acquire privileges; GLE=0x514 // Returning status 0x514
Additionally, after installation was successful, it was not possible to mount a WIM or create boot media in ConfigMgr.

Crating ConfigMgr or MDT Task Sequence Media fails with the error:

Error: 1313  A required privilege is not held by the client.  Refer to CreateTsMedia.log file to find more details.


CreateTSMedia.log file…

using CreateMedia.exe /K: boot … fails


The PowerShell cmdlet New-CMTaskSequenceMedia -BootableMedia … fails

Mounting a WIM with DISM fails


DISM.exe /Mount-Image /ImageFile: …

Error: 1313  A required privilege is not held by the client.


In my case the root cause was that a default permission was removed for the local Administrators group by a domain policy.

[read-more-redirect urltext=”CatapultSystems.com” url=”https://www.catapultsystems.com/blogs/configmgr-reporting-services-point-with-complex-sql”]


By default, the User Right Assignment for “Back up files and directories” and “Restore files and directories” is held by the “Administrators, Backup Operators“.  But in this case the “Administrators” group had been removed and replaced by the “Domain Admins“.

Since my account isn’t and shouldn’t be a domain admin, I simply added it to the local “Backup Operators” group, logged off, logged back on, and presto!  Success.


If the User Right Assignment isn’t you issue, another solution, or rather workaround, is to run the installation as the SYSTEM account.


Getting to the workaround

Multiple other solutions were attempted before resorting to the SYSTEM account for installation including

  • Run as Administrator
  • Run a Command Prompt as Administrator then run ‘ADKsetup.exe
  • multiple system reboots
  • manually creating the folder structure and file
  • manually running the ‘Windows Deployment Tools-x86_en-us.msi‘.  Strangely this succeeded; however, when re-running the ADKsetup.exe, the same failure occurred.
  • manually running the ‘Windows System Image Manager on amd64-x86_en-us.msi‘.  Strangely this succeeded; however, when re-running the ADKsetup.exe, the same failure occurred.
  • both the system drive (Drive C:) and a data drive (E:) were attempted
  • disabling the antivirus / antimalware software (Sophos)

None of these made any difference.

Several forum posts were found with a resolution pointing to a blog that has since been taken down.  That solution required removing the computer from the domain.  This solution was not attempted.

Executing the workaround

There are a few ways to gain SYSTEM account access; however, I took the interactive route and used PSEXEC from Sysinternals.

From an elevated Command Prompt (Run as Administrator), run ‘PSEXEC.exe -s -d -i cmd.exe

A new Command Prompt will be generated.  run ‘whoami‘ to ensure you are running as SYSTEM, then run ‘adksetup.exe


Thanks to Adam for working through the issue with me.


Other instances and workarounds

There are a few instances of the same error documented in a few blogs and forum posts.  The options basically include ensuring you are running as an administrator (and with the administrator token), running as SYSTEM (as described in my workaround), or dis-joining the computer from the domain and running as admin.


Error installing Windows ADK
Tagged on: