White Paper

10 Steps to Improving
your Deployment Process to
Microsoft Environments
APPLICATION DEPLOYMENTS At XebiaLabs, we have decades of combined experience deploying to, and
supporting customers deploying to, complex Microsoft and .NET environments.
1. Require Silent Installers
Based on this wide-ranging knowledge, we have collected a list of practices
2. Look Out for Local and recommendations that can help you improve your application deployment
Admin Permissions process to your Microsoft-based middleware stack.
3. Look Out for UAC
Many of the following practices, which we have grouped into Application
4. Look Out for System Restarts
Deployments, .NET Deployments and General sections, are applicable and
5. Learn About PowerShell valuable in other middleware environments too. We also discuss issues
6. Learn About WinRM specific to Microsoft systems and applications.

DEPLOYMENTS TO IIS

7. Avoid XCOPY Best Practices for Application Deployments

8. Avoid MSIs 1. Require Silent Installers
9. Website and Application To begin with an obvious recommendation, ensure that all installers that need to be
Pool per Application automated provide an adequate “silent” or “unattended” mode. Also ensure that the
all the options available during an interactive install can be specified, not just e.g.
10. Single Version of Web.config the default settings.

Attempting to automate interactive installers using scripted screen interactions is

GENERAL simply too brittle and complex to be effective in a large-scale environment.

11. Consider the Entire

Microsoft Stack 2. Look Out for Local Admin Permissions
12. Consider Components The members of the “Administrators” group lack some of the privileges of the local
Outside the Stack Administrator account. Requiring local Administrator permissions is not a blocker for
automated deployment, thankfully, but it does mean that the account needs to be
13. Version Artifacts with enabled at least temporarily. Check this with your security team as disabling the
Application Configuration local Administrator is becoming a more common security practice.
and Prerequisites
Managing, distributing and updating credentials for many local accounts also adds
14. Automate Environment and
administrative overhead. Managing one domain account that is added to each
.NET Middleware Provisioning machine’s Administrators group is definitely preferred.

Ideally, of course, your applications will not require any elevated permissions and
can be installed using e.g. a Power User account.

xebialabs.com
White Paper

3. Look Out for UAC

User Account Control adds a potentially valuable layer of safeguards but
can make automated deployments tricky since UAC is designed to be non-
automatable and almost always requires user interaction.
XL DEPLOY, WINDOWS & .NET
XebiaLabs’ XL Deploy is the only Ensure your installation procedures are not only tested using an administrative
fully-automated Application account, which often does not prompt for this additional confirmation.
Release Automation solution If there is no way to avoid UAC-prompting actions during your deployments,
on the market today. XL Deploy you could consider a “preparation” phase for new systems, during which
was built from the ground up UAC is disabled, before they are released to end users.
to support the best practices
derived from our extensive
experience of deploying to 4. Look Out for System Restarts
Windows and .NET and Most system-level changes to a Windows system (installations as well as
working with Microsoft. uninstallations!) require a restart to complete. Installers that force a system
reboot add a significant level of complexity to the automation process:
Featuring out-of-the-box simple installation scripts need to broken up into chunks that are coordinated
Windows and .NET deployment by a higher-level process that tracks which chunks have been completed,
logic, XL Deploy offers unrivaled re-establishes connections to restarted target systems, supports timeouts
support for the Windows in case servers do not come back, and other common scenarios.
middleware stack including
Windows OS, SQL Server, Try to ensure your deployments do not require any system restarts or, if
IIS and BizTalk. XL Deploy can unavoidable, allow all restarts to be combined into one final action once the
deploy over 100 Microsoft last component has been deployed. Unfortunately, this can be difficult or
application and configuration impossible if components depend on the completed deployment of prior
types out-of-the-box, supports components that require restarts.
many additional components
beyond the Microsoft stack, and
In either case, if restarts cannot be avoided, ensure your automation tooling
supports the “chunking”, re-establishing of connections, timeouts etc.
integrates with Windows Azure.
described above.
With XL Deploy, organizations
can accelerate time to market
5. Learn About PowerShell
for Windows and .NET
applications and eliminate Batch files have served us well for a long time and will doubtless be around for
manual activities and scripting, a while to come, but the “weapon of choice” for Windows automation is clearly
while reducing cost and PowerShell, especially on the server side.
error rates.
Apart from being Microsoft’s preferred way of doing automation, PowerShell is
more uniform and powerful than batch files. It’s also more tightly and effectively
integrated with the underlying OS runtime, avoiding some of legacy holdovers
from the times of DOS. More and more examples, modules, content packs
and generally useful scripts are being produced by Microsoft and the Windows
community, continually increasing the chances of being able to reuse code
produced by experts, rather than having to re-invent many wheels.

PowerShell provides a useful set of building blocks for all kinds of

administrative tasks. Bear in mind, though, that assembling these blocks
into a deployment automation solution that covers your various use cases
will require significant scripting effort.

xebialabs.com
White Paper 3

6. Learn About WinRM

After Telnet and the associated security issues that make it almost unusable
in a secured environment, Microsoft finally provided a standards-based remoting
interface for its operating systems. Windows Remote Management is available
for Windows XP (on the desktop side) and Windows 2003 (on the server side)
upwards and has become progressively more “enabled by default” in
newer versions.

WinRM supports a number of security features including HTTPS connections

and encrypted messages and supports Kerberos authentication. Libraries for
remote execution via WinRM are available for a variety of languages. Finally an
alternative for long-running Remote Desktop sessions!

Best Practices for Deployments to IIS

1. Avoid XCOPY
XCOPY, ROBOCOPY and similar file transfer programs are fine for moving web
content from one place to another, but that is not exactly a complete solution for
IIS deployments.

In the first place, it assumes that all the configuration settings – websites,
application pools etc. – have already been set up in IIS. This may still be a
reasonably infrequent task relative to web content updates, but with increasing
capabilities around automatically provisioning new environments and scaling
existing ones it is important that your deployment automation can handle
configuration settings as well as file transfers.

XCOPY and ROBOCOPY also do not support placeholder replacement or other

means of environment-specific customization. Unless you are fortunate enough
to be able to use the same Web. config in all environments, you will need some
additional logic to handle environment-specific values.

In addition, XCOPY and ROBOCOPY do not handle file copies atomically, i.e.
either copying all the files successfully or making no changes to the target system.
If a problem occurs halfway through the file transfer, you will be left with a
partially updated site. Some additional logic to copy first to a staging location,
followed by an atomic rename or update of the website’s physical path, is a
common solution to this particular challenge.

2. Avoid MSIs
Although MSIs are the workhorses for many application deployments to
Microsoft platforms, they are not well suited to IIS deployments. Firstly, it’s hard

xebialabs.com
White Paper 4

to define configuration settings such as website or application pool attributes

in an MSI, other than actually including the script or command to perform
the configuration.

This lack of separation between deployment content (provided by developers)

and deployment logic (determined by middleware experts) means that many
organizations end up unpacking or indeed re-packing MSIs to verify or modify
the deployment logic.

Such repackaging is also often required to make settings such as the target
website name configurable in order to be able to deploy to different environments.
This is especially common when MSIs are provided by developers, based on the
development environment.

Even when MSIs are created flexibly enough to suit the needs of the various
target environments, they still present a “closed” interface that does not allow
for easy preview of the various steps that will be, or tracking of the actions
that are being, performed. This results in a lack of visibility into the multi-
step process of a typical IIS application update.

Rollback support is good but the silent install capabilities of MSIs are still brittle:
if an incorrect input value is entered or unexpected errors occur, msiexec can still
attempt to throw up dialog boxes that cannot cannot be closed automatically.

3. Website and Application Pool per Application

It may be tempting and convenient to simply stick everything under a single
website and application pool – no configuration changes required to add a
new application – but it greatly increases your deployment flexibility if each
application uses its own website and pool.

This allows the website and application pool settings to be tailored to match
the needs of one specific application, rather than becoming the common
denominator for many apps where e.g. one application needing basic
authentication may mean that all applications are accessible in that way.

It also makes lifecycle management of your applications much more flexible,

since e.g. the application pool can be stopped to release file locks without
multiple applications being affected. Obviously, the configuration settings
for the pool and website should be versioned alongside the application
and form part of the application deliverable.

4. Single Version of Web.config

In most enterprise scenarios, websites need to be configured slightly
differently depending on the target environment, since e.g. the payment
provider endpoint or database credentials will differ between dev, test,
QA and production. One common approach to this problem is to maintain
one Web.config file for each target environment, usually stored together
in source control as Web.config.dev, Web.config. test etc.

xebialabs.com
White Paper 5

Almost inevitably, successive changes lead to these files drifting out of sync,
with new entries not correctly propagated to all versions, copy-pasting of
new entries leading to values for e.g. the dev environment appearing in the
QA file etc. The overhead and potential for error of managing multiple
files can be avoided if only a single version of Web.config is maintained.
This version contains placeholders for all environment specific settings
which are automatically replaced by the appropriate values at deployment
time, based on the target environment.

Such a tokenized Web.config documents at a glance which configuration

settings are required from the middleware support or operations teams
before an application can be deployed. It also provides an important fail-fast
mechanism, since the deployment can be stopped if any placeholders remain
unresolved – something that is not easily possible if the file simply contains
an incorrect value.

Finally, tokenized Web.config files also mean that no sensitive information,

such as credentials to a production database, need be stored in a developer-
accessible source control system.

General
1. Consider the Entire Microsoft Stack
Microsoft offers a family of products, and while automating one part of the
stack such as IIS is a good step, if there are still manual processes in place for
all the other components that make up real-world applications - database
updates, registry changes etc. - there are still error-prone links in the chain.
Most Microsoft products expose decent automation interfaces, and PowerShell
is slowly becoming the unified mechanism to handle multiple products.
Identify a strategy to leverage PowerShell to unify point solutions.

Automating deployments across the Microsoft platform creates a shared

interface that encourages collaboration between developers, middleware
specialists and operations and so supports the creation of a DevOps culture.

2. Consider Components Outside the Stack

Enterprise deployments often reach beyond the Microsoft stack. Bear in mind
that apps will use components such as other databases like Oracle, configuration
files or libraries to be placed on the file system, or will require interactions with
load balancers etc.

Ensure your automation can handle all the steps required to deploy
your applications. Otherwise, you’ll again be left with error-prone steps
outside the Microsoft stack.

xebialabs.com
White Paper 6

3. Version Artifacts with Application Configuration and Prerequisites

Most applications are more than just an EXE or some web content for IIS.
Keep information about your application configuration – the registry keys,
shares, virtual directories, application pools etc. that are required for
this application and which you also want to remove when the application
uninstalls alongside code so you know what your application actually
needs to run, even if you have to set it up in a brand new environment.

Configuration changes required for a new version simply take place as part
of the deployment to the next environment – no waiting around for the
middleware team to deal with a configuration request. Even better, backing
those configuration changes out again is as simple as downgrading to the
old application version: no more IIS installations with lots of potentially
“stale” configuration resources about which nobody can say whether
they are still in use or not.

Your application’s prerequisites, e.g. requiring a specific version of the .NET

framework, should be captured alongside any configuration settings in
the same versioned package. In this way, you can easily verify whether a
target environment is even ready for your application to be deployed.

4. Automated Environment and .NET Middleware Provisioning

A lack of available test environments, and environments that have been
misconfigured or modified by previous users, are a leading cause of deployment
failures and project delays. “Clean” environments greatly reduce the risk of
old settings or configuration changes made for unrelated applications
frominterfering with your applications.

Many proven options exist to automatically provision a Microsoft stack, from

cloud management systems based on Hyper-V or VMware’s vSphere and vCloud,
to dedicated provisioning tools like PuppetLabs’ Puppet and Opscode’s Chef.
These tools, combined with versioned environment configuration, allow you
to quickly spin up ready-to-use target environments that satisfy your
applications’ prerequisites.

The capabilities of some of these tools to continually track environment

configuration changes and enforce a “known-good” state also avoids time-
consuming and expensive troubleshooting exercises to tackle configuration drift.

If you are able to modify your applications to handle slightly different runtimes,
or are starting a greenfield project, consider fully-managed platforms such as
Azure’s PaaS layer. These dramatically reduce the effort required to provide
automated, “on-demand” development and runtime environments.

xebialabs.com
White Paper 7

About XebiaLabs
XebiaLabs develops enterprise-scale Continuous Delivery and DevOps software, providing companies with the
visibility, automation and control to deliver software faster and with less risk. Global market leaders rely on XebiaLabs to
meet the increasing demand for accelerated and more reliable software releases.

The XebiaLabs DevOps Platform for

Continuous Delivery at Enterprise Scale

Release Orchestration Deployment Automation DevOps Intelligence

Orchestrate, automate and get Automate and standardize complex Get unprecedented insight and decision
visibility into release pipelines application deployments support for your software delivery process

For more information and a free trial please visit www.xebialabs.com.

xebialabs.com