D3w4yne

Unfortunately that's not an option for me as my environment has many Surface Pro's and other UEFI systems.

Microsoft has no solution at this time... They have escalated the issue to the "Design" team and suggested I file a bug on the Connect web site. I pretty much expected this once we learned that the issue could be replicated with WDS and the default Windows 10 boot.wim. I guess they would have to generate new wim files in a later release of Windows 10 and ADK 10? I don't see that happening anytime soon so I guess we're stuck with this... Sorry

I followed Brandon's post and it still fails. At this point I can produce failures with just WDS and ADK 10 boot images with Powershell. SCCM isn't the problem.

I did a little more experimenting this morning. I set up a standalone WDS server and imported my SCCM boot image. Powershell failed. I set up brand new boot images using the winpe.wim in ADK 10. I added Powershell and it's dependencies with dism and added it to WDS. Powershell still failed. I took the boot.wim provided with the Windows 10 enterprise media and added Powershell with dism. Powershell still failed. At this point there are no SCCM components involved at all.

So tonight I got a call from Microsoft, this time from another department. He had me try the boot.wim that is included in the Windows 10 media. I went through all the steps to add .Net and PowerShell and we encountered the exact same issue as before. I think they are starting to narrow their focus onto WDS since the issue only presents itself during PXE boot. Dewayne

EDIT: Never mind

Out of curiosity could you both give a few more details about your set up? In my case I have a single server, hosted on VMWare. OS is Server 2012 R2, SQL 2012, SCCM 2012 R2 SP1 CU1 and ADK 10 (Obviously) My PXE test machine is on the same subnet so I'm not using any helpers or DHCP options. The only optional components in my boot images are WinPE-NetFx and WinPE-PowerShell. As of last night MS said "I have engaged our technical leads and they are also trying to get in touch with the product development team to get more information about the issue. This procedure may take some time and I will be keeping in touch with them for any updates on the issue and will keep you posted as well."

FYI MS is trying to reproduce the issue in their lab. I am waiting on their results. Niall, I upgraded to R2 SP1 and then removed ADK 8.1 and installed ADK 10. I did follow Brandons guide after the upgrade. Joohan, I created a bootable iso and PowerShell is launching every time, although very very slowly.... it takes roughly 30 seconds after running powershell at a command prompt. Dewayne

I did finally get a ticket submitted successfully. I'll keep updating this thread.

And the support request site breaks when I submit my ticket. How ironic. I don't see any phone numbers published on the site anymore either.

Yeah that's me... I've gotten nowhere with this. A single support incident from Microsoft is $499 now (I thought it used to be $299) but I guess I'm going to have to suck it up and call.

I only have: WinPE-NetFx WinPE-PowerShell

I've been fighting this crazy problem as well... example here: http://imgur.com/6o0TAof I've rebuilt my wims, reinstalled the adk, added/removed components and nothing has worked. Can you give me some more detail on how you resolved it? Are you sure it's resolved? Thanks, Dewayne

Awesome! I installed the hotfix, re-installed the console, and WDS is still running. Thanks for the heads up.

Uninstalling the console worked for me.... It was mentioned in another thread on this forum. Apparently MS is suggesting running a PXE enabled DP on another system as a temporary work around.

Mine was already set to .Net 4.... Glad you found a fix though.

I was able to resolve my issue.

Removing SCEP had no affect for me.

That worked! Appears the main difference is using copype.cmd, as I had already done all of the other steps in that order, except for that one. Awesome! Thank you. Well, that didn't last long. It's back to WDS refusing to start. It was running ok with just the x86 boot.wim, as soon as I added the x64 boot.wim WDS crashed. I removed the x64 boot.wim and WDS still won't start...

I tried all of the above methods and nothing is working so far.... My lab was upgraded from CU3 to R2 and I did not experience this issue. We set up a new production site from scratch however and this has been an issue from the start. edit: Hadn't seen mniccum's post yet. I'll give that a shot and see what happens...

$Schedule = New-CMSchedule -Start "10/30/2013 12:00 AM" -RecurInterval Days -RecurCount 1 New-CMDeviceCollection -Name "TEST-Collection Schedule" -LimitingCollectionName "All Systems" -RefreshSchedule $Schedule -RefreshType Periodic The above works in my 2012 R2 lab, but I cannot get it to work in production on 2012 SP1. Is the code specific to R2? Mainly the -RefreshSchedule parameter? If I use New-CMDeviceCollection to create a series of collections, they are created with no update type enabled. Neither schedule or incremental. I was able to use your powershell code from the link above to set a schedule, however the box to actually enable the schedule is still unchecked. Any ideas? Thanks, Dewayne

Please disregard. Apparently it was necessary to re-deploy the KB977384 hotfix to increment the client version.

I have installed the latest version of R3 but my client version number is still 4.00.6487.2125. I had the beta of R3 installed previously. I removed it and upgraded to the RTM but my client version will not increment. Dewayne

I posted this on myitforum but I am still not entirely clear on what is happening.... We’re beginning a computer refresh from XP to W7. I have created USMT task sequences for client profile migration. When the client attempts to connect to the SMP I get the following error from the smsts.log: Failed to verify certificate signature for 'distributionpoint.domain.local' (0x80090006) ClientKeyRequestToSMP failed (0x80090006). I tried deleting the cert on the client machine, and that provided this in the locationservices.log: Both the trusted key and the mp certificate have changed on serverThe client cannot validate the authentication information I AM able to resolve this by running CCMSetup RESETKEYINFORMATION=TRUE however that does not seem like a very clean solution. Some have suggested running the delcert.exe utility on my management point but I do not know the impact that will have on my environment. I have installed the hotfix KB977203 on my site server and deployed ccmcertfix.exe to all of my clients. I thought this was all I needed to do to correct all of the certificate problems caused by the windows update KB974571. Any advice is appreciated, Dewayne