It's just not designed to work in that way as it expects to have the core server functionality available. Yes, you could probably make this work editing the PXE config and possibly finding a bunch of associated files but you'd be just as well either building another core server to use offline (at least that would be supported) or using another PXE service such as WDS.
LANDesk Silver ESP
The One-Stop Shop for LANDesk Enhancements
1 of 1 people found this helpful
Step 1 - PXE Representative
The PXE Rep sends a query to the Core Server. If the Core Server does not a respond, the default list should be sent to the PXE booting device.
Note: If you are not seeing this, please submit a bug. It used to work this way and so if it isn't working this way, then something changed in the past few versions as I last tested this years ago. Also, while you submit the bug, you might ask for a registry key to turn off the Core check altogether as why wait for the timeout if you know access to the core will be non-existant.
Step 2 - Booting to WinPE
WinPE will contact the Core Server early on to get the DosMenu.cfg. You must add a local version of Dosmenu.cfg. However, if you don't have access to the Core Server, this isn't going to help you.
Step 3 - Imaging process
The Menu of OSD Scripts requires access to the Core Server, so without Core Server access, you are left to your own devices. That means you need to use your own script (batch, VBscript, etc...). Feel free to open your OSD Script.
So your process would be like this:
1. Pxe boot
2. Machine loads a tool you wrote that shows a list of your scripts (not a list of our scripts)
3. You select your script and it runs (as bat or VB or whatever you wrote the script in)
Thankyou for your input.
I have managed to get the build to complete!. The build menu was exiting after an image was selected, but no build was actually being started because it couldn't register on the core. I modified the StartNet.cmd to start the BuildMenu itself, instead of calling PxeMenuStart.cmd, and then started the exe we use to initiate the build from StartNet.cmd too.
The next issue was that the script was starting the BuildMenu and the actual imaging exe at the same time, so by using the 'start' command with a /WAIT switch when I started the BuildMenu and build executables it waited for the build menu to exit (after failing to contact the core) and then starts the imaging exe.
So now the training system looks like it's working the same as a live system (even though the process behind is different!). I also had to add a 'reboot' command to the end of the script as the auto reboot done during imaging did not work.