3 Replies Latest reply on Dec 7, 2011 7:51 AM by DanOstaniewicz

    Can I PXE build a device without it contacting the core server?




      I'm basically trying to set up a training rig and which will be used in a totally offline environment (i.e. the master server and some PoS devices, running windows xp embedded, will only be connected via a hub with no access to a core server, or any other network for that matter).


      When I originally attempted to pxe build I could only get as far as a blank PXE build menu.  I found out that was because there is no DosMenu.cfg available, so I injected the cfg file into our image and modified the PxeMenuStart.cmd to use the local copy.  I now get the build menu I'm expecting, but when I select the build option it just hangs on the LanDesk splash screen.


      I believe it is hanging as it's trying to identify itself and register on the core server but can't, and therefore hangs.  So, does anyone know if there is a way to get this device to build without contacting the core server?



        • 1. Re: Can I PXE build a device without it contacting the core server?
          MarXtar ITSMMVPGroup

          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.


          Mark McGinn

          MarXtar Ltd


          LANDesk Silver ESP


          The One-Stop Shop for LANDesk Enhancements

          - Wake-On-WAN - Distributed Wake-On-LAN, Scheduled Power Down, and SWDist Sequencing

          • 2. Re: Can I PXE build a device without it contacting the core server?
            Jared Barneck SupportEmployee

            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)

            1 of 1 people found this helpful
            • 3. Re: Can I PXE build a device without it contacting the core server?

              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.