SCCM is dumb when it comes to deciding on the boot.wim to use. The last advertised TS is how SCCM decides which boot.wim to use. So if you have a colletion of x86 and x64 machines and you advertise a TS with a x86 boot.wim all systems will boot from the x86 boot.wim first but hte x64 machines will reboot into x64 boot.wim if they pick a x64 TS. Now if you advertise a x64 TS to this colletion all machines will try to boot off the x64 boot.wim first. obviolusly x86 machines and VMs will fail to boot in this way. whats really stupid is the PXE knows what architecture is being used. SCCM should force a x86 boot.wim for x86 architectures. As for x64 it really doesnt matter other then having to press "finish" after selecting a TS that doesnt match the TS architecture. Having seperate collections for x64 and x86 machiens will help control this. So as the topic says "How do you control the default boot.wim PXE uses?" I really dislike having to re-advertise a TS just to control the boot.wim pxe uses. Plus if the lastadvertisment was x64 it breaks ALL x86 only machines and VMs.

Look in Windows Deployment Services, right click your site, properties, Boot tab.

SCCM doesn't use this to control what boot.wim to use. Thats for if you are using WDS in a stand alone setting in this case WDS is just the PXE service. SCCM controls the boot.wims as i discribed in my first post.

this has been the second time i have asked this question and no responce, really would like to get a clean answer.

Hi Mykel, I experienced the same issue, and eventually decided to define seperate collections based on x86 / x64 architecture. You will probably have this issue only on older machines, since most machines are x64 boot capable nowadays. You will notice that when a client is enabled for x64 boot, it will boot the x64 WinPE and afterwards download the x86 boot image in order to continue the deployment of the x86 OS. For us this works most of the time as well. I do agree that some tweaking on this behaviour can be done though. Good luck ! Regards, Kenneth

I don't think the boot.wim really makes any difference at all, does it? It's only a WinPE staging OS. The actual OS that is installed on the PC is determined by the TS that you run. All of our newer PCs are x64 compatible and they boot off of the x64 boot image, but they are then installed with an x86 standard image. Is that what you mean?

Sure all "newer" machines are x64. But not all computers are x64. Primarily VMs via virtual PC or Virtual Server 2005 are x86 only (where is hyper-V for VISTA!). Plus we still have at least a couple hundred x86 machines around that some day may need to be reimaged. I am more concerned with the lack of control of what is the default boot.wim for architecture. I know WDS by itself handles it way better, since the PXE in SCCM is a shimin toWDS why cant it handle it better. Why would advertising a x64 OS mess up all the x86 only computers. Be smart, if its an x86 only CPU then load a x86 boot.wim no matter what, cause its going to fail.

There are two boot.wims, aren't there? One for x64 and one for x86. Under your Boot Images section of the OSD in SCCM should be two images, one labeled x64 Windows PE Boot Image for SCCM and the other x86 Windows PE Boot Image for SCCM. I think that's the default names for the the images, but I could be wrong. I think that SCCM just detectst the architecture for the machine that is PXE booting and loads the relavent WinPE image. Once that's done it starts the TS and loads the specified image. Maybe I'm not 100% clear on exaclty what your system is doing that's causing you problems. Are you saying that an x86 machine is trying to boot an x64 WinPE image and therefore crashing?

SCCM determines the pxe boot.wim by the LAST advertised TS. So if you advertise a TS with a x64 boot.wim assigned to it to a baremetal collection then ALL machines doing a pxe boot in that collection will always try to boot from the x64 boot.wim even if its a x86 only CPU. The only way to control this is by advertising a new image thats now has a x86 boot.wim so that the default for everything in that collection is now x86, even x64 machines but this is annoying because now if you pick a x64 image it will have to DL the x64 boo.wim to the machine, you have to press finish then the machine now boots into the x64 wim and does its OS install. side note, doesnt wiak 1.1 now support x86 installs via x64, can SCCM do this too somehow?

Where did you read that? I may be totally off base, but that doesn't sound right at all, to me. #1) I really don't think that SCCM determines which boot.wim file by the last advertised TS. At least I have never run into anything like that, and we have completely mixed environemnt of x64 and x86 capable PCs. #2) You don't use a TS to advertise the boot.wim, EVER. The TS should be used to advertise the Image that you intend to deploy to the PC, any software you want deployed and other related tasks. The SCCM server (using WDS) determines what boot.wim to use bydetecting the hardware type when it PXE boots. #3) If you have the boot.wim image advertised by a TS, then, yes any PC that is booted with that TS will then attempt to use that image. The thing is, you shouldn't be advertising that boot.wim in any section of your TS, because of that very problem. I think the root of the problem may be from a very basic misunderstanding of the usages of these .WIMs, which is usually only complicated by Microsoft's inablitlity to properly explain the technologies that they deploy. Forgive me if you already know this, I'm only trying to establish a base of knowledge. There are two WIMs that you use when image your PCs, the Boot Image and the OS Image. The Boot Image comes in three flavors, the x86, x64 and Itanium and these images are only used by SCCM to boot up a PXE PC in a safe OS. They are small and are loaded to a RAMDrive in the PC's memory. The OS Image is the image that you create that you wish to deploy to the PC. This image can be whatever OS you choose and if it's a 64-bit OS that you use and you deploy it to an x86 PC, then you'll have problems. This image, the OS Image is the only image that should be specified in any Task Sequence. I think that you might want to start from scratch with a test collection, create a brand new and very simple TS that only installs your OS Image and see what results you get. If it works properly, you can assume that the problem is probably with the TS that you've been using, or the collection rules. I would guess that you either have a line in your TS that is attempting to apply an incorrect .WIM (like the boot.wim) or you have a TS advertised as Mandatory that is incorrectly imaging your PCs. Let me know if this makes sense, since I have a tendency to babble... Just as a note, if it's running properly, SCCM does not require you to do any of that stuff that you mentioned.

Hi, Just my 2 cents in this discussion. If you have a collection with Task Sequences advertised which contain both, x64 and x86 boot images, the last advertised task sequence boot image is booted. (we run SCCM SP1 R2) If you upgrade to SCCM SP1, the WAIK (and the boot images as well) will be updated to WAIK 1.1. If upgrading to SP1 is somehow not possible check my blogpost here in order to update your boot images manually: http://www.techlog.org/archive/2008/03/21/how_to_add_waik_11_boot_images When you have hardware which is capable of booting both x64 and x86 boot images, we make sure the x64 boot image is loaded, if the executed task sequencecontainsa x86 boot image, that boot image is downloaded locally and is started right after a reboot. Regards, Kenneth

exactly the behaviorI discribed above. so 2 things then, why is SCCM not smart enogh to see a x86 archtecture and just load the x86 boot.wim and I can stop complaing about it. i guess the issue could beis, there could be a dozen boot.wims and which one should it use, easy answer, assign multiple boot.wims to a TS. and If you are using wiak 1.1 boot.wims why does it needto reboot into x86 for the OS deployment. Waik 1.1 is suppose to support x86 OS deployment while in x64 enviroment. I am thinking another SCCM thing where its hardcoded to check archetecture where 1. always just reboot to the boot.wim assigned to the TS and 2. if the boot.wim assigned to the TS doesnt match the archetecture of the TS image wim it fails the deployment.

Hi Mykel, One small correction: SCCM-OSD will download an boot image if the boot image already loaded is different then the one defined on the chosen task sequence. In your case, i would say define 2 distinct collections. One for x86 and one for x64, and advertise your task sequences depending on boot image. Regards, Kenneth

what about collections where the machine archetecture is not known, like advertising an image to a business unit of 50 machines? They might have some that are x86 only and x64. If I advertise x64 vista and x86 XPI would always have to make sure the x86 one is advertised last and make surethe x86 has all the network drivers needed for all machines where the x64 image would only need drivers for newer machines. I am playing more of devil advocate role here than anything else. Its just seems, to me, the PXE boot is handled very poorly and bringing it to light may see a fix. Like how baremetal support got better in R2.

Hey Mykel, have you tried setting the TS to only run on x64 or x86 platforms? I would surmise that if you create a collection and have two TSs assigned to it, one being an x64 and the other being an x86, then specify on each TS that only one type of architecture can use it, then SCCM would be forced to run the proper TS. Does that sound valid?

I took a quick look at trying this the other day. Nothing caught my eye on how to seperate x86 and x64 unknown machines.

Go to the properties of a task sequence and then the Advanced tab. You can specify which architectures will use that task sequence, and which will not. Does that make any difference in your situation?

I dont think that will do anything. Thats for advertisement to a running OS not to a specific architecture.This will stop an x64 image being advertised to an x86 OS. When doing a XP boot that means nothing the machine is baremetal, no OS is on it. As well, if I select onlyx64OSs to advertise an x64 TSits means any machine with an x86 OS won't be able to upgrade to x64.

Hey MYKEL, I was just about to start a thread with the same question. It seems like you didn't get the answer I was looking for to my question either. This whole time I have been booting to boot media. Then I went to PXE... But how does SCCM know which boot image architecture to use?... Especially on a baremetal install.

After policy has been downloaded for the selected task sequence and the referenced packages are downloaded, the boot image is checked to see if it differs from that for the TS. If so, the correct boot image is downloaded before the task sequence is actually run.

Bump I am experiencing the same problem. I amusing the Unknown Computer container to make it easier on client services. The last TS advertised gets the trump. It would really suck to have them have to create the object beforehand and choose a collection (Assuming i target a TS respectively). Any easy way to get around this?

Ok, just to give it a bump. I have the two default boot images x86 and x64. Recently I created another x86 image and injected some network drivers into it for a specific model. Now I have three boot images. We are deploying Win7 ENT 32bit only to our collections. Now that I have created the third boot image, that is the only one that now gets used when I perform the PXE boot. Even if I am using a different boot image in the TS, it still selects the new one when the PC boots. Why? Anyone? I would hope that someone would weigh in on this. It is unfortunate that such an old thread is still relevant after all the iterations that SCCM has undergone. I am running SP2 R2 and this is still a genuine issue. Anyone?

I am experiencing the same issue. An x86 system would not image today due to trying to use an x64 boot image. After reading these comments I simply created a new advertisement for a Task Sequence that used the x86 boot image and the x86 system booted right up and imaged. I am currently running R3, so no fix yet unfortunately. Again, sad to see that this is not being addressed.