I received a call recently, from a customer who was having trouble updating his MDT deployment shares.
I logged onto the server and tried myself, sure enough I received this error.
Unable to mount the WIM, so the update process cannot continue.
OK, so it looks like MDT is having trouble mounting the Window PE image from the WAIK. MDT using ImageX to do this, so I figure this was a good place to start.
Curious, I opened an Administrator Command Prompt and attempted to mount an image using ImageX. I used the following command.
ImageX.exe /mount ..PEToolsx86winpe.wim 1 c:Mount
As you can see, the results weren’t fantastic, ImageX was unable to mount and WIM file, reporting this error.
A required privilege is not held by the client.
Now that I have a bit more of an idea of what was happening, I went about checking for obvious issues.
Next I looked at what error level was being reported by ImageX, it was “2”. The ImageX TechNet Reference suggests that error 2 relates to a WIMGAPI failure. I found that pretty funny, most of the functionality for ImageX resides in WIMGAPI.dll, so this wasn’t particularly helpful. Nevertheless I checked out the copies of WIMGAPI.dll from the WAIK folder, as well as ones I found on the path, in C:WindowsSystem32, and C:Program FilesWindows Imaging. Everything seemed ok, the version numbers all matched up (6.1.7600.16385) and permissions were fine. I even tried replacing this dll, all to no avail.
After spending a few hours staring at Procmon logs, I was really no closer to understanding what going on, and ImageX wasn’t passing through the error from WIMGAPI.dll, so things were looking pretty bleak.
One of the guys in the office even went so far as to write up a little program that would use WIMGAPI.dll to mount a folder from a WIM. It also failed, however we were able to retrieve the correct error code, which was 1314. The MSDN page for System Error Codes says error 1314 is “ERROR_PRIVILEGE_NOT_HELD” and that “A required privilege is not held by the client.” Which privilege!! At least now we knew there was definitely something out of place with some permissions.
I turned my attention back to Group Policy, starting to turn settings off one by one, trying to coax out the culprit. In the end I found it! The offending policy lives under Computer Configuration –> Policies –> Windows Settings –> Security Settings –> Local Policies –> User Rights Assignment. Permissions to “Manage audit and security log” had been set to a group which my user account was not a member.
For some reason WIMGAPI.dll required this permission to function. After being granted this permission, ImageX and MDT both worked at intended. Quite an obscure one I know, however if someone else happens to have the same circumstance, I hope you stumble upon this article before spending as much time as I did, trying to figure out what was going one.