Im hoping to use SCCM 2012 R2 to image a slew of machines that will be ordered over the next year. There will be several different vendors which implies different NICs, graphics, RAM, etc.
My question: does the machine that the OS image is captured from have to be the same as what it gets deployed to? IE could I use a VM to create the captured image? Or do I need to create a different image for every piece of hardware?
Unless you want to go download new drivers for NICs, display adapters, sound cards, etc., etc., each time you get a new model or brand of computer, then you will need to slipstream drivers into your images. Also you need to think about whether you'll use WDS (Windows Deployment Server), or MDT (Microsoft Deployment Toolkit). WDS is great for smaller companies that can't use full blown SCCM and don't have hundreds or thousands of computers to image each year. MDT is great for experienced users who know how to make detailed Task Sequences that will allow you to add all your drivers and applications and other tweaks based on WMI Queries. You capture info from WMI Queries off of the machines which you want to image, which can then target certain computers and grab certain driver packages based on what those machines are; meaning, you use WMI queries to get certain information off of a computer then put that in your MDT Task Sequence to look for these types of computers when you start the imaging. If these types of computers are detected then a detailed Task Sequence is kicked off that grabs the right drivers for your particular model of computer. That way you don't have to have dozens of images as you've described in your question. My experience with MDT has been pretty good, and using Dell computers in general has also given me good luck.
You don't need a different image for each piece of hardware, just a different set of driver packages per chipset, or per model. Typically a Dell X9000 (just a fake model for this example) will have the same chipset on all X9000 models with some variance based on when they are manufactured and/or purchased. If you buy 20 of them though, you should be alright to capture one image then go to the Dell website and look for the Driver CAB for the X9000 or whatever the real model is and download it and add it to your driver packages on your MDT server then add it in as part of a Task Sequence.
Please see this for an in-depth look at MDT so you can get a better grasp on what you'll need.
You can capture one image and deploy it to different hardware by creating different task sequences containing the appropriate drivers for each model .
See Introduction to Operating System Deployment in Configuration Manager.
Capturing from a VM is actually better than using a physical computer. The VM allows you to take a snapshot right before you run sysprep. A month later you can boot from that snapshot, update all of the software, run sysprep and capture again. SCCM will detect and inject the proper drivers into the image at deployment time.
For SCCM I implore you to read Kent Agerlund's System Center 2012 R2 Configuration Manager: Mastering the Fundamentals. You can find older Kindle versions for $10.
Actually, though you can get much more specific about it, a deployment share will automatically use whichever driver it first detects that applies to the hardware in question. While it isn’t necessarily recommended, you can simply load all of the drivers for devices into an unorganized deployment share and the deployment will still succeed. See scenario 1 – total chaos here on Johan Arwidmark’s blog.
A more up to date resource to introduce you to MDT is the Windows 8.1 Deployment Jump Start at Microsoft Virtual Academy. The content in the video is relevant to anyone deploying any Windows operating system. I would urge anyone who works with Windows deployment who has not yet seen it to give it a watch. Johan and other experts in Windows deployment chime in on the issues facing Windows deployment and how they can be resolved.
Also, it is strongly recommended to use a virtual machine for a reference machine to avoid driver conflicts between the image and the destination hardware.
