Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Tuesday, May 20, 2014 10:13 PM
Greetings,
I was curious if anyone has experienced a similar issue where your PXE enabled DP receives a TFTP request, but then fails with "Error Code 63: Illegal TFTP Operation, Message: Access violation." We are cutting our teeth on PXE and this is our first attempt to get it working. It took a bit of work with our network team to get the boot path configured, and argue between forward slashes or backward slashes, lol. PXE Clients can reach the DP now obviously, but not beyond that. Media based TS are working flawlessly, so we know the mechanics are in order. As a sidebar, does anyone know where the "WDSServer" account is being issued for the REMINST share? I can't find it on the local machine or in the domain.
The first screenshot is the PXE error on the DP. The second screenshot is the sneaky WDSServer account.
Where ever you go, there you are.
All replies (8)
Tuesday, May 20, 2014 11:01 PM
It took a bit of work with our network team to get the boot path configured in the IP Helpers, and argue between forward slashes or backward slashes
Sorry, but that makes no sense. You do not configure paths for IPHelpers, you do configure paths for DHCP scope options though. They are two very different things. IPHelpers are the preferred and supported solution.
Jason | http://blog.configmgrftw.com
Wednesday, May 21, 2014 1:25 AM
Thank you for your reply and I agree with you. I was reiterating what our network team told me, they might be simplifying it for me. But, the result is still the same regardless of the method. Since the client can reach the DP, I think we can rule out possible network issues, which is what I was trying to convey. Thanx again.
Where ever you go, there you are.
Wednesday, May 21, 2014 6:25 AM
What exactly has been done by the network team? You either set up IP helpers *or* DHCP options 66/67 (which is officially unsupported but works). Please tell us the exact configuration.
Torsten Meringer | http://www.mssccmfaq.de
Wednesday, May 21, 2014 3:45 PM
Thank you for your reply. The Network team elected to use DHCP options 66/67. Our environment is not straight forward, we use two DNS services for instance. What I do know is that PXE is working for other OS's using the same method as ours. They verified with me that the server was getting the TFTP boot request, so they ruled out a network configuration issue.
Where ever you go, there you are.
Wednesday, May 21, 2014 4:04 PM
What has been configured for 66 and 67? /REMINST/... etc is incorrect. It should be SMSboot\x86\wdsnbp.com
Torsten Meringer | http://www.mssccmfaq.de
Thursday, May 22, 2014 3:14 PM
Option 66 is the IP of the WDS server, and 67 is the path "/REMINST/SMSBoot/x86/wdsnbp.com" on the same server. How would you suggest for me to test that the path you provided is accessible? The path I provided is what shows up as a share to c:\RemoteInstall..., which I didn't create. Should there be one starting with "SMSboot"? I do know that if we use backslashes in the boot path I gave to our network team, the client sees the entire path as a single file name and the backslashes are removed.
Sorry for the bad quality, but this the what happens when we assign back slashes.
Where ever you go, there you are.
Monday, June 9, 2014 4:03 PM
Changing the path to '/SMSboot/x86/wdsnbp.com' got it working, though I'm not sure why exactly. Could this be explained a little more? I was using a path from a share to the boot file which seemed logical. Anyway, thank you for your help. It got us underway!
Monday, June 9, 2014 4:28 PM
Because it's using TFTP during PXE boot and is not accessing the file using a share.
Jason | http://blog.configmgrftw.com