wimboot/iso client boot

[spgsitsupport]

TFTP server that comes with WDS works (after mod) fine for 1/2/3 machines booted at once.

But if I do the whole room of 20+ machines, it all comes to almost stand still (no wonder, 20+ machines try to pull down 500Mb .wim image)

That is from SCCM server - VM on Hyper-V with iSCSI 10G storage

 

Boot via http using wimboot is much faster for PXE (or iso boot via ipxe & grub for that matter)

 

Anybody has an idea how to FORCE client once booted to be directed to SCCM server for Task Sequence processing?

 

Thanks

 

Seb

[spgsitsupport]

One like this does it fine, and also this

WAY quicker than WDS tftp

 

Seb

[spgsitsupport]

NONE of the below is in any way supported by anybody (but me). Probably too scary for most, but works extremely well

 

As default I use ipxe with pxelinux menu & wimboot, where SCCM default boot is just one of the options.

 

That way I get (the missing so far in SCCM) fast http download of the .wim boot file!

 

DHCP supplies boot file entry undionly.0, which is served by SCCM WDS TFTP which points to pxelinux.0 served by SCCM WDS server again, for menu

 

It can be made even "more exciting", where the WinPE boot "thinks" that it was actually PXE booted, already to the image that is to be used in TS for the very computer:

Lets say that we wimboot over http PC#1, which is in Collection#1 that has to run TS#1 which uses BootImage#1

 

Using instructions, ipxe with pxelinux menu & wimboot will happen really fast BUT most likely TS will reboot again to BootImage#1 as specified in TS#1, which will then carry on with TS#1

But that is not so nice, as speed advantage of wimboot is negated by another download of BootImage#1.wim & another reboot.

So if one creates bootable media iso - either by Console GUI or using:

 

Creating a SCCM Task Sequence boot media using vbscript...

 

& in process selects BootImage#1 & then use that Variables.dat (why on earth it is not possible to just edit this file!?), which stores info about the site, where to conenct etc), the startnet.cmd can be adjusted as this:

echo ** Patching Ramdisk
reg add "HKLM\SYSTEM\CurrentControlSet\Control" /v PEBootType /t REG_SZ /d "Error" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control" /v SystemStartOptions /t REG_SZ /d " MININT RDIMAGEOFFSET=8192 RDIMAGELENGTH=3161088 RDPATH=NET(0)\\SMSIMAGES\\SP10010C\\WINPE.SP10010C.WIM" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control" /v FirmwareBootDevice /t REG_SZ /d "ramdisk(0)" /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control" /v PEBootTypeErrorCode /t REG_DWORD /d "2147942413" /f

where WINPE.SP10010C.WIM is the BootImage#1 selected in iso (the above values I picked up from PXE SCCM WinPE booted machine, while running TS#1)

In that case machine wimboot over http & instantly runs TS#1 (which is assigned as PXE ONLY REQUIRED to Collection#1, exactly where imagined machine belongs = in my case deployed it to all Workstations). No more separate .wim download and/or another reboot.

 

That will of course assumes that one has TsmBootstrap.ini with Unattended=true (in other case one can still get the normal TS Menu)

One can of course argue that there is no PXE Deployment record for machine in SCCM DB, but I rather have this for the speed of initial boot

 

Edit

Possibly one could get really creative using tsenv2 from 1E and do on-fly replacement of variables ie

 

TSEnv2.exe set _OSDOSImagePackageId=00200005

Setting _OSDOSImagePackageId=00200005

 

Sadly TSEnv2 ONLY runs if TS Environment is initialized, which is too late to do clever stuff of Ramdisk patching in same session if bootimages (booted & expected) are different = so this is a nogo!

 

And to get rid of the WinPE Command Prompt shell window (which runs the startnet.cmd), there is nice Auto-it solution (ShellExecuteWait) here

 

Seb