wimboot - sccm tsbootshell.exe

[muzz]

so, it turns out I haven't quite got it sorted:

The BootServerReply key in HKLM\SYSTEM\CurrentControlSet\Control\PXE does in fact contain some useful information.

so having done a packet capture of a traditional tftp boot sequence, the following happens:
1. gets smsboot\x64\wdsmgfw.efi (in the case of an uefi machine) .com or whatever for bios
2. boot manager performs a dhcp against a dhcp request against the WDS host, passing options 93 (arch) 97 (uuid) 60 (vendor class) and another 15 bytes as option 250 (private). and requests options 60, 128-135

the dhcp ack from the wds server then provides:
option 243 (private) 83 bytes which refers to \SMSTemp\YY.MM.DD.HH.MM.SS.MS.{GUID}.boot.var
option 252 (Private/Proxy Autodiscover) 80 bytes which refer to the (as above).boot.bcd



so these files are being generated by the SMS/WDS server and it is this DHCP request/ack that are present in the registry of the booted winpe image as the HKLM\SYSTEM\CurrentControlSet\Control\PXE BootServerReply & DHCPServerACK keys.

tsmbootstrap.exe then runs and attempts to tftp download the boot.var and use this as x:\sms\data\variables.dat

this is where the problem lies: these files won't exist for a client that hasn't been booted via the traditional tftp download; furthermore it seems that SMS/WDS is doing some housekeeping on \SMSTemp

Ill play around a bit more when I get some time and let you know how I get on - this is my plan

1. the boot.bcd seems to be irrelevant in a wimboot scenario so ill ignore it
2. it seems that the .boot.var appears to be consistently the same data for different machines. so I'll try to see if I can inject a variables.dat with wimboot to see if this satisfies tsmbootstrap.exe
3, alternatively if it insists on downloading a file, I'll see if I can create a wimboot.boot.var that hopefully is ignored by SMS/WDS housekeeping and modify my wimboot injected script to write PXE registry information to refer to this static file.