MDT – Monitoring creates event viewer entries


This quick post is about admitting that sometimes even I learn new stuff about MDT.

Since I usually do not setup MDT monitoring (I use dynamic logging most of the time), at a particular customer I did, since they wanted to track progress of their deployments.

Setting up monitoring is quite easy, enable the checkbox on your deployment share properties and add an additional property into your customsettings.ini:

figure 1.1: Enabling MDT Monitoring


figure 1.2: Monitoring property customsettings.inimdtmonitor002


When this is done, for each machine that will be deployed through MDT, the MDT Monitoring service will create an event in your Application log, with information regarding when the deployment was started for a particular machine, when it has ended and if any error’s did occur.

figure 1.3: Eventviewer Application Log MDT entriesmdtmonitor003

Cheers! Rens

MDT – Put the domain join where it belongs..


Hi Guys and Gals,

Long time no see. Took me some time to move into our new house which had to be decorated with wallpaper, flooring, additional electric and internet wiring etc. So March 2015 will leave a gap in my blog archive, but I’m hoping to compensate this with writing some new articles.

One of them is this one: Put the domain join where it belongs. If you are like me, I like to work with one MDT deploymentshare to rule them all. When looking on social.technet in the MDT forum’s I see many people struggling to combine build and deployment shares together, or shares that have separate settings regarding computer deployment or domain membership.

Now MDT offers four options to create a deploymentshare so flexible you’ll only need one share to truly rule them all:

  1. The customsettings.ini
  2. Multiple customsettings.ini
  3. The MDT Database
  4. Task Sequence Variables

Allow me to explain each option and the pro’s and con’s:

Customsettings.ini: hey If you can manage it per model, macaddress, tasksequenceid etc. thats fine! But usually you are going to end up with a conflict that either strikes your build deployment or your deploy deployment. Most issues I see here are domainjoin and capture related.

figure 1.1: CustomSettings.ini


Multiple customsettings.ini, you can specify which ini file to process right into your task sequence “gather” step; this makes your deploymentshare more flexible and forces a specific task sequence to use a different ini file for processing then let’s say the default task sequence. Editing the Gather step is an option, but since you’ll have to edit it multiple times in one task sequence, it’s easy overlooked and prone to error when making typo’s

figure 1.2: Multiple customsetttings.ini


If you are planning on changing the gather step’s, then please take into consideration there are four of them in every deployment task sequence:

The first is during Initialization, the second during Preïnstall the third during State Restore and the last one can be found during Imaging

figure 1.3: Configuring different CustomSetting.ini


Then there is the MDT Database, store settings that would otherwise end-up in your customsettings.ini individually based per machine, make and/or model, roles or location, a very good alternative to use but a little bit overpowered when just wanting to make the difference between machines joining a domain or getting captured.

figure 1.4: Using the MDT database integration


figure 1.5: Properties of a MDT database object (A customsetting.ini of your own)mdtdb002

Task Sequence variables, this to me is the most powerful option of all. Let’s say I want to specify a property which may not occur anywhere else, simply put a task sequence variable at the front of your task sequence.

figure 1.6: Using task sequence variables in your task sequence


Just as you would post information about capturing your reference build in the build task sequence, you could do exactly the same for the following values regarding domain joins:

  • JoinDomain=contoso
  • DomainAdmin=mdt-domainjoin
  • DomainAdminDomain=contoso
  • DomainAdminPassword=P@$$w0rd
  • MachineObjectOU=OU=Computers,OU=Laptops,DC=contoso,DC=local

This prevents machines that are intended to be captured, end up domain joined and machines that are deployed and are domain joined to be captured (which will result in error, since sysprep will not allow a domain joined machine to be generalized for capture).

Hope this helps in gaining insight in how to achieve a more flexible MDT deployment.

Cheers! Rens

MDT – Inject printer drivers


Just a quick post before February ends:

Allot has been said and written about injecting drivers with MDT into you operating system. However I thought that it should be useful to point out that any of the drivers you want to inject into your operating system, at the preïnstallation phase, occur before the actual drivers for your system are applied.

I cannot substantiate this process which (part of the) script does the trick, but I recently noticed that injecting hardware drivers for a particular machine prior to injecting printer drivers, is not going to do anything with the printer drivers. They are skipped and later on in the process not found on the Operating System “C:\Windows\System32\DriverStore”. But when I switch the tasks with each other, and printer drivers are injected before hardware specific drivers, the printers drivers are nicely injected.


The only conclusion I can draw from this, is that the mechanism which triggers “Microsoft.BDD.PnPEnum.exe” to query for the vendor and device ID’s of the hardware, does not have a complete match of hardware devices found in relationship to the pool of drivers which is offered. Until then it will accept all drivers to be injected prior to the actual hardware driver injection.

Hope this can be of any assistance

Cheers! Rens

By the way I’m receiving the key of our new house in the next couple of days and I’ll be spending my time getting our house ready for moving in. So I’m not expecting to write an article before the beginning of April.

MDT – Custom Property: Set your environment in testing or production


Hi people,

2015 is almost 2 weeks old, and it already feels like we’re halfway through the year. Just a quick post I wanted to share with you all, about building, developing and testing an MDT environment that is going to be used for production purposes.

I often find myself forgetting to disable certain steps in MDT during testing, that effect’s the turnaround time a certain task sequence is taking. For example, testing an entire roll-out, from OS deployment up to application installation takes quite some time. And if you have forgotten to disable the Windows Updates step, during this test, and new updates are available, you’ll lose valuable time that could have been spent otherwise, whilst Windows Updates is a guaranteed step in your task sequence that works.

Or another example, Windows Activation, against KMS or MAK, should that run when testing?

OK, so we can create development task sequences, copy tasks back and forth. But what about making things less complex and work with something cool as Custom Properties?

So this is how I have setup my customsettings.ini for a project I’ve been working on:

script 1.1: CustomSettings.ini Properties

Using the custom property: “MDTStatus” I can easily use this as a Task Sequence Variable condition on all the steps that I would like to include or exclude during development, testing and production:

figure 1.1: MDT Status on Windows Updates001
figure 1.2: MDTStatus on Windows Activation002

Now to quickly assess this, there is an easy way of processing these settings in the CustomSettings.ini against the designated TaskSequence:

script 1.2: Executing the ZTIGather.wsf script

Upon execution, you will see that the ZTIGather.wsf script, starts evaluating with the CustomSettings.ini and designated Task Sequence in mind:

figure 1.3: Evaluating CustomSettings.ini and TaskSequence with ZTIGather.wsf


When the ZTIGather script is finished processing, you’ll find the following folder in the root of your C:\ Drive: “C:\MININT\SMSOSD\OSDLOGS” and within that folder you’ll find the BDD.log which is used by MDT to echo all actions of the steps that are executed back to this particular logfile.

In this logfile you will find the following:

figure 1.4: Custom property added004
figure 1.5:  Custom property picked up005

And there you have it, setting an entire MDT environment in a certain mode enables you to perform testing without being bothered with steps that impact the turnaround time, or make you spill your MAK keys for no other reason then testing.

Cheers! Rens

2014 – My year in review…


Lasts day of the year, always a good day to look back and to look forward, to what’s been and what comes :)

In addition to last years review: 2013 – My year in review, MDT, MCT, Music, Vinyl, Concerts and more… I’ll start with the top 5 best read posts of this year:

  1. MDT – Unattended.xml, CustomSettings.ini, Task Sequence Variable, which setting takes precedence over which setting?
  2. Windows 8.1 – Installation of NetFx3 by command line will fail if language pack is installed
  3. Office 365 – Automatic deployment of Office 365 with MDT
  4. MDT 2013 – Configuring your environment for Bitlocker deployments with TPM, Windows 8.1 and MDT 2013
  5. OSD – Live from the field my ‘Best Practices’ for Operating System Deployment

Now lets talk numbers:


As you can see here, over the entire year. I had nearly 60k sessions. 41k unique visitors which generated 152k pageviews. That’s a staggering number for me, as I never expected this many people would visit my blog. Taking into account, that most of you stayed nearly for 1:30 minutes per session on my blog is incredible and I would like to thank you for all this.

Also it’s funny to see when the weekend kicks in, and when the working days are. Somewhere between March 13 and March 18 I lost my Google Analytics tracker due to the change of my websites theme.

If we are talking geographics, the United States, United Kingdom and the Netherlands are in the top three of visits by country:


Browsers, Google Chrome on top:


So I’m really dazzled by all these numbers, and I would like to thank you all for visiting my blog over in 2014.

But 2014 meant more for me, then just writing some posts about IT related stuff. We’ve sold our apartment which due to the financial crisis wasn’t really easy. It took nearly three years before it got sold. Bringing a huge sacrifice at this point, enabled us to buy our dream house only 8 months later, and now we finally have a house with a rooftop to shout it from :)

But 2014 was also a year of music, and for my fellow music enthusiast, I wanted to share my list of music for the year 2014:

  1. The War On Drugs – Lost In The Dream
  2. Royal Blood – Royal Blood
  3. Wovenhand – Refractory Obdurate
  4. Interpol – El Pintor
  5. Lana Del Rey – Ultraviolence (Deluxe)
  6. Amatorski – From Clay To Figures
  7. Damien Rice – My Favourite Faded Fantasy
  8. PAUW – PAUW – EP

Above are some of my top listed albums and EP’s from 2014, which are definitely worth a try If you haven’t heard from any of these bands (although I doubt the War on Drugs is unknown, since it occupied the radio-waves home and abroad throughout the entire year)

Well this leaves me to say and wish you all the very best in 2015, with health luck and love and have a safe New Years Eve.

Cheers! Rens