Since I posted this I've come into the problem many times, and in nearly all of them it was Scope Options
Having any of the following options set caused problems, 60, 66, 67. In the case of only 60 being set it still allowed connection to an SCCM PXE point outside of the subnet with IP Helpers enabled but failed at providing a boot image.
In addition I've also seen incorrect vlan id's causing very similar issues. So in general if you get to the point that PXE starts, talks to CM but doesn't complete (and no error is reported), check your IP Helpers, your vLANs and your Scope options.
I'm still in the process of implementing SCCM 2012, but I've done some research on this topic to come up with a good plan for implementing software updates.
First, there is a finite limit for the number of patches you can include in a single deployment. I think with 2012 it was increased to 1000, so that's generally not going to be a concern. Though, I believe there are still some drawbacks to having a very large number of patches - every time you make a change to the deployment (adding new patches), there's a lot more processing that has to happen to re-evaluate compliance. Unless you have a TON of patches, or a lot of clients (50,000-100,000+), I think it will be negligible.
That said, this is my plan. It's somewhat specific to my environment, but I think it can apply to most environments.
- Have one large deployment containing all patches for all products that are included on your standard image (if your image was fully patched as of Feb 2013, only include the patches that are actually necessary).
- Every month, create two new update group deployments: one for all critical patches, and one for all non-critical patches. That way, our QA department can test them independently, and focus on releasing the critical patches first.
- Every 6 months to a year, update the base image WIM source file to include all patches released in that time period.
- Move the 6 months of patches into the 'base' patch deployment group.
One thing to note - if you weren't already aware, SCCM only downloads the updates that are applicable to each computer - even if you have one deployment with 150 patches, it will only copy down the files and install the patches that are needed. With this approach, we should be able to keep our systems fully patched, and keep the image up to date so it doesn't take an additional 45 minutes to image a machine.
Also note, we aren't patching servers, and we have a fairly standardized environment. If we had multiple images / operating systems to support, I might make a few changes to the above plan (multiple "baseline" patch groups, one per image).
Best Answer
As stated on the question, I had rebooted the SQL server without success.
I opened a case with MS support and the analyst recommended rebooting both SQL server and SCCM server.
I tried this and the server is now syncing correctly with Windows Update.
The original cause of the issue was that the SQL server ran out of space. I did not have this information before. The space issue was fixed and the server rebooted, however, a reboot of both servers was necessary in this case.