Category Archives: Tutorials

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.

Manage Microsoft Office 2013 volume licensing via command-line.

Microsoft Office 2013 ships with a great utility to manage volume licensing in the form of VBScript.  You can use it to manage volume licensing for the local computer or even a remote computer; provided you enter credentials with administrative access to the remote system.

This VBScript is called OSPP.VBS and is located here:

%ProgramFiles%\Microsoft Office\Office15\OSPP.VBS

To run this file, open a command prompt in administrator mode and change directory to the above path.

Some common switches I use are below:

  • Activating a license
    cscript.exe ospp.vbs /act
  • Resetting a license
    cscript.exe ospp.vbs /rearm
  • Status of a license
    cscript.exe ospp.vbs /dstatus
  • Input a new key
    cscript.exe ospp.vbs /inpkey:<KMS/MAK volume key>
  • Removing a license (You need to get the last 5 characters of the license to be removed via /dstatus)
    cscript.exe ospp.vbs /unpkey:<last 5 of volume license to be removed>
  • Manually set KMS host
    cscript.exe ospp.vbs /sethst:<FQDN of KMS host>
  • Manually set KMS host port
    cscript.exe ospp.vbs /setprt:<port - 1688 is default>
  • Manually configure DNS domain in which KMS SRV records are found
    cscript.exe ospp.vbs /skms-domain:<FQDN>
  • Of course if you need help, you can always display the full switch list by running
    cscript.exe ospp.vbs

You can also combine several commands into one continuous command to achieve several actions.  For example, to manually configure a KMS host, port and activate, use the following command:

cscript.exe ospp.vbs / & cscript.exe ospp.vbs /setprt:1688 & cscript.exe ospp.vbs /act


Also, here is a link to the KMS client setup keys for VL Office activations.  I hope this aids you with replacing and deleting volume licensing without having to reinstall the entire Microsoft Office Suite.

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

Create a WinPE 4.0 USB Flash Drive or ISO using Windows ADK

Now that the Windows ADK for Windows 8 (WADK) superseded the old Windows AIK, the procedure to create a Windows PE image has slightly changed.  In my opinion, it has greatly improved as Microsoft has now included a simple command-line utility that is capable of creating both ISO and USB flash drives.  The name of this utility is MakeWinPEMedia.cmd, and once the WADK is installed, you can find this utility here:

C:\Program Files (x86)\Windows Kits\8.0\Assessment and Deployment Kit\Windows Preinstallation Environment\MakeWinPEMedia.cmd

OK, so how do you create a WinPE 4.0 image?  Let’s read ahead!

  1. You will need to download and install Windows ADK for Windows 8.  The installation is as simple as running the adksetup.exe executable and making sure to check off the Windows Pre-installation Environment option.
    11-2-2013 8-34-35 PM
  2. Once installed, click on Start, All Programs, Windows Kits, Windows ADK, Deployment and Imaging Tools Environment.
  3. Type the following commands depending on what hardware architecture you need:
    WinPE x86
    copype.cmd x86 C:\WinPE_x86
    WinPE x64
    copype.cmd amd64 C:\WinPE_x64
  4. Once the files are copied, you can optionally mount the boot.wim.  You would want to do this in order to integrate mass storage, USB and ethernet hardware drivers and/or scripts.
    ImageX.exe /Mountrw C:\WinPE_x86\media\sources\boot.wim 1 C:\WinPE_x86\mount

    For hardware drivers integration, I like to use DISM GUI, a graphical user interface to the excellent command-line utility, DISM.EXE.  Though it has no documentation yet, the interface is pretty intuitive.  In a nutshell, you choose the WIM file and mount location, then go to the Driver Management tab and choose a directory of drivers to integrate.

    For utility and/ or scripts, I always add GImageX, which is a graphical user interface for IMAGEX.EXE command-line utility.  When adding this utility, the original Microsoft ImageX.exe executable is not needed, only the GImageX.exe executable is required.  Also, please make sure to add this to the “C:\WinPE_x86\mount\Windows\System32” directory.

  5. Once your changes to the WIM are complete, you will need to dismount and commit all changes:
    ImageX.exe /Unmount /Commit C:\WinPE_x86\mount
  6. Now we can build out our WinPE image depending on our target, USB or ISO image:
    ISO Image
    MakeWinPEMedia.cmd /ISO C:\WinPE_x86 C:\WinPE_x86\WinPE_x86.ISO
    USB Flash Drive
    MakeWinPEMedia.cmd /UFD /F C:\WinPE_x86 G:

I hope you have enjoyed this tutorial as much as I have enjoyed making it for you.  If you have any questions, please comment.  Thank you in advance.

Capturing task sequence log files during OSD deployment.

This idea grew out of the need to troubleshoot certain task sequence errors.  Usually when your task sequence throws an error, the code will be displayed for an X amount of time after which the machine reboots.  Retrieving the SMSTS.LOG file is somewhat cumbersome, as the exact location of the file varies depending on which phase of the OSD the machine is in:

WinPE, Before HD Format x:\windows\temp\smstslog\smsts.log
WinPE, After HD Format x:\smstslog\smsts.log
Windows, No SCCM Client Installed c:\_SMSTaskSequence\Logs\Smstslog\smsts.log
Windows x86, SCCM Client Installed c:\windows\system32\ccm\logs\Smstslog\smsts.log
Windows x64, SCCM Client Installed c:\windows\sysWOW64\ccm\logs\Smstslog\smsts.log
Task Sequence Completed x86 c:\windows\system32\ccm\logs\smsts.log
Task Sequence Completed x64 c:\windows\sysWOW64\ccm\logs\smsts.log

An easier way to gather these logs is to take advantage of a Task Sequence Variable within the OSD deployment.  Whenever the task sequence finishes either successfully or not, the TS variable “_SMSTSLastActionSucceeded” returns a true or false value.  We can then leverage this variable to create a step in the task sequence to run only if the return value is false and then further run some steps to map a network drive and copy the logs over.  I was lucky to find an old post by Steve Rachui, a Microsoft Premier Field Engineer which helped saved me time brainstorming a solution.  However, my implementation makes use of the %OSDComputerName% variable and displays a custom error message in order to prevent WinPE from rebooting after clearing the countdown.

Below are the steps I took:

  1. Created a network share and allowed “Everyone” full access permission.  You can restrict this share to a specified AD account if you wish but you will then need to specify the account in the steps below.  I named my network share “TSLogCapture”.
  2. In the root of your task sequence, create a new group named “Task Sequence” and move all the steps as a subfolder to this new group.  In the Options tab, make sure the “Continue on error” box is checked.  The idea is to have all the steps grouped and if there is an error, pass control to the next group which will copy the logs to a share.10-31-2013 3-25-10 PM
  3. Also in the root of your task sequence, create another group named “Log Capture”.  In the Options tab add a condition to run when the task sequence variable “_SMSTSLastActionSucceeded” equals “False”.11-1-2013 8-25-52 PM
  4. We will need to add the above displayed steps to the “Log Capture” folder.  To add the first step, go to Add, General, Connect to Network Folder.11-1-2013 8-31-56 PM 

    In the Properties tab, you will need to specify a Path, Drive Letter and Account to connect and map the network share.  If you restricted the network share to a specific AD account, input that account here.  Also, please note I chose the “Z:” drive letter, therefore, all my command line entries reflect this drive letter.  If you choose a different drive letter, please update any subsequent command lines with this new drive letter.11-1-2013 8-35-04 PM

  5. Now we will need to add “Run Command Line” steps to the “Log Capture” folder.  To add this step, go to Add, General, Run Command Line.  This step will remove any pre-existing folders for that machine name you are currently using from the network share.  Its purpose is to prevent duplicate log files.11-1-2013 8-43-32 PM 

    In the Properties tab, type the following:11-1-2013 8-45-53 PM

    cmd.exe /c rd /s /q z:\%OSDComputerName%
  6. Add another “Run Command Line” step.  This step will create a folder named after the computer name in the TS variable %OSDComputerName% (a friendly name of your choosing).  You can also use %_SMSTSMachineName% which will name the folder after the random “MiniNT-12345” name if the error occurs in WinPE or after the actual AD computer name if the error happens in Windows.11-1-2013 9-00-26 PM
    cmd.exe /c md z:\%OSDComputerName%
  7. Add another “Run Command Line” step.  This step will copy the log files from the path contained within the %_SMSTSLogPath% variable to machine named folder in the network share.11-1-2013 9-03-58 PM
    cmd.exe /c copy %_SMSTSLogPath%\*.* z:\%OSDComputerName%


This last step is entirely optional.  I use it to display a custom error message using VBScript in order to prevent the error countdown from starting and rebooting the machine.  To add this step, you will need to create a Package out of one file, ErrorPrompt.vbs.  To create this file, open Notepad.exe and copy/ paste the following and update the path to your network share:

WScript.Echo "There was an error in the task sequence." & VbCrLf & VbCrLf & "Please review the log files stored at:  [Your Network Share Path Here]"

Next, save the VBScript file in a folder in your SCCM package repository and create a package using the SCCM Administration Console:

11-1-2013 9-24-09 PM

11-1-2013 9-27-54 PM

11-1-2013 9-34-38 PM

Click on “Next” all the way until the package is created.  Once complete, you will need to distribute it to your distribution points or groups.

11-1-2013 9-38-28 PM

11-1-2013 9-39-38 PM

10-31-2013 4-11-36 PM

10-31-2013 4-12-13 PM

Once again, click “Next” until you finish distributing the package.  You will need to watch the “Content Status” pane in the package information section to verify that the package was distributed successfully.

10-31-2013 4-12-56 PM 10-31-2013 4-13-49 PM

Now that you have created your package and have it distributed to your distribution points.  You may proceed creating that last “Run Command Line” step in your task sequence.  In the Properties tab, insert the following command line and don’t forget to specify the package we created:

11-1-2013 9-08-06 PM

cmd.exe /c wscript.exe errorprompt.vbs

Phew!  We are finally done!  Give yourself a good pat on the back because from now on, whenever your task sequence encounters an error, you will see the following:

11-1-2013 10-01-52 PM