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! :)

RES Workspace Manager – Inject Java Security level for users

Today I encountered a challenge which I think needed to be shared with you all.

Currently I’m working with other colleagues on building a brand new Citrix XenApp 7.5 environment based on Server 2012 R2 x64 in combination with RES Workspace Manager 2014 SR1, together with mandatory profiles and RES Zero Profiling technology.

A user who works with several java applications encountered the following problem:

figure 1.1: Java Application Blocked by Security Settings

java selfsigned blocked

Since this error is generated by Java, I immediately went to the control panel to investigate the available options for configuring Java.

You can find the Java control panel applet, when you change the “Category” view in your control panel to “Large” or “Small” icons.

figure 1.2: Control Panel – Java (32-bit)

04

Click the “Java (32-bit)” shortcut in your control panel, and the following screen will appear:

figure 1.3: Java Control Panel

java05

Now for example, if we want to change the security level of Java, which prevents the current Java application from running, change the security level from “High”

figure 1.4: Java Control Panel – Security High

java10

To “medium”

figure 1.5: Java Control Panel – Security Medium

java11

And click “OK”.

This would do the trick, but how can this setting be passed on to users logging on to a Citrix environment with mandatory profiles?

Since we are using RES Workspace Manager, I did the following:

First of all I needed to capture the setting with some kind of tool. You’ve got two options here:

  1. Regshot, wich is an opensource and free tool to capture and compare system state registry and file system changes between two snapshots and show the result as to what has changed
  2. ProcMon, which is a great tool for checking realtime processes, registry behavior and much more.

I chose for ProcMon, (make sure it runs in admin mode!)

figure 1.6: ProcMon

procmon

Now, when ProcMon is started, make sure you stop capturing (leave ProcMon running for some time and you’ll know why ;) ) and make sure the list of captured events is made empty by clearing the screen:

 figure 1.7: ProcMon – Capture and Clear Screen

procmon arrows01

Now that’s out of the way, since we want to capture some Java activity, go to Filter in the menu, and add the following filter: “Path” contains “Java”

 figure 1.8: ProcMon – Add filter

path java09

Click “Add” and then “Apply”.

Now you have made a filter only showing event’s which concern the word “Java”.

Now repeat the configuration of the Java security level on the Java control panel menu. And you will see the following appearing in ProcMon:

 figure 1.9: ProcMon – Results

procmon12

As you can see here, Java writes the changes to the following path: “C:\Users\Administrator\Appdata\LocalLow\Sun\Java\Deployment\deployment.properties”

Examining this location reveals the following:

 figure 1.10: Windows Explorer – File location

java13

If you open this file with notepad, you will find several properties which indicate how Java is configured on your machine.

 figure 1.11: Deployment.Properties – Content

deployment.properties

So there you have it: the Java configuration file.

The same goes when adding certain trusted websites to the Java applet:

figure 1.12: Java Control Panel – Edit Site List

java10

If you click “Edit Site list” the following screen appears:

figure 1.13: Exception Site List

java14

By clicking “Add”, another screen appears:

figure 1.13: Exception Site List – Adding the website

java15

For example, by adding Google.com to the list of trusted sites to run Java-applets, you’ll receive security warning if you click “OK”

figure 1.13: Exception Site List – Just click OK…

java17

And by clicking “Continue”, the website will be added to the list of trusted sites to run Java-applets. Again a setting which will be written to a config file, this time on the following location:

“C:\Users\Administrator\Appdata\LocalLow\Sun\Java\Deployment\Security\exception.sites”

 figure 1.14: Windows Explorer – File location

java16

If you open this file with notepad, you will find the website we’ve just added:

 figure 1.15: Exception.Sites – Content

exception sites

Now, how can this be incorporated for every user signing into a Citrix environment with mandatory profiles you ask?

In the RES Workspace Manager console, go to “Administration > Custom Resources”, and add the deployment.properties and / or the exception.sites file as a custom resource:

 figure 1.16: RES Workspace Manager Console – Custom Resources

Custom Resources

Go to “Composition > Execute Command” and click “New Command”

In the properties pane, make sure the script is executed “At logon after other actions” as command specify the following: “%script%”, this makes sure you can use the “Script” pane which can hold far more complex  and even more important, multiple lined scripts.

 figure 1.16: RES Workspace Manager – Execute Command

command01

As you can see, I’ve pasted the following script in the “Script” pane:

 figure 1.17: Execute Command – Script

script

The exact content of the script is:

script 1.1: Copy Java security permission file to designated location

 figure 1.18: RES Workspace Manager – Execute Command

execute command

Now each time a user log’s into the Citrix environment the Java configuration file “deployment.properties” will be copied from the database used by RES, into the specified location. Setting the correct Java security level, trusted websites and other related settings for each user, during each session.

As you can see an entire different warning appears, which is just perfectly normal. It hopefully makes users aware of the potential risk opening the Java applet. But 90% of the users will happily make use of their trigger-finger twitch!

 figure 1.19: Java Security Warning

java do you want to run

Got anything to add, got a trick up your sleeve which can simplify this action, or am I just doing it all wrong? :) Please leave your comments in the comment section!

Cheers Rens!

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

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! :)

MDT – How I build my reference images (User Question)

Based on my last post: “MDT – Post me your MDT Questions” I’ve received a question from mr. “Jones” who reached out to me with the following comment:

Hi,

Great that Microsoft at last put an understandable Technet article on “Create a Windows 8.1 Reference Image”. Great comments by you aswell on clearing the event logs. I think Microsoft should put that as default in MDT.

Maybe there are some other small “tips” that you ALWAYS perform at every MDT installation you do that you can share with us?

So to put my words in action, this is how I build my reference images.

!Note: this post focusses on building a Windows 8.1 Enterprise image, but with some adjustments can well be used for a Windows 7 Enterprise deployment.

1. Use the ConfigureDeploymentShare script.

To get a headstart with configuring MDT, you can save a lot of time by using my powershell script. It will create and configure everything in your deploymentshare, based on a logical structure I’ve designed.

You can find the script and post about it, here: “MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

2. Create a build task sequence

Within MDT there are several templates available which set you up with a task sequence from where you should be able to do a deployment.

Now understand that there is no difference between a so called ‘build task sequence’ and a ‘deploy task sequence’, the differences are made by the person that’s responsible for the MDT environment.

To get started, I assume you have already imported the following sources:

  • Operating System source (like from a Microsoft ISO file)
  • Applications (like visual C++ redistributables, Office 2013 etc.)
  • Possible VMware drivers (if you are building your image on a VMware platform)
  • Packages containing Windows 8.1 update files
  • Language packs

Under the task sequences node, select the Build folder, which represents task sequences that are used for creating reference images:

figure 2.1: Task Sequence Node

build001

and on the right side pane, click “New Task Sequence”

figure 2.2: New Task Sequence

build002

From there a wizard will start, asking some basic information. This information is used to generate the unattended.xml which is used to deploy the operating system unattended with the information specified in the xml file.

figure 2.3: Task Sequence Wizard – General Settings

build003

In the general settings, I always like to specify a build task sequence with OSB (derived from Operating System Build) followed with a unique number. If this is the first task sequence, call it OSB001

figure 2.4: Task Sequence Wizard – Select Template

build004

 

Select the standard client task sequence if you want to deploy a client, select the standard server task sequence, if you want to deploy a server

figure 2.5: Task Sequence Wizard – Select OS

build005

Select the base operating system image source

figure 2.6: Task Sequence Wizard – Specify Product Key

build006

Normally for any deployment task sequence, you need to specify a product key. Since we are building an image here, this is not necessary. Presumably by the time you have reached the 180 day grace-period, your image must have been built ;)

figure 2.7: Task Sequence Wizard – OS Settings

build007

The same goes for the OS Settings, why specify the company name during the build already, when the company information is only relevant during deployment. Using generic information, does not cloud your image with irrelevant information, and enables you the use the images for more then one company for instance.

figure 2.8 : Task Sequence Wizard – Admin Password

build008

I always work with a specified admin password, nothing more to add here

figure 2.9: Task Sequence Wizard – Summary

build009

 

The summary displays the information we have provided before the task sequence is created.

figure 2.10: Task Sequence Wizard – Confirmation

build010

And lastly, the task sequence is created. And for the powershell fanatics among us, a script to perform these steps is provided:

Now that’s out of the way. Lets have a closer look at the Task Sequence properties.

3. Task Sequence Properties

Open up your task sequence, to modify the following settings:

!Note I will only describe the changes I’ve made to the default “standard client task sequence”

First: create the following Task Sequence Variables, stored in a group called Task Sequence Variables, prior to the “Initialize” step:

  • TSVAR: WindowsSource
  • VALUE: %DeployRoot%\Operating Systems\Windows_8.1_Enterprise_x64\sources\sxs
  • TSVAR: DoCapture
  • VALUE: YES
  • TSVAR: ComputerBackupLocation
  • VALUE: %DEPLOYROOT%\Captures
  • TSVAR: BackupFile
  • Value: W81ENTx64.wim
  • TSVAR: FinishAction
  • VALUE: SHUTDOWN

These Task Sequence Variables are set with the task sequence, and define the following actions:

WindowsSource, points to the sources\sxs folder which is needed in some cases when you want to install the .NET FX role with your Windows 8.1 installation
DoCapture, sets the flag to yes, so that at the end of your deployment the machine will be captured to a wim file
ComputerBackupLocation, determines the location where the wim file will be stored
BackupFile, specifies the name of the wim file, which sometimes may differ from what you normally want to call it, due to testing purposes
FinishAction, specifies that when the machine is finished capturing the wim file it will shutdown automatically.

By now you should have a task sequence which looks like this:

figure 3.1: Task Sequence Variables at the beginning of your task sequence

build011

this is also the moment to say: “I wish MDT Task Sequnces had a maximize button” – Which the MDT Team already came back to me explaining it’s a restriction of the current GUI / Console they are using :(

Next stop: Go to the Preinstall step, and select “Inject Drivers”. At this step, select the preconfigured selection profile: “Drivers_Virtual_VMware”

figure 3.2: Driver Selection Profile

build012

Selecting a driver profile for injecting drivers, makes sure incorrect drivers are not injected during this phase, which can cause a lot of trouble at later stages during the deployment

Next, under the “Inject Drivers” step, you will find the “Apply Patches” step. From the preconfigured selection profile, select: “Packages_Windows_8.1_x64″

figure 3.3: Packages Selection Profile

build013

Injecting packages upfront will shorten the time Windows Updates will run post-Operating System installation. This means that update files can be changed offline which is much faster then online update installation. Since there are no services running yet, no DLL’s registered, etc.

Next stop: “State Restore”, since the “Install” step only concerns applying the source wim file to the virtual machine and post install is setting up and configuring the machine for use. We can skip these steps and advance straightaway to the “State Restore” step.

Make sure to enable both “Windows Update” steps, if you want to service your image with the latest available updates! Besides this, remove the “Install Application step” and move the “Custom Tasks” step, inbetween the two Windows Update steps. Like this:

figure 3.4: State restore – Windows Updates and Custom Tasks

build014

Underneath the “Custom Tasks” step, I’ve created the following steps:

  • Install Roles and Services – Windows 8.1 – .NET Framework 3.5 and 4.5
  • Restart computer
  • Install application – Windows 8.1 Language Pack
  • New group, called: “Install Visual C++ Redistributables”
  • Install application – Visual C++ 2005 up to 2013
  • New group, called: “Install Office Suite”
  • Install application – Office 2013, incl. language packs
figure 3.5: Install Roles and Features

build015

figure 3.6: State Restore – Custom Tasks

build016

Of course these steps can be altered and can be focused on the requirements of your own organization. This is not a best practice, this is just my way of building a corporate ready reference image.

Next stop, is the end of the task sequence, right before the machine will be sysprepped and captured into a wim file, I perform a cleanup of several things:

  • Temp files and temp directories, such as logfiles that have been left over from the Visual C++ installation, the “Perflogs” and “temp” directory etc.
  • Clean up logfiles, this makes sure your logfiles are clean and empty before the machine is being captured. This makes sure that newly deployed machines don’t have a logfile full of entries back at the day the reference image was created.
figure 3.7: Cleanup phase

build017

The cleanup happens with a powershell script, which is located in the .\DeploymentShare\Scripts folder and called with a “PowerShell Script” step:

  • %ScriptRoot%\OSDCleanup.ps1

The contents of the script, are as following:

Log files can be easily cleaned by performing the following “Run Command Lines”:

  • - wevtutil cl application (for the application log)
  • - wevtutil cl security (for the security log)
  • - wevtutil cl system (for the system log)

And last but not least, before the sysprep and capture phase takes place, one final reboot of the machine to process system changes that otherwise may interfere with the sysprep process and may cause your entire task sequence to fail at this point.

figure 3.8: Reboot -just to be sure-

build018

And that is how I build my reference images mr. Jones :)

If there is any need to manually make changes before the machine is being captured, just insert the following “Run Command line” right after the Windows Updates (Post application installation) process: “cscript %ScriptRoot%\LTISuspend.wsf”

This will create a shortcut on the desktop, enabling you to make adjustments, restarting the computer and when finished making alterations, to continue the process of creating the reference image.

For more information about LTISuspend, please visit this great blog written by Michael Niehaus: “MDT 2010 New Feature #3: Suspend and resume a Lite Touch task sequence

This concludes my blog for this time. I felt I had to make it up to all of you, due to my absence the past couple of weeks :D

I’ll leave you with the content for and from this blog, which contains the screenshots used in this blog. The scripts, and installation command’s of the applications used in this blog, like visual c++, Office 2013, language packs, and many more…

zip
ReferenceImageBlogContent.zip

Untill next time my padawan automaters ;)