This is the first post of a series that will walk you through the process to create a Task Sequence in Configuration Manager 2012 R2 that can be deployed for all scenarios (Bare Metal, Refresh, Replace). It uses MDT 2013 to augment the sequence and provide some location-based automation rules. To provide full OSD functionality to branch locations without the need for servers, in the next post we will go through the process to create a second Task Sequence specifically for Nomad-enabled sites. The third post goes over how to configure Automatic Deployment Rules to maximize workstation patching with minimal effort. Though not specifically related to OSD, a solid patching design will eliminate the need to perform Software Updates during a Task Sequence, further reducing execution time.
There are a few prerequisites and assumptions that must be in place before we get started with our Task Sequence creation and tuning. The Configuration Manager environment must be healthy, and MDT 2013 installed and integrated with CM12. We also need to have an image to deploy with our new Task Sequence, along with Drivers and Packages.
For most small organizations, it’s pretty common to see included in the gold image all the corporate used free apps, like PowerPoint Viewer, and software that has been purchased for the entire company, such as Microsoft Office. Usually the image is created using MDT, as there’s lots of documentation on the tool, and the price is right 🙂
Once these are in place, inside the Configuration Manager Console and in the Software Library Workspace, we’re going to expand the Operating Systems node and click on Task Sequences. From the ribbon, we’ll then click on Create MDT Task Sequence, to give us the Create MDT Task Sequence Wizard, and use a Client Task Sequence template.
On the General screen for the Template customizations, we’ll call the Task Sequence Windows 8.1 Corporate Image.
At Template Details, we’re just going to populate the Organization name because it is required. All these settings will be configured later.
We never use SCCM to create a reference image, so that’s what we’ll select on the Template’s Capture Settings screen.
On the Boot Image screen, we will specify our MDT-created Boot Image.
*Note: to enable 64-bit UEFI deployments, a new 64-bit WinPE image must be created.
We’ll select the Toolkit package on the MDT Package screen.
Now it’s time to select our Gold Image.
I like to make all my deployments as less intrusive on the end user as possible, so I always consider UDI more of a “Technician Driven Installation,” so when I deploy UDI it’s tailored to Deployment Technicians. Since this sequence will be deployed out to the user environment, we’re going to choose ZTI.
On the Client Package screen, we want to make sure that we’re not using the original Configuration Manager Client Package that was automatically created during the Primary Site Server installation. This is for two reasons: 1) It isn’t the same version as what’s in production, as Cumulative Updates have been installed, and 2) It’s read only. Therefore, we can’t enable the package for 1E Nomad Software Distribution.
The original Configuration Manager Client package will have a PackageID that ends in 0004 (or 0002,depending on the version that was initially installed), and will have the following listed as a comment:
This package is automatically created and distributed so that client can upgrade itself from the closest distribution point.
We’ll select our User State Migration Tool package…
On the Settings Package page, we’ll create a new Windows 8.1 x64 Settings Package. This package will contain most of our customizations.
On the Settings Details page, we’re just going to populate the Name field.
Next, Next, Finish through the remaining screens and your initial Task Sequence is complete!
Now I’ve never known a Task Sequence to work perfectly out of box, so there’s a half dozen things we’ll need to do just to get it to work as it should.
With our new Task Sequence highlighted, we ‘re going to click the Edit button in the Ribbon.
In the Task Sequence, under Initialization -> Partition if necessary -> Script exists and non-NTFS partitions, we’re going to select the Format and Partition Disk (UEFI). In the Properties page of the Results Pane, we’re going to remove the top three Volumes, so only OSDisk (Primary) remains.
When it comes time to implement UEFI into our deployment scenario, this change is required to successfully perform UEFI deployments.
Next, at the other Format and Partition Disk (UEFI) step, under the Script does not exist or no partitions group, we need to make the same change there as well. After both have been modified, they’ll look like this:
Under the Preinstall -> New Computer Only -> Format Disk group, we’re also going to delete the Format and Partition Disk 6.0 step. This is for XP, which is now dead and gone.
The next bug has been around for quite a while. We’re not sure why Microsoft continues to include this in their production releases…perhaps they just want to see how many people will blog about it 🙂
Scrolling down to the Install group, we need to modify the Set Variable for Drive Letter action so that OSDPreserveDriveLetter is True. Failing to switch this setting will cause Windows to be installed on the E: drive.
When we created the Task Sequence using the Wizard, we didn’t specify to join it to a domain. At this point we’re going to modify the step in the Task Sequence that performs the join into a domain or workgroup.
The specific Organizational Unit that the computer account resides is dependent upon its geographic location. This cannot be automated in native Configuration Manager without the use of custom built scripts, however is actually quite simple in MDT. For now, the Domain OU field just needs to have a value, so we’re going to put LDAP://OUWillGoHere as a placeholder. We also need to specify the Domain Join account in the Account field.
Now we get to address the lovely topic of Drivers. Many of my customers had struggled with driver application in Configuration Manager for years, and almost every one of them were using the default Auto Apply Drivers method. If you’ve only got two or three models, give ‘er. Otherwise, get rid of the Auto Apply Drivers step, and replace it with individual driver packages for each model, with conditions applied to execute only after verifying applicable Make/Model via WMI.
This may sound overly complicated, but the implementation is very linear. I like to store my Driver Package Data Sources and Driver Source binaries using the same structure that I use in my Task Sequences…that way whether I’m looking at the folder structure in Windows Explorer or the Groups in my Task Sequence, it’s the same thing.
We’ll Start by creating a group called Apply Driver Packages in place of the existing Auto Apply Drivers step that we can remove. Under this group, we’ll create Groups based upon Manufacturer, so HP, Lenovo, and Dell. Within there, we’ll add an Apply Driver Package step for each model, referencing the applicable Driver Package. In the Options tab for each Apply Driver Package step, we’ll add a Query WMI condition, ensuring that only models for that driver package will download it.
Here’s how it looks for our HP-standardized environment:
This next modification is not actually a bug for once! I like to make my deployments as fast as possible, and I’m sure you do as well. If so, here’s a tip: Don’t install Software Updates as part of your deployment sequence. If the organization has a mandate that all machines must be 100% patched before coming on the network, implement Network Access Protection. Installing Software Updates in a deployment sequence is flaky at best, and there are much better ways to ensure that your machines are patched. I will address Software Updates later, including how to patch your gold image with your monthly patch cycle, and how to properly implement a fire-and-forget ADR strategy.
Under the State Restore group is another bug that has existed in MDT for a few versions. At the point where the user state data is restored, there’s no action to find the State Store. This causes a failure in Replace deployments (as well as when HDDs need re-provisioning during a Refresh) as the Task Sequence does not know where to connect to retrieve the .mig file.
Though the implications are troublesome, the resolution is quick. Under the Set Status 5 step, we’re going to add an action to Request State Store. This is found under the Add -> User State menu. Once it’s in there, the Request state storage location to property needs to be changed to Restore state from another computer. Also select the check box to use the Network Access Account.
A couple of steps down, there’s an Apply GPO Pack action. We’re gonna want to disable that right out of the gate. It modifies a whole bunch of policies that normally aren’t defined with Group Policy, so GPOs would have to be created to revert some of the settings. Let’s just take this out of the mix altogether, and let Group Policy Manager/Preferences manage our client policies, shall we?
At this point we’re good with the Task Sequence, for the main office at least. We may need to come back in later to add an app or a patch, but that should be about it. Clicking OK applies the changes and closes the Task Sequence Editor.
However, as it stands the Domain Join piece will fail, as the OU specified does not exist. We want the Computer object to be placed in the OU that’s associated to that machine’s site.
In order to accomplish this with the least administrative effort (sounds like an exam question, eh?) we will modify the CustomSettings.ini file that is a part of our Settings package. It will add a little automation to our deployment sequence, and is super easy to set up. Before we get there though, we’re going to get MDT Monitoring configured so we can add the SLShare, SLShareDynamicLogging, and EventService entries into the CustomSettings.ini file as well.
On our Configuration Manager server, we’ll launch the Deployment Workbench. Although MDT was used to create the reference image, it was created from a different machine…the Deployment Share still needs to be created. To do this, we’ll right click on Deployment Shares, and choose New Deployment Share.
This Deployment Share will take up very little space. We’re going to be enabling Task Sequence Dynamic Logging and configuring an MDT Database, but these will ultimately be stored outside of the Deployment Share. We’ll just create it in the default location.
Just continue on through the rest of the wizard, accepting the defaults. We have full control over the deployment share, so anything that requires modification will come later.
Now in the results pane we can see MDT Deployment Share. Let’s right click on it and go to Properties.
Within the Properties window, we’ll go to the Monitoring tab and select the checkbox to Enable monitoring for this deployment share. Click OK to finish the server side configuration to get MDT Monitoring working.
As an introduction to automation, we’re going to look at using the CustomSettings.ini file to define a ComputerName based upon a set naming convention and part of the serial number, place computer objects into a site-specific Organizational Unit, and set the proper Time Zone. We also need to tell clients where to send their log files during Task Sequence Execution.
This is just an example of a couple of the things that can be automated with MDT rules, but there are dozens upon dozens of possibilities.
In this text window, we can see that we’ve added settings for Init and Default Gateway at the top. Init section will contain the initial settings that we will need throughout the ini file. Default Gateway is a special setting that works off information obtained through ZTIGather, which we will use to define the site of a machine being deployed.
The subsequent groups for each location define the settings that we want customized.
Entries in the Default section will apply to all deployments, if a setting hasn’t been previously applied (there are exceptions to this rule, however we’re not triggering any of those here). There are also steps added at the bottom to transfer up the Task Sequence logs upon failure/completion, as well as a Dynamic Log location. These respective shares must already exist.
Finally, save the file, perform an Update Distribution Points action on your Windows 8.1×64 Settings Package, and deploy!
É
