Grasty

Thanks for the clarification as to why changing it to x64 didnt work. I did tell the network guy that they need to add ip helper addresses, I am just waiting for him to actually do it. Thanks again both of you

Here is the video https://vid.me/G4RK I tried removing the DHCP Options, but then the IPv4 PXE just timed out. Then I tried changing the boot option to be boot\x64\wdsnbp.com but i got the same error as before. I am still waiting on the network guy to try and add the ip helper addresses.

So after spending all day trying to get this to work, I think I found the issue. I could have sworn these guys were using ip helper addresses and not DHCP Options, so when I saw all those recommendations to use ip helper addresses, I ignored them because I thought they were already setup. I noticed that there was another message popping up in between the PXE IPv4 and the error I was getting, but it was flashing across the screen really quick and i couldnt read it in time. I video recorded the process and tried to go frame by frame and noticed "NBP Filename boot\x86\wdsnbp.com", which is weird because im using a x64 Boot image. So I looked at the DHCP Options and sure enough, there was Option 66 and 67 pointing to the SCCM Server and boot\x86\wdsnbp.com. I tried removing them, but then PXE just timed out so I dont think they have the ip helper addresses configured. Unfortunately that isnt something I have access to so I cant check it. Anyways, im confident that is the issue. If it still doesnt work after ip helper addresses then I will post back here.

Im not sure if it is failing before or after picking the boot image and connecting to the SCCM Server. I only see these two lines in the smspxe log from this morning since I got here Begin validation of Certificate [Thumbprint E6A6897EBADD1990D967119DE527783A302D2587] issued to '{E80B36A6-97EA-40AE-AB65-C5D77BEC0077}' SMSPXE 9/26/2015 9:44:57 AM 11544 (0x2D18) Completed validation of Certificate [Thumbprint E6A6897EBADD1990D967119DE527783A302D2587] issued to '{E80B36A6-97EA-40AE-AB65-C5D77BEC0077}' SMSPXE 9/26/2015 9:44:57 AM 11544 (0x2D18) Here is the error: http://imgur.com/6YchO5i To PXE Boot, I am holding down the volume down button and pressing the power button. Then I let go of the volume down button when i see the Surface Logo. Then i see something along the lines of "PXE Boot ipv4" or something like that. Then I get the error. This is a brand new surface pro 3, so the settings on it should all be whatever they default as when you buy it.

So I have a working Windows 10 OSD Deployment MDT Based Task Sequence that I am trying to use on a Surface Pro 3. I added the NIC Drivers to the x64 Boot Image, and I have confirmed on other systems that the x64 Boot Image is the one being grabbed by PXE (The whole LIFO thing), so I am confident that the x64 Boot Image is what is being grabbed on the Surface. When i attempt to PXE Boot on the Surface I just get the error "Invalid Signature Detected. Check Secure Boot Policy in Setup". If it makes a difference, I am using a dock. Also I am using SCCM 2012 R2 SP1 (I also have MDT 2013 Update 1 Re-Release installed).

Youre right, it isnt needed. I forgot to make a new MDT Toolkit package when i upgraded from Build 8290 to 8298. Once i added in the new Toolkit, it all worked correctly.

I installed 8298 last night on my MDT Server and on my SCCM Server, and I created a new MDT Based Task Sequence in SCCM (as recommended by the re-release post from Microsoft). When trying to image a system with my Windows 10 Image, the system installs ConfigMgr and then reboots and goes through the "setting up services" first boot/sysprep setup area. Then it continues setting up ConfigMgr and I get the error "Cannot find script file X:\LTIBootstrap.vbs". So I assumed it was related to the options you said to remove from the Unattend since that script is referenced in the FirstLogonCommands section which you said to remove. I tried creating a new Settings package thinking that maybe it would be different after 8298, but i still get that error. Ill remove the sections from the unattend.xml and see if it makes a difference, but im not 100% sure my error is related to that unattend.xml.

Do you still need to remove AutoLogon and FirstLogonCommands from the Unattend.xml after the re-released MDT 2013 Update 1 (8298)? In your guide you said that Johan had said to remove them in his MDT Update 1 upgrade guide, but i dont see it there, so I can only assume that he removed it when the re-release came out because it was no longer needed?