Still the development of MDT 2013 is hopelessly behind the technical preview releases of Windows. Until that happens you can still apply some custom hacks to the current version.
In Windows 10 Build 9926 you still need to add updated DISM files to the boot image (until the Windows 10 ADK is released), and due to the new "10.0.9926.0" version number, many of the MDT scripts, especially the LTIApply.wsf and ZTIUserStafe.wsf scripts has quite many string checks for "6.X" versions.
The problem is however that "10.0" is not higher than "6.2" when you do a string comparison. That means if you have a snippet that says:
If Left(oEnvironment.Item("OSCurrentVersion"), 3) >= "6.2"
Windows 10 will not fall into that If statement (since "10.0" is lower than "6.2" in a string comparison").
First, this is not supported so don't blame me if something is not working.
Update 2015-01-29: This post is only for plain bare metal deployment, to build a reference image see this post: Create a Windows 10 reference image using MDT 2013
In addition to have the the task sequence copy the right servicing stack to the WinPE 5.0 boot image you also need to use updated versions of some MDT 2013 scripts (click the link for download).
On your MDT server, copy the updated scripts to the scripts folder of your deployment share, replace existing files.
Also, copy the dism.exe and DISM folder from a x64 WTP boot.wim file to your deployment share, in my case E:MDTProductionToolsx64.
The dism.exe file and DISM folder are found in the X:WindowsSystem32 on your boot image (once booted), or E:MountWindowsSystem32 if you just mounted the boot.wim.
The needed files, copied to the deployment share.
After copying the files, add two run command line actions to your Windows Technical Preview task sequence (and only this task sequence).
Copy WTP dism.exe
cmd /c copy %deployroot%\tools\%architecture%\dism.exe x:\windows\system32 /y
Copy WTP DISM subsystem
cmd /c copy %deployroot%\tools\%architecture%\dism* x:\windows\system32\dism /y
The additional actions in the task sequence.
For those with the built-in administrator problem where the start button and notifications bar do not work, I have found a quick fix. Resolution – enabling the security policy: User Account Control – Admin Approval Mode for the Built-in Administrator Account. You can do this by running secpol.msc and making the change yourself or making a registry change here:
I plan on adding the this change as a .reg tweak added to the MDT task sequence.
Naboo, I have just tried a new build and capture with all of the new "tricks" and still have the admin account issue. Sad face 🙁
tmcglaun, have you get rid of your admin account problem. I've done again the whole process of build and capture and i encounter the same behaviour… weird since i managed to make it work once…
Thanks for all your comments. I have written a completely new guide for the build and capture process. There are more to it, and you will like it! 🙂
Oh, and used Johan's method to fix sysprep 🙂
Thanks for the tip Diagg. On a side-note, this mod also fixes the buttons on the OS Info tab. I changed it to 6.4.9926.0 since build 9879 was 6.4.9879.0 🙂
So to summarize, here's what I did:
– used the 9926 dism assemblies
– used Johan's script fixes
– used Diagg's tip (changed it to 6.4.9926.0)
Build & Capture like there's no tomorrow!
In fact, the faking the version of OS in XML trick plus your LTIApply.wsf manages to make the build and capture done. I'm testing right now to deploy the resulting image. Thanks all for your clever tricks 🙂 Helped me a lot.
LTIApply.wsf has multiple sections that are used with various actions in the task sequence. For example the "Apply Windows PE" action and the "Apply Windows PE (BCD)" are also using the LTIApply.wsf script. Some sections are using the ImageBuild variable and some are using OSCurrentVersion.
Just because a normal bare metal deployment works, it does not cover all scenarios. For example build and capture with the same task sequence fails.
Just give it a try, i used it to roll out my own machine. I could be wrong, but as far as i understand the LtiApply.wsf script, sOSBuild is the variable used to launch the apply process (lines 129 to 147).
Thanks for the tip Diagg.
but, the change in the xml file has only an effect on the sOSBuild variable (in the LTIApply.wsf), all the control made with the oEnvironment.Item("OSCurrentVersion") variable remains buggy (since OSCurrentVersion is gathered by ZTIGather process, ie WMI call, and is still 10.x). So, it addresses the bootsector creation, but i think that's all. Regarding the apply PE (my current issue ^^), some scripts are not still copyied on root drive because of this test… I'll continue digging into this tomorrow.
Awesome tip Diagg, yet to test it, will update the post once I do.
small tip for the lazy admin crew : instead of updating LtiApply.wsf and ZTIUserState.wsf, you can simply edit %DeployRoot%ControlOperatingSystems.xml.
Search for 10.0.9926.0 and replace it with 6.3.9600.17031
Up on this little "reboot-to-WinPE-problem" the deployment with MDT 2013 works now like a charm. It's just for gaming with the technology. 😉
I added a suspend step before apply WinPE to see the last reboot. After the last reboot I hit any key to boot from WinPE.iso as at the beginning. Image is captured.
Just to clarify, this is only for Capturing an image after the deployment. A bit useless if I can't create my own image as I install Office and everything else in it.
Of course my set up and MDT deployment share was working fine with the previous Tech Preview and I have applied all the changes suggested by Johan. A standard deployment works fine.
Same here, I can see that WINPE gets applied by MDT but when it reboots it still launches the target OS, not PE. At this point the MDT task sequence fails (cannot find a script file on C:).
I tried with both legacy BIOS and UEFI (because I thought that maybe the HDD geometry was affecting this) and actually with UEFI is even worse – My PC fails to reboot. I am running this on a VM on Hyper-V.
Dietmar, i don't know if the issue you encounter is exactly the same as Arjan's because my problem is the same as yours but not arjan's.
After sysprep, my machine do not boot in PE as well (but i don't have any issue regarding Admin account).
It probably be due to LTIapply.wsf that doesn't apply well the reboot to PE process but since i didn't know well the normal behavior… I have some difficulties troubleshooting this. So, if anyone has a good input, i'll be glad to read this :). (And i continue to try and understand what's going on).
Hi! Thanx for sharing! But same problem like Arjan. After Sysprep the machine do not boot into WinPE but Windows 10. Any idea? Thanks!
Unfortunately, it is difficult to troubleshoot if you can't log in 🙁
I am able to complete a build and capture but when I deploy the captured wim I get that the administrator account is disabled. It never joins the domain, etc. I'm troubleshooting now to see what the problem is.
Thanks again Johan, for the quick fix.With 9879 I was able to do a build and capture. Have you tried this and does it work for you? The build part runs ok, but the capture stops after the sysprep + reboot telling me the administrator account is disabled, where it should boot to PE and do the capture.I suspect this is caused by some differences in the 9926 image and the 9879 image? When I check the properties for the 9926 tasksequence (OS info) I notice I have a Sysprep.inf button and a Unattended.txt button and clicking them launches notepad… Read more »
Cortana is only available when you log in with a Microsoft account. MDT 2013 run the task sequence as a local account (Administrator).
Looks legit, but shouldn't there be a Cortana "Ask me anything" field on the taskbar? I have one on mine.
Bravo for having the MDT "how to" online before most people have it downloaded!!