wimboot - sccm tsbootshell.exe
|
2017-11-16, 18:59
Post: #1
|
|||
|
|||
wimboot - sccm tsbootshell.exe
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 |
|||
2017-11-16, 20:01
(This post was last modified: 2017-11-20 18:19 by NiKiZe.)
Post: #2
|
|||
|
|||
RE: wimboot - sccm tsbootshell.exe
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. Use GitHub Discussions VRAM bin |
|||
2017-11-20, 14:04
Post: #3
|
|||
|
|||
RE: wimboot - sccm tsbootshell.exe
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 |
|||
2017-11-20, 18:22
Post: #4
|
|||
|
|||
RE: wimboot - sccm tsbootshell.exe
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? Use GitHub Discussions VRAM bin |
|||
2017-11-27, 19:53
Post: #5
|
|||
|
|||
RE: wimboot - sccm tsbootshell.exe
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. |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 1 Guest(s)