8 Replies Latest reply on Dec 7, 2018 1:52 AM by phoffmann

    PXE Configuration in a Mixed UEFI/Legacy Environment


      Over the last year or so I've been trying to resolve the issue of supporting PXE Boot clients with a mix of UEFI and Legacy BIOS devices. I believe that I have resolved my issues. I currently have this implemented and it works very well. I have documented the solution and have submitted it here. I have tested this solutions on 9.5 SP3 through 2016. Feel free to critique, correct, or provide your own input.

        • 1. Re: PXE Configuration in a Mixed UEFI/Legacy Environment
          LANDeskWizard SSMMVPGroup

          Not a critique on your document, as it looks very detailed, but in 2016 SU3, LANDESK has added the capability to PXE boot UEFI devices without scheduling them.


          It has not been advertised much but the capability is there. We are using it but are experiencing an issue with Legacy BIOS. Currently working through that issue.

          • 2. Re: PXE Configuration in a Mixed UEFI/Legacy Environment

            Your solution surely works, but I found another way to attack the problem.


            LDMS 2016 gives you the possibilty to have conditions in the template. Therefore I created a little wizard where the user can make a lot of choices, like UEFI or BIOS mode, and the template will then apply the right configuration. There's also a way to automate the recognitiion of the current mode, but I wanted to leave the choice to the user / technician. I guess my approach is easier, but certainly not as elaborated as yours :



            I am pretty new to Landesk, as my company acquired it only last year. First priority was software deployment, so by now we got this going and it is working fine. The next challenge was to deploy images over the network, as we have a lot of subsidiaries in the world, often with no technical people at all. If you use PXE, you don't need any USB stick, you just connect to the network and always have the latest version.


            As this works that way for BIOS systems, I recently learnt that it is just not possible to do this for UEFI systems.


            Landesk's solution is to either use a USB device booted in UEFI mode in order to load the boot_64.wim or to create an entry as bare metal server and then schedule the template. With the help of the community I got this working, but for me this was no feasible solution, as it would have created supplementary work for our IT and made the simple system more complicated.


            I read also a post from someone who just renamed the boot_64.wim in boot.wim and thus got the 64bit version over PXE. This solution has the limitation that you're restricted to UEFI only which doesn't work for me neither, as he still have a lot of systems that run only legacy BIOS.


            By the way, another downside of the 64bit  WinPE for me is the unpredictable behaviour of the resolution - while it is ok for a Dell Latitude 7440, it's just not reasonable on a Dell Precision 5510.


            So I decided to keep the 32bit WinPE and add the possibility to deploy an image in UEFI mode.




            If you are in 32bit, bcdboot.exe supposes that you are in BIOS mode and thus applies the standard procedure for MBR.


            As we need to format the HDD in GPT mode, this doesn't work and leaves you with a system that doesn't boot



            We have to manually copy the boot foiles to the system drive and configure the bootloader as described in Apply a Windows Image to UEFI-based Computers



            1 ) The standard Landesk script for UEFI :


            select disk 0


            convert gpt

            create partition efi size=100

            format quick fs=fat32 label=System

            assign letter=S

            create partition msr size=128

            create partition primary

            format quick fs=ntfs label=Windows

            assign letter=C


            2) A copy of the EFI folder of an UEFI system


            3) A batch file with the following commands :

            bcdedit /store s:\EFI\Microsoft\Boot\bcd /set {bootmgr} device partition=s:

            bcdedit /store s:\EFI\Microsoft\Boot\bcd /set {memdiag} device partition=s:

            bcdedit /store s:\EFI\Microsoft\Boot\bcd /set {default} device partition=c:

            bcdedit /store s:\EFI\Microsoft\Boot\bcd /set {default} osdevice partition=c:





            1) Create an Execute file action that runs diskpart with the script


            2) Create a Copy file action to copy the EFI folder to the S:\ drive


            3) Create an Execute file action that runs the script


            Then you can apply your wim file and the computer will boot to Windows.

            1 of 1 people found this helpful
            • 3. Re: PXE Configuration in a Mixed UEFI/Legacy Environment
              phoffmann SupportEmployee

              Great info & sharing throughout this post.


              *tips hat*.


              This sort of stuff makes you guys awesome .

              • 4. Re: PXE Configuration in a Mixed UEFI/Legacy Environment

                Thanks for the info LANDeskWizrd, but would you happen to know where the UEFI/BIOS PXE capability you mention in SU3 is documented?

                • 5. Re: PXE Configuration in a Mixed UEFI/Legacy Environment
                  MrGadget Expert

                  I know this discussion was already answered but I will put my 2 cents in.

                  We are on 9.5 SP3landesk Management and just started with with windows 10 64 bit in UEFI mode.

                  Most of our other computers are a mix of 32 and 64 bit legeacy bios Windows 7.

                  The 64 bit legacy bios computers only grab the boot.wim  not the boot_64.wim. I found when we started imageing the UEFI mode computers(64bit) it grabbed the boot_64.wim. So we have had no problems with PXE booting.

                  If you have 32bit in UEFI mode then I haven't tested that since all computers I've seen that are newer come in 64bit OS.

                  • 6. Re: PXE Configuration in a Mixed UEFI/Legacy Environment

                    I got around this with a powershell call to identify if it was a UEFI BIOS in PE, and then taking action based on that using a set of conditional actions...

                    The command parameter line for the conditionals is:

                    -noprofile -nologo -noninteractive -executionpolicy Bypass -Command "$isuefi = (Get-ItemProperty -Path HKLM:\System\CurrentControlSet\Control).PEFirmwareType; exit $isuefi"


                    If it returns 2, its UEFI, if not, its BIOS.

                    So the top conditional checks if not UEFI, and in that case make the MBR boot partition bootable.

                    Then, if it is UEFI, down the process a-ways, auto assign partitions and bcdboot to the S:, which is the UEFI system partition

                    If it's BIOS, just bcdboot the C:, which is the Windows Installation drive

                    A lot simpler than some other approaches, but should really have been integrated.  I've found that if you capture the image from a BIOS based VM, the built-in process works fine for the most part.  If you capture from a UEFI based VM, you need something like what I've done...


                    Good luck out there!

                    • 7. Re: PXE Configuration in a Mixed UEFI/Legacy Environment
                      Abnranger67 Apprentice

                      Hey all, kind of late to the party, but with Windows 10 having the built in tool mbr2gpt tool, you could put a task that executes a file as such c:\windows\system32\cmd.exe. Command line parameters would be /c mbr2gpt.exe /convert /allowFullOS. Then add a reboot task after. This would convert the existing firmware from BIOS to UEFI. If the drive is already UEFI, it will just error out and continue.

                      • 8. Re: PXE Configuration in a Mixed UEFI/Legacy Environment
                        phoffmann SupportEmployee

                        Interesting / good idea.


                        Though you'd probably want to wrap it into a script ... that way, if you get an error, you can handle it & still exit gracefully (as an error exit-code may well be expected in this "well, if it WORKS, great ... if it doesn't, that's fine too" scenario) .