Tag Archives: customsettings.ini

MDT – Use MDT cross domain / workgroups

Published / by Rens Hollanders / 2 Comments on MDT – Use MDT cross domain / workgroups

Hi there,

Just a short post of something I had to deal with very recently, an MDT environment that is cross domain / workgroup connected.

Basically I had two challenges:

  1. Connecting to different shares based on DefaultGateway
  2. Connecting to shares in a domain and in a workgroup

The following example of the bootstrap.ini, does just that:

As you can see here, I use the DefaultGateway section to process from which location the machine is going to be deployed, to choose the designated deploymentshare for this particular location.

Next thing, is making sure the authentication of the shares is going smoothly. My first try was using the “LocationServer.xml“, this seemed to solve my problem of having multiple shares. Unfortunately, when you use LocationServer.xml it will destroy your authentication settings, since they are not parsed through while processing the xml file. Leaving you with a question to authenticate (again!) with the target share.

/rant the not parsing of the credentials while using LocationServer.xml is something that goes back since 2010. A thread on social.technet answered by Keith Garner, reports that a bug was filed, but it did never make it to any new release of MDT 🙁

So how did I get around this, by putting all the common denominators in the default section, and all the anomalies in the DefaultGateway subsection. Giving me the opportunity to use the same account, but use a different UserDomain. This means you can use the same account (a domain account for the machines in the domain, and a local account for the machine in the workgroup)

Also since the deploymentshare outside the domain, cannot be resolved by DNS, you’ll need to map this share based on an ip address.

Now doing the same thing for the CustomSettings.ini, gives me to opportunity, to put logfiles for each machine on the same location where it has been deployed.

Happy deploying 🙂

Cheers! Rens

 

MDT – Put the domain join where it belongs..

Published / by Rens Hollanders / 53 Comments on 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

customset000

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

customset002

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

customset001

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

mdtdb001

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

tsvars001

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 – Custom Property: Set your environment in testing or production

Published / by Rens Hollanders / Leave a Comment

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

003a

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

 

MDT – Linked Deployment Shares, Litetouch.vbs and CustomSettings.ini properties and priority (User Question)

Published / by Rens Hollanders / 2 Comments on MDT – Linked Deployment Shares, Litetouch.vbs and CustomSettings.ini properties and priority (User Question)

Last week Alexander reached out to me with the following question(s):

“Hello could I ask some questions?

  1. I am creating Linked Deployment Share, what difference between Merge and Replace, during creating?
  2. What properties do you recommend for using?
  3. Could you explain features of Extrafiles directory on MDT, how can I use It, and may be you know were I can find information about it. May be you know good examples?
  4. Is it important the order of positions priority in CustomSettings.ini
  5. Priority=DefaultGateway,Make,Default,SendMail
    Properties=OSDSendMailFrom,OSDSendMailTo,OSDSendMailSubject,OSDSendMailBody,
    OSDSendMailSMTPServer,OSDSendMailIncludeBDDLog,SavedJoinDomain and how could I understand what have to be first, second, third etc.
  6. What is Priority and Properties?
  7. What difference between LiteTouch.wsf and LiteTouch.vbs? And which script I have to start to implement replace scenario?

Thank you for your answers!”

Well Alexander, you didn’t hold back on asking questions, so let me ‘not’ hold back on giving answers 🙂

Linked Deployment Shares

Linked Deployment Shares is MDT’s mechanism to distribute and synchronize content which is originated with the MDT Deployment Share, to parent deployment shares or remote locations. Deployment Shares can be connected to other deployment shares, and this is called “Linked Deployment Shares”. Now how will MDT know what content to distribute and/or synchronize? This is determined by using selection profiles.

Selection profiles are profiles which can be created within MDT, under “Advanced Configuration” in the MDT workbench, and are no more or less then a list of items that are checked or unchecked by the person creating the profile. These profiles can be used for lot’s of things, such as driver profiles, package profiles, offline media profiles, and linked deployment share profiles.

Basically by checking and unchecking content from the MDT Deployment Share through the workbench console, you can decide which content needs to be distributed and synchronized from time to time.

Now you ask the purpose behind merge and replace. This can be best compared by doing a copy and paste action on a windows folder, which already holds content that you are going to copy/paste into the exact same folder. What happens is that the Windows Explorer File Manager will ask you what to do with the content: Replace, or do nothing. This action is similar to the replace or merge function. Merge means that content which is already present in the parenting deployment share will be maintained, while replace means that the entire content which is already present in the parenting deployment share will be replaced.

However, I would not recommend using linked deployment shares, since it is prone to error’s, and it lacks control, which you otherwise would have, when you use robocopy for instance. Even MDT guru Johan Arwidmark recommended me to use robocopy above using linked deployment shares, and I won’t argue with him on that point!

What properties do you recommend for using?

I’ve written a blog about my commonly used customsettings.ini properties, read it here

Could you explain features of Extra files directory on MDT…

The extra files directory is quite simple. But first, let us determine the extra files directory:

Go to your deployment share, right click on it, and click “Deployment Share Properties”

figure 1.1: Open Deployment Share Properties

DeploymentShareProperties

My approach has always been to embed extra files like this:

figure 1.2: Deployment Share – WinPE Properties

Extrafiles

As you can see I’ve specified the extra files directory within MDT as following: “%DEPLOYROOT%\Extra” and the same goes for the Custom MDT background which is also located in in my Extra directory, the benefit of this is, that I can create a folder named “Extra” within my deploymentshare, and place all the content I need into my boot image, in this location:

figure 1.4: Extra folder

Extrafolder

Next time when you will update or completely regenerate your boot images, the contents of the Extra folder will be present in your boot image, and it can be found by opening a command prompt and browse to the root of your drive: “X:\” there you will find trace64.exe for example, which is quite handy viewing logfiles, rather then using notepad.exe!

figure 1.5: Command Prompt in WinPE

Extracommandprompt

So there you have it, the Extra files directory in MDT

Is the order of  priority positions in CustomSettings.ini important?

Short answer: Yes, priority determines in which order subsections of the CustomSettings.ini is processed:

cs_rules_priority - Copy

As you can see in this example, my priority order is as following: Priority=Model, Default. This means that first if the machine you are going to work with, matches the model description specified in the customsettings.ini this section will be processed first, before the default customsettings.ini rules will be processed.

This can be quite handy, if you want certain machines to join the domain, while others just need to be joined to a workgroup or the other way around. So yes priority matters, however the location of your subsection in Customsettings.ini does not. You can place the Model subsection beneath the Default section, and add in other subsections as well. This does not affect the priority.

What is Priority and Properties?

This question hooks onto the previous one:

  • Priority determines in which order Properties are processed
  • Properties represent objects which contain a value that MDT can work with since the scripts that are used within MDT rely on these properties.
  • The priority of properties is of no importance. It doesn’t matter if you place OSDSendMailFrom before OSDSendMailTo or OSDSendMailTo before OSDSendMailFrom, it just matters that the property is present.

So for example the Property “OSDComputerName” = HAL9000, this value will be collected during the Gather step in a task sequence, and then will be stored and used when the time is right to set the hostname of the machine, which happens during the setup phase of the operating system.

What’s the difference between LiteTouch.wsf and LiteTouch.vbs? And which script I have to start to implement replace scenario?

Good question, if you would have examined both script’s you will find the following:

Litetouch.vbs is used to start the deployment, and setup a connection with the deploymentshare. This process can either be initiated from within Windows, or from within WinPE, it doesn’t matter. Either way Litetouch.vbs is used. Litetouch.vbs can be started by double-clicking on it on a running Windows machine, but that’s just to easy since Windows recoqnizes VB script’s and know’s what to do with it.

The correct way to start Litetouch.vbs is to open an elevated command prompt and type: cscript.exe <path to litetouch.vbs\litetouch.vbs. This also provides some cool tricks to instantly specify certain values that litetouch.vbs can work with, for example: cscript.exe litetouch.vbs /tasksequenceid:<tsid> will initiate the mdt deployment which immediately calls the specified and desired task sequence!

figure 1.6: Litetouch.vbs

litetouch.vbs

And as you can see here: Litetouch.vbs paves the way, Litetouch.wsf finishes what has been started!

About your replace scenario, this is not decided by either Litetouch.vbs or Litetouch.wsf but determined by the value which given to the property: “DeploymentType

This properties knows three known values:

  1. NEWCOMPUTER
  2. REFRESH
  3. REPLACE

And depending on the value you specify, one of these three scenario’s will kick-in. Just open your task sequence and look at the groups Refresh, Replace and view the options, to find a Task Sequence Variable is set as condition. And if the condition is met, these steps are executed during the deployment of the machine!

That concludes this blog, and I hope you Alexander and many others will find this information usefull in your way of working with the Microsoft Deployment Toolkit!

Cheers!

 

MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

Published / by Rens Hollanders / 5 Comments on MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

Very recently, deploymentreseach’ Johan Arwidmark, blogged about configuring your DeploymentShare properties (which are saved in .\Control\Settings.xml) with Powershell.

Some time ago I started working on some Powershell scripts myself, mostly oriented on configuring the bootstrap.ini and customsettings.ini, and creating some folders within the MDT Workbench.

While I never had gotten the time and energy to finish it, Johan’s blog basically pushed me over the edge, and then it happened… I went BESERK /cannot compute 😛

beserk

The result you can find in the following script which not only configures your deployment share properties, but also configures:

  • Bootstrap.ini
  • CustomSettings.ini
  • Modifies “.\Scripts\Litetouch.wsf” to use the _SMSTSPackageName variable
  • Configure DeploymentShare Properties
  • Creates a folderstructure within MDT
  • Creates selection profiles within MDT

The script! Updated @ 2014-03-20

Basically this script can be divided into five pieces:

1. Constants

The constants that I have declared are the variables that represent the value that is shown, by modifying these values, you can customize and personalize this script for your own purposes. This script is primarily intended for new to be configured deployment environments, so keep in mind that using this script on existing environments will overwrite all content within the bootstrap.ini and customsettings.ini!

2. Configuring Bootstrap.ini and Customsettings.ini

Basically I use a multiline string for both my Bootstrap.ini and CustomSettings.ini and within that line of code, on certain places I call my variables. This way the variables will be used for input, instead of having to change a server name every single time on every single row of code.

3. Configuring the DeploymentShare properties

This part we already know from Johan / deploymentreseach, however I’ve took the liberty to customize it to my wishes, and fully write out all the available settings in .\Control\Settings.xml

4. Configure a logical folderstructure within the MDT Workbench

This part is quite new, I now know again thanks to Johan and Roger the Young a PSDrive can be browsed from a powershell command prompt, just type: dir ds001: and you can actually see and browse the MDT Workbench ‘folder structure’.

figure 1.1: Browse PSdrive

psdrive

If you want to browse any further, just type dir DS001:\Applications or “DS001:\Operating Systems” (note that if you use spaces in your folders, you need to use quotes “”)

5. Configure selection profiles for Driver and Packages selection

The last thing I wanted to do is configure pre-configured selection profiles which can be uses for injecting certain drivers, targeting packages, creating media etc.

What has changed since 2014-03-20

The script needed some simplification to avoid having to enter the same values at different places. Also now the script creates an entire deployment share for you. So now there is no need to create an deploymentshare with MDT before executing this script. Lastly the ZTIDiskpart.wsf will be modified to calculate with binary metrics. So a 100 Gb disk partition specified will actually end up as an 100 Gb disk partition instead of 98,7 Gb.

Closing

Is this the right way to do it, I have no clue, what I do know is that I never want to configure a deploymentshare manually ever again, so this script definitely helps me. Also, adjusting the values of the constants declared is a fraction of the effort I have to put in vs. going through “Create folder” wizards for the 50th time.

Special thanks go out to scripting wizard Roger the Young a.k.a. “DrillSergeant” and Johan Arwidmark, for giving me renewed inspiration to continue to develop this script in what it has become.

ps I. forgive my powershell language, using words as constants, variables, properties and values, are perhaps not used in the correct way! -im still trying 🙂

ps II. also I can imagine this script can be simplified drastically, and I don’t mind if you do, as long as you share it back with me, like I shared it here with you 😀 Or as the Germans say: “wiedersehen macht freude”

Finally, you can download the script here:

zip
ConfigureDeploymentShare.zip