Tag Archives: mdt

MDT – Add deployment information with PowerShell and perform a REFRESH scenario

Published / by Rens Hollanders / 8 Comments on MDT – Add deployment information with PowerShell and perform a REFRESH scenario

Hi, just a quick post about an idea I wanted to share with you all:

A request from a colleague -since we are using MDT to deploy our corporate machines- was to create a mechanism that prevents the re-partitioning and formatting of hard drives that have already been deployed with MDT.

Now this can easily be done by creating the following steps in your deployment task sequence:

figure 1.1: Set Task Sequence Variable – DeploymentType

005

As you can see above, the Task Sequence Variable “DeploymentType” will be set, during the execution of the task sequence. But how can we achieve this only happens if for example the machine has already been installed with MDT a previous time?

figure 1.2: Task Sequence Variable Condition

006

By setting a condition on this Task Sequence Variable. For example by checking if a certain file exists. Naturally it is key, that this file will be created at the first initial deployment of the machine, or the file is created manually afterwards. The reason why I check both C: and D: drive, is that within Windows PE, it may occur that sometimes your C: drive is detected as D: drive due to the “System Reserved” or “System” partition.

This way I’m always right.

Now, to generate a file for identification, I’ve created a powershell script, which dumps certain Task Sequence Variables queried by the ZTIGather.wsf script in a text file, together with a couple of WMI queries:

The script is pretty straight forward:

First it sets the invocation path, which is the path from where the script is called. Then it sets the variables which are needed as input for the script. And the cool thing is, since ZTIGather.wsf queries the entire machine, we can use the MDT Task Sequence Variables as input for our script, which will be dumped into the text file.

To determine the computername, I wanted to use the OSDComputerName task sequence variable, but strangely enough, it outputted the AssetTag instead, for this reason I used the WMI query:

And the same thing goes for the Windows Operating Sytem version:

And bitlocker recovery key:

I then just needed to format these results in a readable usable manner, to get all my variables straight.

Now that’s out of the way, I needed a folder to store this information in, but I don’t want to bother end-users looking into it. So I create a folder called “MDTRollout” and placed it in the root of C:\ and give it the “Hidden” attribute, also I perform a check if the folder itself does not exist, in that case it will be created.

The same thing goes for the text file which is automatically created, if it does not exist. And if the file exists, it will add the content, for example when the machine is reïnstalled for the 2nd, 3rd, or 50th time.

And now to show you the result:

figure 1.3: No folder present at first

001

figure 1.4: running the script

002

figure 1.5: Task Sequence has finished

003

figure 1.7: Contents of the DeploymentInfo.txt004

There you have it, a little usefull file which can be used to quickly evaluate the computer’s identity and configuration. Which on it’s turn, forms the basis to perform a MDT REFRESH scenario, instead of a NEWCOMPUTER scenario.

The script can be placed in the .\DeploymentShare\Scripts folder, and executed with a “Run Powershell Script” step from within the Task Sequence properties pane. You can call the script as following: “%Scriptroot%\MDT_DeploymentInfo.ps1”, the great thing about doing it this way, is that MDT handles the execution policy of powershell which would otherwise prevent the execution of the script. Normally it is necessary to set the policy to “Bypass” or “Unrestricted”.

figure 1.8: Calling the script

008

figure 1.9: Testing it yourself

007

Now to test the script yourself, a custom task sequence with the following two steps should do the trick:

  1. “Gather”
  2. “Run PowerShell Script”

Hope this can be of use to anyone else.

Find attached the screenshots used, and the actual script, which can be downloaded

zip
MDTDeploymentInfo.zip

Cheers and have great 2014/2015! Merry Christmas and a Happy New Year!!!!

MDT – Versioning made easy (powershell = king)

Published / by Rens Hollanders / Leave a Comment

The great thing I like about doing projects with customers, is that each and every customer has it’s own challenges. And I think it is safe to say, that challenges brings out the best of all of us IT Pro’s.

In this particular post, I want to talk about the Microsoft Deployment Toolkit, versioning mechanism: ..MDT has no versioning mechanism 🙁

Wouldn’t it be nice to just have an option to duplicate a task sequence, like MDT’s big brother Microsoft System Center Configuration Manager?

Well that day has come my friends 🙂

Currently I’m working on reverse engineering a Citrix XenApp 6.5 environment which needs to be rebuild from the ground up with MDT. And after it has been built, it needs to be managed, improved, extended further when necessary.

Now it is perfectly possible to duplicate task sequences manually. Just create a new task sequence with the wizard within MDT, and copy the ts.xml and optionally the unattend.xml from your control\<tsid> folder to the new control\<newtsid> folder, and voilá your task sequence is duplicated. But wouldn’t it be nice to do this automatically?

Depending on the tools that are present in any particular organization, since MDT is free, and tools such as RES Automation Manager and System Center Config. Mgr. cost money (..and particularly Config. Mgr. costs lots of it too) I wanted to create a solution for having some kind of versioning system in MDT.

Since I’m getting more and more familiarized with PowerShell, I can kick in the open door by saying what we all know: PowerShell is truly King. Although I do not poses all the knowledge, luckily I have multiple colleagues who are willing to help me at any given time. This time I would like to thank Pascal Zeptner, for spending his free time with me 😀

Now before we are going to talk about the script, it is imperative that your Task Sequence ID is built up out of the following naming convention:

  • OSB001
  • OSD002

I maintain this convention at all of my MDT implementations. The abbreviation OSB stands for “Operating System Build“, while OSD stands for “Operating System Deployment“. The essential difference between the two is, that the first one is used for creating reference images for target machines. While the second is used for deploying the reference image that is created, to target machines.

And to have a complete MDT environment with an orderly created folder structure in less then 20 seconds, please visit this blog: MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

Behold the script:

Function

First of all, the script checks for elevation, if you do not run this script elevated it will not execute:

Secondly, the script needs certain variables made clear to work with. In this case the following static variables:

After these variables are filled in. The script will import the MDT PowerShell module, located at the default location where MDT normally is installed. If you have installed MDT elsewhere, you will receive notice that the MDT module was not found and the script will terminate.

Next, a new PowerShell drive will be created, so we can browse the MDT virtual folder structure:

After this, the real stuff begins: In the following lines of code, the properties of a task sequence will be queried. This happens with the “Out-Gridview” cmdlet, since this presents a nice selection dialog, to select the desired task sequence which we want to duplicate.

From this selected task sequence, we query it’s ID, and increase the number on the ID with +1 to create the new Task Sequence ID.

The same thing goes for the Task Sequence Version, which is also queried, and increased with +1. As soon as the version of the task sequence hits .9, it will increase the master version from 1.0 to 2.0.

Lastly the name of the task sequence is queried, and assuming we use a specific naming convention for our task sequences, which uses “v1.0” at the end. The last three characters are removed and replaced with the $NewTSVersion variable. This causes our newly created task sequence, to receive a name with the increased version number too!

Now all the information we need to know to duplicate our task sequence is known, we can actually create a new task sequence and copy the contents from our reference task sequence to the new task sequence:

As you can see, there are some checks built-in that verify if the new to be created task sequence does not already exist on physical folder level.

Now to underline all this, screenshots:

figure 1.1: Select designated task sequence for duplication

versioning001

figure 1.2: Task Sequence duplicated

versioning002

figure 1.3: Press F5 to refresh and see the new task sequence

versioning003

figure 1.4: Perform duplication at v .9

versioning004

figure 1.5: Version 2.0 created

versioning005

figure 1.6: Press F5 to refresh and see the new task sequences

versioning006

figure 1.7: *.xml files are copied from destination task sequence to new task sequence

versioning007

..and that my padawan automaters, is how the cookie crumbles.

Comments, questions, improvements? Please let me know in the comment section. It’s as always much appreciated.

The script and images used in this blog can be downloaded here:

zip
MDTVersioning.zip.zip

Cheers! -Rens

MDT and RES Automation Manager – Let’s come together (in Sweet Harmony)

Published / by Rens Hollanders / 1 Comment on MDT and RES Automation Manager – Let’s come together (in Sweet Harmony)

More and more I encounter company’s who already own a distribution mechanism, or already have implemented the Microsoft Deployment Toolkit, and are looking for a distribution mechanism or deployment mechanism.

Since MDT is free to use, and RES Automation Manager costs a fraction of the cost then System Center Configuration Manager or nowadays the entire System Center Suite. This makes allot of sense to allot of people, that integrating or combining MDT with RES Automation Manager is a strong combination to service workstations, servers or other hardware that needs to be provided with an operating system and software.

Although I’m pro MDT, I’m not necessarily against RES Automation Manager. I only want to point out that the need for a management tool depends on requirements that are drafted by the people who determine the company policy on this topic.

Now it may occur that you or your organization already has RES Automation Manager incorporated into your organization. All the modules, projects and run-books have been figured out, so taking them out of RES Automation Manager to put them in MDT might be a bit crazy, especially when those modules are also used in other situations.

Today I’m going to show you how you can incorporate RES Automation Manager in MDT!

First of all we need to have the RES Automation Manager Agent, which needs to be imported in MDT as an application.

Depending on which kind of agent you have created from RES Automation manager, the standard MSI or the MSI preconfigured to run a certain project, you’ll need to specify the following installation parameters:

Standard RES AM Agent installation, invoking a project:

RES AM Agent installation, preconfigured:

Now, for instance, If you want to deploy a computer with MDT and manage it afterwards, then the last step in your task sequence should be the installation of RES Automation Manager. And the FinishAction in your customsettings.ini should be set to either:

Leaving the FinishAction property blank, will simply do nothing. The machine will be finished, MDT will clean-up it’s act, and RES Automation Manager will kick in, and depending on if you have created a project that always should be invoked on this particular deployment, RES Automation Manager will begin executing this project.

The second option FinishAction=LOGOFF, will logoff the machine, making it unavailable for people to access the computer will it is being configured by RES Automation Manager.

Today I encountered a different scenario which put’s things in a whole other perspective. For this particular client who is building an Enterprise VDI image, the machine will be deployed with MDT, and when MDT is finished, RES Automation Manager will finalize the installation with middleware components and other configuration’s, before it is being converted to a VMware Snapshot which is at the basis of this VDI solution.

Now I received a question today, to use this same RES Automation Manager project, with some minor configuration changes to be used when creating a reference image with MDT on physical hardware to deploy to one and the same hardware model.

Just to be clear, this goes against the concept of MDT. Building a reference image on physical hardware is basically a no-go. Due to driver-store pollution, driver conflicts etc. this is something you want to avoid at all costs. Also using another tool to do the same as MDT is capable of, especially when creating a reference image, also might be a bit contradictory. However I do not question the client’s request.

To achieve this, we again need the RES Automation Manager Agent incorporated as an application within MDT.

figure 1.1: Install RES Automation Manager Agent 2014

res_am005

Then in our task sequence we need to make use of the “LTISuspend.wsf” script, which temporarily pauses the MDT task sequence at any moment that the script is called. As you can see here, this happens right after the installation of RES Automation Manager.

If you don’t pause your task sequence, or if RES Automation Manager isn’t the last action in your MDT Task Sequence, MDT will just continue executing other tasks when the RES Automation Manager Agent is installed! Reversed, RES Automation Manager will terminate the MDT Task Sequence process and you’ll be left with an incomplete deployment!

figure 1.2: LTISuspend.wsf

res_am006

After MDT has been configured, we need to create a module in RES Automation Manager, called: “Operation: Resume Suspended Task Sequence”

figure 1.3: RES Automation Manager – Module

res_am001

This module holds an “Execute Command” task

figure 1.4: RES Automation Manager – Execute Command

res_am002

The “Execute Command” action, contains the following command line:

figure 1.5: RES Automation Manager – Execute Command – Settings

res_am003

Now make sure that this particular module is set to last. After this no other task from RES Automation Manager may be executed:

figure 1.6: RES Automation Manager – Project

res_am004a

Now, when RES Automation Manager is finished executing the project, the last thing RES Automation Manager will do, is execute the resume function of the “LTISuspend.wsf script”.

After this, MDT will continue the task sequence, and capture the machine into a WIM file. If you don’t want to have the RES Automation Manager Agent into your reference image, you’ll need to provide an un-installation command in MDT before the machine is being captured. Uninstalling software is executed by using:

In addition, you might want to delete the following REG KEY. Since it holds the GUID RES AM uses to authenticate against the database.

This can be done by executing the following command:

And sow I can now finally say: MDT and RES Automation Manager can live in (sweet) Harmony. And to underline this….MUSIC!

Cheers! 🙂

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!

MDT – Quick Post: How to install App-V 4.6 SP3 and 5.0 SP2 client

Published / by Rens Hollanders / 1 Comment on MDT – Quick Post: How to install App-V 4.6 SP3 and 5.0 SP2 client

Some time ago I needed to install both App-V 4.6 and 5.0 with MDT for a Citrix XenApp 7.5 base installation image.

Figuring out which command lines run with different applications, can sometimes be a painful process. Of course opening up a command prompt, and entering the following command “executable.exe /?” will get you on the right track, but sometimes that’s just isn’t enough.

One of those applications I’ve encountered numerous times, which will always get to you is, is the installation of the App-V 4.6 client with SP1, SP2, SP3 and hotfixes.

This guide will help you install the App-V client to the latest available versions out there!

First of all, here’s a list of the most up to date version of the App-V 4.5 and 4.6 client:
Current list of App-V 4.5 and App-V 4.6 file versions

And the same goes for the App-V 5.0 client
Current list of App-V 5.0 file versions

Next to this you’ll need middleware components, App-V uses several Visual C++ components. I have the following installed prior to the installation of App-V:

figure 1.1: Installation of Visual C steps

app-v002

The install command lines for Visual C++ are as following:

  • vcredist_x64.exe /q
  • vcredist_x86.exe /q
  • vcredist_x64.exe /q
  • vcredist_x86.exe /q
  • vcredist_x64.exe /q
  • vcredist_x86.exe /q
  • vcredist_x64.exe /q
  • vcredist_x86.exe /q
  • vcredist_x64.exe /quiet /norestart
  • vcredist_x86.exe /quiet /norestart
  • vcredist_x64.exe /quiet /norestart
  • vcredist_x86.exe /quiet /norestart

At this moment my task sequence looks like this:App-V 4.6 SP3 especially needs Visual C++ 2008 SP1 x64 and x86

figure 1.2: Installation of App-V client

app-v001

And the command lines used are as following:

  • msiexec.exe /i SETUP.MSI SWIGLOBALDATA=”D:\App-V” SWIUSERDATA=”%APPDATA%” SWICACHESIZE=”30721″ SWIPUBSVRHOST=”SAPPV.CONTOSO.COM” /norestart /qb
  • cmd /c NET STOP SFTLIST
  • cmd /c NET STOP SFTVSA
  • setup_upgrade.exe /S /v”/qn REBOOT=ReallySuppress”
  • Restart Computer
  • msiexec /p AppV4.6SP3-RDS-KB2897394-x64.msp /qb-! /norestart
  • APPV_CLIENT_SETUP_RDS.EXE /q /norestart /ACCEPTEULA
  • AppV5.0SP2-RDS-KB2934349.exe /q /norestart /ACCEPTEULA
  • AppV5.0SP2-RDS-KB2956985.exe /q /norestart /ACCEPTEULA

Next, stopping the App-V services is necessary to perform the remainder of the installation of the App-V 4.6 SP3 update. This is because after the reboot the App-V services are already up and running. The line marked orange is to stress the need for a reboot at this point.

Update, since App-V 5.0 SP2 hotfix 5 has been released, the following command line can be added to the steps above:

  • AppV5.0SP2-RDS-KB2963211 /q /norestart /ACCEPTEULA

That’s all folks, hope this comes in handy when you are struggling yourself with the installation of any App-V client.

If you have any remarks, questions or comments, feel free to contribute in the comment section.

Cheers! 🙂