Quick Fix: Get-MDTComputer by Description Broken in the MDT PowerShell Module

The short story:

Launch SQL Server Management Studio, expand the MDT database > Views > right-click on dbo.ComputerSettings and click on “Design”, tick the “Description” column in the CI table in the View.

The long story:

During my experiments with using PowerShell to automate Windows imaging and deployment tasks I’ve been working with the MDT database module, provided by Michael Niehaus from Microsoft.

I was disappointed to find the Get-MDTComputer cmdlet is broken somewhat, as in you can’t retrieve a computer record from the database matching a description. This is what the error message says when you try:


I thought I’d take a look at the Get-MDTComputer function in the PowerShell module and saw that the function was doing nothing more than building a SQL statement and querying the MDT database. Specifically, it was querying the “ComputerSettings” table as shown below:


This, along with the error message we saw earlier mentioning “Invalid column name ‘Description'”, led me to fire up the SQL Server Management Studio to examine the “ComputerSettings” table, only to find there isn’t a table with that name but there was a “View” called “ComputerSettings”.

I right-clicked the “ComputerSettings” View and selected “Design” and immediately saw what the issue was here. It was apparent that the problem was that the “ComputerSettings” View didn’t include the “Description” column from the ComputerIdentity table.

So the solution is to tick the checkbox next to the “Description” column in the CI table in the View:



And here you can see the Get-MDTComputer cmdlet working with the –Description parameter:


Capturing the Reference Windows 10 Image using MDT 2013 Update 2

This is the second of a three-part series on Windows 10 OSD using MDT and SCCM.

Recap: In the first post we populated our MDT deployment share and then created and ran a task sequence to install Windows 10 on a virtual machine along with our applications and the .NET Framework 3.5 enabled. We left the post at the point of having a Windows 10 installation which we can brand as our own and customize the default user profile.

Here, we’re going to pick up from where we left off – I’m going to assume you’ve done all the customization to your liking and thus effectively turning the Windows 10 virtual machine into a reference machine. We’ll create a task sequence to sysprep and capture an image of our virtual machine which will give us our “Reference Windows 10 Image”. We’ll also create the unattend.xml file in this post which we’ll need in the next post. Ok, let’s get started.

Step 1) Create Task Sequence to Capture the Windows 10 Reference Image Continue reading

Building a Reference Windows 10 Image Using MDT 2013 Update 2

This is the first of a three-part series on Windows 10 OSD using MDT and SCCM.

I’m using the Windows 10 Enterprise 64-bit 1511 ISO and MDT 2013 Update 2 for this post. I’m going to assume you already have your MDT build environment up and running and have access to the Windows 10 installation ISO as well as any applications you wish to add to your reference image.

Here’s a quick overview of how this will work:

  • We’ll start off with a blank/vanilla Windows 10 ISO which we’ll import into MDT
  • We’ll also add our applications to MDT
  • We’ll then create a task sequence instructing it to first install this blank/vanilla Windows 10 and then install our applications and also enable .NET Framework 3.5 feature
  • We then run this task sequence on a virtual machine which will leave us with a Windows 10 installation (with our applications installed and .NET Framework 3.5 enabled)
  • We customize Windows, customize the default user profile and effectively turn it into a Reference Virtual Machine

(The next post will cover creating a task sequence to capture this reference machine image and creating an unattend.xml answer file. Running this task sequence on the Reference Virtual Machine will capture an image of our customized Windows 10 and leave us with a “Reference Windows 10 Image”. The final post in the series will cover using SCCM to deploy our “Reference Image” onto a computer)

Step 1) Populating the MDT Deployment Share

Before we can build our reference image we need to populate our deployment share in MDT by importing the Windows 10 media and adding applications.  Continue reading

Deploying Windows 7 in Audit Mode using MDT 2012

It’s interesting that MDT 2010/12 doesn’t have a native way of deploying Windows 7 in Audit Mode, especially when Audit Mode is often the starting place to building Windows 7 reference or master images.

With no way to do this natively using MDT one would have to do this manually, either by running Sysprep post-install or booting into Audit Mode during the Windows Welcome stage when installing the OS (by hitting Ctrl+Shift+F3).

I have a healthy curiosity when it comes to these things which is exactly what led me to experiment on how Windows 7 could be deployed straight into Audit Mode using MDT 2012 in my Lab. I thought the challenge at hand was quite interesting and I think I may have found a workable solution.

My first few attempts were to edit the Task Sequence’s Unattend.xml answer file to run a Sysprep command. I tried adding synchronous commands in the Specialize pass to run Sysprep with the /audit switch to boot into Audit Mode but that didn’t work out very well.

I then turned my attention to the Task Sequence steps. As with my previous attempts, I knew the only way to get this to work would be to run Sysprep, but the trick was to work out where in the Task Sequence to add the Run Command Line step.

Anyway, here’s how I done this on MDT 2012:

  • Created a new Standard Client Task Sequence to deploy the Windows 7 DVD image (I already had the image imported in my deployment share)
  • Disable all the steps under State Restore in the Task Sequence properties
  • Add a Run Command Line step as a last step under PostInstall
  • Add the following command in the Command line field

sysprep.exe /generalize /audit /reboot in the

  • Add the following directory path in the Start in field


The Task Sequence steps  should look like this:


If you have your Customerttings.ini file configured to hide the Deployment Wizard panes and provide all the answers to the wizard then executing this Task Sequence to deploy Windows 7 and booting into Audit Mode should be fully automated.

There is, however, one minor hiccup to this ‘solution’. Right at the end when Windows 7 is booted into Audit Mode a message pops up saying there is a deployment in progress but is not in an expected state.


It asks if you would like to ignore this in-progress deployment. It is important that you click on Yes on this pop up message.

Although I haven’t found a way of suppressing this message yet, I have used the Task Sequence above to build reference images for testing purposes and it’s worked fine without any problems.

I understand this needs to be tested more thoroughly in a working environment and hope someone, somewhere will find this a useful starting point to take this further with some proper testing.

Using the MDT Database

I turned to the MDT database when I needed greater control over the customizations I wanted to make to my target computers, like setting the hostname, IP address, screen resolution, etc. As it turned out, the MDT database is designed for just that. It’s also a more flexible solution compared to using the Customsettings.ini file for the more complex customizations.

With the MDT database you can apply different customizations for different group of computers based on the computer’s hardware such as Mac address, its physical location, or manufacturer and model. In this post we’ll first take a look at how to apply customizations to specific computers (by identifying them using their Mac address or UUID) and also to a group of computers by identifying them by their manufacturer and model.

Applying customizations to specific, individual computers

If you wanted to apply customizations to specific computers in your environment, you need to create a Computer record in your MDT database and specify one of the following to uniquely identify the computers in question:

  • Asset tag
  • Serial number
  • Mac address
  • UUID

You can obtain this information from your target computer’s BIOS. A Mac address generally works well unless the target computer has two NIC’s, in which case you will need to identify the computer using one of the other uniquely identifiers listed above. For the uninitiated, a UUID is a set of 36 hexadecimal characters collectively known as a Universal Unique Identifier used to unique identify a computer.

Here’s how this works. The first thing to do is to create a Computer record in your MDT database. Launch Deployment Workbench, expand the deployment share and navigate to and expand Database in the navigation pane.


Right-click on Computer and select New, and you will see the following Properties window.


Enter your choice of unique identifier along with a description of this particular computer in the Identity tab. Mac addresses must be separated by colons and UUID’s must be entered in the exact format.

The customization settings are entered in the Details tab. If you wanted to give this particular computer a unique hostname, for example, look for the OSDComputer settings under Identification and enter a hostname in the adjacent field.


Any customization settings you enter here will be applied at deploy time to your specified target computer.

Applying customizations to a group or type of computer based on their Manufacturer and Model

To be able to target a particular manufacturer and/or model of computers you need to create a Make and Model record in the MDT database and provide the Manufacturer and Model name of the targeted computers. The MDT database will use this to identify the computers at deploy time and apply the customizations.

The first thing to do here is to find out the exact make and model of the targeted group of computer(s) you want to apply the customizations to. To make sure you get this exactly right you must obtain the manufacturer and model by running the following WMIC query on the target computer

WMIC csproduct GET Vendor,Name

In this query Vendor refers to the make and Name refers to the model of the computer. As an example, the results of this query in the screenshot below shows the make as Dell Inc. and model as Inspiron N5050.


Bear in mind that you must copy the manufacturer and model exactly as shown, right down to the full stop.

On the Deployment Workbench right-click on Make and Model and select New. A Properties window will come up as shown here:


Enter the Make and Model fields in the Identity tab, making sure you copy the vendor and name values returned from the WMIC query on your target computer correctly.

Again, you enter your customization settings in the Details tab.


You could, for example, set all Dell Inspiron N5050 laptops to have a specific screen resolution at deploy time.

Of course, this is only the basics of what’s capable with the MDT database. The level of complexity and the customizations you choose to make will depend on your deployment environment. I’m still exploring the MDT database and hope to write more on this in the future.

Creating A MDT Database

This is a quick follow up to my last post where I produced instructions on how to install and configure SQL Server 2008 Express for the purpose of using the SQL server to create a MDT database.

Creating a MDT database is really simple as you will see in the instructions below which can be used with MDT 2010 and 2012.

Here’s the instructions:

open deployment workbench

Open the Deployment Workbench and expand your Deployment Share

Expand Advanced Configuration, right click on Database and select New Database

Continue reading

Installing SQL Server 2008 Express Edition (For MDT)

The instructions here are specifically intended to be used with MDT 2010 or 2012 on a Windows Server 2008 R2 server. As in the past they are step by step visual instructions which I thought best to deliver as a PowerPoint presentation.

In a working environment you will typically have a group of IT support staff who are members of an Active Directory group which in turn has been given access to the Deployment Share to allow the members of the group to carry out deployment duties (by authenticating themselves when initiating the Deployment Wizard).

If this applies to your situation I’d like to draw your attention to Slide 13 in the PowerPoint presentation. This is the point where you’ll need to add the Active Directory group object to the list of SQL Server administrators. As an example, the screenshot below shows an AD security group called DeploymentAdmins added to the list of SQL Server administrators in my Lab.


Without giving the group administrator access to the SQL Server you will find none of the MDT database settings will be applied at deploy time if the deployment (or Task Sequence) was initiated by a user who is a member of the DeploymentAdmins group.