Well MDT 2013 Update 1 is out. Yea!
Time to test and evaluate to see if there are any regressions in my test and environment.
Wait… Something went wrong…
As I mentioned in an earlier blog post, I recently purchased a super fast Intel 750 SSD to make my MDT Build machine run faster. Blazing Fast
You might think: “Wow, that’s super cool, everything would be so much better with a faster machine”
Essentially, yes, except when it’s faster than the Operating System can handle. :^(
When updating a deployment share you may get the following error message:
Deployment Image Servicing and Management tool Version: 10.0.10240.16384 Image Version: 10.0.10240.16384 Processing 1 of 1 - Adding package WinPE-MDAC-Package~31bf3856ad364e35~amd64~~10.0.10240.16384 Error: 1726 The remote procedure call failed. An error occurred closing a servicing component in the image. Wait a few minutes and try running the command again.
Dism.log shows nothing interesting:
2015-07-15 13:55:00, Error DISM DISM.EXE: DISM Package Manager processed the command line but failed. HRESULT=800706BE 2015-07-15 13:55:00, Error DISM DISM Manager: PID=2364 TID=2424 Failed to get the IDismImage instance from the image session - CDISMManager::CloseImageSession(hr:0x800706ba) 2015-07-15 13:55:00, Error DISM DISM.EXE: - CDismWrapper::CloseSession(hr:0x800706ba)
I asked someone knowledgeable at Microsoft (MNiehaus), and he mentioned that he saw it a couple of times, but couldn’t repro it consistently. However, I could easily reproduce the problem on demand with my hydration/buildout scripts.
Turns out that there is a narrow case where this bug manifests:
- If you add any optional components to WinPE within MDT
- If you have a fast hard disk (like my Intel 750 SSD)
- If you have <UseBootWim> defined in you settings.xml, it may get worse.
The fast disk is most likely why the Windows Product Group teams never saw this bug in testing.
Well, I provided a repro environment to the Windows Product Groups involved in this component, even letting them log into my machine to reproduce the issue.
Good news is that they were able to determine what the root cause is ( timing related during unload of various components ), and even provided me with a private fix for testing! The private passed!
Now the real fun begins, there is a legitimate challenge here, because the error exists in the Windows 10 Servicing Stack, and that stack is embedded *into* WinPE.wim on the ADK and Boot.wim on the OS Install disk.
How do you update these files with the updated servicing stack, it’s not a trivial matter. They could send out a KB QFE Fix, and let customers manually update the files manually with dism.exe, they could also repackage/rerelease the ADK Itself, or worst case wait till the next release of the Windows OS ISO images.
I have been monitoring status, and there are several team members working on the release issues, and even someone from Customer Support acting as a customer advocate. My work is done.
In the mean time, you can work around the issue:
- Removing optional components from MDT. :^(
- Of course, you move to a machine with a slower disk.
- I had some luck getting optional components added when I set <UseBootWim> to false in the settings.xml file.
- Additionally, Johan has mentioned that he can get it to pass if the OS running MDT is Windows 10 ( I was running Windows Server 2012 R2 ).
For me, it was easy, I don’t use the MDAC components in my environment, so I just removed them from the settings.xml file. Lame, I know.
More Deployment bugs to follow!