Ok, so I’ve found out a lot more about why booting up with Windows files is more painful than it should be. Most of it comes down to the file system (on Linux) taking notice of case sensitivity. The problems I was having with the BCD were sorted out by making sure the BCD was put into Boot/BCD. I originally had it in BOOT/BCD. The case really matters, if it doesn’t match what bootx64.efi is expecting, then it will fail.
I then had another problem, again with case sensitivity, in that the BCD was requesting a WIM file from \sources\boot.wim – but I had my WIM file in \Sources\Boot.wim. I had to check the path using this Windows command:
I needed to copy the BCD file onto a Windows PC or somewhere else where the command could find it.
It took me a while to figure that one out as it never specifically said that it couldn’t find the WIM file, it just failed with an error code. I originally had code 0x0000000f – boot device inaccessible and then later got 0xc0000022 – BCD unreadable or configuration corrupt (not exact but I’m going by memory here, this message will self-destruct if left on the screen, normally before you’ve had chance to search for it in a search engine). Once all that is in place I could boot an MDT Windows PE image up and proceed with a deployment. In fact, it may even work with Windows 10 setup disks, but I’ve not tried that, and I imagine it would need a lot more in the sources folder which would make the size rather large (install.wim comes to mind).
I used the guide found here http://labalec.fr/erwan/?p=791 for which files I needed, however I found that some of the files were not where they were supposed to be. Generally, if a file cannot be found where it’s supposed to be, look in the EFI folder of your Windows source. I found some of the files in EFI/Microsoft/Boot. I had to check /var/log/messages a few times too to see if the correct files were being served. If something isn’t working right then it’s usually because Microsoft developers seem to be really sloppy with case sensitivity, I had to have ‘boot.sdi’ in a folder called ‘Boot’ and ‘boot’. However, once ‘boot.wim’ has loaded it uses an MS filesystem so no further changes to the filesystem are necessary. On reflection I wish I had created a small FAT partition to host my TFTP files which have solved these problems. Is this even possible?
The file winsipolicy.p7b is required in the EFI/Microsoft/Boot folder for secure boot to work.
I host the actual deployments in a standard Nethserver share created in the web console with read-access for everyone. Once you’ve create the share you can use the MDT Workbench to create a new deployment there using the share name as the path. The resulting WinPE (obtained by ‘updating’ the deployment share) is where I get all my boot files from – bootx64.efi, BCD, boot.sdi etc. This is found in the ‘Boot’ folder of your deployment share. I had to mount the ISO file to get the files.
As for my dnsmasq.conf the config I posted earlier actually works but I’ve stripped it down to:
I still don’t completely understand it, but it works. If anyone wants to do the same then don’t forget about the Nethserver templates-custom system otherwise your changes aren’t going to be seen. That was my first mistake and the reason for the NBP file messages I originally got.
So finally, I have all the services I could ever need from just one server and have saved on resources by not needing to create a VM for Windows Server which means my Microserver feels a lot more responsive (and for the most part all managed by a web interface).
One finally thought. I’ve come to realise this isn’t the most efficient way to boot Windows deployment images as it tried to do a majority of it through TFTP. This is slow. Even though the ‘boot.wim’ I use only weighs in at around 350mb it still took around 10 minutes before I was loaded into Windows PE.
Thanks everyone for your help and pointing me in the right direction!