Tag Archives: lti

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 2013 – Deploy HP Elitepad 900 using the HP Expansion Jacket, HP Dockingstation, MDT2013, WinPE 5.0 and ADK 8.1

Published / by Rens Hollanders / 4 Comments on MDT 2013 – Deploy HP Elitepad 900 using the HP Expansion Jacket, HP Dockingstation, MDT2013, WinPE 5.0 and ADK 8.1

Well… that’s a mouth full, but I couldn’t describe it better any other way 🙂 Because that’s what I’m doing right now!

In this ‘tutorial’, I will explain the steps I did to achieve a basic MDT LTI deployment based on:

  • MDT Lite Touch Deployment
  • FAT32 Formatted USB Bootable WinPE 5.0 stick
  • Deploy HP ElitePad 900 with all drivers installed working out-of-the-box

For a new project I’m working for a major health care facility which are going to use approx. 800 HP Elitepad 900 tablets, who will be running not the stock Windows 8, but the recently released Windows 8.1.

Currently I’m in testing phase so I’ve got a nice setup at home, running some VM’s, a connection to my deployment share and of course a HP Elitepad 900 tablet, with HP Expansion Jacket and HP Dockingstation

To get things going I first installed a MDT 2013 dedicated machine, with the newly released Windows ADK 8.1 which brings us support for Windows 8.1 and Server 2012R2.

Then I recovered the HP Elitepad 900 which was already used for some testing, back to factory settings and started the whole operation.

For the following weeks, I will try to keep track of the most important things I encounter and share my experiences with you all.

The first thing I had to do is create a driver folder structure in MDT which makes sense (at least for me it does).

figure 1.1: Deployment Share Driver folder structure

DriverStructure_ElitePad_900

As you can see I created several additional driver folders parenting in the WinPE folder, this is all for driver manageability.

HP offers perfect support when it comes to driver packs for the various WinPE environments, so I have downloaded all available packs and imported them into MDT.

The drivers of the HP ElitePad 900 came from the following sources:

HP Website

Microsoft Windows Update Catalog

Extraction of the following HP executable, which can be downloaded from the HP website listed above: “.\sp64292\x86_Win8.1\Driver – Firmware and Chipset\HP\sp63851

Keep in mind you need to extract the SP64292 file AND the SP63851, when all drivers are extracted, together with all other HP ElitePad 900 drivers, target the “Import Drivers” step to the parenting folder which possesses all drivers.

When all drivers are imported, it should look something like this

figure 1.2: HP ElitePad 900 drivers

ElitePad Drivers List

Because the HP ElitePad 900 also has touchpad (which actually works in WinPE IF you embed this into the boot image) drivers and other specific drivers, I targeted these drivers specifically in a separate folder.

With these folders, I have created selection profiles. These selection profiles target individual (driver) folders and present only the content that is residing in that folder during a certain step in the task sequence. This way I have managed to create a WinPE x64 and x86 folder, and I can target these folders individually when generating the boot images for x64 and x86 deployments.

Figure 1.3: Selection Profile Properties

SelectionProfile_ElitePad_900_WinPE_x86

Makes sense right? Each selection profile targets a different WinPE platform folder

figure 1.4: Overview of Selection Profiles

SelectionProfile_ElitePad_900

How this looks on the deployment share properties?

figure 1.5: WinPE x64 Properties

DepShareProperties_x64

figure 1.6: WinPE x86 Properties

DepShareProperties_x86

Next we can have a look at targeting the drivers for the HP ElitePad 900 in a decent manner. (Johan Arwidmark has described a new driver management approach for MDT 2013 Lite Touch, read it here).

First I have executed the following ‘query’, on the HP ElitePad 900 in a command prompt:

wmic computersystem get model“, which showed the following result

figure 1.7: Result of query

wmic HP Elitepad 900

Since we have imported the drivers of the HP ElitePad 900 in a earlier stage, the remainder of what we need to do is modify the “Inject Drivers” step in the task sequence to target only the drivers for the HP ElitePad 900. So open up the deployment task sequence, and advance to the step “Preinstall\Inject Drivers”, and select the driver Profile matching the HP ElitePad 900

figure 1.8: Inject Drivers based on Selection Profile

InjectDrivers

Now to make sure that these drivers are only applied if the model equals the HP ElitePad 900 our little query comes in handy

figure 1.9: WMI Condition on Inject Drivers step

DriverCondition

The exact WMI query used is: ” Select * FROM Win32_ComputerSystem WHERE Model like “%HP Elitepad 900%” ” (without the two “” at both ends, that’s just me explaining the query 😉 )

The next thing we need to configure is disk partitioning of the HP ElitePad 900, since it’s a UEFI based machine, it uses GPT, so advance to the step: “Preinstall\New Computer Only\Format and Partition Disk” and change the disk type from: Standard (MBR) to GPT

figure 1.10: Format and Partition Disk GPT

GPT

Click Apply and OK.

Basically we are ready to perform a deployment test, and that’s what I have done during the writing of this blog, to see the following results:

Figure 1.11: Device Manager OK! (no unknown devices left) and Deployment Finished successfully!

HP Elitepad 900 Device Manager

Also what we can see is that by selecting the GPT Disk type, during deployment the GPT partitions have been created automatically.

figure 1.12: Disk Management GPT Scheme

diskmanagement

This concludes my little tutorial of how to deploy Windows 8.1 to the HP ElitePad 900.

In the upcoming period I’m going to:

  • Configure the Default User Profile
  • Configure the start screen with the Start-Layout PowerShell command
  • Configure Bitlocker
  • Configure Direct Access
  • Configure and tweak Windows 8.1 wherever it is needed
  • Configure the LTI deployment furthermore so that it becomes fully automated just like ZTI 🙂
  • Configure RES Automation Manager and RES Workspace Manager for automation and user workspace management

And of course the test environment will be mitigated to a Windows Server 2012R2 with WDS and PXE Boot enabled to deploy these tablets via PXE, and we will see how that goes!

I’ll leave you all with a little package that might become handy when you are going to approach the same challenge. In the attached zip file you will find:

  • BDD.log_properties which are quite useful to determine al kinds of conditions, queries and variables
  • A Driver list which is an export of my HP ElitePad 900 driver folder, so you can verify if all drivers are present
  • All screenshots used in this tutorial

zip
HP_ElitePad_900.zip

Keep on automating my young padawans 😀

! Any general reconsideration’s to keep in mind are:

  • Format the bootable USB drive with FAT32, NTFS is not read by the HP ElitePad 900
  • When staging a HP ElitePad 900, make sure a USB keyboard is attached if you are performing an LTI deployment, yes touch works, but that doens’t mean you can type in WinPE!!!

 

 

MDT 2012 will HideShell=YES and LTISuspend.wsf work together in one task sequence?

Published / by Rens Hollanders / 4 Comments on MDT 2012 will HideShell=YES and LTISuspend.wsf work together in one task sequence?

Short answer: YES 😀

Recently I have created a Build Task Sequence for a customer where it was needed to do some checks upfront, before the operating system, running on a virtual machine would be captured to a WIM file.

As some of you might know, the LTISuspend.wsf script, residing in the SCRIPTROOT of MDT (DeploymentShare\Scripts), can be called after the ‘State Restore’ step in the task sequence.

At any given moment, but preferably under the ‘Custom Action’s’ folder, create a ‘Run Command Line’, with the following commandline: “cscript.exe %SCRIPTROOT%\LTISuspend.wsf”

figure 1.1: Suspend Task Sequence Step

LTISuspend_ts

this will postpone the task sequence and create a shortcut on the desktop called ‘Resume Task Sequence’. However when using the following property in your customsettings.ini: “HideShell=YES”, your desktop shell will not be fully loaded, thus it would be possible that no desktop, taskbar and other icons where presented during the LTISuspend.wsf.

figure 1.2: No Explorer Shell

TS Progress

Luckily this isn’t the case. When the machine is suspended and HideShell is set to YES in the customsettings.ini the task sequence will be succesfully postponed, however the Windows theme, will be set to basic, as we can see by the screenshot I took:

figure 1.3: Suspended Task Sequence

LTISuspend

So use it with confidence!

Keep on automating my young padawan learners! 😀

 

MDT 2012 LTI Deployment, Regional and Locale settings based on #chars of Hostname

Published / by Rens Hollanders / 12 Comments on MDT 2012 LTI Deployment, Regional and Locale settings based on #chars of Hostname

Recently I have done an MDT implementation for a customer regarding a deployment which featured an database of approx. 250 clients, each with known mac-addresses and host-names available to make use of.

The customer requested that based on mac-address the host-name would be provided, and based on the host-name, Regional and Locale settings could be set during LTI deployment. After a little bit of consult on technet and talked to deployment artist ‘Johan Arwidmark’, I’ve incorporated a custom ‘user exit’ script that does just the trick!

Basically, the company had 5 different affiliate locations in 5 different countries, with each different Regional and Locale settings

The script created/used was a joint effort between a colleague and me, (thanks Roger the Young aka. Drillsergeant):

Explanation of script:

The first 4 lines is our basic UserExit script function, the second function retrieves the CountryCode, and retrieves this information based on the first two characters of the host-name. Last, if no value is declared, the script will automatically fill-in the desired default country, which in our case is NL – Netherlands

The script then executes, and replaces the following values, with the values that are specified in the customsettings.ini:

Make sure you add the following properties to your customsettings.ini: “ByCountry“, “CountryAbbr” (which stands for Country Abbreviation) and define the custom properties: “CountryAbbr“, “CountryOU” as your custom declared properties. This way the script knows what to process.

The values I then had declared were:

CountryOU: since they had different OU’s for each country
CountryOrRegion: Country#
InputLocale: specifies the input language and keyboard layout for a Windows installation.
KeyboardLocale: specifies the input language and keyboard layout for a Windows installation.
UserLocale: specifies the per-user settings used for formatting dates, times, currency, and numbers in a Windows installation.
TimeZoneName: gets the Notification Services assigned name for the time zone

This way, the default values will be overwritten with the values that matches the hostname’s first two characters and the values will be placed in your unattend.xml, which is located in the “C:\Windows\Panther”, during the inital setup of the operating system, just after the image has been applied.

If all fails, you’ll notice immediately because then you will find an error during the setup phase of your operating system, which will look like this:

figure 1.1: Unattended.xml parsing error

panther

This indicates that an incorrect value has been written into the unattend.xml, likeley in the <specialize> pass, you can look this up by opening the unattend.xml with notepad during your deployment.

Concluding:

You can just use any country abbreviation that is out there, accompanied by the default settings for this country, or off-course your own values, and also, extend the list of values with other country related settings you wish to apply.

Download the script here:

zip
ZTIGetCountryCode.zip