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.

It is possible to use DHCP options to PXE boot UEFI devices by adding option 60, however doing so prevents legacy devices from working so it's only an option if you use solely UEFI. As the others have said, IP helper on your network infrastructure devices is the best solution.

I don't think so? I'm not known for my agricultural skills!

I have to say I agree on that point actually group policy is definitely not the best way to go, and can lead to unintended effects as group policies for software deployments (or anything else) often can, but it is a supported client deployment method which is documented in the SCCM Technet pages. Like your clients, my preferred option is to just take care of the machines through OSD as and when they're imaged, but where it is desirable or necessary to install the client on machines without doing OSD I think WSUS is probably the best choice other than manual installation.

From the sounds of it what you need to use is a Prestaged Media Task Sequence which does exactly that, though personally I found the way it works extremely confusing at first. You create prestaged media (Software Library -> Task Sequences -> Create Task Sequence Media -> Prestaged Media), from your existing OSD Task Sequence, which gives you a wim file. You then need to apply this wim file to the disk of the target machine. You can create a new task sequence to apply the wim file to a disk, using the Apply Data Image step rather than Apply Operating System Image, or just do this offline with imagex. There is a blog post on Technet which goes into detail on how to create a task sequence to do this, and provides an importable template task sequence for applying a prestaged wim file. http://blogs.technet.com/b/system_center_configuration_manager_operating_system_deployment_support_blog/archive/2014/04/02/how-to-apply-task-sequence-prestaged-media-on-multi-partitioned-disks-for-bios-or-uefi-pcs-in-system-center-configuration-manager.aspx What then happens is, when you turn on the machine that has had the prestaged image applied it boots into your boot image just like it would from PXE or boot media and presents you with a list of task sequences as usual. If you pick the task sequence that has been prestaged, the task sequence will just skip over the apply operating system image step because it's already been done.

Frankly in my experience automatic client push is very unreliable, I've had entire rooms with dozens of machines with identical setups which I've ensured are left on for days at a time with reliable network connections and half will get the client installed from client push and half won't despite the fact that they've all been discovered and are all in the same IP range and on the same domain and in the same OU. I know that other people have had similar experiences with client push as well. You'd probably be better off disabling automatic client push and either using group policy to deploy the client or publish the client package to WSUS and do it that way.

I work in an educational environment much like you, and see a similar effect to you with PXE boot. PXE booting multiple machines, 20 - 30+ at a time causes a dramatic slow down in boot time. We do in fact have distribution points at all of our campuses, which obviously alleviates the problem to some degree since clients across different campuses are not competing for bandwidth on the same server but even so it is slow when PXE booting a large number of machines. Having a DP and MP (seperate or colocated on the same box) at each site is definitely a very good idea, as long as 1) You ensure you set up boundary groups to ensure the clients actually use them for anything other than PXE booting. 2) You're running at least SCCM 2012 R2 SP1 / 2012 SP2, as prior to this boundary groups do not provide preferred management points to clients, they only provide distribution points and state migration points. If you're running a standalone primary site, i.e. not multiple primaries with a CAS, or secondary sites, then you'll need Cumulative Update 1 installed as well as the setting for clients to use the management point from the boundary group does not work in standalone primary sites prior to this. Point 1 being more important than point 2. However if you have a large boot image due to needing lots of drivers for a wide variety of hardware then there's only so much help moving PXE boot load onto a local DP will do. You may still find that boot times are frustratingly slow when trying to do entire computer labs even with a local DP, if so you may find it more efficient to create USB boot media instead, this is always substantially quicker than PXE. The only slight downside to this is the you need to ensure your boot media is updated any time that you update your boot image, otherwise when you start a task sequence that is associated with a more recent boot image than is on your USB drive, the TS will download the up to date boot image and reboot into that before it starts. If you're just using USB boot media, rather than stand alone task sequence media, then you can pull the sticks once booted so you don't necessarily need that many to do a whole lab.