phil_w

You definitely need to specify the site code if you're not already, management point could be useful as well. If you're AD schema extensions contain entries for both SCCM 2007 and 2012 and you're installing the client without specifying the site or management point, I think this could explain what you're seeing.

Cumulative updates for the SCCM client need to be deployed, in the same way as any other package, in order to update clients of an older version that are already installed. Automatic Client Upgrade only updates to major versions i.e. Service Packs.

are you specifying the management point and/or site code for the 2012 environment in the install parameters when you deploy the client? Have you applied AD Schema extensions for one, or both, of your SCCM environments?

First thought that occurs to me is, is the reinstallation actually a reinstallation from the same deployment that installed the application originally or is it being installed again by a different deployment of the same application? Do you have multiple deployments of the applications that are affected, and if so are the affected machines for some reason becoming members of more than one collection with a deployment of this application?

How are you deploying your 2012 clients?

Have you put the variable names in place of the credentials in the domain join step in the task sequence?

Are you sure you've installed CU1? This sounds like a bug that was fixed in CU1, I had exactly the same issue after SP1 but before CU1. The version number you gave is for R2 SP1 with no CU. With CU1 the version number is 5.00.8239.1203.

Don't panic and reinstall SCCM just yet, it could be simple to fix, at worst I suspect you might just have to remove and reinstall the distribution point role. No way a missing boot image should require a complete reinstall. Apologies if this is going over stuff you've already done. It sounds like you've managed to create a new 64 bit boot.wim? The only place you need copy this to is a share that's accessible from your SCCM server (may or may not be on your SCCM server). Go to boot images in your console, select add boot image and browse to your new boot.wim. It should have appeared in the console, but not be distributed anywhere yet. Before you try and distribute it go to.the properties of the boot image and make sure "Deploy this image to the PXE enabled distribution point" is checked. Now try and distribute it.

When you say you just right clicked and deleted the boot image, do you mean you deleted it from within the SCCM console or you went into RemoteInstall\SMSBoot\x64 and delete the actual file from in there?

It may be that your USB boot media has a different boot image (or an earlier version of the same boot image) than is in your task sequence. If you boot with this media and select the task sequence, the machine will want to download the boot image associated with the task sequence and then ask you to reboot so it can load that boot image. Try recreating your boot media, and make sure you use the same boot image that is associated with your task sequence.

Try this. Create a new device collection, don't bother adding any members or rules just leave it empty. Deploy the task sequence for your legacy machines that uses your normal PXE boot image to the new collection. Now see if your PXE is working again.

I'm assuming this is because the existing server isn't powerful to handle everything? Personally I would keep the old server, and let it continue to function as the Primary Site Server and simply add the second server into the site, install all the roles you need on it and use boundary groups to make the clients use the new server instead of the old one. It's the least messy way of getting the new server into use, but it does mean keeping the old server on. Alternatively you could do a complete site backup and do a restore during install on the server, in order to make that the primary server and decommission the old one. But that means more down time than just adding an additional server. A funky third option would be to set up a new server as a new primary site along side the existing one, then from the existing site deploy a client package with install switches to connect to the new site. No downtime involved but it does mean waiting for all your machines to run the client install package. But really it's much much easier to just add the new server into the existing site, and keep the old one running just to act as the Primary Site Server with all the real work being done by the new box.

Is the client actually working at that point? It could be it's taking a while to come out of provisioning mode for some reason, if you haven't already you may want to add a step at the end of your task sequence to change the registry keys to bring the client out of provisioning mode. Since you're finding you have to restart for your network drives to work, have you tried adding an additional restart step at the end of your task sequence?

has it been deployed anywhere? if so that will your problem!

When you say you don't use an x86 boot image, do you at least still have one? WDS PXE doesn't work unless both boot images are present even if you're not using one. The x86 doesn't need drivers in or anything if you're not using it but it does need to be enabled for PXE and distributed. Edit: just noticed you did say the x86 is distributed, but is it enabled for PXE? Also regardless of the bit level of boot image your DHCP option points to SCCM will actually load the WinPE image that was associated with the last task sequence that was deployed to any collection, so if you've deployed a TS that uses anything other than your usual x64 image it could be that. I recently discovered that this still happens even if the last deployed TS uses a boot image that isn't PXE enabled, resulting in completely broken PXE.