SCCM OSD Part 2: Consolidating the Captured Images

In part of one this series, SCCM OSD Part 1: Building Reference Images, we setup task sequences to capture reference images for all of the required operating systems. Further on in this series, we will be using Microsoft Deployment Toolkit to create a User-Driven Installation (UDI) with the Configuration Manager integration and in order for this to work, we need to consolidate our images into a single master .wim file.

This post will focus on this area. There are no screenshots to offer here as this is a purely command driven exercise. In order to complete the steps in this post, you will need to know the path to where you captured the reference image task sequence .wim files. For the purpose of this, I will assume in this post that all of your captured images are stored in the D:\Images\Captured path on your server. To keep this post consistent with my lab environment, I will provide the commands for capturing Windows 7 and Windows 8.1 images for both 32-bit and 64-bit architectures into the consolidated image.

We start the process by capturing the first image with the following command:

Dism /Export-Image /SourceImageFile:”D:\Images\Captured\Windows 7 x86.wim” /SourceIndex:2 /DestinationImageFile:”D:\Images\Consolidated.wim” /DestinationName:”Windows 7 x86″

Dism is a complicated beast and has a lot of switches that we need to throw into our commands to make it work as we want. To make it worse, Dism is a command line tool not a PowerShell tool so we don’t have the luxury of tabbing our commands to completion. When you enter this command for yourself, make sure you include the quote marks around any names or file paths with spaces. If you have no spaces in your names or paths then you can omit the spaces.

To breakdown this command, the Export-Image opening parameter tells Dism that we want to export the contents of one .wim file into another. The SourceImageFile parameter tells Dism where our source file is located and the SourceIndex tells it which image within the .wim file we want to export. The reason we need to target index 2 is that when a machine is captured using the Build and Capture Task Sequence, two partitions will be created on the disk and captured. The first will be a 300MB System Reserved partition used for Boot Files, BitLocker and Windows Recovery Environment if any of these features are configured. The second partition is used to install the actual Windows operating system. DestinationImageFile is obvious in that we are telling Dism where we want the image from the original file to be saved. In essence, we are telling Dism to create a new file with the index from an existing image. The DestinationName parameter is not required but is makes our lives a lot easier down the line. With Destination Name, we provide a friendly name for the index within the .wim file so that when we are using SCCM or MDT to work with the image we are shown not only the index number but a friendly name to help us understand what index in the image file does what.

The command will execute fairly quickly and once complete, we will have a new file called Consolidated.wim with the contents of the original .wim file for Windows 7 x86. Now, we repeat the command for Windows 7 x64.

Dism /Export-Image /SourceImageFile:”D:\Images\Captured\Windows 7 x64.wim” /SourceIndex:2 /DestinationImageFile:”D:\Images\Consolidated.wim” /DestinationName:”Windows 7 x64″

You will notice the two differences heres. Firstly, we specify a different Source Image File to the 64-bit version of Windows 7. The second difference is the Destination Name. When we run this command, Dism sees that the Consolidated.wim file already exists and does not overwrite it but instead, applies our Export Image command as a second index to the Consolidated.wim file and hence you see how we build a consolidated image.

Repeat the command twice more to add the Windows 8.1 iimages:

Dism /Export-Image /SourceImageFile:”D:\Images\Captured\Windows 8.1 x86.wim” /SourceIndex:2 /DestinationImageFile:”D:\Images\Consolidated.wim” /DestinationName:”Windows 8.1 x86″
Dism /Export-Image /SourceImageFile:”D:\Images\Captured\Windows 8.1 x64.wim” /SourceIndex:2 /DestinationImageFile:”D:\Images\Consolidated.wim” /DestinationName:”Windows 8.1 x64″

Once these two commands have completed, it’s time to review our work. Use the following command with Dism once more to list the contents of the new Consolidated.wim file and make sure everything is as we expect it.

Dism /Get-WimInfo /WimFile:”D:\Images\Consolidated.wim”

The result will be that Dism outputs to the command line the name, index number and size of all of the indexes within the image. If you are following my steps above to the letter then you will have a resulting Consolidated.wim file with four indexes, each with a friendly name to match the operating system within that given index.

SCCM OSD Part 1: Building Reference Images

This is the first in what will become a multi-part series of posts on configuring Operating System Deployment in Configuration Manager 2012 R2. The end goal will be to use Configuration Manager with MDT integration to provide a rich end-user experience for deploying operating systems.

In this first part, we will lay the foundation for what will become the core of the deployment – the Windows Operating System images. In this part, we will create task sequences to build and capture the reference images and update them as needed.

Import OEM Media OS Images

We start with our source Windows media. Copy the contents of the Windows .iso file you plan to use for your installations to a suitable directory in your SCCM source structure and import the Operating System Images as shown above. Repeat this for as many Operating System versions and architectures as you need to support. If you are supporting many operating systems, I would highly recommend creating a folder structure to aid locating the images.

Create Task Sequence Wizard Build and Capture

Once you have imported your base Operating System Images, we need to create a new Task Sequence. In the Task Sequence Wizard, select the Build and capture a reference operating system option.

Specify Task Sequence Name and Boot Image

Next, we need to give our Task Sequence a name and specify the boot image to use. You should always use the 32-bit (x86) boot image because with this one image we can support both 32-bit and 64-bit operating system images however if you use the 64-bit boot image, that is only able to support 64-bit operating system images.

Specify OS Image to Use as Reference

Next, we need to specify our source operating system. In this demonstration, I am using Windows 8.1 Enterprise with Update (x64). The install.wim file in the source Windows media only contains a single image so Image 1 automatically selected from the .wim file. If you are using a Windows image that provides multiple Images such as Home Basic, Home Premium and Professional then you need to make sure you specify the correct image from the list.

Specify Join a Workgroup

Next, we need to specify our machine to join a workgroup and not a domain. We don’t want our reference machine to join the domain as joining the domain will cause Group Policy Objects to be applied to the image which could in turn install software, none of which we want included in the base image. Specify any workgroup name you like but I stick to WORKGROUP just for simplicity.

Set ConfigMgr Client Package Properties

On the step shown above, we need to configure the Configuration Manager Client Package that will be used to install the Configuration Manager Client. Configuration Manager will automatically select the package from the site however we need to customise the parameters that get used for the installation. Parameters are automatically detected from the site Client Push Installation parameters and in my case, this added the Fallback Status Point (FSP) record automatically. We need to add to this the SMSP parameter. The SMSMP parameter tells the Configuration Manager Client the name of the Configuration Manager Management Point. A domain client would find this automatically via Active Directory Publishing of Configuration Manager but as we are in a workgroup, we need to add it. Without this parameter, our Install Software Updates steps will fail to find any updates. Add the parameter as SMSMP=RJGCMSITE1.rjglab.local where RJGCMSITE1.rjglab.local is the FQDN of y our Configuration Manager Management Point.

Specify Install All Software Updates

After setting our SMSMP parameter, we need to tell the task sequence wizard that we want to install All Software Updates. This will install any updates which are either Required or Available to the client from any deployments that are visible to the client.

Specify Capture Path and Network Access Account

 

On the final step, we need to specify the capture path and a network access account. Specify the UNC path to the location where you want the captured reference image to be uploaded. This captured file is not automatically added to Configuration Manager once the capture process is complete. The network access account does not use the account configured in the Site Properties and requires us to re-enter the username and password. This is because we may be saving the captured image to a location or to a server which the normal network access account does not have access.

Once you reach this point, the reference image task sequence will be created with all the default steps and can be used like this if you wish however I like to add a few more steps manually.

Add Install Software Steps to the Reference Image

As you can see from the image above, I have added an Install Software step to the task sequence to install .NET Framework 4.5.1 so that all of my reference machines include this newer version of .NET Framework. Other things you might want to consider including in your reference images are Windows Features such as .NET Framework 3.5.1 or software such as Visual C++ packages that will be required by your end-user applications later on down the road. This is down to personal preference and individual requirements so do as you will here. Use an Install Software step to perform this and reference the package and program as required to do so.

Add Software Update Scan Step

Next, I like to make some changes to the Install Software Updates phase of the sequence. Firstly, I have found, as have others in the community that sometimes the task sequence just fails to find any updates. We can fix this with two steps added to the task sequence. The first step shown above calls the Configuration Manager Client and forces it to perform a Software Update Scan Cycle. To add this yourself, use the following, added as a Run Command Line action in the task sequence.

WMIC /namespace:\\root\ccm path sms_client CALL TriggerSchedule “{00000000-0000-0000-0000-000000000113}” /NOINTERACTIVE

Add Software Update Wait Step

In the step following our forced Software Update Scan Cycle, add a wait timer to the task sequence. This is to give the Software Update Scan Cycle enough time to run, complete and evaluate the updates requirements. Some people will want to use a VBScript to initiate this but doing so requires a package to be downloaded by the client. The easiest way is to use PowerShell and the Sleep command. Use the following added to the task sequence as a Run Command Line action to add a wait timer to the task sequence.

PowerShell.exe -Command Start-Sleep 45

You can change the timer from 45 to any number of seconds that you require but I found that 45 seconds works okay for my requirements.

As you will also see from the two screenshots above, I have added multiple Software Update sections with a Restart Computer step following each wave. As we all know, some Windows Updates require dependencies to be installed or require a restart to complete their installation. Having three iterations (waves) of Install Software Updates in the task sequence does add a chunk of time to the end of the capture process but it is worth it, especially given you won’t be running these too often if at all after the one time. Having three passes of the Install Software Updates step will pretty much ensure that your reference images have 100% of all available updates installed and will be fully up to date.

Once you’ve reached this point, your task sequence for building and capturing a reference image is done. If like me, you are supporting multiple operating systems and architectures then you can now copy the task sequence to create a duplicate of it. For each duplicate you create, edit the Apply Operating System and the Capture the Reference Machine steps to change both the operating system image that gets applied to the reference machine and also the path to which the image is captured.

Once you have created all of the required task sequences, advertise (deploy) them to a collection and run them on your client. At the end of the process, you will have captured a .wim file for each operating system variant you support as a fully patched reference image and we are ready to move on to the next step which is image consolidation which I will be posting in the coming hours or day or so.

Extending SCUP with the Patch My PC Catalog

If you read my two previous posts, Preparing Certificates and GPOs for System Center Update Publisher and Setting Up System Center Update Publisher, you will have already a working SCUP installation and integration with Configuration Manager and you will have the certificates and Group Policy Object settings in place for your clients to trust the updates distributed by SCUP. The downfall to the work done with SCUP up to now is that the out of the box catalogs that Microsoft give you access to are subject to that provided to Microsoft by the software vendors. Adobe, Dell, Fujitsu and HP all provide catalogs however none of these are complete and cover their entire product line but the gesture is most welcome none-the-less.

Where SCUP becomes really powerful is when we look beyond these out of the box catalogs and look at starting to patch other third-party software that doesn’t get delivered through Windows Updates normally and the primary reason is security.

Third-party applications as much as we need them can be the bain of an administrators life and the need to keep them up to date, especially when you look at heavily updated applications like Adobe Flash Player or Google Chrome. We need to keep pace with these updates to make sure that the vulnerabilities and CVEs addressed by the updated versions get into the hands of our users but it is a balance between time, effort and cost as are all things in business. Depending on the sector or organisation you work for, you might have a requirement to keep pace too. UK bodies that use the Public Services Network (or PSN) or organisations accepting credit card payments required to comply with PCI DSS all have compliance requirements to maintain applications within a certain number of versions of the latest available release.

Another reason for considering SCUP for these third-party updates is consistency and efficiency. Google Chrome and Adobe Flash Player for example, both have automatic update engines built into them designed to keep the products up to date however these systems aren’t designed with the enterprise in mind and as a result we not only can find ourselves in a scenario where we start to find divergent versions of software across the estate but also we find a large amount of internet connection bandwidth being consumed by downloading these software updates for each and every client. Yes there are workarounds to this such as caching the updates on a proxy server but that doesn’t really resolve the root issue.

Home Brew Updates and Detectoids

The brave amongst you may be looking around the SCUP console and have realised that you can import your own updates from a Local Update Source and that you can write your own detectoid rules to locate installed software at specific versions but that is time consuming work, requires a lot of testing and prone to error: I tried myself to write custom detectoids for patching Oracle Java in a previous life and it didn’t go so well even though I followed instructions somebody else claimed to have worked.

If we look back to the statement I made about balancing time, effort and cost, creating custom updates in SCUP uses all three of those although the cost is born out of man-hours spent on the endeavour and not a real cost like buying something. Therefore, this isn’t an effective solution so we need to find something else.

Patch My PC SCUP Catalog

As we already know, SCUP provides some out of the box catalogs for getting third-party updates but the list of products and vendors is extremely limited. To my mind, the worst offenders like Oracle with Java and Google with Chrome should be doing more to help enterprises with services like SCUP catalogs but they don’t sadly. Luckily for us though, the market answers our needs and here is where I introduce a company called Patch My PC who have a product simply named SCUP Catalog.

What Patch My PC provide is a subscription based catalog that we can import into our SCUP console and they do all the hard work for you of creating the detectoids, pulling together the update files and crucially, the testing. Unlike most enterprise software that costs the earth, Patch My PC is priced simply and fairly: $1 per managed client per year. There is a minimum order of 250 managed clients so even if you have only 100 devices, you need to license 250 still but at $1 per client, per year, I fail to see how any organisation could manage the patching of third-party applications more cheaply.

Before I get any further into the details on this post, I just want to make one thing clear. As are all of my posts on this blog, nobody is paying me to write a favourable review for a product or say anything nice about their company in exchange for favours. I approached Patch My PC to request the NFR license for my lab so that I could blog about it to show you all the value of the software, not because I’m making revenues of advertising their product for them. There are other products on the market which can perform a similar job to Patch My PC SCUP Catalog but none of them are able to do it with the simplicity that we can here today nor do any of them come even remotely close on value for money and price. As we all know enterprise IT is squeezed year-on-year for budgets, if we can achieve something more effectively and more cost consciously then it is good thing.

Add Patch My PC SCUP Catalog

After registration and payment, you will be emailed a URL to a .cab file. You don’t need to download this file as this file is updated frequently by the team at Patch My PC with the latest updates. In the SCUP Console, on the Catalogs page, select the Add Catalog link in the Ribbon. In the wizard, enter the URL given to you for your unique catalog and enter the details for Patch My PC as shown into the various form fields.

Import Patch My PC SCUP Catalog

Once you have added the catalog, you need to import it. Still on the Catalog page in the console, select the Import button and select the Patch My PC catalog to import it. Unlike the out of the box catalogs I showed in my previous posts, this will take a lot longer to import as there is a lot more here but it shouldn’t take more than a minute or two.

Publish Patch My PC Updates to WSUS

With the catalog imported, head over to the Updates page and take a look at the list of products and updates that the catalog has added to SCUP. The list of products includes too many products for me to mention directly here but you can look at the list they maintain at https://patchmypc.net/supported-products-scup-catalog. To deploy an update to clients, we need to publish it to WSUS. Select the update(s) you want to deploy and select the Publish option from the Ribbon.

Once you have published the updates they will be inserted into WSUS and we now need to make a quick change in Configuration Manager for the remainder of the process to work.

Add Products to SCCM SUP Point

In your Configuration Manager Administration Console, navigate to the Administration page and expand the Site Configuration folder followed by Sites. In the main area, right-click your Configuration Manager site and select the Configure Site Components menu item followed by Software Update Point. In the SUP settings, select the Products tab and check the boxes for all of the products you just published into WSUS as they will currently not be enabled.

SCCM Software Updates with Patch My PC

Once you have done this, the next time your Software Update Point WSUS server performs a synchronisation either automatically on the schedule or if you force one, the updates for the recently added products will appear in the All Software Updates view of the console and will be available for you to deploy to your clients following your normal software update process.

As you can see, with Patch My PC, we can use SCUP to quickly get third-party software updates published into WSUS and made available to Configuration Manager for us to deploy to clients extremely quickly and easily without having to create our own custom updates or detection rules. Furthermore, we no longer need to manually create Software Packages in Configuration Manager for the updated products and Device Collections to locate machines on the network with particular software versions installed to target the deployment of these updates.

The whole process took me in my lab no more than 30 minutes to get setup with a working Update Publisher deployment already in place and now that it is done, it would take less than ten minutes each month to add approvals for the products I am interested in and get them into Configuration Manager to the point that I would be ready to roll them out to clients and to be able to achieve this level of simplicity in third-party patch management for $1 per device per year is frankly amazing.

SCCM OSD Failed Setup Could Not Configure One or More Components

Last week I got asked to look at an issue where a new model of laptop was failing to deploy using a Configuration Manager Operating System Deployment Task Sequence. We knew that the environment was good as other machines were able to complete the task sequence without any issues and the first thought was that it could be a driver issue.

Initially I was sceptical of it being a driver issue as when we see problems with machines completing operating system deployment, problems with drivers normally fall into the category of silent fail whereby the driver is missing all together and we end up with the yellow exclamation mark in Device Manager or the task sequence fails because the driver missing or problematic is related to network or storage and blocks the task sequence from completing.

In this instance however, we knew that the problem was specific to this model. Given that we are failing in the Windows Setup portion of the task sequence, the usual smsts.log file is of no help because the Configuration task sequence has not yet been re-initialized after the reboot at the Setup Windows and ConfigMgr step. in this instance, we need to refer to the setuperr.log and the setupact.log in the Panther directory which you will find in the Windows installation directory. This is where errors and actions relating to Windows Setup live as opposed to the normal smsts.log file.

We rebooted the machine back into WinPE to allow us to open the log file with visual Notepad and began reading the file. Sure enough, we hit an error and the code given was 0x80004005. Looking at the activity either side of this, we can see that the machine is busy at work with the CBS (Component Based Servicing) engine and is initializing and terminating driver operations so we know that something has happened to a driver to cause this problem.

At this point, we had nothing more to go on. Two weeks’ ago, I had a similar issue with another customer whereby the issue was clearly logged to the setuperr.log file and the problem in that instance was an update we had added to the image with Offline Servicing required .NET Framework 4.5 to be present on the machine however Dism didn’t know to check that so we simply removed the update but here, we have no such helpful fault information.

Given that this was a new machine and given that we are deploying Windows 7, I had a thought? What if these drivers being applied require the User or Kernel Mode Driver Framework 1.11 updates that were released for Windows 7 some time ago?

This theory was easy to check. I mounted the Windows 7 .wim file on our SCCM server and then used the Get-Packages switch for Dism to list the installed updated in the image. Sure enough, User-Mode Driver Framework 1.11 (KB2685813) and Kernel-Mode Driver Framework 1.11 (KB2685811) were both absent from the list. I downloaded the updates from the Microsoft Download Center and Offline Serviced the Windows 7 image with the updates and commited the changed back into the .wim file.

After reloading the image in the Configuration Manager Administration Console and updating the .wim file package on the Distribution Points we re-ran the task sequence and by-jove, the machine completed the task sequence with no dramas.

For background reading, the User-Mode and Kernel-Mode Driver Framework 1.11 update is required to install any driver file which was written using the Windows 8 or Windows 8.1 Driver Kit. What I have yet to be able to determine is if there is a way of checking a driver .inf file to determine the version of the Driver Framework required. If there had been a way to determine this, Configuration Manager administrators around the world may rejoice a little so if you do know of a way to check this, please let me know as I would be interested to hear. This would have not been an issue had the reference images been patched with the latest (or at least some) Windows Updates however in this case, I was not so lucky.

Setting Up System Center Update Publisher

In my earlier post Preparing Certificates and GPOs for System Center Update Publisher, I showed you how you can prepare your environment with the appropriate certificate and Group Policy Object to support a System Center Update Publisher installation. With all of this installed and configured, the time is upon us to now install and configure System Center Update Publisher.

I am not going to go through the installation process for SCUP here because it is literally a Next, Next, Finish installation. What I will tell you though is that the latest version of SCUP is 2011 and you can download it from http://www.microsoft.com/en-gb/download/details.aspx?id=11940. The steps in this post can be applied to Configuration Manager 2007 or Configuration Manager 2012 and 2012 R2 but all of my screenshots for the Configuration Manager side of things will be in SCCM 2012 R2.

Configure SCUP Options

Once you have got SCUP installed, you want to open the console, ensuring that you use the Run As Administrator option. If you don’t elevate the console when you launch it, a number of the options and settings will prevent you from changing them. Once open, click the blue icon in the first position on the Ribbon and select Options to get to the settings.

SCUP Configure WSUS Server

First, we want to configure the WSUS Server settings tab. On this tab, you can either specify the hostname for a remote WSUS server or if you are running the SCUP console locally on your WSUS server you can select the option for Connect to a Local Update Server. An important note here is that if you are connecting to a remote WSUS server, the connection must be over SSL on either Port 443 or Port 8531 in order to be able to configure the Signing Certificate settings.

Once you have specified the server, select the Browse button in the Signing Certificate area and locate the .pfx file that has the exported Code Signing certificate including the private key that was exported in the Preparing Certificates and GPOs for System Center Update Publisher post. Once you have located the file and the path is shown in the field, select the Create button and this will publish the certificate into WSUS. You will be prompted to enter the password for the .pfx file at this point.

SCUP Configure SCCM Server

With the WSUS settings configured, we now need to head to the ConfigMgr Server tab. Here, specify whether to connect to a local Configuration Manager server if you are running the SCUP console on your Primary Site Server, otherwise enter the remote server name.

In the fields in the lower part of the screen, you can specify the behaviour of SCUP for transitioning updates between Metadata only and Full Content publishing status according to the required client count. In a nutshell, you can have SCUP publish only the metadata for an update into SCCM to allow you to determine if clients require the update. Once a defined number of clients report the update as required, SCUP will change the status of the update to Full Content and will download the files such as .msp or .exe files for the update.

Adding Catalogs to SCUP

SCUP works by using catalogs which are lists of updates published by manufacturers and included in these catalogs are the update definitions which are called detectoids, working to determine if a client meets the requirements for an update as well as defining the URL where SCUP can download the update from.

In the SCUP console, select the Catalogs button from the left navigation and then hit the Add Catalogs button from the Ribbon.

SCUP Add Catalogs

After clicking the Add Catalogs button, you will be presented with the list of partner catalogs supported by SCUP. These are out of the box and are at no cost to use. To my mind, the Adobe Reader and Adobe Flash Player are the most important. As you can see from the screenshot, I have added these two catalogs from the list of partner catalogs to include in my SCUP catalogs to be used.

Once you have added catalogs to SCUP, we aren’t quite finished as that only adds them to the list of catalogs that can be used however it does not automatically start getting update information. Now, we need to Import the Catalogs. Select the Import button from the Ribbon to access the Import Software Updates Catalog Wizard and here, select one, some or all of the catalogs you just added. Doing this may take a few moments and you might receive a security warning asking you to accept some certificates in the process so go ahead and allow this.

Publishing Updates from SCUP

With the update catalogs added to SCUP and the updates in those catalogs imported, now it is time to look at some actual updates. Head over to the Updates view in the console with the button in the lower-left corner. and expand one of the folders to view a subset of the updates.

SCUP Updates List

Here we can see the name of the updates, if there are any relevant article IDs or CVEs that they address as well as the date the update was released and whether or not it is expired. As you can see for Adobe Flash Player, many of the updates are expired because they have been superseded by later updates. Highlight an update that has not been superseded and select the Publish button in the Ribbon. Click through the wizard to download the update files if required and the update will be published into WSUS ready for SCCM to use.

Configuring SCCM Software Update Point Products

With the updates now published into WSUS for Configuration Manager use, we need to make sure that Configuration Manager will be able to detect the updates. As part of installing and configuring Configuration Manager you will have setup the products and classifications for which you want to download updates and we need to add to this the products that we just published with SCUP.

In the Configuration Manager Administration Console, navigate to the Administration page and then expand the Site Configuration followed by the Sites view. Right-click on your site and then select the Configure Site Components menu item followed by Software Update Point.

SCCM SUP Products

As you can see in the screenshot above, after publishing the Adobe updates into WSUS, there is now some additional products listed for Adobe Systems Inc including Flash Player and Reader. There is also a new product called Local Publisher which is the product SCUP updates for any updates you create manually. Check all of the new products you want to be able to deploy to clients and then save the changes to the Software Update Point role.

Viewing the SCUP Updates in SCCM

SCCM Adobe Updates Available

With the updates now published to WSUS for Configuration Manager and with Configuration Manager’s SUP role configured to accept updates for these products we’re all set. You can either wait for the WSUS server to perform a scheduled synchronisation or you can force it from the Software Updates area of the Software Library page in the console. Once a synchronisation has occurred Configuration Manager will be able to list the new updates for the new products.

As you can see in the screenshot above, I used a criteria to filter the search results for Bulletin ID contains APSB which is the prefix Adobe uses for all of their security updates much like Microsoft use KB to prefix their updates. I can now follow the normal process of downloading the updates into Deployment Packages and approving the updates for distribution to collections.

 

Automatically Select a Configuration Manager Task Sequence

With Configuration Manager, we have a great amount of power and control over how we deploy computers using Task Sequences. Many people go to great lengths to make their operating system deployment experience a great one be it for end-users with User Driven Installation or for their support technicians driving the builds instead. One way which we can streamline the process is to use a consolidated task sequence which handles all of our various operating systems, languages, drivers and applications in a single task sequence with intelligence.

If you have gone to the great lengths to make this happen in your environment, you may be left with a sinking feeling that everytime you PXE Boot or USB Media Boot a client to deploy, you still have to select a task sequence to run even though you only have one as shown in the sample below.

Select TS Task Sequence Wizard

Luckily, we have a solution to this and a way to allow us to skip the Task Sequence Selection wizard and automatically enter our one task sequence to rule them all and it is done using Prestart Commands on our Boot Images in Configuration Manager. You don’t need MDT or any other fancy software integration with Configuration Manager to do this as it is done using the default boot images.

To start, we need to know the Deployment ID for the Task Sequence. This is not to be confused with the Package ID. The Deployment ID is the unique ID assigned to a single instance of the task sequence deployed to a collection.

We can get the Deployment ID for the Task Sequence by navigating to the Software Library portion of the Configuration Manager Administration Console and then expanding Operating Systems followed by Task Sequences and then locate your sequence from any folder structure you may have created. With the Task Sequence selected, the lower half of the screen will show the summary properties for it. Click the Deployments tab at the bottom here to see where your Task Sequence is deployed, in my example, to the All Systems collection.

In this area, right-click on the column titles and add the Deployment ID column to the view. This is the value we need.

Task Sequence Deployment ID

With this value in hand, we now need to create a very simple VBScript file. I store this file in a directory called OSD Prestart Files on my Primary Site Server but where you store it is up to you. Create a VBScript with the following contents.

Set DefaultOSDTS = CreateObject("Microsoft.SMS.TSEnvironment")
DefaultOSDTS("SMSPreferredAdvertID") = "RJG20008"

In your case, you will need to change the value of DefaultOSDTS to the Deployment ID shown in your console. My Deployment ID was RJG20008 as set.

Once you have created and saved this file, head over to the Boot Images section of the Operating System portion in the Software Library and view the Properties for your boot image.

Boot Image Prestart Command Setting

As you can see from the image above, we need to check the box for the option Enable Prestart Command on the Customisation tab of the properties. Once this is checked, we can add the command to call our VBScript file which in my case will be cscript AutoStartOSD.vbs. Once you have entered this, check the box for Include files for the prestart command and specify the path to the script file you created so that this file is integrated into the Boot Image file.

When you save the changes, you will be prompted to update your Boot Image files and the file will be rebuilt and updated on your Distribution Points. Once complete, if you are using PXE to boot your clients you need to do nothing more and you can start enjoying your automatically starting task sequence. If you are using USB or ISO Boot Media to start your task sequence process, you will need to update your image as the Boot Image that the media is based on has been updated.

Configuration Manager OSD Fails with Error 80070002

When working in my lab environment to build a deadly Operating System Deployment Task Sequence, I did the usual thing of creating reference image task sequences and building reference images. After doing this I fired off the real deployment task sequence to test some PC deployments and I was running CMTrace within Windows PE to monitor the logs and the progress.

I noticed in the testing that the Windows 7 images I had created worked just fine but my Windows 8.1 images kept failing at the Apply Operating System step. The package would be downloaded okay from the Distribution Point but would hang for quite some time after downloading it and fail to start applying the image to the disk. The error code in the smsts.log was 80070002 and the message for the code was The system cannot find the file specified. (Error: 80070002; Source: Windows).

Given that the build and capture task sequences had completed without problems, I knew that it must have been something added or changed between the original source media and the reference image task sequence and the most likely culprit is the Install Software Updates steps in the build and capture task sequence.

I started searching online to see if anyone had produced a list of known bad updates as having to identify manually which of the 92 updates being applied during the reference image creation process would be a pain. Luckily, Microsoft have a support article for just this at https://support.microsoft.com/en-us/kb/2894518. After reviewing the articles referenced on this page, it turned out that one of these updates was approved in one of my Software Update Groups and downloaded to one of my Deployment Packages. I unapproved and deleted the update and refreshed the package on the Distribution Points to flush it out.

My Windows 8.1 build and capture task sequences are running again as I type, fingers crossed this time working in the main deployment after capture.

UPDATE: Confirmed that removing the KBs referenced in the support article resolved the issue and here’s a screenshot just for proof. I will have loads of posts coming soon how this task sequence is built including sample files.

Windows 8.1 OSD Deployment

Updating Configuration Manager 2012 R2 Client Package to UR4

When you install UR4 for Configuration Manager 2012 R2 one of the things it doesn’t do is update your base client install package. As a result of this, newly installed agents will still install the out-of-the-box version 5.00.7958.1000 of the agent not the UR4 version 5.00.7958.1501. It goes without saying that we don’t want newly deployed agents to have to install and them straight away afterwards, update to UR4 because it makes sense to incorporate this update at install time.

One of the most common ways to apply an update rollup is using the PATCH MSI parameter in both your Client Push Client Installation Settings and also in your Setup ConfigMgr step in any Operating System Deployment Task Sequences. Not only does this mean updating it in two places at minimum but if you have a number of task sequences, it could be even more.

In this post, I’m covering to explain a great method of getting UR4 installed with a new agent that was posted by a blogger named Matt at http://www.m4ttmcg.com/2013/05/sccm-2012-client-push-including.html. This process is deemed to be not officially supported however using the PATCH parameter isn’t exactly filled with support and joy and with this method being easier, it makes it all the more promising.

The Configuration Manager Client Agent installation by default looks to a sub-folder of the Client directory called ClientPatch and installs any .msp files it finds as part of the installation, installing multiple patches alphabetically in order.

To do this, on your Primary Site Server, navigate to the local file system path where the update patch .msp file is stored. On my server this is located at D:\Program Files\Microsoft Configuration Manager\hotfix. In the hotfix directory will be a folder for any updates that you have installed which in my case is UR4 or KB3026739 and then there are subsequent subfolders for AdminConsole, Client, SCUP and Server.

Open the Client folder and then you will see more folders for x86 and x64 for the two client architectures.

SCCM Client Hotfix Folder

In another Windows Explorer window, open the folder for the Client Agent in the site which is used by both the Client Package and the path for the Client share on the site server. On my server, the share is located at D:\Program Files\Microsoft Configuration Manager\Client.

In the Client folder are two subfolders for x86 and x64 for the two architectures of the client agent. In each architecture folder (the screenshots herein are all for the x64 architecture but simply repeat for x86) create a folder called ClientPatch.

SCCM Client ClientPatch Folder

In the ClientPatch folder you just created, copy the .msp file for the KB (UR4 in my case) and then repeat this for the other architecture so that both x86 and x64 client folders have a ClientPatch subfolder and the appropriate .msp file to match the architecture.

Once you have updated both of the client folders, head over to your Configuration Manager Admin Console and the Software Library and then navigate your library to locate the Configuration Manager Client Package. Right-click on the software package and select the Update Distribution Points option.

SCCM Client Update Distribution Points

Once your package has been updated on all of your distribution points, you’re set. Your client package now includes the UR4 update .msp file and any new client installations such as Client Push or via an Operating System Deployment Task Sequence will be installed with the UR4 update automatically with no need to update your Installation Parameters with the PATCH option.

Upgrading Configuration Manager 2012 R2 Agents to UR4

In this post I’m going to assume that you’ve already installed UR4 in your Configuration Manager environment as that’s covered by many a post and article online already. I’m also going to assume that your UR4 Software Packages have been distributed to your Distribution Points.

After you’ve installed Update Rollup 4 for Configuration Manager on your Primary Site Server and updated your site database, it’s time to update the rest of the servers in your Configuration Manager hierarchy and then move on to your agents and administration consoles. The first thing to do is we want to create some device collections to help us. I have created the following collections using the included WQL statements for the query based membership.

Creating the Query Based Collections

SCCM UR4 Collections

Configuration Manager 2012 R2 Agent (x64)

SELECT
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System INNER JOIN SMS_G_SYSTEM_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId WHERE SMS_R_System.ClientVersion = "5.00.7958.1000" AND SMS_G_System_COMPUTER_SYSTEM.SystemType = "x64-based PC"

Configuration Manager 2012 R2 Agent (x86)

SELECT
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System INNER JOIN SMS_G_SYSTEM_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId WHERE SMS_R_System.ClientVersion = "5.00.7958.1000" AND SMS_G_System_COMPUTER_SYSTEM.SystemType = "x86-based PC"

Configuration Manager 2012 R2 Console

SELECT
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client FROM SMS_R_System INNER JOIN SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId WHERE SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = "System Center 2012 R2 Configuration Manager Console" AND SMS_G_System_ADD_REMOVE_PROGRAMS.Version = "5.00.7958.1000"

Configuration Manager 2012 R2 UR4 Agent (x64)

SELECT
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System INNER JOIN SMS_G_SYSTEM_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId WHERE SMS_R_System.ClientVersion = "5.00.7958.1501" AND SMS_G_System_COMPUTER_SYSTEM.SystemType = "x64-based PC"

Configuration Manager 2012 R2 UR4 Agent (x86)

SELECT
SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System INNER JOIN SMS_G_SYSTEM_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceId = SMS_R_System.ResourceId WHERE SMS_R_System.ClientVersion = "5.00.7958.1501" AND SMS_G_System_COMPUTER_SYSTEM.SystemType = "x86-based PC"

Deploying the Software Packages for Agents

With the collections now created, head over to the Software Library node of the console. As part of installing UR4, the installer will have automatically created four software packages for you, two for the client architectures, one for the console and one for servers.

Clicking one of the Software Packages in the upper half of the view reveals the details of the package in the lower half. Select the Programs tab in the lower half and you will see the Program associated with the Software Package. Right-click the Program and select the Deploy option from the context menu as shown below.

SCCM UR4 Deploy Program

After clicking this, the Deploy Software Wizard will be shown. The Software field will be automatically populated by the wizard; we just need to enter the collection to target the deployment. For example, we want to deploy the UR4 update to all clients which have the out-of-the-box version installed so we need to target the Configuration Manager Client RU4 Update (x64) software program to the Configuration Manager 2012 R2 Agent (x64) collection.

SCCM UR4 Agent Deploy Software Wizard 1

On the next tab, we need to change the default Purpose from Available to Required. This purpose will force the installation to occur according to a schedule which we set on the following panel.

SCCM UR4 Agent Deploy Software Wizard 2

On the scheduling panel next up, we want to configure the schedule in accordance with any change control we may have to comply with. In my lab environment, I simply want to push all of the agent updates out to the servers and clients as soon as possible so the As Soon as Possible option is ideal for me.

SCCM UR4 Agent Deploy Software Wizard 3

If you aren’t using Maintenance Windows on any of your collections in Configuration Manager you can click next through to finish on the wizard now and have your agent deployment begin. If you are using Maintenance Windows then you will want to pay attention to a setting on the following panel.

SCCM UR4 Agent Deploy Software Wizard 4

If you are using Maintenance Windows then you may want to select the Software Installation checkbox to allow the agent installation to occur outside of any windows. The agent installation does not require a restart and in most cases, should be updated in a couple of minutes with no fuss so there is really isn’t a reason to not allow this to happen. Ticking the Software Installation checkbox allows the agent upgrade to take place outside of any maintenance windows so it will take place as soon as possible.

SCCM UR4 Agent Deploy Software Wizard 4

Once you have completed the wizard, you can confirm that your Deployment was successfully stored by viewing the Deployments tab in the lower half of the Software Library Packages view. As shown below, you can see that the deployment I just created to deploy the 64-bit agent has been stored. With this completed, you will want to repeat the process for the x86 (32-bit) agent so that both types of client get the UR4 agent update.

Deploying the Software Package for Admin Consoles

I’m not going to walk through the process for this as it is the same as above for the agent update however there is one important difference I will cover.

When you get to the Deployment Settings panel, you need to select the Available deployment option and not the Required option. The reason for this is that when you deploy the UR4 agent updates, the agent version gets updated from 5.00.7958.1000 to 5.00.7958.1501 however installing UR4 for the Admin Console does not update the version number reported for the console in Programs and Features in Control Panel.

With the Admin Console, because the version number does not change, if the deployment was set to Required, clients would install the update package and would continue to re-evaluate it because it would still be detected as the old version not the UR4 version. What we need to do instead is advertise it to computers with the Admin Console installed and make it available for those users to initiate themselves.

If anyone knows of a different way to target the Admin Console UR4 update, perhaps using the installed Software Update detection I would really like to hear how you have been able to have it automatically installed as Required as that would save a tonne of headache and effort. In the meantime, enjoy your UR4 client rollout. In another post, I will be covering how to update your base client package with UR4 so that newly deployed clients get this updated version hassle free.

Controlling Configuration Manager Clients Across WAN Links

At work this week, we encountered an issue when a package I created for Adobe Reader 10 went mandatory in Configuration Manager. We service retail stores connected via slow WAN links back to our head offices. When I first joined the company, on a monthly basis when new Windows Updates were released into the wild, our network team would come down upon our team, fire wielding whilst we raped and pilaged the lines to stores.

Configuration Manager gives you the power to create BITS (Background Intelligent Transfer Service) policies to throttle the bandwidth that will be consumed by SCCM client transfers for packages and patches, however the problem with Configuration Manager is that it’s policy is not granular, it is singular which means to apply a policy of 32KB/s which we needed to do to facilitate stores, you would also be limiting the speed of head office clients connected to 100 Megabit or 1 Gigabit high speed LAN connections.

Group Policy also gives you the ability to configure BITS throttling policies and in actual fact, Group Policy gives you more options to control the granularity plus the fact that you can link Group Policies to OUs and not just entire domains, or sites, allows us to control the speeds in a more appropriate way.

In a Group Policy Editor window from Group Policy Management Console (GPMC), navigate to Computer Configuration, Administrative Templates, Network, Background Intelligent Transfer Services (BITS). From here, enable the Limit the Maximum Network Bandwidth for BITS Background Transfers setting and configure the speeds and times as you need. You can also configure an out of hours policy which we make use of, limiting the store clients to 32KB/s between 8am and 6pm daily, but allowing them to expand to 256KB/s overnight when the store is closed, not making VoIP calls or trying to transact credit cards.

This worked great and the next time we deployed patches we had no complaints from the stores, but instead, we had a problem at the head office. The problem had not been manifested previously as we had to delay patch deployments before the packages reached everyone, but the issue we experienced now was that due to the length of time a Configuration Manager client was connected to the Distribution Point downloading packages, we were now seeing prolonged connections to the IIS site on the Distribution Point and lots of 64KB/s connections makes lots of bandwidth – We were now actually consuming all of the bandwidth at the head office site, causing inter-site applications between our two head offices to crawl.

We found a solution to this problem in IIS. The solution probably isn’t recommended by Microsoft or any System Center consultants out in the wild, but it works for us and causes no side-effects that we’ve witnessed in the year or so that it has been in place, so it has withstood the test of time.

Using IIS Manager on the Distribution Point server, expand the Default Web Site. From the Actions pane on the right hand side of the interface, select Advanced Settings. From the Advanced Settings dialog, expand the Connection Limits group under the heading Behaviour. By default, IIS accepts a number of connections so large is may as well be infinite. We calculated that based on our free capacity on our link at the head office, taking into account the traffic required for LoB applications, we could handle about 20Mbps of client traffic. We divided the 20Mbps into 64KB/s BITS setting out which gave us a number of 320. Setting the IIS connection limit to 320 and restarting the site in IIS, we saw an instant reduction in Distribution Point server network activity and also the drop we needed on the site link.

As I have mentioned above, this was done over a year ago. In this time, we’ve had not a single complaint from stores, head office users or our network team that there are network contention issues due to SCCM traffic, nor have we seen any apparent SCCM client issues such as clients never properly reporting due to connection retry limits being reached. This isn’t to say that this fix is for everyone: You would need to factor in things like how many total clients do you have in an SCCM site, and if a client was back of the IIS queue, would it be waiting for a connection for so long that it would timeout, or do you need to be able to rapidly deploy high threat updates regardless of the impact to other LoB applications?

Since implanting these changes, we’ve had two Microsoft SCCM RAP assessments and neither have produced red or amber health status problems due to the changes to BITS and IIS, so I think we found ourselves a winner.