Tag Archives: linked deployment shares

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!