PXE Problems

[mobit]

Hey Everyone,

 

When I've run in to hitches in the past this has been a great place to find information related to the problems I've experienced, so I'm hoping someone can help me out with the problem I'm currently having. I've been working on getting Operating System Deployment functioning on the newly-implemented SCCM server in my organization by following the instructions in Anyweb's guide. However I'm encountering an issue at the PXE boot portion of this.

 

The SCCM 2012 server is virtualized, but is not using infiniband. The boot images have been successfully distributed, are checked with the "Deploy this boot image from the PXE-enabled distribution point" option. The distribution point itself has PXE support enabled, along with all of the other options for unknown computers, responding to PXE requests, requiring a password, etc. The WDS role was installed after setting this up, as per usual. There were a few indications of possible issues in the distmgr.log now that I look back at it (I presume if it's in red it's failure/error?) and I'll attach that in a moment. But I wasn't looking for anything but the WDS at the time.

 

Anyway, so WDS is installed and since the DHCP server is not on the same host so I've set the appropriate DHCP options for PXE clients to access this. Attempting to PXE boot from a physical machine on another subnet simply results in the PXE client getting the DHCP address and then starting the TFTP, but then immediately exiting with "PXE-M0F: Exiting Intel Boot Agent" and proceeds to the next boot device. Not wanting to complicate things by traversing subnets just yet, I took that out of the equation and added a VM on the same subnet as the server. When I tried to PXE boot from that client it starts the TFTP process and then returns PXE-T01: The Specified file was not found, PXE-E3B: TFTP Error - File Not Found, PXE-M0F: Exiting Intel PXE ROM, etc.

 

Taking a step back, I have attempted to troubleshoot the TFTP process and see what the hang-up here is. Checking the SMSPXE.log shows that it finds the image (though there are some errors here that don't make sense "Failed to copy the needed boot binaries from the boot image. The operation completed successfully. Error: 00000000"), after these errors it seems to find the images, load the required API, open the image, read the image file and then subsequently validate it. I check the REMINST folder for the appropriate files, they're there. So maybe the TFTP process is failing?

 

On another system on the same subnet, I attempted to use the TFTP client to grab one of the PXE files from the SCCM server using the same information I supplied to the DHCP options. The only result is a long pause and a "TImeout occurred, Connect request failed" message. Trying the same command from the SCCM server itself grabs the file just fine. I try again from the TFTP client on a remote machine and attempt to grab a file that I know doesn't exist on the SCCM server. No pause, it errors out immediately saying "Error on server : The specified file was not found. Connect request failed". So, this confirms to me that it is at least communicating with the SCCM server at the TFTP level, but it's not getting the file that should clearly be there.

 

I tried my first test with the TFTP client again, this time with wireshark running. It seends a read request on the correct file, and it looks like the SCCM server starts returning Data packets. The TFTP client continues to send read requests, and the SCCM server continues to send data packets until the TFTP client system sends an error code saying that there's been a timeout on receive. The SCCM server stops sending data packets shortly thereafter. The test file is only about 25k and should not present an issue of this sort.

 

In my troubleshooting I've tried removing the WDS role through SCCM and then re-adding it as some guides have recommended (purging the windows temp folder in the process), I've turned off the firewalls of the computers I'm working with without any change in behavior, I've deleted the distributions for the boot files and re-distributed them/validated them. Looked for issues in the SCCM log files during the PXE process, the only issues I've found were from the setup of these - nothing during the actual process - see logs. I've checked and re-checked the settings that I've configured for these images and their distribution through SCCM.

 

Sorry for the wall of text, wanted to provide as much info as I could as to what was happening and what I've done. I have yet to attempt this with a physical machine on the same subnet, but am working on that now. Any help is much appreciated!

SMSPXE.log

distmgr.log

[mobit]

A bit of an update. I tried to transfer over TFTP from a physical machine on the same subnet and it had a different problem in that "tftp.exe: can't write to the local file 'C:\temp\pxeboot.n12'", which was the file I tried to copy. So, again it seemed to be communicating with the TFTP server, but had issues going further.

 

This gets messier, DHCP traditionally has been disabled on the subnet that the SCCM and DHCP server occupy. For testing this, I enabled DHCP and limited the scope to a few available addresses that are currently unused on that subnet. Since all the hosts there are statically assigned this would not impact them, but I quickly found out that only other virtual machines were grabbing DHCP addresses and that physical ones were unable to get DHCP addresses. Great, another issue.

 

Sidestepping this, I reassigned the SCCM server to a different subnet, changed the DHCP options for that subnet to point to the appropriate IP address, and then tried booting a DHCP PXE client on that subnet, and lo and behold it had no problem grabbing WDSNBP and searching for a policy. Since I hadn't configured the policy for the machine I was working with I left it at that. That worked! Unfortunately, the SCCM machine can't live on that subnet, so I switched it back - but now, given all the other issues I seem to be encountering, would it just be simpler to throw another vnic in that system on the other subnet and have the server respond to PXE requests using that nic?

 

Barring that, does the results of these further tests help identify where the problem may lie with this? At the moment, my best guess is that some configuration on the subnet I'm trying to current work with is hindering these TFTP transfers... but then why did wireshark show TFTP data packets being returned to the client computer when I was attempting to grab a file using the windows TFTP client?

 

Thoughts anyone?