[Step-by-Step] Creating a Windows Server 2012 R2 Failover Cluster using StarWind iSCSI SAN v8

March 27, 2014 at 10:27 pm | Posted in Cluster, Windows Server 2012, Windows Server 2012 R2 | Leave a comment
Tags: , , , , , , ,


If you don’t know StarWind iSCSI SAN product and you currently handling clusters that require a shared storage (not necessarily Windows), I highly recommend to take a look around to this the platform. To summarize, StarWind iSCSI SAN represents a software which allows you to create your own shared storage platform without requiring any additional hardware.


I created a post a while ago about “Five Easy Steps to Configure Windows Server 2008 R2 Failover Cluster using StarWind iSCSI SAN” to explain how can a Failover Cluster can be easily configured with the help of StarWind iSCSI SAN. Since there has been some changes in the latest releases of Windows Server and StarWind iSCSI SAN has a brand new v8 of its platform, I thought it would be a good idea to create a new article to achieve an easy way to create our own cluster.

As I did, for the previous post, the main idea about this article is to show a simple step-by-step process to get a Windows Server 2012 R2 Failover Cluster up and running, and without requiring to use an expensive shared storage platform to complete it. The steps involved are:

  1. Review and complete pre-requisites for the environment.
  2. Install StarWind iSCSI SAN software.
  3. Configure and create LUNs using StarWind iSCSI SAN.
  4. Install Failover Cluster feature and run cluster validation.
  5. Create Windows Server 2012 R2 Failover Cluster.

1. Review and Complete Pre-Requisites for the Environment

Windows Server 2012 introduced some changes into the Failover Cluster scenarios, even though those are important and improved changes, the basic rules of Failover Cluster has not changed. Here are the requirements for a Windows Server 2012 R2 Failover Cluster.

Requirements for Windows Server 2012 R2 Failover Cluster

Here are the requirements in Windows Server 2012 R2 for Failover Clusters:

  • Two or more compatible servers: You need hardware that is compatible with each other, highly recommended to always use same type of hardware when you are creating a cluster. Microsoft requires for the hardware involved to meet the qualification for the “Certified for Windows Server 2012 logo”, the information can be retrieved from the Windows Server catalog.
  • A shared storage: This is where we can use StarWind iSCSI SAN software.
  • [Optional] Three network cards on each server, one public network (from which we usually access Active Directory), a private for heartbeat between servers and one dedicated to iSCSI storage communication. This is actually an optional requirement since using one network card is possible but not suitable in almost any environment.
  • All hosts must be member from an Active Directory domain. To install and configure a cluster we don’t need a Domain Admin account, but we do need a Domain account which is included in the local Administrators of each host.

Here are some notes about some changes introduced in Windows Server 2012 regarding requirements:

We can implement Failover Cluster on all Windows Server 2012 and Windows Server 2012 R2 editions, including of course Core installations. Previously on Windows Server 2008 R2 the Enterprise or Datacenter Edition were necessary.

Also the concept for “Active Directory-detached cluster” appears in Windows Server 2012, which means that a Failover Cluster does not require a Computer object in Active Directory, the access is performed by a registration in DNS. But, the cluster nodes must still be joined to AD.

Requirements for StarWind iSCSI SAN Software

Here are the requirements for installing the component which will be in charge of receiving the iSCSI connections:

  • Windows Server 2008 R2 or Windows Server 2012
  • Intel Xeon E5620 (or higher)
  • 4 GB of RAM (or higher)
  • 10 GB of disk space for StarWind application data and log files
  • Storage available for iSCSI LUNs: SATA/SAS/SSD drive based arrays supported. Software based arrays are not supported in iSCSI.
  • 1 Gigabit Ethernet or 10 Gigabit Ethernet.
  • iSCSI ports open between hosts and StarWind iSCSI SAN Server. The iSCSI ports are 3260 and 3261 for the management console.
General Recommendations for the Environment

In this scenario, there are several Microsoft and StarWind recommendations we must fulfill in order to get the best supportability and results. Keep in mind that each scenario could require different recommendations.

To mention some of the general recommendations:

  • NIC Teaming for adapters, except iSCSI. Windows Server 2012 improved significantly the performance and of course supportability of network adapters teaming and is highly recommended to use that option for improved performance and high-availability. But we must avoid configure teaming on iSCSI network adapters.

Microsoft offers a very detailed document about handling NIC teaming in Windows Server 2012: “Windows Server 2012 NIC Teaming (LBFO) Deployment and Management” and also check this article “NIC Teaming Overview”.

  • Multi-path for iSCSI network adapters. iSCSI network adapters prefer handling MPIO instead of NIC teaming, because in most scenarios the adapter throughput is not improved and moreover there could be some increases in response times. Using MPIO is the recommendation with round-robin.
  • Isolate network traffic on the Failover Cluster. It is almost mandatory that we separate iSCSI traffic from the rest of networks, and highly recommended to isolate the rest of traffic available. For example: Live Migration in Hyper-V clusters, management network, public network, or Hyper-V replica traffic (if the feature is enabled in Windows Server 2012).
  • Drivers and firmware updated: Most of hardware vendors will require prior to start any configuration, like a Failover Cluster, to have all drivers and firmware components updated to the latest version. Keep in mind that having different drivers or firmware between hosts in a Failover Cluster will cause to fail the validation tool and therefore the cluster won’t be supported by Microsoft.
  • Leave one extra LUN empty in the environment for future validations. The Failover Cluster Validation Tool is a great resource to retrieve detailed status about the health of each cluster component, we can run the tool whenever we want and it will not generate any disruption. But, to have a full “Storage Validation” it is required to have at least one LUN available in the cluster but not used for any service or application.

For more information about best practices, review the following link: “StarWind High Availability Best Practices”.

One important new feature introduced by StarWind iSCSI SAN v8 is the use of Log-Structured File System (LSFS). LSFS is a specialized file system that stores multiple files of virtual devices and ensures high performance during writing operations with a random access pattern. This file system resolves the problem of slow disk operation and writes data at the speed that can be achieved by the underlying storage during sequential writes.

At this moment LSFS is experimental in v8, use it carefully and validate your cluster services in a lab scenario if you are planning to deploy LSFS.

2. Install StarWind iSCSI SAN software

After we reviewed and verified the requirements, we can easily start installing StarWind iSCSI SAN software, which can be downloaded in trial-mode. This represents the simplest step in our list, since the installation does not have any complex step.


In the process, the Microsoft iSCSI service will be required to add to the server and the driver for the software.


After the installation is complete we can access our console and we will see as a first step necessary is to configure the “Storage pool” necessary.

We must select the path for the hard drive where we are going to store the LUNs to be used in our shared storage scenario.


3. Configure and create LUNs in StarWind iSCSI SAN

When we have the program installed, we can start managing it from the console and we will see the options are quite intuitive.


We are going to split the configuration section in two parts: Hosting iSCSI LUNs with StarWind iSCSI SAN and configuring our iSCSI initiator on each Windows Server 2012 R2 host in the cluster.

Hosting iSCSI LUNs with StarWind iSCSI SAN

We are going to review the basic steps to configure the StarWind iSCSI to start hosting LUNs for our cluster; the initial task is to add the host:

3.1 Select the “Connect” option for our local server.

3.2 With the host added, we can start creating the storage that will be published through iSCSI: Right-click the server and select “Add target” and a new wizard will appear.

3.3 Select the “Target alias” from which we’ll identify the LUN we are about to create and then configure to be able to cluster. The name below will show how we can identify this particular target in our iSCSI clients. Click on “Next” and then “Create”.


3.4 With our target created we can start creating “devices” or LUNs within that target. Click on “Add Device”.


3.5 Select “Hard Disk Device”.


3.6 Select “Virtual Disk”. The other two possibilities to use here are “Physical Disk” from which we can select a hard drive and work in a “pass-through” model.


And “RAM Disk” is a very interesting option from which we can use a block of RAM to be treated as a hard drive or LUN in this case. Because the speed of RAM is much faster than most other types of storage, files on a RAM disk can be accessed more quickly. Also because the storage is actually in RAM, it is volatile memory and will be lost when the computer powers off.

3.7 In the next section we can select the disk location and size. In my case I’m using E:\ drive and 1GB.


3.8 Since this is a virtual disk, we can select from either thick-provision (space is allocated in advance) or thin-provision (space is allocated as is required). Thick provisioning could represent, for some applications, as a little bit faster than thin provisioning.


The LSFS options we have available in this case are: “Deduplication enabled” (procedure to save space since only unique data is stored, duplicated data are stored as links) and “Auto defragmentation” (helps to make space reclaim when old data is overwritten or snapshots are deleted).

3.9 In the next section we can select if we are going to use disk caching to improve performance for read and writes in this disk. The first opportunity we have works with the memory cache, from which we can select write-back (asynchronous, with better performance but more risk about inconsistencies), write-through (synchronous, slow performance but no risk about data inconsistency) or no cache at all.


Using caching can significantly increase the performance of some applications, particularly databases, that perform large amounts of disk I/O. High Speed Caсhing operates on the principle that server memory is faster than disk. The memory cache stores data that is more likely to be required by applications. If a program turns to the disk for data, a search is first made for the relevant block in the cache. If the block is found the program uses it, otherwise the data from the disk is loaded into a new block of memory cache.

3.10 StarWind v8 adds a new layer in the caching concept, using L2 cache. This type of cache is represented in a virtual file intended to be placed in SSD drives, for high-performance. In this section we have the opportunity to create an L2 cache file, from which again we can select to use it as write-back or write-through.


3.11 Also, we will need to select a path for the L2 cache file.


3.12 Click on “Finish” and the device will be ready to be used.

3.13 In my case I’ve also created a second device in the same target.


Configure Windows Server 2012 R2 iSCSI Initiator

Each host must have access to the file we’ve just created in order to be able to create our Failover Cluster. On each host, execute the following:

3.14 Access “Administrative Tools”, “iSCSI Initiator”.

We will also receive a notification about “The Microsoft iSCSI service is not running”, click “Yes” to start the service.

3.15 In the “Target” pane, type in the IP address used for the target host, our iSCSI server, to receive the connections. Remember to use the IP address dedicated to iSCSI connections, if the StarWind iSCSI SAN server also has a public connection we can also use it, but the traffic will be directed using that network adapter.

3.16 Click on “Quick Connect” to be authorized by the host to use these files.


Once we’ve connected to the files, access “Disk Management” to verify we can now use these files as storage attached to the operating system.


3.17 And as a final step, just using the first host in the cluster, put “Online” the storage file and select also “Initialize Disk”. Since these are treated as normal hard disks, the process for initializing a LUN is no different than initializing a physical and local hard drive in the server.

Now, let’s take a look about the Failover Cluster feature.

4. Install Failover Cluster feature and Run Cluster Validation

Prior to configure the cluster, we need to enable the “Failover Cluster” feature on all hosts in the cluster and we’ll also run the verification tool provided by Microsoft to validate the consistency and compatibility of our scenario.

4.1 In “Server Manager”, access the option “Add Roles and Features”.

4.2 Start the wizard, do not add any role in “Server Roles”. And in “Features” enable the “Failover Clustering” option.


4.3 Once installed, access the console from “Administrative Tools”. Within the console, the option we are interested in this stage is “Validate a Configuration”.


4.4 In the new wizard, we are going to add the hosts that will represent the Failover Cluster in order to validate the configuration. Type in the server’s FQDN names or browse for their names; click on “Next”.


4.5 Select “Run all tests (recommended)” and click on “Next”.


4.6 In the following screen we can see a detailed list about all the tests that will be executed, take note that the storage tests take some time; click on “Next”.

If we’ve fulfilled the requirements reviewed earlier then the test will be completed successfully. In my case the report generated a warning, but the configuration is supported for clustering.

Accessing the report we can get a detailed information, in this scenario the “Network” section generated a warning for “Node <1> is reachable from Node <2> by only one pair of network interfaces. It is possible that this network path is a single point of failure for communication within the cluster. Please verify that this single path is highly available, or consider adding additional networks to the cluster”. This is not a critical error and can easily be solved by adding at least one new adapter in the cluster configuration.


4.7 Leaving the option “Create the cluster now using the validated nodes” enabled will start the “Create Cluster” as soon as we click “Finish”.

5. Create Windows Server 2012 R2 Failover Cluster

At this stage, we’ve completed all the requirements and validated our configuration successfully. In the next following steps, we are going to see the simple procedure to configure our Windows Server 2012 R2 Failover Cluster.

5.1 In the “Failover Cluster” console, select the option for “Create a cluster”.

5.2 A similar wizard will appear as in the validation tool. The first thing to do is add the servers we would like to cluster; click on “Next”.

5.3 In the next screen we have to select the cluster name and the IP address assigned. Remember that in a cluster, all machines are represented by one name and one IP.


5.4 In the summary page click on “Next”.


After a few seconds the cluster will be created and we can also review the report for the process.

Now in our Failover Cluster console, we’ll get the complete picture about the cluster we’ve created: Nodes involved, storage associated to the cluster, networks and the events related to cluster.


The default option for a two-node cluster is to use a disk as a witness to manage cluster quorum. This is usually a disk we assign the letter “Q:\” and does not store a large amount of data. The quorum disk stores a very small information containing the cluster configuration, its main purpose is for cluster voting.

To perform a backup for the Failover Cluster configuration we only need to backup the Q:\ drive. This, of course, does not backup the services configured in the Failover Cluster.

Cluster voting is used to determine, in case of a disconnection, which nodes and services will be online. For example, if a node is disconnected from the cluster and shared storage, the remaining node with one vote and the quorum disk with also one vote decides that the cluster and its services will remain online.

This voting is used as a default option but can be modified in the Failover Cluster console. Modifying it depends and is recommended in various scenarios: Having an odd number of nodes, this case will be required to use as a “Node Majority” quorum; or a cluster stretched in different geographically locations will be recommended to use an even number of nodes but using a file share as a witness in a third site.

For more information about quorums in Windows Failover clusters, review the following Microsoft TechNet article: “Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster”.

More Resources

To review more information about Windows Server 2012 R2 clusters and StarWind iSCSI SAN review the following links and articles:

About Packaging (and not virtualizing) Applications – Part II: First Approach for Silent Installations

January 14, 2014 at 9:39 pm | Posted in Application Packaging | Leave a comment
Tags: , , ,


After the general overview about application packaging, benefits and best practices in Part I of this series, it is time to start working understanding existing installation packages, handle some examples and reviewing step-by-step processes we will need to start packaging applications.

In this second post, the focus will be packaging applications without the use of any 3rd party tool, basically achieving applications deployment with silent and customized installations. What we will review in this article:

1. MSI Files are your New Best Friends
a) Reviewing the Windows Installer

2. Understanding and Identifying Installer Vendors
a) InstallShield Overview
b) Wise Installation System Overview
c) Inno Setup Overview
d) SetupBuilder and ActualInstaller Overview

3. Packaging Examples for Silent and Customized Installations: First Approach
a) Finding our MSI when there’s no MSI
b) Creating and Using “.iss” Answer Files
c) Troubleshooting InstallShield Deployments

MSI Files are your New Best Friends

So, after we’ve decided that silent installations is going to be our first stop in packaging applications, we must know that MSI files provides the best way to achieve that.

An MSI file is a container that works with an embedded engine in the OS (Windows Installer service) in order to facilitate applications installations and uninstallations. This platform (MSI + Windows Installer service) contains all necessary instruments to accomplish a customized, automated and silent installation.

Later in the next following posts we will discuss on the components in an MSI file, but initially we can take a quick overview about the Windows Installer platform, the MSI files and how we should interact with them.

Reviewing the Windows Installer

The Windows Installer service appeared embedded in the Windows OS since Windows 2000 and with the solution to several problems about inconsistencies in the software vendors on how they were using the application installers, typically in setup.exe files.

The Windows Installer services function is to support the application life-cycle: installation and customization, maintenance (auto-repair and patching for example) and retirement. To process all of these steps is msiexec.exe. MSIEXEC takes all the information contained in the MSI file (installation database, a summary information stream, and data streams for various parts of the installation) and other optional (in most cases) files, to perform the installation or desired process.

These other files can be MST (Windows Installer Transform), which contains customizations for the installation (for example, features to be installed); MSP (Windows Installer Patch) representing application update/patch.

The complete list for installation files available:


It is important to remember that MSI files support silent installations natively; meaning that every application containing one will be suited for this type of installation.

We will take a closer look to the MSI components in the following posts when we start building our own. For now, we will focus on how to use them in silent installations.


As we were talking, msiexec.exe represents the engine from which the Windows Installer performs any of the life-cycle tasks of each application. Using msiexec, if you haven’t before, it’s simple and should not represent any problem.

Once we have our MSI file, using it for silent installations should be in most cases as the following example:

msiexec.exe /I <path_to_MSI.msi> /qn

  • Using “/I” parameter at the beginning we are configuring MSIEXEC to install or configure the application (also known as “product”).
  • The “/qn” parameter represents for a “quiet” (q) installation (no user interaction) and “No User Interface” (n). This way, the application will complete its installation without prompting any notification for the user.

If everything about packaging and deploying applications would be represented by MSI files, then these articles won’t be necessary. We’ll see that most of the times, we will have to deal with EXE files for deployment.

Also, using these EXE files could have different methods according the vendor that created the installer. In the following section we will review how to handle those situations.

Understanding and Identifying Installer Vendors

Even though there are plenty of EXE files which contain MSI files within (to be reviewed later in this post), there are other files with no MSI file available but supporting a silent installation method. To identify how we can silent install the application we must first understand which installer vendor (if any) was used for this app. Identifying is not always easy, the installer icon available could be helpful and sometimes we will just have to guess.

The most common vendors involved in installation files are:

  • InstallShield, from Flexera Software
  • Wise Installation System (formerly InstallMaster), from Symantec (previously from Wise)
  • SetupBuilder, from LinderSoft
  • ActualInstaller, from Softeza Development
  • Inno Setup, from JR Software (open source project)
InstallShield Overview

This is probably the most common vendor involved for developing installation files. We can easily identify their installers by reviewing the logo involved.



There are also two ways we can deploy InstallShield packages, which actually depends if the MSI file was included in the installation package:


1. If the MSI is included in the package, the InstallShield installer should support a silent installation using this example (the /v parameter is optional for verbose):

setup.exe /s /v"/qn"

2. If the MSI is not included there’s an interesting method for some legacy installers to use “answer files”, InstallShield calls this “Package for the Web”. We will need to run an installation with specific parameters to generate our answer file (“.iss”) that we can later use for deploying the application silently and with specific parameters. We will discuss the details later in this article.

The “Package for the Web” has been discontinued by Flexera Software, and it will no longer be available for InstallShield packages. But, most likely, in most organizations we can still find this alternative as a valid method.

To review the complete parameters available for InstallShield check this link: “Setup.exe Command Line Parameters

Wise Installation System Overview

You will find this installation file type in some legacy applications in your environment. Wise Solutions was the creator of this platform, which originally started with CompuServe; later on was acquired by Altiris Inc, which also had been acquired by Symantec on 2007. The last release of this suite was 9.0 but has been already discontinued by Symantec.


The applications created with this platform support the classic “/s” parameter for silent installations.

setup.exe /s

But unfortunately there are no other options available for customization and the exit status when you executed the process was inconsistent, so it might get a little bit confusing.

Inno Setup Overview


This open source project has been receiving significant contribution of the community in all the years it has been available (since 1997), supports all Windows OS, including Windows 8 and Windows Server 2012.

The command line used for supporting silent installations in this suite are:

setup.exe /sp- /verysilent /norestart

  • “/sp-“: Disables the “This will install… Do you wish to continue?” prompt at the beginning of Setup.
  • “/verysilent”: Will execute silently the installation process. The “/silent” parameter is available but, even though it will not require users’ intervention will show a progress bar.
  • “/norestart”: Prevents automatic restarts, which can be very useful if the “verysilent” parameter is used since it will automatically restart the OS without the user intervening.

For more information about Inno command lines available: “Setup Command Line Parameters”.

SetupBuilder and ActualInstaller Overview

SetupBuilder and ActualInstaller represent a couple of somehow new installation packagers’ vendors available in the market. Like many of these recent suites, both platforms support Windows 8 and Windows Server 2012.

One of the most common standards for recent installation packagers is the use of the same type of parameters for the silent and customized installations. SetupBuilder and ActualInstaller have the same silent installation method:

setup.exe /S

Among other providers we will find the same parameters that can be used, we have to be aware that sometimes the parameters are case-sensitive.

Packaging Examples for Silent and Customized Deployments: First Approach

Let’s review some of the examples we can find when we want to package applications using silent and customized deployments.

Finding our MSI when there’s no MSI

One common situation that we might find is that the application we are trying to deploy does not contain an MSI file, instead we are provided with an exe file that could not support silent installations. But, fortunately, most times there are some secrets hiding in plain sight.

When we are handling EXE installer files (usually as setup.exe), several times we are using an installer file that is actually a packaged set of files that contain an MSI, installation instructions and other optional files that could be used during the installation.

Companies use this alternative to have more scalable installation procedures that cannot be achieved with one MSI file. For example: Adding several MSI files which can be activated depending on the type of installation selected by the user. One example for this situation is Apple’s iTunes.

There are a two ways to extract the needed MSI file/s. Let’s review them using Google Earth as our application:

In the particular case of Google Earth, we need to download the standalone installer for the application available in this link.

1. Double click the EXE installer file and when the installation wizard starts access %TEMP% folder to locate our MSI. This process is called “expanding EXE packages”.

Most of the times, the files are located in a folder using a random name (in this case %TEMP%\._msige61).


2. Use 7-Zip File Manager to browse inside the EXE file. This free tool is quite useful, all we need to do is use the option “Open Inside” and we can browse around the installer and handle all the files within.


3. Some software vendors provide a command line to extract the files without the need to double click them or using 7-Zip File Manager.

Once we have our MSI, the process for a silent installation is simple:

msiexec /i “Google Earth.msi” /qn

Creating and Using “.iss” Answer Files

As we reviewed earlier in this article, InstallShield represents one of the vendors commonly used by software companies to create their installers. When we handle this type of installer, we get the simple option to use the “/s /qn” parameter or we might need to create an answer file.

This answer or response file is represented by our “.iss”. This file must be created running a command line which will install the software normally with all the desired options, but creating in the process the .iss file to be used in other deployments. Since every time we need to create an answer file we will need to install the software, using virtual machines and snapshots will be quite useful at this point.

InstallShield also supports the use of different compiled scripts, .ins files. Only applies for InstallScript and InstallScript MSI projects only, InstallShield version 12 and earlier.

The process for creating response files and then deploying the package is the following:

1. Locate your setup.exe (or the installer’s name) and a target machine to deploy the application (ideally a virtual machine).

2. Open a command line and execute the following to create the “setup.iss” response file:

setup.exe /r

The response file will be created in %WINDIR% (typically C:\Windows), but we can alternatively change the path by using the following command line:

setup.exe /r /f1”C:\setup.iss”

Note that there’s no space between –f1 and the “<>“ with the destination path.

3. Install the application with all the customization’s necessary.

4. Once is completed, locate the setup.iss file created.

5. To deploy the application, if we are using the .iss file with the default name (“setup.iss”) and is located in the same folder as the installer, we can deploy our package using the following command line:

setup.exe /s /v/qn

If we changed the name of the response file or we have it located in a different folder, the command line should be the following:

setup.exe /s /f1”<.iss name and location>”

Keep in mind that there’s no space between –f1 and the “<>“ with the file location.

6. [Optional] We can use /f2 as a parameter to create a log file for the deployment:

setup.exe /s /f1”<.iss name and location>” /f2”<.log name and location>

If we don’t set log file name and location, it will automatically generate “setup.log” file.

Troubleshooting InstallShield Deployments

In case there’s a deployment issue with our package, creating the setup.log would be mandatory in order to find out the exact problem we have.

The Setup.log file contains three sections.

  • [InstallShield Silent]: Identifies the version of InstallShield Silent used in the silent installation.
  • [Application]: Details Installed application’s name and version, and the company name.
  • [ResponseResult]: The result code indicating whether or not the silent installation succeeded.

The result codes can be one of the following:

-0 Success.
-1 General error.
-2 Invalid mode.
-3 Required data not found in the Setup.iss file.
-4 Not enough memory available.
-5 File does not exist.
-6 Cannot write to the response file.
-7 Unable to write to the log file.
-8 Invalid path to the InstallShield Silent response file.
-9 Not a valid list type (string or number).
-10 Data type is invalid.
-11 Unknown error during setup.
-12 Dialogs are out of order.
-51 Cannot create the specified folder.
-52 Cannot access the specified file or folder.
-53 Invalid option selected.

In the next article we will review more details about silent and customized deployment, including more examples in more complex scenarios.

About Packaging (and not virtualizing) Applications – Part I

August 15, 2013 at 1:57 pm | Posted in Application Packaging | 3 Comments
Tags: , , ,


It’s been a while since I don’t write new entries in my blog, so I decided to get back on track with a few articles about packaging applications. But, the approach won’t be from the virtual applications perspective, will be focusing on that strange matter of building the right installation, configuration and deployment process for your applications.

What We Will Cover

Packaging applications represents a very vast set of topics that we can discuss, even if we take the virtualization off the table. Here’s a short summary of what we will cover in this set of posts:

  1. Understanding Application Packaging
  2. Silent installations vs. MSI customized packages
  3. Benefits of Application Packaging
  4. Packaging Best Practices
  5. Packaging Applications without 3rd Party Tools (silent installations): Reviewing best practices; Packaging Examples; Troubleshooting .
  6. Packaging Application with 3rd Party Tools: Reviewing the Windows Installer; Reviewing best practices; Packaging Examples; Troubleshooting.

Understanding Application Packaging

Let’s take a moment to talk about application packaging and the statement I’m using about using or not 3rd party tools to achieve it.

Application packaging can actually have several definitions by itself, and it can definitely vary depending on each situation and the outcome we are looking for. But, in a simple manner, I can say that application packaging represents the process from which we can get an automated method to deploy applications with the proper configurations for our environment.


To achieve that, basically, we have two alternatives: Using silent and customized installations or using 3rd party tools (like AdminStudio or Advanced Installer). This second alternative can generate for us, from “capturing” a valid installation, a customized MSI file with the personalization we need for that application (keep in mind that MSI files are, by definition, installation files that can be silently installed).

Silent installations vs. MSI customized packages

Considering silent installations and MSI customized files as valid forms of packaging, we need to establish when we want silent installations or capturing MSI files for deployment.

The answer will depend on these two initial questions:

1. Does the software provider support silent installations and how many parameters can we introduce?

Many providers give us the opportunity to achieve silent installations with all the necessary configurations for our environment. Autodesk and Adobe are great examples, since they provide their own engine to generate “answer files” for the installation process and achieve automated and customized installations.

Many others include in their “User Guide” the right parameters we can use to get similar results in the installation process and some just not provide any method for an automated process.

This is what Autodesk offers us to create our own packages (applies for any suite). A simple wizard to follow and create a “deployment type”; the outcome we can later deploy automatically with all necessary customizations.


2. How many customizations I need to perform in my package in order to have it ready for deployment?

In some cases we have the possibility to perform silent installations with personalized configurations, but sometimes these are not enough. There are several examples of licensed software that require introducing licenses using a manual process; this could be an example of applications that might need for 3rd party tools for packages creation.

Take a closer look to the documentation available for the application and review the parameters we can use to deploy the applications without generating a customized MSI.

In my personal opinion I always try to use the silent installation method as the preferred one. This is because, if the software provider gives us the chance to install and customize the software automatically, then we have an official support and “guarantee” that this software is going to be installed in a proper manner.

If we decide to capture and create an MSI of our own, the package will depend on the software and type of “capture” we will be using for this application; and of course having the risk to exclude files and registries that will be required later using the app.

Benefits of Application Packaging

Let’s take a quick moment to analyze why application packaging is highly recommended in almost any company:

1. Customizing the application so it can fit to our company’s needs and policies: No matter if you are using silent installations or customized MSI, you should be looking for a way to configure your applications properly among all users.

2. Provides an easy, predictable and repeatable way to deploy our applications: Removing the complexity in deployments and the possibility of user misconfigurations not only saves us troubleshooting time but money we need to invest in admins for deployment and support.

3. Helps us standardize our users’ desktops: Related to the previous benefit mentioned, having the standard method to deploy applications also facilitates us in the OS and applications life-cycle; easier to maintain and update.

4. Gives you the possibility to limit the administration rights delegation: When you are using non-packaged apps, you will depend on users or delegated admins to install, reconfigure and/or uninstall applications. Having packaged applications and a deployment tool to deliver the applications, you can annul distributing admins rights to users or help desk personnel for example.

First Approach to Packaging Best Practices

Prior to get our hands into some examples of packaging applications, I want to take a moment to review some of the general best practices when we are packaging applications. When we start talking about some examples, we will take a deeper look into these best practices and some other specific for silent installations or using 3rd party tools for packaging.

1. Understand the application and the environment you are using.

Review applications requirements, documentation (if any) and the scenario you will need to deploy each application. Understand the purpose of the application and targeted users. Understand the environment you will be using for deploying the applications: The distribution method available, operating systems involved, and so on. We usually tend to use a comfortable and predictive environment for packaging the application, this most likely won’t be the environment you’ll be deploying it.

2. Review and write down common use cases for each application so you can test it properly.

Once we completed packaging an application we need, of course, to test it. And it is important to remember that we cannot complete a test just by verifying the installation has completed, we need to have a small group of tests to run on each application, consider having a talk earlier with each application owner to verify the tests you might need to run in order to validate the app functionality.

3. Don’t start packaging until you have the final OS image ready.

Operating systems represents an important part in the packaging process; applications behavior should vary depending on the Service Pack level installed, features implemented (a good example is .Net Framework), other basic components and software to be installed, configurations to be used (for instance, UAC enabled/disabled). If we are using an image as an assumption for the targeted operating systems, we could find several problems with packages not being able to install or applications malfunctions.

4. Prepare a virtual machine with OS “gold image” and use snapshots for packaging.

It is important to have a fresh OS image available whenever you are going to package a new application. And using the term “fresh” doesn’t refers on having a Windows OS without any application installed, should be the “gold image” from which the applications will be later deployed. Having the possibility to virtual machines and snapshots will be crucial to facilitate the process.

5. Try using silent installations as the first option for packaging.

Like I mentioned earlier, using silent installations is the preferred method to start packaging an application. With that, we are ensuring that our app will be installed and supported by the vendor involved. Using a customized MSI file we could have a higher level of personalization and even improving package size and deployment, but it could also result on having to later troubleshoot the application functionality because we excluded necessary files in the app environment.

Also keep in mind that several applications are not suited to be re-packaged into a new MSI and even though you can create a customized packaged, the deployment process won’t succeed.

6. Try not to think applications to be packaged as independent from their OS or other applications.

Since we are not virtualizing applications, these packages won’t exist in a “bubble”, they will have dependencies with OS components as well with other applications. We usually try to package an application in the best scenario, like a fresh installation using from a virtual machine snapshot. We must pay attention if the application could require a reboot for completion, if we are deploying several applications our process could be stopped waiting for a reboot from the previous package. Also, one application requirement could be conflicting with the requirement from a different application.

Try to think out-of-the-box and review any dependencies that could appear in production.

7. Be methodical in the application packaging process

Plan your packaging and deployment processes; document what you are going to do and the tests you perform; prepare checklists and any other thing that can help you and others along the process. If any constraints are found in the packaging process (for instance, applications that require a reboot to complete deployment) write it down and use that information to adjust your planning in the deployment process.

Having a predictable way to package applications will help you and colleagues in their jobs.


In the next post I’ll be reviewing some examples and hands-on processes for applications silent and customized installations.

Free eBook: Windows 8 for IT Professionals

October 23, 2012 at 11:25 pm | Posted in Books, Free Stuff | 1 Comment
Tags: , , ,


I haven’t got much time for publishing new articles in my blog, but I found this brand new publication and I thought it could be useful for a lot of people around there: “Introducing Windows 8, an overview for IT Professionals” (preview version).


This book has some quite important topics that every IT guy which is considering implement Windows 8 in their company should read it carefully. Here’s a short summary for the topics included (I’m just naming a few; the entire list is available in the download):

  1. 1. Overview
  2. 2. Experiencing Windows 8
  3. 3. Windows 8 for IT Pros
    • Customizing and configuring Windows 8
    • Client Hyper-V
    • Redesign NTFS
    • PowerShell 3.0
  4. 4. Preparing for Deployment
    • Windows 8 SKUs
    • Application compatibility
    • User state migration
    • Windows To Go
  5. 5. Deploying Windows 8
    • Windows Assessment and Deployment Kit
    • Deployment and Imaging
    • User state migration tool
    • MDT 2012 Update 1
    • e. SCCM 2012 with SP1
    • f. Desktop Virtualization
  6. 6. Delivering Windows Apps
  7. 7. Windows 8 Recovery
    • DaRT
  8. 8. Windows 8 Management
    • Group Policy Improvements
    • Windows Intune
    • Mobile device support
  9. 9. Windows 8 Security
  10. 10. Internet Explorer 10
  11. 11. Windows 8 virtualization
    • Virtual Desktop Infrastructure
    • Application Virtualization
    • User State virtualization

I did not read it completely, but for what I’ve seen so far the content is not fully detailed with step-by-steps but contains valuable information and guidance that must be read it if you are implementing / managing Windows 8.


App-V Advanced Book Giveaway and the Happy Winner

July 31, 2012 at 7:44 pm | Posted in App-V, Books | Leave a comment
Tags: , , , ,


The giveaway contest for my latest book: Microsoft Application Virtualization Advanced Guide ended June 30th. Now, we can confirm that our happy winner received the book.

Rajesh Attaluri from the UK received is the winner for this contest and is sharing with us a pic. Thank you Rajesh!


Thank you all for participating in this contest and as a reminder, the book is available in the following stores:

App-V Advanced Guide Book Giveaway!

June 11, 2012 at 12:48 pm | Posted in App-V, Books, Cool Stuff, Free Stuff | 1 Comment
Tags: , , , , , ,


As I did for my first book, celebrating the publication of my second App-V book: Microsoft Application Virtualization Advanced Guide, I’m giving away a free paperback copy among my readers.


Here’s a short summary for those who want to participate:

  • Email me at augusto@augustoalvarez.com.ar with the subject: “App-V Advanced Book”.
  • Include in the email body your full name plus the address where you would like for us to send the copy.
  • I’ll close up the contest on June 30 (2012, just in case). All the emails sent until that date will be included in the election, which will be completely random.
  • I’ll notify the winner in the following days and we’ll ship a free copy of “Microsoft Application Virtualization Advanced Guide”.

To avoid any problems, here are some disclaimers:

  • Only one email by person will be included. Do not use different mail accounts to participate several times.
  • Emails that don’t include person’s full name and address will not be considered valid.
  • We’ll cover the expenses regarding shipment but we are not responsible for extra fees or taxes other countries may include in the package.
  • Please don’t send any email requesting exceptions to this contest (like asking for a digital copy of the book), I’m not allow to do any of those.

Remember that the book is available in the following stores: Packt Publishing; Amazon.com; Amazon.co.uk; Barnes & Noble and Safari Books Online.

[Interview] Question and Answer Session with Rod Trent (CEO, myITforum.com)

May 21, 2012 at 12:42 pm | Posted in Interviews, System Center | 1 Comment
Tags: , , , ,


A while ago I started this Q&A series of posts interviewing Aaron Parker (App-V MVP and reviewer of both of my App-V books); and continuing with this series, this time is turn for Rod Trent (myITforum.com owner and CEO).

Rod has been contributing to the IT community in several ways: Evangelizing technical communities, books and articles written, and of course engaging with the large System Center community around the globe with myITforum.com.

You can find more about Rod following him on Twitter: @rodtrent.

Here’s the Q&A:

1. To start with the interview, can you give us a quick synopsis about yourself, your experience and myITforum.com?


I’m a father or four children, ranging from 3 years old to 21 years old and my wife and I, Megan, just recently celebrated our 22nd wedding anniversary. I am a faithful, church-going Christian, an avid gadget fan, a die-hard old television show and cartoon buff, a health and exercise freak, a long-time evangelist of System Center products, and a part-time missionary to the Chinese people.

I have written many books, thousands of articles, and speak at various conferences and User Groups during the year, but my main, professional focus is evangelizing technical community on the web and in “real life”.

I have been in IT for over 25 years. I actually got my start as a computer salesman, moved on to managing a computer repair center, and then finally migrated IT in the early 1990’s, working for a large accounting firm. I have been blessed with a real aptitude to be able to just “fix things.” IT is the perfect industry for that. So, while I’ve kept the techie side, over the years, due to working with myITforum.com, I’ve also become a marketing person. myITforum.com flourishes through the way we highlight and interact with our sponsors. We don’t charge to be part of the community, instead our sponsors help offset our costs, allowing everything on myITforum.com to be free. We don’t believe that support, community, or content should ever have a price tag. So, while it was never an intention of mine to become a marketer, my experience over the last 10 years has been vast, and has served of sponsors well enough to continue building a strong and large community.

Way back in the SMS 1.x days, the product was barely supported by Microsoft itself. So a grass-root, community for SMS 1.x was started on an old, BackOffice support site called, Swynk.com. I ran the SMS section of the web site. I posted articles and tips for SMS since I worked with it daily in my job in a top Accounting Firm. SMS 1.x actually saved our lives at work, giving us the ability to manage desktops with only a handful of support people. So, I simply started sharing my knowledge online. After a few months of success, I was offered a section manager job that paid something like $15 per month and a free technology book.

Traffic and popularity continued to increase, and the community grew larger and larger. Then, at the SMS and Windows 2000 conference (what MMS was called prior to being the Microsoft Management Summit) I was told that Swynk.com was going to be sold to Internet.com. This created a huge issue, as the community cried out with the knowledge that it could, potentially, be broken up.

So, with a little ingenuity and a great set of industry contacts, myITforum.com was born. The community was offline for maybe, 2 months, and then we unveiled myITforum.com 1.0. myITforum.com has gone through numerous changes over the years, but the basic premise has remained. We just help people – and give folks a central location for support, education, training, networking, and giving honest, direct feedback on System Center products.

There’s much, much more to it than that, but that’s the basics. And, the basics work. myITforum.com now receives a little over 145,000 visitors a day, all looking for help and all looking to learn how to manage their environments.

As many probably know our success with myITforum.com and great partnership with Microsoft has led to additional opportunities to be able to reach out and provide community support services for various Microsoft conferences like TechEd and the Microsoft Management Summit. We always look forward to having the great opportunity to “communitize” boring, technical events, and give them that something special to make them memorable and extra valuable.



2. You’ve been really close to System Center evolution over the past years, what do you think about the 2012 editions of this suite? Having all products with the 2012 editions will make a difference in the market?


Pulling the products together is a smart idea, and should really prove gains for Microsoft. ConfigMgr has been the real winner for so long, with very little uptake for the other products. Hopefully, by bringing the products together, particularly from a licensing standpoint, will allow the other products to catch hold. It will be interesting to watch as customers try-out products they would not have before simply because the products are now part of the license agreement.


3. In the past there weren’t many companies that decided to implement the full System Center suite (SCCM, SCVMM, SCDPM, and SCOM) and chose other technologies or simply did not use any tool for specific tasks. Which are the challenges a company should take note in order to consider implementing this complete suite (including also Service Manager)?

Glad you mentioned Service Manager as part of the question. There are pieces of the System Center suite that still seem a bit convoluted and still beta-esque. Service Manager is one of those components. But, whether it’s Service Manager, or some other product, education is the key. Those that have been familiar with specific products, and the way they work, will need to get up to speed quickly, and understand how they can all work together. Orchestrator, in my opinion, is the glue between all of the products, and that may be the single most important piece to understand first.


4. Which are the products and features that you think CTOs and IT decision makers should pay attention the most in the System Center 2012 suite?

From a CTO and decision maker standpoint, I believe the provisioning of the private cloud will be one of the most important aspects. As shown at MMS 2012, you can provision a private cloud in less than 30 seconds. This enables IT organizations to save time, money, and provide SLA and support at unimaginable levels.


5. In the System Center 2012 suite, is there a feature or product that you think might be improved or a missing functionality that should be included in a R2?

I hate to keep harping on Service Manager, but additional functionality is needed to make it easier to work with. Also, in ConfigMgr, Microsoft has to somehow get past the Exchange connector function when supporting mobile devices.


6. Regarding companies’ investments in IT (hardware, services, products, human resources), how do you feel the next few years would be like? Is the cloud model taking over company’s strategies?

The Cloud is on the horizon, but from what I hear in real circles, Microsoft believes it’s closer than anyone else does. It makes sense that they believe this, though, since they are putting so much behind development and marketing of the Cloud from the Microsoft perspective. I believe Microsoft will be highly successful in the private cloud – as to when, that’s up to the customer to decide.


017. With thousands of companies using iPads, iPhones, Android phones and tablets and so on; to maintain compliance, availability and security onto these devices, which is the best approach for client device management?

In line with what I mentioned previously, ConfigMgr and even Windows Intune help to better manage devices like iOS and Android. In fact, Windows Intune may actually do it a bit better than ConfigMgr right now, but I fully expect those functions to show up in ConfigMgr over the life of the 2012 product. If a company wants to manage these devices right now from a full management perspective, they will still need to source a 3rd party; one that provides full integration with ConfigMgr. Odyssey Software (now part of Symantec) is still the best 3rd party solution available.


8. About virtualization and particularly VDI, do you think this trend regarding virtualizing desktops will increase significantly in the following years?

I definitely believe this will happen. In fact, I believe this will become so seamless and so common that it becomes part of normal operating procedure. Right now, VDI gives organizations the ability to not have to worry about compatibility issues with corporate software as they migrate to new technologies. In the very near future, possibly, this will lead to PC operating systems supplied solely from the cloud.

I hope you enjoyed this interview; I’ll get back soon enough with more Q&A sessions.

App-V Books with Packt Publishing Discounts on May

May 13, 2012 at 8:16 pm | Posted in App-V, Books | 1 Comment
Tags: , , , ,


Packt Microsoft Carnival” is a special offer released by Packt Publishing during May from which you can acquire several Microsoft’s titles with important discounts, including “Getting Started with Microsoft Application Virtualization 4.6” and “Microsoft Application Virtualization Advanced Guide”.


Packt’s Microsoft Carnival includes a variety of titles on App-V, BizTalk, SharePoint, SQL Server, Silverlight, .NET Framework stack, XNA, Forefront, System Center and more.

Packt has slashed the cover prices on its selected Microsoft titles by up to 30%. Some of the books include:

My two App-V books are also available in other stores, but the “Packt Microsoft Carnival” discount only applies in Packt Publishing site.

Deploying Windows 8: Unattended Installation Using Windows Deployment Services (WDS) – Part II

April 28, 2012 at 11:25 pm | Posted in Deployment, WAIK, Windows 8, Windows Deployment Services (WDS) | 24 Comments
Tags: , , , , ,


See also: Deploying Windows 8: Unattended Installation Using Windows Deployment Services (WDS) – Part I

In the first post of this series we’ve already reviewed the initial steps for preparing Windows Deployment Services (WDS), adding boot and clean Windows 8 images into the environment, an also how to capture a reference Windows 8 image for deployment. Now, it is time to take a deeper look into the unattended process for deployment.

In this post we will complete our step-by-step guide for unattended deployment of Windows 8 images: Understanding unattended deployment process, generating our own unattended/answer files, reviewing some examples and deploying a full Windows 8 image using our unattended files.

Understanding Unattended Files

The process of automated and silent deployment of an operating system, as well as for any application, depends on parameterizing correctly our setup. These parameters are stored in what we call unattended or answer files.

Starting in Windows Vista / Windows Server 2008 (these two have the same OS kernel), Microsoft improved the setup process of operating systems making it highly scalable and simpler. That’s why these unattended files are presented in an XML.

Using XML as unattended files makes sense since this markup language is used to structure, store, and transport information. Structure is a key term because Windows setup is composed by “configuration passes” which are basically the phases of a Windows installation; and the answer file can structure the information in an efficient manner to offer answers for each phase.

Reviewing Configuration Passes

As we said, the configuration passes represents the phases included in a Windows installation; those phases are basically the same since Windows Vista, even though several of its components have changed over time.

To understand a little bit more about the unattended files we are about to create, let’s review the configuration passes included:

  1. windowsPE: In this phase we can find the configurations and parameters used in Windows Preinstallation environment (reviewed in Post I), for example handling the disk where we are going to install the OS.
  2. offlineServicing: This configuration pass is used to apply updates, drivers, or language packs to a Windows image.
  3. generalize: In this phase computer-specific information is removed from the Windows installation enabling you to capture and reapply the Windows image to different computers.
  4. specialize: In this stage we can find several Windows configurations like enabling features, network settings and domain settings.
  5. auditSystem: This phase is only used when we select to boot using audit mode. Settings apply here before a user logs onto the computer, for example to installing out-of-box drivers.
  6. auditUser: This phase also runs when audit mode is selected in the boot process. Here are settings applied when a user logs onto the computer.
  7. oobeSystem: In this configuration pass, settings are applied before the “Windows Welcome” message starts. Some options usually used are language or creating user accounts.

Here’s a short diagram, taken from Microsoft TechNet, to explain the configuration passes:


For more information, visit the following link: “How Configuration Passes Work

Reviewing Unattended Files Best Practices

Before we jump into creating our own unattended files, let’s review some common best practices we need to know:

  • Review and understand configuration passes: We need to have the installation phases clear as we explained above; understanding them will allow us to use the right components and settings.
  • Always validate answer files: Windows System Image Manager (WISM) is the tool we are going to use to create our unattended files; this tool includes the option for “validation” which verifies that the settings we’ve configured are set correctly and there’s no inconsistency.
  • If you have Windows Vista / Windows Server 2008 unattended files, do not try to use the same for Windows 7 or Windows 8: Even though all of them use XML files, there have been several changes in time. Take a look to the following link: “Changes in Unattended Setup Settings from Windows Vista and Windows Server 2008”.
  • Don’t add unnecessary settings: Answer files could contain hundreds of settings, which translate in time to parse them and slow installation processes. Do not use unnecessary settings that could delay the OS deployment.
  • When you are not sure about the setting value, try WISM help: All of components include a “help” option which describes the setting and provide some examples. If you are not sure what value to use or if you can leave the setting “empty”, check the help file to verify.
  • Use separate answer files for separate images and architectures: It is not convenient to use same answer file to different OS architecture. Even though it is possible to include same settings for both architectures in the same file, it could lead us into deployment problems or failures.

6. Preparing Windows System Image Manager (WISM)

Windows System Image Manager (WISM) is included in the Windows Automated Installation Kit (AIK) as one of the tools offered to customize Windows OS deployments.

Using WISM we are going to be able, taking a selected OS image, to retrieve the configuration passes included and modify the settings available on each phase. To prepare it for creating our unattended files we only need a simple process:

6.1. Download and install Windows Automated Installation Kit (AIK).

6.2. Copy the “install.wim” file from Windows 8 media to a local folder (must be available to WISM for read/write operations).

If we don’t have the media available, we can still use the reference Windows 8 image we’ve uploaded in Post I. We need to use the “Export” option from WDS console.

6.3. Access Windows System Image Manager (WISM), “File” and “Select Windows Image” and select the WIM file we’ve copied or exported.


If WISM is not able to perform read/write operations to the file we selected we will receive an error message saying “Windows SIM was unable to generate catalog. Details: The specified image file did not contain a resource section

6.4. Now we will have all the components available in the image. We are going to select several of these components and add those to the configuration passes.


Optionally we can use a “Distribution Share” in WISM; in here we can save drivers and other files to use them in the configuration passes.

7. Creating and Using WDSClientUnattend.xml

Here’s an example of WDSClientUnattend.xml for Windows 8.

Now that we have WISM ready to start creating answer files, we are going to start with the first one used by WDS: WDSClientUnattend.xml. In this file, we will configure all necessary components related to our first configuration pass: windowsPE.

The components we will need to add are the following:

  • amd64_Microsoft-Windows-International-Core-WinPE_6.2.8250.0_neutral\SetupUILanguage
  • x86_Microsoft-Windows-Setup_neutral\DiskConfiguration\Disk\CreatePartitions
  • x86_Microsoft-Windows-Setup_neutral\DiskConfiguration\Disk\ModifyPartitions
  • x86_Microsoft-Windows-Setup_neutral\WindowsDeploymentServices\ImageSelection\InstallImage
  • x86_Microsoft-Windows-Setup_neutral\WindowsDeploymentServices\ImageSelection\InstallTo
  • x86_Microsoft-Windows-Setup_neutral\WindowsDeploymentServices\Login\Credentials

7.1. To start adding them, in “Components” right-click on the selected one and use “Add Setting to Pass 1 windowsPE”.


7.2. After adding all of those mentioned, the WISM console should be looking like this.

Now we need to start editing this components and adding some values.

7.3. For example: Selecting “amd64_Microsoft-Windows-International-Core-WinPE_6.2.8250.0_neutral”, we need to configure the options for “InputLocale”, “SystemLocale”, “UILanguage”, “UILanguageFallback” and “UserLocale”. In my case I’m selecting all of them as “en-US”.


To understand the option we are selecting, we can right-click the setting in WISM and select “Help”. In there, we will find a complete description to understand the setting and in some cases a few examples to use in the answer file.

7.4. The rest of values that need to be added can be reviewed in the following table:


Here’s an example of WDSClientUnattend.xml for Windows 8.


  • When we use the “CreatePartitions” and “ModifyPartitions” components, we need to first right-click on this option, select “Insert New CreatePartition” and then we will receive the options to edit.
  • Value used in “Filename” name must be the WIM file located in WDS. For example “install.wim”.
  • Also, in “ImageGroup” and “ImageName” we must use the values used in WDS console.


7.5. After completing the settings values, we need to validate the answer file. Select “Tools” and “Validate Answer File”.


7.6. Verify that in the lower section, “Messages”, there’s no warning / error appearing.


7.7. Save the file and place it in “%drive%\RemoteInstall\WdsClientUnattend”. This particular file must be located in this folder, and should not be moved.


7.8. To configure the unattended file, access the WDS console and right-click the name of the server selecting “Properties”.

7.9. Select the “Client” pane. Since in this example we’ve used the x64 architecture, browse for the XML file in the selected section.


IMPORTANT: Using WDS we can only assign one WdsClientUnattend file at a time (considering the same architecture for all clients). And as we can see, these file contains the image file we are going to install, so every time we need to change the image, to use a full unattended installation we are going to need to manually change the unattended file.

8. Creating and Using AutoAttend.xml

Here’s an example of AutoAttend.xml for Windows 8.

Our second unattended file is dedicated to the Windows customization, as well as providing some important settings to the computer, for example: Product key, computer name, joining it to domain or workgroup, and so on.

Using this answer file we are going to focus in two configuration passes: 4 specialize and 7 oobeSystem. Let’s take a look to the components we are going to use:

Cycle 4: specialize

  • amd64_Microsoft-Windows-UnattendedJoin_neutral\Identification\Credentials
  • x86_Microsoft-Windows-Shell-Setup_neutral

Cycle 7: oobeSystem

  • amd64_Microsoft-Windows-International-Core_neutral
  • amd64_Microsoft-Windows-Shell-Setup_neutral\OOBE
  • amd64_Microsoft-Windows-Shell-Setup_neutral\Themes
  • amd64_Microsoft-Windows-Shell-Setup_neutral\UserAccounts\AdministratorPassword
  • amd64_Microsoft-Windows-Shell-Setup_neutral\UserAccounts\LocalAccounts\LocalAccount\Password

8.1. Select “File”, “New Answer File” WISM to start creating the new unattended file.

8.2. Add the mentioned components to their particular cycles.

8.3. After it’s done, the WISM pane should look something like this.


8.4. Complete the settings using the values shown in the following table.


Here’s an example of AutoAttend.xml for Windows 8.


  • In “ProductKey” setting, the value must be entered using the “-“ as separator between 5 digits. For example: 6RH4V-HNTWC-JQKG8-RFR3R-36498
  • When we add “LocalAccount” component, as we did for disk partitions, we need to right-click the component and select “Insert New LocalAccount”. In my example, I’m adding the “Admin” user in the Administrators group.

8.5. Validate the answer file. Take note that using these components, there will be some warnings generated that we can actually ignore.


For example, some components that is deprecated and no longer used in Windows images like “StartPanelLinks”.

8.6. Save the answer file and place it in any location available for WDS Server. This particular file does not have to be saved with any special name nor location.

8.7. To associate this file with the reference Windows 8 image, access the WDS console and select “Properties” in the install image we would like to use the unattended file.

8.8. In the lower section, select the option “Allow image to install in unattended mode” and select the file we’ve just created.


9. Deploying Windows 8 Using Unattended Files

Once we have completed the unattended files and associate them in Windows Deployment Services (WDS) console, the rest is really simple: Just turn on a client machine and start a PXE boot.

9.1. Start the PXE boot in any client machine.

9.2. Make sure you select the Windows PE for booting an installation and not the capture process.


9.3. Review that the steps are completing without any user intervention.


When the normal installation is finished, in “Finalizing your settings” stage all the customizations in the image will be performed.


9.4. After the process is done, we should see in our case the OS ready for account login using domain credentials.



As we can see, the processes involved for a fully unattended deployment of Windows 8 are really simple:

  • Installing and configuring Windows Deployment Services (WDS) only requires a couple of wizards.
  • Adding clean boot and install images for Windows 8 to WDS does not require any complexity, just by using Windows media we can complete it.
  • Capturing a reference Windows 8 basically requires running sysprep and boot the machine using a capture boot image.
  • To create our own unattended files using WISM, we have all the support we need in the same tool.

Taking these aspects into account, I think all IT departments should consider using an automated and unattended deployment for Windows operating systems. Using this free tools offered by Microsoft can improve IT processes efficiency in large amounts.

See also: Deploying Windows 8: Unattended Installation Using Windows Deployment Services (WDS) – Part I

Deploying Windows 8: Unattended Installation Using Windows Deployment Services (WDS) – Part I

April 25, 2012 at 12:45 am | Posted in Deployment, WAIK, Windows 8, Windows Deployment Services (WDS) | 8 Comments
Tags: , , , , , ,


See also: Deploying Windows 8: Unattended Installation Using Windows Deployment Services (WDS) – Part II

For a while now I’ve been preparing articles in this blog regarding deploying operating systems, and especially unattended deployments. I’ve started with Windows Vista deployments and the initial version of Windows Deployment Services (Post I, Post II and Post III); the moving forward with Windows 7 using also WDS (Post I and Post II), and also MDT 2010 adding Microsoft Office 2010 to the mix (Post I, Post II and Post III).

And of course, with the release of Windows 8 I had the necessity to prepare a new set, even though this new OS is just at “Consumer Preview” beta.

This set of posts is intended to provide step-by-step procedures to accomplish a full automated deployment of Windows 8 using WDS.

Overview of the Process

The main goal of this process we are going to review in detail is to provide an unattended deployment of Windows 8 using Windows Deployment Services (WDS).

In order to provide a complete guidance, we are going to capture an installed Windows 8 image, add it in WDS and then use this customized image to deploy it using unattended files.

In this set of posts we are going to examine:

  1. Reviewing requirements.
  2. Installing and configuring WDS Role.
  3. Adding Boot and clean Windows 8 images to WDS.
  4. Create a capture boot image in WDS.
  5. Capture the Windows 8 reference machine.
  6. Prepare Windows System Image Manager (WISM).
  7. Manage first unattended file: WDSClientUnattend.xml
  8. Manage second unattended file: AutoAttend.xml
  9. Deploy Windows 8 using Unattended Files.

1. Reviewing Requirements

For the scenario we are going to review, here are the pre requisites we must fulfill in order to complete the unattended deployment of Windows 8:

  • Active Directory and DNS server in place. The computer running WDS must be a member of an Active Directory.
  • An active DHCP server on the network
  • An NTFS partition on the server with the WDS role to store your OS images.
  • Windows 8 media. To download it, access this link “Windows 8 Consumer Preview”.
  • Windows Automated Installation Kit (WAIK). This is an optional component that we can use to create unattended files.

The WAIK version we are going to use is the version released for Windows 7, which is available in the following link: “The Windows® Automated Installation Kit (AIK) for Windows® 7

2. Installing and Configuring WDS Role

The steps necessary for this are really simple and covered in this previous post of mine: “Deploying Windows 7 Using Windows Deployment Services (WDS): Step-by-Step – Part I”.

3. Adding Boot and Clean Windows 8 Images to WDS

These steps are also simple if you ever manage WDS. Let’s review them:

3.1. Access the WDS Console and right click in “Boot Images” and select “Add boot image”.


3.2. Select the Windows 8 media and locate “%drive%\sources\boot.wim”.


The “boot.wim” file is the Windows Preinstallation Environment (Windows PE), which is a minimalistic OS in charge of preparing the environment prior the installation. For more information about Windows PE, check the following link: “What is Windows PE?

3.3. Select the name we are going to use to identify the image, in my case “WinPE – Windows 8 (x64)”.


3.4. Click “Next” in the following screen and wait until the process completes.

3.5. Once it’s completed, in the WDS console the new image will appear.


3.6. Now, for adding a clean Windows 8 install image, in the WDS console right-click “Install Images” and select “Add Install Image”.


3.7. Create a new image group; in my case I’m using “Windows8”.


3.8. Select the installation file available in Windows 8 media in the following path: “%drive%\sources\install.wim”.


The “install.wim” file is where all the Windows operating system files are stored and compressed for optimization. In this new version, the Windows 8 files we have available in the media correspond to the specific version of Windows we’ve downloaded. In the previous versions (Windows Vista and Windows 7) the size of “install.wim” was a little bit bigger since it contained files from several OS versions.

Also, in Windows 8, the compression algorithm for this file has change in order to optimize the download process for installation.

3.9. Click “Next” in the image selection window.


3.10. Also click “Next” in the following step to confirm the new image to be added.

3.11. Once we click “Finish”, we will see the new image added to Windows Deployment Services.

An important part of the OS life cycle in our environment is to distinguish the base images we are using. This base image does not only refer to the OS, it also includes the applications and basic configurations we add to the operating system.

Even though we don’t need to capture a reference Windows 8 image to accomplish an unattended deployment, we are going to take this scenario to understand a little bit more about the possibilities in WDS.

4. Create a Capture Boot Image in WDS

In order to be able to capture a Windows 8 image using WDS, we must convert a boot image into a “Capture Boot Image”.

This type of image is basically a Windows PE modified to be in charge of capturing a prepared Windows 8 image, instead of providing the environment for an installation. The steps are really simple:

4.1. Copy the “boot.wim” file located in Windows 8 media to a local folder in WDS. Alternatively we can “Export” the boot image we’ve added in WDS.

4.2. Right-click in the existing boot image in WDS and select “Create Capture Image”.


4.3. Select the image name, description, and the location of the “boot.wim” file copied in the first step.


4.4. We’ll receive a warning regarding the image we are about to modify: “Image File with the same name already exists. Do you want to append to the existing file?


Clicking “Yes” will keep the original WinPE image and add the capture WinPE; if we click “No”, the entire image will be overwritten with the new capture WinPE.

Take note that we are not going to replace the boot image we’ve added earlier in WDS; in these steps we are going to generate a new one.

4.5. Complete the steps and select “Add image to the Windows Deployment Server now”.


4.6. Confirm the location of the new boot.wim file.


4.7. Insert the boot image name, in my case “Capture (x64)”.

4.8. Complete the wizard and the new boot image should be added to WDS.

5. Capture the Windows 8 Reference Machine

The capturing process of a Windows image is performed by using a tool provided by Microsoft “sysprep”. Sysprep is the component Microsoft provides in order to IT teams be able to scale OS implementations.

With sysprep we are able to “generalize” an OS by removing some particular characteristics in Windows and transforming this new “generalized” image in a prepared OS ready for a massive deployment. If the image is not generalized we will not be able to capture it using the image we’ve selected earlier.

By applying sysprep we’ll be able to remove some specific data from the OS installation, for example:

  • Computer name
  • Owner and Company name
  • SID
  • Domain or workgroup membership
  • TCP/IP Settings
  • Regional and keyboard settings
  • Specific hardware drivers. This refers to specific computer hardware, like video or audio drivers. But if you only applied drivers used on the Windows installation, the same will apply for the deployment, but any other external driver installed will be unavailable.
  • Any saved network connections (wireless networks saved)
  • OS product key. This is an important note, since no matter if your product has been activated; the key is reset after this process.

But of course, there are other several components that will be kept to maintain this as a base image. For example:

  • Programs and features installed.
  • Local Users and Groups created.
  • Product Keys used for programs installed. Meaning if you have Microsoft Office installed, the key used will remain as the same on the deployments.
  • Windows updates installed
  • User Profiles: Since all the profiles configuration are basically data stored on the Users folders, all that information will be uploaded within the image.
  • Printers installed.

For more information about sysprep, take a look to the following link: “What Is Sysprep?

The process of preparing the image requires only running a specific command line; let’s take a look to the steps:

5.1. Access the reference Windows 8 image.

5.2. In a command prompt, locate the following folder: “C:\Windows\system32\sysprep”.

5.3. Run “sysprep /oobe /generalize /shutdown” (alternatively the /reboot parameter can be used). This command line will generalize the OS removing the specific components mentioned above and shutdown after the process is completed.


We must remember that, since this OS is going to be generalized, the next the normal boot process occurs, it will appear as Windows was just installed. And, of course, prior to that we must capture this image and store it as our base Windows 8 image in WDS.

For more information about this generalize process, take a look to the following link: “Prepare to Capture an Image for Deployment (Generalize)

5.4. Configure the reference machine to boot from network. Usually by using F12 in the start of the boot process we will be able to select the network card as the preferred boot option.

5.5. Boot from network in the reference machine. Since we have two boot images available in WDS, we should see something like this.


Select the capture image.

5.6. Once the capture image is loaded, a new wizard will appear.


5.7. Select the volume to capture “C:\” and select an image name and description.


If no drive is available to select, this means that the image was not generalized properly. The only volumes that can be captured are those generalized with sysprep.

5.8. Select a local path for the image location and optionally we can upload the image we are going to create to WDS; for that we need to use the WDS Server FQDN (we will be prompt for credentials) and selecting the image group.


If the image is not uploaded to WDS, we can still retrieve it later in this machine and import it manually to the server using the WDS console.

The capturing process will start and is going to take a while to prepare the reference WIM file.


With that, we’ve completed the steps to prepare our environment and the reference image is uploaded in WDS.

In the next post, we are going to take a deep dive into the unattended files: Understanding how they work, some best practices and of course generating our own for a complete unattended Windows 8 installation using WDS.

See also: Deploying Windows 8: Unattended Installation Using Windows Deployment Services (WDS) – Part II

Next Page »

Create a free website or blog at WordPress.com. | The Pool Theme.
Entries and comments feeds.


Get every new post delivered to your Inbox.

Join 144 other followers