Okay lets try again...

Hello.

I am working on a server lab and i have to servers in my network a DC and an app server and they are both Windows Server 2012 R2 DataCenter.

on the DC i have DNS, AD DC and so on.
and on my app server i have SQL server 2012 enterprise and SCCM 2012 R2.

I have setup my router to alow TFTP and my client PC finds the router, the server and the boot image but it can't find the install image that i have in my shared folder (\\app-server\SCCM\OS\Client\Windows 7\x64\sources\install.wim). Everytime i try the PC just reboots after trying to start the network connection in Win PE.

I have tested it on a client machine and in Hyper-V on Server 2012 R2 whit the same result also i have don a repeare on the Windows 8.1 ADK and that did not work ither.

Is there some one there knows if theres a way to fix this?

Hi Jonas,

I just reviewed the previous discussion thread for you, and watched the youtube video you made.
Is this still unchanged? No resolution?

If so, I made the following notes of the timeline from your video:

00:13 firmware boot device menu selection
{selected nVidia boot agent
00:16 DHCP discover/request
00:17 DHCP offer/ack
00:18 TFTP boot

{client is      192.168.1.162
{dhcp is        192.168.1.1
{boot server is 192.168.1.198
{dloads wdsnbp from boot server
{arch=x64
{WDS message: "CM is looking for policy"
00:19 contacting server 192.168.1.198
00:38 tftp dload : smsboot\x64\pxeboot.com - press F12 for notwk srv boot
00:41 loading files... 192.168.1.198, file: \SMSboot\boot.sdi
00:42 loading files... 192.168.1.198, file: \SMSImages\AAA00005\boot.AAA00005.wim
02:39 blank screen
02:44 Win8 logo
02:47 BSOD: DRIVER_VIOLATION

Is this still your situation?

This is quite a long time to download the boot.wim (but it could be your network, or, there is a hotfix for CM12R2 for slow dloads, I think).

It seems to me that the TFTP download looks ok, but, is it downloading the correct WIM for your client hardware (x64-capable ?)

It also might be, the boot.wim contains errors.

Since the same error occurs in a Hyper-V VM, (which generation VM did you use, G1 or G2?), this tends to suggest a problem with the WIM.

I Note that the issue is occurring with boot.wim, not with install.wim. (the video shows that you have not progressed fully into the boot.wim environment yet, so cannot be at the install.wim phase y

Yes it is. It's the same even after the Update and i run a Dual core Intel. My virtual machine is G2 for the pxe but the pxe use the Windows deployment service for the boot and boots in to system center and reboots like in the video. I have even made a repare on the ADK for Windows 8.1 and updated the DP.

For a test, I would try with a Gen1 VM, to see if the boot.wim can boot successfully.
I would also try a TS Boot media to eliminate any possible PXE issue and to confirm the integrity of your boot.wim.

What about LAN a driver or DNS? I only have a fresh boot image and a DNS server on both my router an DC? Could that be the problem?

Sure, it's possible it might be a LAN/NIC driver, but these drivers are contained within the boot.wim, and you've said that you are using the boot.wim from the ADK?

So if you haven't customised the boot.wim (e.g. by adding/injecting additional drivers), the boot.wim is the original one from MS, and likely to be ok, I think :)

It's possible that a "bad" NIC/LAN or storage driver (either bad drivers injected by implementer, or, the boot.wim is damaged/corrupted), could cause this issue.

I can't imagine that a DNS problem could cause your symptom.

Your video shows that the boot.wim is downloaded from WDS/DP via TFTP, and then a long delay before WinPE throws the BSOD DRIVER_VIOLATION for you.
This suggests to me that when the WinPE kernel is initialising into the RAMdisk instance, boot-critical drivers are loading but throw an exception. This is difficult to diagnose, because a BSOD which occurs at this early phase in WinPE, really needs logging (which WinPE doesn't readily offer, as it reboots), or debugging via serial port.
All of which is rarely needed, and unlikely to be fruitful unless you are a Windows kernel engineer, I think ;)

Maybe it's the NVidia NIC (I'm not familiar with those), so this is why I suggested a VM, and since you have tried a Gen2 and it failed, I would try a Gen1, and if that fails, maybe your ADK download from MS is bad?

I will give the hyper-v g1 a try when I get home.

This is my Hyper-V G. 1 Test on my laptop.

http://youtu.be/CTQNe6qf5pU

My ADK is a so called web installer from MS them self. And i have tryed a repare on it whit no luck.
Can i use my boot image from my Win 8.1 install disk to check if it's boot.wim?

So, your new video shows that a few things have changed.
00:41 start dload boot.wim AAA00004
05:25 dload complete
05:27 pe logo splash
05:45 logo gone
05:50 wallpaper and tsui with org name
05:58 prep nw conns
06:01 reboot

a. this is using a different boot.wim from a different package number (what have you changed there)
b. the boot image wallpaper background and TS progress UI are displayed (this confirms that WinPE is now successfully loading)

c. a reboot occurs after WinPE initialisation is complete (this is a default behaviour of WinPE, when there is nothing left to do i.e. the WinPE list of tasks is empty)

So this is progress, of a certain kind, even though it is still not doing what you want.

Check the packages for your boot images, is AAA00004 for x86 and AAA00005 is for x64 ?
There is a clear difference between the two boot.wim files on that "hardware", it could simply be the x86 vs. x64 architecture incompatibility to your hardware or VM generation.

Enable the debug feature on the boot image package, and try again, at the point in booting where the background/wallpaper is displayed, repeatedly tap the F8 key (to open the debug console) and then you can check the SMSTS.log, to find out what WinPE is doing (possibly it's not getting policy, or has not been approved or something).
Also check the SMSPXE.log on the DP to correlate the server view of events with the client log.

For some reason have it changed boot image fro x64 to x86. I'm working on a redo for that. I have tryed the debug feature before and it just open CMD for a few seconds and then it reboots.