Month: March 2016

ConfigMgr–Extending Hardware Inventory

So if you are using ConfigMgr you probably know that you can extend hardware inventory to inventory pretty much anything. The cool thing is that by almost default there are two classes that are really nice to have.

The first being Win32_QuickFixEngineering which is a WMI class listing all installed patches. Having that inventoried means you can build collections based on missing or certain patches installed which when it comes to critical patches or hotfixes are really nice.

The second is a kind of custom class and its called Microsoft_BDD_Info and it is created by ZTITatoo.wsf when you deploy a computer with either MDT or ConfigMgr with MDT integration. This includes a bunch of information from the deployment. For instance it lists which sequence ID was run and the timestamp. So if you inventory this you can keep collections based on what sequences was used and if you have a nice version control in your sequence you now find all your computer that where deployed with a certain version of sequence.

So how do you enable this awesomeness? Well its pretty simple. Fire off your ConfigMgr console and check under Administration and Client settings. You will have a setting called Default Client Settings. Open it up and on the left hand click Hardware inventory. Next click the button to the right where it says Classes. You will be presented with a long list of WMI classes that can be enabled and disabled. At the top just do a search for “Quick” and select the class Win32_QuickFixEngineering.


To enabled the second class a bit more work is required but don’t worry it is not hard. Go back to the client settings (if you left it) and click the Add button seen at the bottom (look at the image above for guidance). You now need to connect to a computer that has been deployed using MDT/ConfigMgr+MDT so click the connect button and type in the computer name and credentials if needed.


When connected you will see all the WMI classes available on that computer. Just find the one called Microsoft_BDD_Info and select it and click OK when done.


So now they have both been selected and you have saved the Clients Settings by clicking OK all the way out. Now all that remains is waiting for the next hardware inventory to complete and you can start using the values collected.

Happy deploying!


PowerShell Wrapper – Windows Management Framework 4.0

I got a question (you know who you are) if I had a WMF 4 PowerShell wrapper and while I didn’t at the time I thought I would create one as you still need WMF4 to be installed before WMF 5 can be installed.

Create a simple folder structure looking like this


In the source folder place the files for WMF4 that can be downloaded from Microsoft Download here

Download the script here

Import as an application into MDT and either dynamically assign the application or add it into your Task Sequence the same way I do in my Windows Management Framework 5 here

Happy deploying!


creating a outlook signature with logo

The other week I was working at a customer and the requested that we rebuild the way they create their Outlook signature from the old word document template. And as we can use PowerShell for everything today that’s where we went. The problem with doing it this way is that the logo image was residing on a file share in their internal environment. This means as soon as the email is sent the image is not attached and the receiving end could not the their logo.

So to fix this there is a small registry value you can set to make sure outlook always includes images. You can also find the complete script here.

First off we need to create a folder structure cause the script has another feature which they requested. So create a folder and inside that folder place the script, your logo image file and create another folder inside named Pictures.

Like this:Folder

Open up the script and at the top of the script change two things, first change the name of the logo file to whatever your file is named and change the name of the signature to something fitting your environment. The name you type in here is the one that will show up if select a different signature in Outlook.

Next Check the bottom of the script there are two sections one being the registry settings to make sure to include the image and the other is a value to defined if the signature should be used by default. If you wish to use this just uncomment the lines creating each of the registry values.

Now just run the script!
That’s it to creating the signature. If you want to customize the look of the signature its a common html creation so pretty much anything is possible.

It should give you a signature looking something like this.


So how does it work? Well we start by getting the username of the current user and then do an AD query for that user and get the above values. This means that whatever is in Active Directory will be in the signature creating a streamlined and unified look for every person in your organization.

Once that is done it will get the logo picture and insert that as well. Next comes the nice extra feature with the Picture folder you created. All images you add in here will be added to the bottom of the signature. So now the question is why would you want that? Well a number of customers I work with like to add a banner at the end during certain times of the year or when they want to push a certain product or happening. Now it can be centrally controlled and all users will get it.

Just don’t forget to remove old pictures in the folder.

So to finish up, deployment!
To accomplish this I create a GPO than runs a login script. If you don’t want to do that you can always do a scheduled task that checks a certain network folder and runs the script or any other preferred solution.

Link to the script is here

Hope this helps and happy deploying!


MDT handoff to SCCM

I will start by saying this is not in any of the best practices books but it works well and is used for certain scenarios.

Sometimes when I get to a customer they have MDT setup and working for OSD but someone higher up have decided that they need ConfigMgr to manage clients going forward. Don’t get me wrong I’m all for using ConfigMgr to manage clients but that being said not everyone finds ConfigMgr the easiest or most understandable platform to use. So the question then arises “Could we still use MDT to deploy the machines and then ConfigMgr to manage them?” and of course the answer is YES!

So how do we accomplish this? There are two ways and I will describe both but only show one.

The first way of doing it by using the excellent startup script created by Jason Sandys (found here it is easy to setup and only requires a small startup GPO and a file share. The upside to using this is that if someone for some reason didn’t get the agent during initial setup or someone uninstalled it from a client that is targeted by the GPO the client will get reinstalled. Jason has also managed to add some repair functions to it. So the downside then is that when using a GPO the client has to actually read the GPO and for that work the client has to be a member of the domain so workgroup computers are out.

The second way is what we are going to focus on for the rest of this post. That way is to install it during OSD in MDT as an application. The upside to doing it this way is, as soon as the deployment is done the client is also installed regardless of if the client joins a domain or not. Another upside to doing it this way instead of with a GPO is that if the client restarts at any point during deployment and the GPO is enabled the client will be installed during OSD possibly messing around while you are doing other installations or configuration steps.

So how do I do this? Well first off we need to create an application in MDT then we link that application into our sequence.

Step 1 – Creating the application

Create a folder named “CMAgent” so we have something to work with. Inside that create another folder called “Source”. Next to the Source folder place the script file and the xml which you download a bit further down in the post. In the Source folder you copy the client installation files from your site server in \\<your site server>\sms_<sitecode>\Client.

You should then have a folder that looks like this


Now we import that into MDT. So you give the application a name, point to your source folder and set a command line. For name I prefer Install – CCM Agent so I can easily see what the application does by just looking at the name. For command line you should use the following

PowerShell.exe –ExecutionPolicy ByPass –File Install-Application.ps1

If you open the application when its done it should look like this


Step 2 – Adding it to the Task Sequence

The next bit is to add it to the sequence in the correct spot to avoid it being installed and then messing with your deployment. So open your sequence go down all the way to the end and mark the step called Apply Local GPO Package, Click Add at the top and Create a group. Now name the group so you know what it does, either Custom Steps or as in this case I named it Custom Handoff. In that group we add a step for Install application. Change the step to install a single application and point to your newly imported application.

The sequence should then look something like this


Step 3 – Customizing the agent installation

The last thing you need to do is change some settings to point the agent to your specific environment. So open up your deploymentshare folder and browse to Applications\Install – CCM Agent. Use notepad to edit the settings.xml file and change the Installswitch section of the file. Below is a sample of how it can look, make sure to change it to suit your server name and infrastructure.


Your all set! Next time you image a computer it will then have the CCM agent installed.

Link to download the script is here

Happy deploying!