Daily Archives: 24 September 2014

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! 🙂