wimboot - sccm tsbootshell.exe

[muzz]

Hi There,

So I am using wimboot with a boot image created on our SCCM environment, and this boots successfully using wimboot within ipxe from either a traditional BIOS environment or a UEFI environment.

the boot image itself has all the required drivers for the hardware I am using, so nics and disks are present and I can see these by doing an ipconfig or diskpart

it seems that tsbootshell.exe is having a bit of a problem in that smsts is logging multiple entries for boot wim. from the UI, it appears to hang on a dialogue for initialising hardware devices.. and then eventually prompts to restart with a "Unable to read task sequence configuration disk" this is usually attributed to missing drivers from the boot wim.

the smsts.log is reporting the following:
<![LOG[ConvertBootToLogicalPath failed to convert 'MULTI(0)DISK(0)RDISK(1)PARTITION(1)\SOURCES\BOOT.WIM (0x80070003)

I'm happy with the boot image because if I chainload the WDS/SCCM and have this image served up by TFTP, this runs successfully.

Any ideas as to what could be the cause?

Regards

Muzz

[NiKiZe]

wimboot emulates a fat32 disk to boot windows.
But SCCM checks how it was booted, and since it was booted from "a local harddrive" as far it can see, and not the network, it probably fails.
You might be able to hack the registry post boot to get it to do what you want, to do this you will have to search for "MULTI(0)DISK(0)RDISK(1)PARTITION(1)" in registry on wimboot booted winpe to find where it is stored.
Then boot via the original Microsoft method and check registry on the same location.

I think there is something similar on the forum already, but I don't think we ever got to a solution that time.

[muzz]

thanks so much for this -

I got it working with this:
HKLM\SYSTEM\CurrentControlSet\Control SystemStartOptions " MININT RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088 RDPATH=NET(0)\\SMSIMAGES\\SS10010B\\BOOT.SS10010B.WIM"

and this one
HKLM\SYSTEM\CurrentControlSet\Control FirmwareBootDevice "ramdisk(0)"

the TsBootClient also had complaints about missing values at HKLM\SYSTEM\CurrentControlSet\Control\PXE so I copied these. im not convinced it actually does anything with the DHCPServerACK and BootServerReply values other than uses these to satisfy itself that it was a PXE boot.

for the benefit of anybody else reading, these registry entries are bundled into a fix.cmd script and this is called by modifying the \windows\system32\winpeshl.ini to call this before firing up the agent.

[LaunchApps]
%SYSTEMDRIVE%\windows\system32\fix.cmd
%SYSTEMDRIVE%\sms\bin\x64\TsBootShell.exe


finally I have these files present in the boot image by injecting them using wimboot.

:wim0010B
set winpeurl ${rooturl}/winpe
kernel ${winpeurl}/wimboot
initrd ${winpeurl}/sources/SS10010B/fix.cmd fix.cmd
initrd ${winpeurl}/sources/SS10010B/winpeshl.ini winpeshl.ini
initrd ${winpeurl}/boot/bcd BCD
initrd ${winpeurl}/boot/boot.sdi boot.sdi
initrd ${winpeurl}/sources/SS10010B/boot.wim boot.wim
boot || goto failed


thanks again for the help!

Regards

Muzz

[NiKiZe]

Awesome that you got it working,
And even more so that you reported back exactly what needs to be done, and in a way so that it is easy for others to use.

The only part we are missing is the PXE part ... any chance you could post your pxe.cmd to make it even easier for others to reuse?

[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.