For legacy purposes, we don't pxe boot directly from sccm but have a separate wds server that we pxe boot from, and upload sccm's boot wim (among others, again for legacy purposes) to that server.
Back in sccm, however, is where the real quirk lies. So, for any given task sequence there is a boot image assigned to it. So for my task sequence Beta I have the same boot wim assigned to it as was uploaded to the wds server, no big deal. I boot to pxe, select Beta from the list of available task sequences, and am on my way.
After this, sccm will make sure any packages referenced by the task sequence are available on some distribution point, this includes boot wims.
My problem comes directly after that. If the PackageID of the boot wim that's referenced in the task sequence does not match the PackageID of the boot wim that's being ran at that moment (or if the task sequence is being run from inside a full Windows OS) then sccm will stage (read download and stash somewhere) the boot wim referenced in the task sequence, prompt the user to 'remove the CD' and restart the machine, then boot up to that boot wim.
Now, I know what you're thinking: "Mike, just use the same boot wim that's referenced in the task sequence on your wds server and you'll be fine."
I wouldn't waste your time by not doing that. The problem is that the PackageID on the wds boot wim isn't showing the correct PackageID.
Correct PackageID: SMS000D8
Perceived PackageID: SMS0009E
Here's a shot of the log for visual learners:
Now, I recognized the perceived packageID: It was the original sccm boot wim that was created after upgrading to SP1. Of course, if I assign that boot wim to my task sequence everything goes on and there is no reboot.
However, there's a good reason why that boot wim isn't assigned to Beta. Everytime we try and update that boot wim, it fails. Doesn't matter if it's drivers, extra features, or nothing at all but a dp update, it fails when injecting the OSD binaries, apparently this also happens from time to time. Importing new boot wims and updating them seem to work fine, so we tried just going that route and that's where we are now.
Beta requires a restart in the middle of the task sequence, and if we reboot into the original boot wim, the network and/or storage drivers for our latest computer models aren't in it, and bad things happen.
So, I did more googling, because surely I'm not the only one having this issue, and it turns out I wasn't.
Now, yes: One could change the value of the BootMediaPackageID task sequence variable to whatever I need inside the task sequence (even before the task sequence starts with pre-execution media hooks) and be jolly. However, the task sequence variable BootMediaPackageID is really _SMSTSBootMediaPackageID and that variable, and others like it, are read only.
The good news is that all the task sequence variables are stored on the boot wim in a file called variables.dat, from what I've read on the net. The bad news is that this file is not clear text.
There is a tool called tsenv2 from 1e that is supposed to be able to edit this file, via memory mapping, however the website says it's for 2007, and when I tried to use it I just get some random error that google hasn't heard of. I have a conference call with these folks later today but I'm not putting all my eggs in one basket.
Another forum post mentioned that this file is encrypted using the media password that's used for accessing the task sequences, if there is one. If not, it's plain xml. We use a media password, so that seemed promising. That poster was also kind enough to mention that it's encrypted using AES-256-CBC, which also sounded promising, so I downloaded openssl for Windows and went to town on the file, with no avail. Speaking with our Sr Security Admin it seems with cbc if I don't have the key and iv but just the password, that may not be enouh to decrypt the file. I doubt if MS is coughin those up.
So, that's where I'm at. If anyone knows how to get around this, I'm all ears.
