Month: June 2015

How to – SCCM and MDT roles

I recently got a question on facebook on how to use Roles with SCCM (you know who you are) so i thought I would do a write up on how to make that happend enabeling both applications and settings based on the role.

The recepie:

1x SCCM server 2012 R2 with MDT integration.
1x Task Sequence with a created Settings package
1x MDT Deployment Workbench
1x SCCM Console

As the above states I persume you already have a task sequence and a settings package created. This can contain rules and settings already that is fine this will just add to that or if you want to try this out, you can create a new Task Sequence and a new Settings package.

First off we need to do some work in the MDT Deployment Workbench. We need to create a Database to save all the settings we intend to use. Start by opening your MDT Deploymentshare or create a new one, then go to the Advanced Configuration and right click on Database. Select New Database.


Point to the SQL server you wish to use. Either create the database on the SCCM server or if you have a seperate MDT server feel free to use that. If you can avoid to use a common SQL server to decrease the dependecies.


Fill in a name for the new database, make sure it its not already used.


Next fill in the sharename of your deploymentshare. If you named your deploymentshare “MDTPrd” the share would probebly look like this MDTPrd$. This allows a SQL connection throu Windows PE to made.


Complete the wizard approving the summary and clicking close when the progress is complete.
Note that you need write permissions in the SQL database with the account that is used to create the database.

You can now verify that the database has been created looking at the information.


Next you need to add in the computers that should be mapped to roles.

In the MDT Deployment Workbench go to the computer node and create a new Computer.
On the identity tab fill in one (1) way of identifying your computer. I have used MAC address in this example.


Next go to the Details pane and fill in the unique information for this computer, such as computername.
Click OK when done.


Next we create the role that will be linked to the relevant computers.
Go to the Role in the MDT workbench and create a new role.
Give the role a name.


On the details pane fill information that is common to this role, ex set x and y resolution to 1 to give the role auto detect on resolution.

Next lets add some applications SCCM style. On the Applications pane click Add and select ConfigMgr 2012 Application.


Now type the NAME of the application, nothing else.
In this example I use the RDCMan application from Microsoft.
(repeat for all the applications you want to be installed for this role)


Next we add a SCCM Package aswell. On the ConfigMgr packages pane click add and fill in the Package ID and Program name. The package ID is built up of your sitecode and a incremental number.


When this is done Click OK to save your role.

Now we need to link this to the computer created erlier. Go back to the computer we created, right click on it and select properties. Go to the Roles pane and click Add. Select the Role you want to add to the computer. You can add mutiple roles to one computer. They will be added to eachother.


Since we now have a computer and a role that are linked we just need to create the rules to make sure they are applied when deploying computers.

Go the Database node in the MDT workbench, right click and select Configure Database Rules.

In the wizard that appears the diffrent check boxes will create diffrent rule blocks in Customsettings.ini. Since they are all SQL queries you should make sure to only tick the boxes you need. In this example we use Computers and Roles.

On the first page, Computer Options, leave all the boxes ticked.
On the second page, Location Options, untick all boxes.
On the third page, Make/Model Options, untick all boxes
On the fourth page, Role Options, Leave all the boxes ticked.
Click OK on the summary page and Close when the progress completes.

Now open the properties of the deployment share or directly open the Customsettings.ini file and you will se something similar to below.


Now there are one last job! Copy the created information from the MDT customsettings.ini file to your customsettings.ini file in your settings package. Note that you need to copy both the Priority bits and the blocks created that corresponds to the priority bits. The deploymentshare you have created to modify this should be keept as is. If you don’t want it you will need to change the SQLShare property to point to another share on the SQL computer to make sure the conncetion can be made.

As a last note, ther are two steps inside the SCCM Task Sequence that does the actual install, one install software and one install applications. Leave both as is and do NOT change the variable names used by them.

and also, don’t forgett to update the distribution points with the settings package used so it actually uses the new customsettings.ini.

Happy deploying!

WSUS and the broken cleanup wizard

For some reason most seem to think that after installing Windows Update Services all is fine and the server can be forgotten and left in a dark corner. I know today we talke about pets and cattle, servers that we care about and servers we replace with new as soon as something is not 100% with them. However a WSUS server is not cattle it is a pet and needs some TLC to continue running smoothly.

The most common problem with a WSUS server is that the DB grows out of control due to not beeing clean up. Since WSUS has been left in a dark corner chances are that it is still running Windows Server 2008 R2 and the powershell cmdlets to WSUS in 2008 R2 is in diplomatic words limited. So again doing what most do, you run the cleanup wizard manual once every eon right?

And when that eon finaly comes around the wizard can’t complete due to the amount of patches and time it takes to clean them.

There are ways of cleaning up even the most horrible setup of WSUS using store procedures inside the database. This is however VERY time consuming. What you instead should do is run a cleanup script that automates the job of the cleanup process for you. A simple scheduled task that runs a script that initiates the clean up and logs the output to a nice log you know whats going on.

I have seen a couple online and most are either limited in their logging or are written for 2012 R2 wich has some nice cleanup cmdlets built in to powershell. So I have written my own and you can find the script here

I would recommend you create a scheduled task that runs this weekly with the following commandline “cmd.exe /c PowerShell.exe -ExecutionPolicy Bypass -File <Path To File>\Cleanup-Wsus.ps1”

If you run this from the same folder i use (C:\Script) the script will work with the above line if you have another folder add the following after the filename “-logfile <Path to use\Logname.log>” and it will use that instead.

If you want to read more about the script just use get-help cleanup-wsus.ps1

Keep your WSUS happy!

Windows 10 – Countdown begins

Today marks the day, the Windows team has finaly given a release date for RTM of Windows 10. The date is soon as well. How about the 29th of July, 2 months to go.

You can read more on the offical Windows blog here

If you haven’t already, start planning on how to move to Windows 10 from your current platform.

Stay tuned for more information from the Windows team aswell!