Category Archives: SCCM

Troubleshooting SCEP Anti-Malware Policies on Clients.

Today I want to talk about how to troubleshoot System Center Endpoint Protection (SCEP) anti-malware policies on your client PCs.  Since the introduction of SCCM 2012 SP1, a new feature called “Client Side Merge” was introduced.  Basically, if multiple anti-malware policies are targeted to the same collection, the policy with the highest priority wins when there are conflicting settings.

For a quick overview of which policies are being applied, you can open the log at C:\Windows\CCM\Logs\EndpointProtectionAgent.log or you can open the SCEP client, click on the drop down arrow next to the “Help” menu and choose “About”.  This will bring up a window with a list of all policies being applied, however, this will not tell you which one has the highest priority.


SCEP Client:

So, how do you figure out which policies are being applied to the client PCs and which one has the highest priority and its settings are being merged?

Method 1:  Check the Windows Registry

  1. Open regedit.exe on the client PC.
  2. Navigate to the following key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\CCM\EPAgent\LastAppliedPolicy
  3. You will see a list of all anti-malware policies along with all merged settings which are shown with a value of “0x00000002”.  In the screenshot below, you can see that “SWS EP VIP Policy” has all its settings merged into the other two policies.  This is because this policy has the highest priority among the other two policies; causing its settings to be merged with the others.

Method 2:  Command-line Windows Registry query

  1. Open a command-prompt in administrative mode.
  2. Run the following command:
    reg query HKLM\SOFTWARE\Microsoft\CCM\EPAgent\LastAppliedPolicy /f 2 /d
  3. You will see the below output showing the merged settings from the policy with the highest priority:

References:  Niall Brady

Simple ways to test SQL connectivity

While installing Configuration Manager 2012 R2, you may have a problem connecting to the remote SQL server.  Here are some ways you can use to test remote SQL connectivity from your Primary SCCM server:

  1. Telnet to the SQL server’s listening port on 1433.  This approach will require a telnet client.  To install the native telnet client on Windows 7/8.1, run the command "OptionalFeatures.exe" and then place a checkmark next to “Telnet Client” and click on OK.
    To use telnet.exe to connect to the SQL server’s port 1433, open a command prompt and type "telnet.exe <sqlserverhostname_or_ip> 1433".  If connection fails, troubleshoot your SQL server accordingly.  A successful connection will appear as a blank screen:
  2. Create an ODBC System DSN to see if connection is successful.  To add a “System DSN” open the ODBC Data Source Administrator by running the following command "C:\Windows\System32\odbcad32.exe" (64-bit) or "C:\Windows\SysWOW64\odbcad32.exe" (32-bit).  Then click on the “System DSN” tab and click on “Add…”.
    Select “SQL Server” and click on Finish.
    In the “Create a New Data Source to SQL Server” window, name the data source anything you want as we won’t be saving this connection – it’s just a connectivity test.  In the “Server” field enter your SQL server’s hostname or IP.
    Leave the next screen on defaults and continue.
    Again, leave the next screen on defaults and continue.
    The next screen you can also leave on defaults and click on Finish.
    In the configuration summary window, click on “Test Data Source…”.
    If test was successfull, you will see the below message.
  3. Last but not least and probably the less intrusive way of testing SQL connectivity is by use of Universal Data Link files (.UDL).  This method does not require the installation of a telnet client or has as many steps as the “System DSN” method and support for this method is built into every windows version.  You can delete the file afterwards to “clean-up” the system.  Right-click anywhere on your desktop and select “New”, then “Text Document”.
    Name the text document anything but make sure to change the “.TXT” to “.UDL”.  Then double-click on the resulting file.
    Double-click on the .UDL file and type the hostname or IP of your SQL server, then select a user account with permission to the SQL server and select a database.  Then click on “Test Connection”.
    If connectivity test was successful, you will receive the below message:

This isn’t an exhaustive guide to testing SQL connectivity.  Your mileage may vary depending on what the root cause of your connectivity issue, but these steps will certaintly start you off in the right direction.

How to create a collection of computers by installed software.

We’ve all been there, needing to create collections of computers by installed software in SCCM.  Sometimes even needing to list computers that have two or more installed software on them.

So how do you create these collections?  Read on below…

For this example, I am going to create a collection that will list all computers with “iTunes”.  Then I will show you how to add multiple software.

  1. In “Assets and Compliance” go to your Device Collections and right-click and choose “Create Device Collection”.
  2. In the “Create Device Collection Wizard” enter a name for this new collection and you will want to limit the search to either “All Systems” or another collection of your choosing.  I have about 3000 clients in the All Systems collection so I will choose another smaller collection for this example.
  3. In the next screen, click on “Add Rule” and then click on “Query Rule”.
  4. In the “Query Rule Properties”, enter a name for this query, “All computers with iTunes” and then click on “Edit Query Statement..”
  5. In the next window, you’ll want to click on “Show Query Language” and then copy/paste the below code and click on OK:
    inner join
    SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
    SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "iTunes%"
    SMS_G_System_ADD_REMOVE_PROGRAMS.Version like "%" order by SMS_R_System.Name

  6. Once back in the “Query Rule Properties” window, click on OK to close and go back to the “Create Device Collection Wizard” where you can add more direct rules, query rules or include/ exclude collections.  For now, click on Next.
  7. In the Summary step, click on Next.
  8. Once complete, click on Close.
  9. You will notice that the icon for your new collection is refreshing and that your member count will be “0”.
  10. Wait a few moments before right-clicking and selecting “Refresh” or press F5.
  11. All done!

To add additional software to the collection, you can add a separate query to the collection’s properties by modifying the line in the code which specifies the software to search for, but keep in mind this will result in an “OR” operation meaning it will list computers with either one or the other.  If you want an “AND” operation then just modify the search criteria on the existing query:

  1. Right-click on the collection and click on Properties.
  2. In the ‘Membership Rules” tab click on Edit.
  3. You can update the query name in the “Query Rule Properties” window or just click on “Edit Query Statement…”
  4. Click on the “Criteria” tab and then select the toolbar button which looks like a yellow star.
  5. Choose the “Installed Applications” attribute class and the “Display Name” attribute and then click on OK.
  6. Change the operator to “is like” and then type the software title in the “Value” input box and make sure to include the wildcard “%” (not required if you want a specific title and are sure of the spelling).
  7. You will notice that the new software title has been added with an “AND” operator.  You can also change the operator to an “OR” using the button second from last which reads “&|”.  Click on OK.
  8. Back at the “Query Rules Properties” click on OK to close this window and then click on “Apply” or “OK” in the collection properties window to save the new changes.
  9. Again wait a few minutes before refreshing and it should update the collection membership as long as it finds the specified software on other computers.

Downgrade/ Replace Microsoft Office 2013 Professional Plus to Standard

This post will address the second requirement mentioned in my previous post.  In summary, we detected unauthorized installations of Microsoft Office 2013 Professional Plus and now we need to uninstall and replace these rogue installations with the Standard version.

For this tutorial, I am going to assume you already know how to create collections and work with queries as well as task sequences.

I am also only going to focus on the MSDN media types, but you can adapt the steps for the Retail versions by substituting the MSI’s for Retail instead of using the MSDN ones.


We need to create a collection of all the computers that currently have Professional Plus installed.  We will then script out a task sequence to uninstall Professional Plus (MSDN and Retail) and install Standard in one motion because if we run the uninstall separately, the computers will drop off the collection as they are being uninstalled.

This is because we will create the collection using a query instead of direct memberships since the latter will take forever to input, not to mention, I find it very difficult to maintain.

Create a collection and add the following query:

inner join
SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId
SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like "Microsoft Office Professional Plus 2013%"
SMS_G_System_ADD_REMOVE_PROGRAMS.Version like "%" order by SMS_R_System.Name

That’s it for this step.


Create a XML file named “SilentUninstallConfig.xml” and save it in your “[Product Code].ww” folder in the root of your installation source files. The contents of SilentUninstallConfig.xml is below:

<Configuration Product="Standard">
<Display Level="none" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" />

Task Sequence

We will now create a task sequence which will be advertised to the above collection.

  1. In the Administrator Console, go to your task sequences and right click and create a new custom task sequence.
  2. Make sure to name the task sequence something descriptive, mine is “Microsoft Office 2013 Standard”.  Then click Next all the way until the task sequence is created.
  3. Right-click and Edit the newly created task sequence.
  4. Create two folders for organizational purposes.  The first folder will group the uninstall commands for Professional Plus.  The second folder will group the install commands for Standard.  For the uninstall group command lines, you will need to have access to each media type that you want to target because you will need to import each respective MSI as a condition to each step.
  5. In the uninstall group, we will add the first step to detect and uninstall the MSDN version of Professional Plus x64.  Add a “Run Command Line” with the following command:
    cmd.exe /c \\[Path to ProPlus installation source]\x64\setup.exe /uninstall ProPlus /config \\[Path to ProPlus installation source]\x64\proplus.ww\SilentUninstallConfig.xml
    If you’re using Retail media the “ProPlus” must be substituted with “ProPlusr”.
    Add a “Run As” account that has at least ‘Read” permission to the installation source files because task sequences run as the “Local System” account and will not have access to the network share.
    In the “Options” tab, click on “Add condition” and click on “Operating System Version”:
    Again in the “Options” tab, click on “Add condition” and then click on “Installed Software”.  You will now need to browse to the installation source files and import the MSI inside the “ProPlus.ww” folder:
    When finished, the conditions for this step should look like this:
  6. If you want to detect and uninstall the x86 version of Professional Plus, repeat step 5 and use the following command:
    cmd.exe /c \\[Path to ProPlus installation source]\x86\setup.exe /uninstall ProPlus /config \\[Path to ProPlus installation source]\x86\proplus.ww\SilentUninstallConfig.xml
    Again, if you’re using Retail media the “ProPlus” must be substituted with “ProPlusr”.
    For the x86 version you only need to add one condition because the x86 version can also be installed in x64 operating systems.  Add the “Installed Software” condition and import the x86 MSI.
    When finished, the ‘Options” tab should look like the following:
  7. For the Retail versions, repeat steps 5 and 6.  The only thing that changes is you have to import the specific MSI for the retail versions.  You don’t need to point the command lines to each Retail’s media setup.exe.  The ProPlus setup.exe is sufficient, but you will need to change the “ProPlus” to “ProPlusr” in each command line right after the “/uninstall”.
  8. Once finished with the uninstall commands, let’s turn our attention to the install group.  Add a “Install Application” step and select the Microsoft Office 2013 Standard application we created in the previous post.  This step does not need conditions because it will install on both x86 and x64 architectures.
  9. Optional:  In my organization, we have a problem with Windows 8.1 systems which are unable to read the SRV records for our KMS in our local DNS.  Therefore, Microsoft Office 2013 Standard installs but doesn’t activate.  We can add two “Run Command Line” steps to manually point each installation to the KMS server and activate against it.
    The first command line is meant to activate Standard x86 on a 64-bit Operating System.  It is composed of the following command line:
    cmd.exe /c cscript.exe "%ProgramFiles(x86)%\Microsoft Office\Office15\ospp.vbs" /sethst:[FQDN of KMS Server] & cscript.exe "%ProgramFiles(x86)%\Microsoft Office\Office15\ospp.vbs" /setprt:[Port number; default is 1688] & cscript.exe "%ProgramFiles(x86)%\Microsoft Office\Office15\ospp.vbs" /act
    It has the following conditions, “Operating System” is set to “All Windows 8 64-bit” or “All Windows 8.1 64-bit” and Registry Key “HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{90150000-0012-0000-1000-0000000FF1CE}” with value “DisplayName” exists.

    The second command line is meant to activate Standard x86 on a 32-bit Operating System.  It is composed of the following command line:
    cmd.exe /c cscript.exe "%ProgramFiles%\Microsoft Office\Office15\ospp.vbs" /sethst:[FQDN of KMS Server] & cscript.exe "%ProgramFiles%\Microsoft Office\Office15\ospp.vbs" /setprt:[Port number; default is 1688] & cscript.exe "%ProgramFiles%\Microsoft Office\Office15\ospp.vbs" /act
    It has the following conditions, “Operating System” is set to “All Windows 8 32-bit” or “All Windows 8.1 32-bit” and Registry Key “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{90150000-0012-0000-1000-0000000FF1CE}” with value “DisplayName” exists.

Once complete, deploy the task sequence to the above created collection and it should uninstall Microsoft Office 2013 Professional Plus and install Microsoft Office 2013 Standard x86.

Deploying Microsoft Office 2013 with SCCM 2012 R2

We recently decided to roll out Microsoft Office 2013 Standard x86 across the enterprise.  As part of this deployment, there were some unauthorized copies of Office 2013 Professional Plus x86/x64 that needed to be uninstalled and replaced with the Standard x86 version.  The solution to this second requirement will be addressed in a separate post.

Microsoft Office Customization Tool 2013

In order to deploy Microsoft Office 2013 Pro/ Standard, you must run the the Office Customization Tool (OCT) in order to create an MSP file which is saved to the “.\Updates” folder in your installation source files.  Please note these generated MSP files are architecture dependent and are not interchangeable.  You will need to run the OCT tool for the specified target architecture type for either x86 or x64.

To run the OCT, open a command line and browse to your installation source directory and type:

setup.exe /admin

  1. The following window will appear, go ahead and enter your organization’s name in the following screen:
  2. Under the “Licensing and user interface” go ahead and choose to use the KMS option if that is your environment, otherwise, go ahead and enter a MAK in the space provided:
  3. In the “Modify Setup properties” add the setup property AUTO_ACTIVATE with a value of 1. This will automatically activate against your KMS or Microsoft if using a MAK during the installation of Office 2013:
  4. Last but not least, under “Modify user settings”, make sure to turn off the “Opt-in wizard” (the prompt to join Microsoft Update on first start) and the “First run” introduction screens. The first is located under Microsoft Office 2013, Privacy, Trust Center and the latter is located under Microsoft Office 2013, First Run:
  5. Optionally, you can configure what Office applications are installed in the “Set feature installation states” section:
  6. Once finished, you can then click on File, Save and save the resulting MSP file with any name you choose under the “Updates” folder.  Setup automatically searches this folder for an existing MSP file, if it cannot find one, it will then proceed with a full installation:OCT7

XML Configuration Files

Next up, you will need to create two XML files, one to suppress the reboot and the other is optional but strongly advised to configure a silent uninstallation.

The first XML file will be named “Config.xml” and goes into the root folder of your installation source files where setup.exe resides. The contents of config.xml is below:

<Configuration Product="Standard">
<Display Level="none" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" />
<Setting Id="SETUP_REBOOT" Value="Never" />
<Setting Id="REBOOT" Value="ReallySuppress"/>
<Setting Id="AUTO_ACTIVATE" Value="1" />

If using the Professional Plus MSDN media the “Configuration Product” is “ProPlus” and if using the Retail media it will be “ProPlusr”.

The second XML file will be named “SilentUninstallConfig.xml” and goes into your “[Product Code].ww” folder in the root of your installation source files. The contents of SilentUninstallConfig.xml is below:

<Configuration Product="Standard">
<Display Level="none" CompletionNotice="no" SuppressModal="yes" AcceptEula="yes" />

Again, it goes without saying to update the “Configuration Product” value accordingly.

Create Application Wizard & Program

Now that we have all the required files and configured for our specific business needs, we can proceed to create the application in SCCM.

  1. Right click and create an Application. Then select [Product Code].ww.MSI in your [Product Code].ww folder in your installation source directory then click on Next:
  2. Verify the imported MSI information and then click on Next:
  3. The application will be created and you will be given an opportunity to change some general information about the application.  Go ahead and change the “Installation program” command line to “setup.exe” (we only used the MSI option to import some information and save us some time). My application is 32-bit so I checked off the “Run installation program as 32-bit process on 64-bit clients.” and also, since I plan to use my application in a task sequence sometime down the road, I changed the “Install behavior” to “Install for system if resource is device; otherwise install for user.” Then click on Next:
  4. You will be given confirmation that the create application wizard completed successfully. Click on Close:
  5. Now you can look for your application in the application list and right click and select Properties.
  6. I also want to use this application in a task sequence so check off the “Allow this application to be installed…” checkbox and optionally fill out the “Publisher” and “Software version” fields. For the version number, I opened regedit.exe on a test machine with Office 2013 Standard x86 installed and browsed out to “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{90150000-0012-0000-1000-0000000FF1CE}” (See References for a list of Product Codes) and copied the value of “DisplayVersion”.  You will need this information later.  My test OS is Windows 7 x64 so I had to look under the “Wow6432Node”, if you have an x86 test OS, you won’t have this node, instead from SOFTWARE, continue onto Microsoft, etc…:
  7. In the Deployment Types tab, select a deployment and click on Edit:
  8. Change the “Content location” to the root of your installation source directory:
  9. In the “Programs” tab, verify that the program states “setup.exe” and modify the “Uninstall program” with a “/qn /norestart” switches.  The checkbox is optional but mine is checked because it is a 32-bit application.  In the product code, browse and select the MSI you used to add the application’s product code to this box or type it in manually:
  10. Under “Detection Method” click on the existing method and then click on “Edit Clause…”:
  11. Verify that the “Product code” matches the MSI product code.  Then optionally modify the radio button to specifically check for any version “Greater than or equal to”  the value you copied from step 6 which is currently “15.0.4420.1017”:
  12. In “User Experience”, verify the options are set according to the below screenshot:
  13. You can optionally add any requirements.  This is useful if you are creating one application with a two deployment types, either 64-bit or 32-bit.  You can specify to install to a particular architecture type depending on your target architecture.  Then click on OK:
  14. Click on OK to close the Properties window:

Distribution Points

Now that we have finished creating the application, we must now distribute it to individual distribution points or distribution point groups.  In a production scenario, I would distribute to the “All Content” group but for testing purposes, we can distribute the application to our local distribution point.

  1. With your application selected, click on the “Distribute Content” ribbon bar button:
  2. In the “Distribute Content Wizard” window, click on Next:
  3. Add an individual distribution point(s) or group to distribute to then click on Next:
  4. Confirm the settings by clicking on Next:
  5. Once finished, click on Close:

Deployment to Collection(s)

Once our content has been distributed to the selected distribution point(s) or groups, we can now deploy our application to a collection.  It is strongly advised to setup a test collection with a direct user rule prior to deploying this application in a production environment.

  1. Again, in the ribbon bar, click on Deploy:
  2. Choose a collection to deploy to in the “Deploy Software Wizard” window and then click on Next:
  3. You can optionally add more distribution points to deploy this application to, I usually leave this blank and click on Next:
  4. Verify that the “Action” states “Install” and choose either “Available” (installed via the Application Catalog and is user initiated) or “Required” (mandatory automatic installation).  If you choose “Required” you will need to choose an assignment on the next screen.  Our organization’s requirement allows us to choose “Available” for this deployment:
  5. If you need to schedule this deployment, choose a start time in UTC and then click on Next:
  6. Leave all settings at default and click on Next:
  7. Leave all settings at default and click on Next:
  8. Confirm the deployment settings by clicking on Next:
  9. When finished, click on Close:

Testing the Deployment

Now that all the pieces for a successful Microsoft Office 2013 deployment are in place.  We can now test out the application deployment.  We can either wait for our test client to receive its updated policies automatically or we can force the client to look for new policies.

  1. In the test client’s Control Panel, click on the “Configuration Manager” applet and then go to the “Actions” tab.  I usually force the updates by running the machine policy cycle followed by the user policy cycle and finally the application deployment cycle.  You initiate these by clicking on each respective cycle and clicking on the “Run Now” button:
  2. Now open the “Software Center” from your start menu and in the upper right corner, click on the hyperlink “Find additional applications from the Application Catalog”.  You will need to do this if you deployed the application as “Available” otherwise, you’re done after the previous step:
  3.  You should see the application listed in the Application Catalog, if it’s not, go back and double check your deployment settings or refresh the client policies using the procedure in step 1,  If it’s listed, selected and go ahead and click on Install:
  4. Confirm the installation by clicking on Yes:
  5. Once the application installation has started, you can close this window:
  6. Open the “Software Center” from your start menu and under “Installation Status” you should see the progress of the installation:
  7. When complete, you will see the confirmation window below:
  8. Now open Microsoft Word 2013 from your start menu, it should open directly to the templates view and not ask about activation.  Click on File and then Account and verify that the product activated successfully:


The following MSI product codes should help you differentiate which version of Microsoft Office 2013 media you have.

MSDN Media

Microsoft Office 2013 Standard x86 (Standard)

Microsoft Office 2013 Standard x64 (Standard)

Microsoft Office 2013 Professional Plus x86 (ProPlus)

Microsoft Office 2013 Professional Plus x64 (ProPlus)

Retail Media

Microsoft Office 2013 Standard x86 (Standardr)

Microsoft Office 2013 Standard x64 (Standardr)

Microsoft Office 2013 Professional Plus x86 (ProPlusr)

Microsoft Office 2013 Professional Plus x64 (ProPlusr)

Next Steps

Want to learn how to put SilentUninstallConfig.xml to good use and downgrade/ replace your existing rogue Microsoft Office 2013 Professional Plus installations?

Continue reading in this post.

Install Windows hotfixes (.MSU) during OS deployment using MDT/SCCM2012.

Recently, our local desktop support team came to me with an issue they had discovered in the image that is deployed via SCCM.  The issue was that when they attempted to “Turn Windows features on or off”, the dialog box shown was blank.  They had assumed that deploying the image via SCCM was somehow disabling this dialog box.


While troubleshooting this issue, I had discovered that Microsoft was aware of this issue and they had created KB931712 in order to fix this.  However, this did not work for me.  Another MSDN post recommended to run the System Update Readiness Tool (SURT) in order to fix any Windows Update corruption.  Again, this did not work for me either.

I started to dig deeper into this issue and found that SURT creates a log file of anything it finds.  The log file is located at C:\Windows\Logs\CBS\CheckSUR.log.  For help with reading the log file, I found this very good tutorial.

Here is the content of the log file:

Checking System Update Readiness.
Binary Version 6.1.7601.21645
Package Version 19.0
2013-12-18 15:57

Checking Windows Servicing Packages

Checking Package Manifests and Catalogs
(w) CBS Catalog Expired 0x800B0101 servicing\Packages\

Checking Package Watchlist

Checking Component Watchlist

Checking Packages

Checking Component Store

Seconds executed: 1424
 No errors detected
 CSI Catalog Expired Total count: 0
 CBS Catalog Expired Total count: 1

Even though no errors were detected, I found that update KB2722913 had an expired catalog file.  I then opened the properties to the referenced catalog file in C:\Windows\servicing\Packages and sure enough, under the “Digital Signatures” tab, the certificate that was used to sign the catalog file had expired as of 06/27/2013.  This expired certificate was preventing the Windows features from being displayed in the dialog box.


To workaround this issue, we could have just uninstalled the affected Windows update(s), but this approach does not address the root cause.  Instead, Microsoft has released KB2749655 in order to resolve this issue.  There are several ways we could use to deploy the hotfix via SCCM, for example, we could create a package with the MSU and create a program to install it using the following command:

wusa.exe Windows6.1-KB2749655-x64.msu /quiet /norestart

Similarly, you can follow this post which uses a VBScript to install multiple hotfixes to a collection.  However, I’m only interested in deploying the hotfix with an OS deployment.  In order to accomplish this we will leverage the power of an MDT/ SCCM 2012 integrated task sequence in order to apply the Windows hotfix (.msu file) to an image right after deployment.  The Powershell script and idea came from the following post at “The Knack” but I found I had to add a “Restart Computer” action to the task sequence in order to allow the hotfix to fully install.

Powershell Script (ApplyHotfixes.ps1):

$scriptPath = split-path -parent $MyInvocation.MyCommand.Definition
$folder = $scriptPath += "\hotfix"
$total = gci $folder *.msu | measure | Select-Object -expand Count
$i = 0
gci $folder *.msu | foreach {
        WUSA ""$_.FullName /quiet /norestart""
        while(get-process wusa -ErrorAction SilentlyContinue)
        {Write-Progress -activity "Applying Windows Hotfixes" -status "Installing $_ .. $i of $total" -percentComplete (($i / $total) * 100)}
        Write-Progress -activity "Applying Windows Hotfixes" -status "Installed $_ .. $i of $total" -percentComplete (($i / $total) * 100)
  1. Make a folder in your SCCM software repository and put the Powershell script along with a subfolder named “Hotfix”.  Inside the subfolder, place the .MSU files you would like to install.12-18-2013 10-10-39 PM
  2. Create a package out of the previously created folder and do not create a program.  Don’t forget to distribute the package to your distribution points.12-18-2013 10-14-12 PM
  3. Add a folder at the end of your OSD task sequence to group the MDT actions together.  The add the below MDT actions.12-18-2013 10-17-48 PM
  4. In the “Use Toolkit Package” action, select your MDT 2012 package.12-18-2013 10-19-07 PM
  5. In the “Gather” action, select your MDT CustomSettings.ini package.12-18-2013 10-19-21 PM
  6. In the “Run PowerShell Script” action, select the package we created with the script and if you named the script “ApplyHotfixes.ps1”, type its name in the space provided.12-18-2013 10-19-34 PM
  7. Last but not least, add a standard “Restart Computer” action to allow the MSU installation to finish.  Make sure the “Default Operating System” is selected or else it will boot back into the task sequence.12-18-2013 10-19-44 PM

This is all that is needed to get this working folks!  The powershell script will continue to recurse the directory until all .MSU files are installed and upon booting into Windows, you should be able to view the install updates under “Programs and Features” in Control Panel.

In the context of my particular issue, we were able to deploy the OS image, install KB2749655 and upon booting into Windows, the “Turn Windows features on or off” dialog box looked like this:

12-18-2013 10-32-22 PM

Support all Dell desktop and laptop drivers in your OS deployment!

Dell maintains an active online community of professionals on their TechCenter wiki.  To make SCCM driver management easier, Dell Support has released several CAB files with all supported drivers for a particular Dell model.

However, the community on the TechCenter wiki took this approach further – they released a driver pack zip file with all related drivers for a particular chassis type!  In other words, we can now choose to download one driver pack for all laptops or another driver pack for all desktops!

Head on to and scroll all the way to bottom of the page to where it reads “Combo CAB Availability” pick your device and download away!

When integrating this driver pack for Dell desktop models for example, you should use an “Any If” statement with the following WMI queries to scope out the driver pack for both Dell desktop families: Optiplex and Precision workstations.

12-9-2013 3-14-57 PM

select * from Win32_ComputerSystem where Model like 'Optiplex %'
select * from Win32_ComputerSystem where Model like 'Precision [^M]%'