jones948

Hotfix is out now: https://support.microsoft.com/en-us/kb/3089193

I opened a case with MS Support on this and they confirmed it's a known bug to be fixed in CU2.

Was able to test again today on a physical PC and it worked fine for me as well. Something odd going on with VMs apparently.

Ah, interesting. What VM software are you using? I got excited and put 10 on my workstation and had to put the beta of VirtualBox 5 to do my builds and testing. Trying to recall if it ever worked correctly under the VirtualBox beta.

I'm using the Win 10 ADK, so that does not appear to be the source of the problem. I'm also on 2012 R2 SP1 CU1 (have been on CU1 prior to beginning my Windows 10 testing). I also ran into this problem when I first started testing SCCM and my build and captures were failing because of the "updates with multiple reboots" issue. The build would fail and end up at the login screen (rather than the Windows setup page) get captured like that, and subsequent deployments with that capture would get named MININT-xxxxx. Even though I had the new "retry" option turned on for Software Updates, I disabled all software updates in my build and capture for Windows 10 and still have this problem.

Check the CCMExec.log on one of your DESKTOP-xxxx machines. If you scroll back to the beginning of the log, do you see time stamps from your original capture? (I am) I'm wondering if the client isn't getting initialized properly during the capture and so we're deploying an image with remnants of the original client install. Edit: Nevermind - just mounted the .wim of one of my older images that works fine and it has the logs from the original capture.

I do the same thing (.HTA at the start of the TS to supply a computer name), and am seeing the same problem with the machine name. The computer is named DESKTOP-xxxxx at the end of the deployment. What's your source image for the OS? I'm using a captured reference image with Office 2013. When I switch the image to the install.wim from the Enterprise .iso, the problem goes away. Odd thing is, it was working for me, but then I recaptured my reference image to include .NET 3.5, as one of our apps requires it.

I ran into a similar problem and came across this thread trying to track down the cause. In my situation, I found a Forefront Defs package a prior admin had setup that was pointed at the root of our package share \\<server>\Packages, where we are storing all our update packages. The package was also being updated by an automatic deployment rule. My guess is the ADR was running, seeing folders that weren't part of the Defs package at the root, and clearing out everything else, like: \\<server>\Packages\Win_7_Updates, \\<server>\Packages\Win_8_Updates I've pointed the Defs package to a subfolder, am rebuilding my other packages, and will see how it works out.