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:
- The customsettings.ini
- Multiple customsettings.ini
- The MDT Database
- 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)
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:
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.