In-Depth

Cut Your IT Workload with System Center 2012 R2 Configuration Manager

Reduce the labor of deploying Windows images, patches, policies and group settings with Microsoft System Center 2012 R2 Configuration Manager.

• By Brien Posey
• 07/07/2014

General wisdom has long held it's better to deploy OSes from an image than to attempt manual deployments. After all, image-based deployments standardize the OS installation process and reduce the chances of human error.

However, depending on how you perform image-based deploy­ments, the process of building and maintaining images can become quite labor-intensive. It doesn't necessarily have to be that way, though, because there are a number of strategies for minimizing the effort involved in this process.

Minimal vs. Monolith Images
If your goal is to decrease the administrative workload involved in image management, one of the best things you can do is avoid creating monolithic deployment images. I've seen situations in which administrators have tried to reduce the amount of work involved in the desktop-provisioning process by creating deployment images that contain OSes, a driver library and a full set of desktop applications. This approach might work out OK in smaller organizations, but the process doesn't scale well.

The problem with creating monolithic deployment images containing more than just the OS is the images are difficult to maintain. Even the simplest application change might require building a new image. Never mind the fact each department is likely to use a different application set, thereby requiring the administrator to maintain a separate image for each department.

A more effective technique is to take a modular approach to desktop deployments. Rather than building an image containing everything but the kitchen sink, it's more effective (from a management standpoint) to keep your deployment images simple and deal with things such as applications and drivers separately. This approach requires a bit more work up front, but it tends to be a huge time-saver on the back-end.

If you're going to take a modular approach to Windows desktop deployments, the tool of choice is System Center 2012 R2 Configuration Manager Configuration Manager makes it relatively easy to deal with the various desktop elements separately, so you don't have to include them in the OS image.

The OS Deployment
Assuming your desktop management strategy involves deploying a basic OS image and then dealing with everything else separately, the next logical question is what should be included in the OS deployment.

In Configuration Manager, the desktop image is captured from a reference computer. That computer's configuration then becomes the basis for the image that will eventually be deployed to your desktops.

The first thing you should know about the reference computer is it must not be configured as a domain member. That's because the process of capturing the reference OS involves running Sysprep. Sysprep is a mechanism designed to normalize the OS by removing anything machine-specific (such as the computer name). As such, Sysprep will fail if the reference computer is joined to a domain.

The Local Security Policy
Another consideration regarding the use of Sysprep is its impact on the local security policy. For the most part, the local security policy settings you apply to the reference computer will still be valid after the machine has run Sysprep. As such, it's a good idea to go ahead and apply local policy settings to secure the reference OS. You can even add administrative templates to the local security policy without having to worry about the templates or the settings they contain being wiped out by Sysprep.

It's important to remember the job of Sysprep is to remove any machine-specific data from the OS. This means any user-level policy settings that apply to specific users or groups will be removed by Sysprep.

OS Patches
Another thing you should include in the reference computer is a current set of OS patches. Even though Configuration Manager lets you deploy patches separately from the OS, you can reduce the amount of patching to newly deployed desktops by installing the currently available patches to your reference computer before running Sysprep.

Departmental Differences
As noted, one of the problems with trying to maintain monolithic desktop images is there's rarely only a single image to maintain. More often than not, there's no such thing as a standard corporate desktop. There are likely to be differences in the application sets used by the various departments. For instance, that payroll application the finance department uses probably doesn't have a place in the sales department.

So how can you deal with these departmental differences without having to build a separate image for each department? One way of dealing with this problem is to tie application deployments to your Active Directory security groups.

Of course, security groups don't have native application deployment capabilities. However, it's possible to link a Configuration Manager user collection to an Active Directory security group. One advantage to using this approach is user collection membership changes dynamically based on the corresponding Active Directory security group.

To create a user collection in System Center 2012 R2 Configuration Manager, go to the Assets and Compliance workspace and then right-click on the User Collection container and select the Create User Collection command from the shortcut menu (see Figure 1). When you do, Windows will launch the Create User Collection Wizard.

Enter a name for the user collection you're creating. This name (or the subsequent description) should ideally reflect the Active Directory security group you're going to be linking to the user collection. Set the Limiting Collection field to All Users and User Groups and click Next.

You'll see the Membership Rules screen next. This is where you can tie the user collection to an Active Directory group. Click on the Add Rule button and then select the Query Rule option from the dropdown list as shown in Figure 2.

Enter a name for the query rule you're creating and then click Edit Query Statement, where it will take you to the Query Statement Properties sheet. Click on the Criteria tab and then click on the orange starburst icon to open the Criterion Properties sheet. Click the Select button and then set the Attribute Class to User Resource. Set the Attribute to Security Group Name. Click OK and then enter the name of your Active Directory security group into the Value field (see Figure 3). You can also click the Value button and select the group. Click OK twice and your query statement will be populated. Click OK once more to create the rule. Then, just click Next twice and click Close to complete the process. It is worth noting it can take a considerable amount of time for the user collection membership to populate.

Now that you've created a user collection, it's possible to tie the application deployment process to the user collection. Suppose you wanted to manually deploy a particular application to the user collection members. You could right-click on the user collection you just created, select the Deploy | Application commands from the shortcut menu (see Figure 4), which launches the Deploy Software wizard. This will let you deploy the application of your choice to the user collection members.

Device Drivers
When you run Sysprep against a reference OS, it becomes largely hardware-agnostic. Configuration Manager lets administrators maintain a collection of device drivers outside the OS deployment image. This design allows device drivers to be added to the driver collection without a new Sysprep image having to be created.

When it comes to device drivers, it's easy to get caught up in making sure you have the latest driver for every conceivable hardware device used throughout the entire organization. However, doing so might not be necessary. There are several different strategies commonly used to manage device drivers.

One strategy is to take a minimalist approach to third-party device drivers. The basic idea behind this strategy is to remember Windows includes built-in drivers for the most common hardware devices, and it's often possible to install Windows 8 onto a desktop without using any third-party drivers.

Of course, critics of this philosophy are quick to point out the drivers included with the OS may be dated and might not provide the same level of hardware support as drivers provided by the manufacturer. This might not be a big deal for basic hardware components such as network adapters or audio devices, but it can be problematic for more specialized hardware devices. For example, I own a scanner that supports six-color scanning. The native Windows scanner driver recognized and allowed me to use the scanner, but didn't support the scanner's higher-than-average color depth.

Another technique sometimes used is to take a vendor-specific approach to device drivers. Some organizations try to purchase desktop hardware from a specific vendor and then build a library of all the device drivers the vendor releases.

This approach works, but it does have its drawbacks in that it involves extra work. If the goal is to maintain a library of all available drivers, then the administrator will probably be downloading and importing device drivers for hardware the organization doesn't even own.

Another drawback to this approach is in certain situations it might increase the chances of device misidentification. Often times, device drivers are similar enough to one another that a piece of hardware might attempt to use a driver written for a different piece of hardware. For instance, Windows might attempt to use a driver designed for an older network adapter previously offered by the vendor.

Yet another disadvantage to building a vendor-specific device driver collection is some vendors provide drivers in the form of EXE files instead of more commonly used driver formats such as INF. This means the administrator has to execute the file and then figure out which drivers were deployed as a result of running the file, and then import those drivers into System Center.

A third approach I've seen used for device drivers is using manufacturer drivers instead of vendor drivers. Suppose, for example, an administrator knows all of the organization's desktops use Intel i7 processors. The administrator might be able to download a chipset driver from Intel rather than having to download chipset drivers from all of the various desktop vendors (Dell Inc., Hewlett-Packard Co. and so on). The disadvantage to this approach, of course, is the loss of any vendor-specific functionality.

Obviously, there are advantages and disadvantages to each approach, so you'll have to choose the approach that works best for you and your organization's needs.

As you can see, System Center 2012 R2 Configuration Manager can make it much easier to maintain deployment images. Rather than rebuilding an image every time you need to change something, you can deal with components such as applications, drivers and patches outside of the image.