;)
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:
Image path is [??C:Program Files (x86)Windows Kits10Assessment and Deployment KitDeployment Toolsamd64DISMwimmount.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.
Solution
In my case the root cause was that a default permission was removed for the local Administrators group by a domain policy.
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.
Workaround
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.
