Web deploy

Automating Deployment with Microsoft Web Deploy
Monday, September 13, 2010 .NET ASP.NET IIS7 Visual Studio

This is the twenty-eighth in a series of blog posts I’m doing on the VS 2010 and .NET 4 release.

This blog post continues a series of posts I’m doing that cover the new improvements we made around web deployment. In my first post in the deployment series I provided an overview of the new VS 2010 Web Deployment features.

In today’s post I’m going to be discussing Microsoft Web Deploy – which is a free server technology that enables a comprehensive publishing and deployment mechanism. Web Deploy enables you to not only publish files – but also provision database schema/data, run database change scripts, set security ACLs, and more. All of these deployment steps can be automated using Visual Studio.

This post will provide a step by step tutorial on how to install Web Deploy and enable it on a web-server. I’ll then demonstrate how you can use Visual Studio 2010 to directly publish to servers using Web Deploy, as well as how you can use Visual Studio to create installation packages that you can use to automate the deployment of your applications.
Web Deploy – And Why Should You Care

Deploying a web application or site involves several steps. You typically need to:

Copy files and folders
Provision database schema and optionally populate database content
Set appropriate read/write and security ACLs on files and folders
Install and configure SSL certificates
Deploy other misc dependencies (Event logs, GAC libraries, COM objects, etc)

Performing all of these steps manually is tiresome, slow, and dangerous (since manual deployment steps are error prone). Enabling an automated process that allows you to quickly provision and deploy applications on a server helps reduce the chances of things going wrong, and can dramatically improve the cycle time it takes for you to get a change you make in an application into production.

Microsoft Web Deploy

Automating Deployment with Microsoft Web Deploy

Monday, September 13, 2010

.NET ASP.NET IIS7 Visual Studio

This is the twenty-eighth in a series of blog posts I’m doing on the VS 2010 and .NET 4 release.
This blog post continues a series of posts I’m doing that cover the new improvements we made around web deployment.  In my first post in the deployment series I provided an overview of the new VS 2010 Web Deployment features.
In today’s post I’m going to be discussing Microsoft Web Deploy – which is a free server technology that enables a comprehensive publishing and deployment mechanism.  Web Deploy enables you to not only publish files – but also provision database schema/data, run database change scripts, set security ACLs, and more.  All of these deployment steps can be automated using Visual Studio.
This post will provide a step by step tutorial on how to install Web Deploy and enable it on a web-server.  I’ll then demonstrate how you can use Visual Studio 2010 to directly publish to servers using Web Deploy, as well as how you can use Visual Studio to create installation packages that you can use to automate the deployment of your applications.

Web Deploy – And Why Should You Care

Deploying a web application or site involves several steps. You typically need to:

• Copy files and folders
• Provision database schema and optionally populate database content
• Set appropriate read/write and security ACLs on files and folders
• Install and configure SSL certificates
• Deploy other misc dependencies (Event logs, GAC libraries, COM objects, etc)

Performing all of these steps manually is tiresome, slow, and dangerous (since manual deployment steps are error prone).  Enabling an automated process that allows you to quickly provision and deploy applications on a server helps reduce the chances of things going wrong, and can dramatically improve the cycle time it takes for you to get a change you make in an application into production. 
Microsoft Web Deploy
Web Deploy is a free technology built by my team that can improve web deployment. It is a deployment service that runs on a server, and enables you to either locally or remotely deploy applications onto it.  Web Deploy includes built-in support for creating virtual directories and applications within IIS, copying files and folders, provisioning databases (both SQL Server and MySQL), setting file-system ACLs and more (it even includes built-in providers for things like setting registry entries, registering COM components, etc).  In addition to having these built-in deployment features, it also supports a .NET based provider API that enables you to create and plug-in your own custom deployment actions – which allow you to customize it however you want.
The wire-protocol for Web Deploy is HTTPS – which means Web Deploy can be used through firewalls (enabling easy, secure, deployment to remote hosted servers).  Web Deploy also supports both admin and non-admin deployment scenarios.  The non-admin scenarios enable administrators to configure Web Deploy on a server, and then delegate a subset of deployment capabilities to developers who do not have admin accounts on the production server.  This enables a very secure and flexible deployment approach.  I’ll cover the configuration steps to enable delegated deployment scenarios in my next blog post in this series.

Installing Web Deploy on Windows Server 2008

Visual Studio 2010 (and Visual Web Developer 2010 Express) will by default install Web Deploy on your development machine as part of their setup.  This provides you with what you need to create Web Deployment setup packages within VS, as well as publish them to remote servers that have the Web Deploy service installed and enabled.
Below are the steps for how to install Web Deploy on a production server running IIS 7.x on Windows Server 2008 or Windows Server 2008 R2:
1) Download and run the Microsoft Web Platform Installer on your production server.
2) Click the “Web Platform” tab within the Web Platform Installer, then click the “Customize” link under the “Web Server” section.  Select the “Web Deployment Tool 1.1” feature as well as the “Management Service” feature:

3) Press the Install Button.  This will download and install the Web Deployment Package, and enable the IIS Management Service feature that is built-into Windows.

Enabling Deployments with Windows Server 2008

We now have Web Deploy installed – next we need to enable deployments with it.
Web Deploy supports deployments by administrators, as well as deployments by non-administrators (aka delegated deployments). In this blog post, I’m going to cover how to enable deployments using an account that has administrator permissions on the server.  I will cover how to enable delegated deployments by developers that do not have an administrator account in my next blog post in this series.
1) The first step to enable Web Deploy is to start the IIS Admin Tool (Start -> Run -> inetmgr.exe).  Then double-click the “Management Service Delegation” icon on the home-screen:

When you double-click the “Management Service Delegation” icon it will bring you to a page that looks like below.  In the Actions pane, click the “Edit Feature Settings…” link.  This will bring up the “Edit Feature Settings” dialog - check the “Allow administrators to bypass rules” option within this dialog box.  This will allow those with Administrator accounts on the server to bypass the delegation capabilities of the Web Management Service and perform actions using their administrator capabilities:

Then return back to the IIS Admin Tool home-screen and double click the “Management Service” icon:

When you double-click the “Management Service” icon it will bring you to a page that looks like below.  Click the “Enable Remote Connections” checkbox to enable remote deployments.  You can optionally choose which IP address and port the management service runs on – as well as what client IP addresses are allowed to connect with it.  You can tweak these settings to lock down who can access the deployment service.
When you are done click the “Start” link within the “Actions” tab to start the Web Management Service on the server:

Automating Deployment with Microsoft Web Deploy

Monday, September 13, 2010

.NET ASP.NET IIS7 Visual Studio

This is the twenty-eighth in a series of blog posts I’m doing on the VS 2010 and .NET 4 release.
This blog post continues a series of posts I’m doing that cover the new improvements we made around web deployment.  In my first post in the deployment series I provided an overview of the new VS 2010 Web Deployment features.
In today’s post I’m going to be discussing Microsoft Web Deploy – which is a free server technology that enables a comprehensive publishing and deployment mechanism.  Web Deploy enables you to not only publish files – but also provision database schema/data, run database change scripts, set security ACLs, and more.  All of these deployment steps can be automated using Visual Studio.
This post will provide a step by step tutorial on how to install Web Deploy and enable it on a web-server.  I’ll then demonstrate how you can use Visual Studio 2010 to directly publish to servers using Web Deploy, as well as how you can use Visual Studio to create installation packages that you can use to automate the deployment of your applications.

Web Deploy – And Why Should You Care

Deploying a web application or site involves several steps. You typically need to:

• Copy files and folders
• Provision database schema and optionally populate database content
• Set appropriate read/write and security ACLs on files and folders
• Install and configure SSL certificates
• Deploy other misc dependencies (Event logs, GAC libraries, COM objects, etc)

Performing all of these steps manually is tiresome, slow, and dangerous (since manual deployment steps are error prone).  Enabling an automated process that allows you to quickly provision and deploy applications on a server helps reduce the chances of things going wrong, and can dramatically improve the cycle time it takes for you to get a change you make in an application into production. 
Microsoft Web Deploy
Web Deploy is a free technology built by my team that can improve web deployment. It is a deployment service that runs on a server, and enables you to either locally or remotely deploy applications onto it.  Web Deploy includes built-in support for creating virtual directories and applications within IIS, copying files and folders, provisioning databases (both SQL Server and MySQL), setting file-system ACLs and more (it even includes built-in providers for things like setting registry entries, registering COM components, etc).  In addition to having these built-in deployment features, it also supports a .NET based provider API that enables you to create and plug-in your own custom deployment actions – which allow you to customize it however you want.
The wire-protocol for Web Deploy is HTTPS – which means Web Deploy can be used through firewalls (enabling easy, secure, deployment to remote hosted servers).  Web Deploy also supports both admin and non-admin deployment scenarios.  The non-admin scenarios enable administrators to configure Web Deploy on a server, and then delegate a subset of deployment capabilities to developers who do not have admin accounts on the production server.  This enables a very secure and flexible deployment approach.  I’ll cover the configuration steps to enable delegated deployment scenarios in my next blog post in this series.

Installing Web Deploy on Windows Server 2008

Visual Studio 2010 (and Visual Web Developer 2010 Express) will by default install Web Deploy on your development machine as part of their setup.  This provides you with what you need to create Web Deployment setup packages within VS, as well as publish them to remote servers that have the Web Deploy service installed and enabled.
Below are the steps for how to install Web Deploy on a production server running IIS 7.x on Windows Server 2008 or Windows Server 2008 R2:
1) Download and run the Microsoft Web Platform Installer on your production server.
2) Click the “Web Platform” tab within the Web Platform Installer, then click the “Customize” link under the “Web Server” section.  Select the “Web Deployment Tool 1.1” feature as well as the “Management Service” feature:

3) Press the Install Button.  This will download and install the Web Deployment Package, and enable the IIS Management Service feature that is built-into Windows.

Enabling Deployments with Windows Server 2008

We now have Web Deploy installed – next we need to enable deployments with it.
Web Deploy supports deployments by administrators, as well as deployments by non-administrators (aka delegated deployments). In this blog post, I’m going to cover how to enable deployments using an account that has administrator permissions on the server.  I will cover how to enable delegated deployments by developers that do not have an administrator account in my next blog post in this series.
1) The first step to enable Web Deploy is to start the IIS Admin Tool (Start -> Run -> inetmgr.exe).  Then double-click the “Management Service Delegation” icon on the home-screen:

When you double-click the “Management Service Delegation” icon it will bring you to a page that looks like below.  In the Actions pane, click the “Edit Feature Settings…” link.  This will bring up the “Edit Feature Settings” dialog - check the “Allow administrators to bypass rules” option within this dialog box.  This will allow those with Administrator accounts on the server to bypass the delegation capabilities of the Web Management Service and perform actions using their administrator capabilities:

Then return back to the IIS Admin Tool home-screen and double click the “Management Service” icon:

When you double-click the “Management Service” icon it will bring you to a page that looks like below.  Click the “Enable Remote Connections” checkbox to enable remote deployments.  You can optionally choose which IP address and port the management service runs on – as well as what client IP addresses are allowed to connect with it.  You can tweak these settings to lock down who can access the deployment service.
When you are done click the “Start” link within the “Actions” tab to start the Web Management Service on the server:

The server is now setup for deployments using an administrator account with Web Deploy.
Important Tip: One thing to watch for is whether you have a firewall enabled on your server, or within the cluster where your server is hosted.  By default the Management Service runs using the HTTPS protocol on port 8172.  This port might be locked down by default depending on your hosting configuration.  If so you should either unlock it with your firewall/hoster – or pick a different port number that is allowed.  You can test to see whether the management service is available simply by opening up a browser and accessing it using a URL like: https://yourservername:8172/MsDeploy.axd – if you are prompted for a username/password then you know it is working, and there is no firewall blocking access to it.  If it times out then it is likely that a firewall is blocking it.
The server is now setup for deployments using an administrator account with Web Deploy.
Important Tip: One thing to watch for is whether you have a firewall enabled on your server, or within the cluster where your server is hosted.  By default the Management Service runs using the HTTPS protocol on port 8172.  This port might be locked down by default depending on your hosting configuration.  If so you should either unlock it with your firewall/hoster – or pick a different port number that is allowed.  You can test to see whether the management service is available simply by opening up a browser and accessing it using a URL like: https://yourservername:8172/MsDeploy.axd – if you are prompted for a username/password then you know it is working, and there is no firewall blocking access to it.  If it times out then it is likely that a firewall is blocking it.
Web Deploy is a free technology built by my team that can improve web deployment. It is a deployment service that runs on a server, and enables you to either locally or remotely deploy applications onto it. Web Deploy includes built-in support for creating virtual directories and applications within IIS, copying files and folders, provisioning databases (both SQL Server and MySQL), setting file-system ACLs and more (it even includes built-in providers for things like setting registry entries, registering COM components, etc). In addition to having these built-in deployment features, it also supports a .NET based provider API that enables you to create and plug-in your own custom deployment actions – which allow you to customize it however you want.

The wire-protocol for Web Deploy is HTTPS – which means Web Deploy can be used through firewalls (enabling easy, secure, deployment to remote hosted servers). Web Deploy also supports both admin and non-admin deployment scenarios. The non-admin scenarios enable administrators to configure Web Deploy on a server, and then delegate a subset of deployment capabilities to developers who do not have admin accounts on the production server. This enables a very secure and flexible deployment approach. I’ll cover the configuration steps to enable delegated deployment scenarios in my next blog post in this series.
Installing Web Deploy on Windows Server 2008

Visual Studio 2010 (and Visual Web Developer 2010 Express) will by default install Web Deploy on your development machine as part of their setup. This provides you with what you need to create Web Deployment setup packages within VS, as well as publish them to remote servers that have the Web Deploy service installed and enabled.

Below are the steps for how to install Web Deploy on a production server running IIS 7.x on Windows Server 2008 or Windows Server 2008 R2:

1) Download and run the Microsoft Web Platform Installer on your production server.

2) Click the “Web Platform” tab within the Web Platform Installer, then click the “Customize” link under the “Web Server” section. Select the “Web Deployment Tool 1.1” feature as well as the “Management Service” feature:

image

3) Press the Install Button. This will download and install the Web Deployment Package, and enable the IIS Management Service feature that is built-into Windows.
Enabling Deployments with Windows Server 2008

We now have Web Deploy installed – next we need to enable deployments with it.

Web Deploy supports deployments by administrators, as well as deployments by non-administrators (aka delegated deployments). In this blog post, I’m going to cover how to enable deployments using an account that has administrator permissions on the server. I will cover how to enable delegated deployments by developers that do not have an administrator account in my next blog post in this series.

1) The first step to enable Web Deploy is to start the IIS Admin Tool (Start -> Run -> inetmgr.exe). Then double-click the “Management Service Delegation” icon on the home-screen:

image

When you double-click the “Management Service Delegation” icon it will bring you to a page that looks like below. In the Actions pane, click the “Edit Feature Settings…” link. This will bring up the “Edit Feature Settings” dialog - check the “Allow administrators to bypass rules” option within this dialog box. This will allow those with Administrator accounts on the server to bypass the delegation capabilities of the Web Management Service and perform actions using their administrator capabilities:

image

Then return back to the IIS Admin Tool home-screen and double click the “Management Service” icon:

image

When you double-click the “Management Service” icon it will bring you to a page that looks like below. Click the “Enable Remote Connections” checkbox to enable remote deployments. You can optionally choose which IP address and port the management service runs on – as well as what client IP addresses are allowed to connect with it. You can tweak these settings to lock down who can access the deployment service.

When you are done click the “Start” link within the “Actions” tab to start the Web Management Service on the server:

image

The server is now setup for deployments using an administrator account with Web Deploy.

Important Tip: One thing to watch for is whether you have a firewall enabled on your server, or within the cluster where your server is hosted. By default the Management Service runs using the HTTPS protocol on port 8172. This port might be locked down by default depending on your hosting configuration. If so you should either unlock it with your firewall/hoster – or pick a different port number that is allowed. You can test to see whether the management service is available simply by opening up a browser and accessing it using a URL like: https://yourservername:8172/MsDeploy.axd – if you are prompted for a username/password then you know it is working, and there is no firewall blocking access to it. If it times out then it is likely that a firewall is blocking it.

Service packs hot fixes testing

Best Practices for Applying Service Packs, Hotfixes and Security Patches
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
By Rick Rosato, Technical Account Manager, Microsoft Corporation

Abstract

This paper recommends a series of best practices for deploying Microsoft service packs, hotfixes and security patches. The information contained in this document has been derived from Microsoft Technical Account Managers, Microsoft Product Support Services (PSS) engineers, and well-known Microsoft subscription products like Microsoft TechNet and Microsoft Developer's Network (MSDN).
On This Page

Introduction
Generic Best Practices
Service Pack Best Practices
Hotfix Best Practices
Security Patches Best Practices
Conclusion
Appendix A - Definitions
Introduction

Service packs, hotfixes and security patches are updates to products to resolve a known issue or workaround.

Moreover, service packs update systems to the most current code base. Being on the current code base is important because that's where Microsoft focuses on fixing problems. For example, any work done on Windows 2000 is targeted at the next service pack and hotfixes are built against the existing available base.

Individual hotfixes and security patches on the other hand should be adopted on a case-by-case, "as-needed" basis. The majority of security updates released are for client side (often browser) issues. They may or may not be relevant to a server installation. Evaluate the update, if it's needed, then apply it. If not, assess the risk of applying or not.

For a full description of service packs, hotfixes and Security Updates, please refer to Appendix A ?Definitions.

The basic rules are:

"The risk of implementing the service pack, hotfix and security patch should ALWAYS be LESS than the risk of not implementing it."

And,

"You should never be worse off by implementing a service pack, hotfix and security patch. If you are unsure, then take steps to ensure that there is no doubt when moving them to production systems."

The following guidelines outline the recommended processes to follow before implementing service packs, hotfixes and security patches. You can follow them as a step-by-step guide to having a successful implementation of any Microsoft recommended update.
Top Of Page
Generic Best Practices

These apply to all updates regardless of whether they are service packs, hotfixes or security patches. The generic items listed below are mandatory steps that need to be performed across all updates. In addition, there are specific best practices for each type of update, and these are listed under each update.

Use a change control process.

good change control procedure has an identified owner, a path for customer input, an audit trail for any changes, a clear announcement and review period, testing procedures, and a well-understood back-out plan. Change control will manage the process from start to finish. If your current procedure is lacking any of the above, please reconsider carefully before using it for deployment of updates.

Read all related documentation.

Before applying any service pack, hotfix or security patch, all relevant documentation should be read and peer reviewed. The peer review process is critical as it mitigates the risk of a single person missing critical and relevant points when evaluating the update.

Reading all associated documentation is the first step in assessing whether:

The update is relevant, and will resolve an existing issue.

Its adoption won't cause other issues resulting in a compromise of the production system.

There are dependencies relating to the update, (i.e. certain features being enabled or disabled for the update to be effective.)

Potential issues will arise from the sequencing of the update, as specific instructions may state or recommend a sequence of events or updates to occur before the service pack, hotfix or security patch is applied.

Documentation released with the updates is usually in the form of web pages, attached Word documents and README.TXT files. These should be printed off and attached to change control procedures as supporting documentation.

As well as the documentation released with the updates, a search on the Premier Web site (https://servicedesk.one.microsoft.com/WRPublic/EN/Consent.asp) for Premier customers or a search on the public Microsoft Support site (http://support.microsoft.com) needs to be done for any additional post-release information on the update. TechNet also has the "List of Bugs Fixed in Service Pack " articles. This is a critical document that must be referenced.

Apply updates on a needs only basis.

One of the common misconceptions about Microsoft updates is that they are mandatory and/or urgent.

All updates, regardless of their type (whether they are service packs, hotfixes or security patches), are to be applied on an "as-needed" basis. They need to be evaluated individually and treated as important optional updates.

Especially with security patches, the expectation is that it must be an urgent issue and must be deployed quickly. Without trying to detract from the urgency, security patches are very much a relative update; for example, customers using solely Windows NT4 can ignore a patch for a security vulnerability in Windows 2000. However, if the issue is relevant and does plug a security hole, then it should be evaluated urgently.

Only when it addresses or fixes an issue being experienced by the customer should it be considered. Of course, it still needs to be evaluated before being installed.

esting.

The prior points really assist in giving you a feel (before installing) for the potential impact, however, testing allows for the "test driving" and eventual signing off of the update.

Service packs and hotfixes must be tested on a representative non-production environment prior to being deployed to production. This will help to gauge the impact of such changes.

Plan to uninstall.

Where possible, service packs, hotfixes and security patches must be installed such that they can be uninstalled, if required.

Historically, service packs have allowed for uninstalling, so verify there is enough free hard disk space to create the uninstall folder.

Consistency across Domain Controllers.

Service packs, hotfixes and security patch levels must be consistent on all Domain Controllers (DCs). Inconsistent update levels across DCs can lead to DC-to-DC synchronisation and replication related problems. It is extremely difficult to trap errors caused by DCs being out of sync, so it's critical that consistency is maintained.

Where it is practical, Member Servers should also be updated with the same service packs and hotfixes as the Domain Controllers.

Have a working Backup and schedule production downtime.

Server outages should be scheduled and a complete set of backup tapes and emergency repair disks should available, in case a restoration is required.

Make sure that you have a working backup of your system. The only supported method of restoring your server to a previous working installation is from a backup. For more information on backup and recovery procedures, please refer to:

" Backup " in the Microsoft Windows 2000 Server Resource Kit Server Operations Guide.

" Repair, Recovery, and Restore " in the Microsoft Windows 2000 Server Resource Kit Server Operations Guide.

Always have a back-out plan.

A back-out plan will allow the system and enterprise to return to their original state, prior to the failed implementation. It is important that these procedures are clear, and that contingency management has tested them, because in the worst case a faulty implementation can make it necessary to activate contingency options.

Enterprises may need to exercise their back-out plan in the event of the update not having an uninstall process or the uninstall process failing. The back-out plan can be as simple as restoring from tape, or may involve many lengthy manual procedures.

Forewarn helpdesk and key user groups.

You need to notify helpdesk staff and support agencies (such as Microsoft Product Support Service - PSS) of the pending changes so they may be ready for arising issues or outages.

In order to minimize the user impact, it is also a good idea to prepare key user group of proposed updates, this will assist in managing user expectations.

Don't get more than 2 service packs behind.

Schedule periodic service pack upgrades as part of your operations maintenance and try never to be more than two service packs behind.

Target non-critical servers first.

If all tests in the lab environment are successful, start deploying on non-critical servers first, if possible, and then move to the primary servers once the service pack has been in production for 10-14 days.

Top Of Page
Service Pack Best Practices

There are great Microsoft TechNet articles that reference Service Pack Best Practices. All you need to know can be found in the documents list below:

Before Installing a Windows NT Service Pack (165418)

Strategies for MS Exchange Service Packs and Version Upgrades.

The Microsoft Windows 2000 Service Pack Installation and Deployment Guide.

Top Of Page
Hotfix Best Practices

Service Pack (SP) level consistency.

Don't deploy a hotfix until you have all current service packs installed. A hotfix is related to a service pack and should be deployed with this in mind. If a hotfix is for post-Windows 2000 SP2, for example, then you need to ensure that the server has SP2 installed.

Latest SP instead of multiple hotfixes.

If multiple hotfixes are to be applied and these are in the latest released service pack, apply the latest service pack instead of applying several hofixes, unless issues relating to the latest service pack may cause the server to break.

Top Of Page
Security Patches Best Practices

Apply admin patches to install build areas.

It is crucial that not only clients are retrospectively updated with security patches, but the client built areas are updated for any new clients. Admin patches are required and differ from the client patch. They need to be applied to client build areas. The admin patches are usually located in a different location to the client-side patches. For example, the admin Office Security patches are available from the Office Resource Kit Toolbox at: http://www.microsoft.com/office/ork/2000/appndx/toolbox.htm.

Apply only on exact match.

Apply these fixes only if you encounter exactly the issue the fix solves or if the circumstances relate to your environment.

Subscribe to email notification.

Subscribe to the notification alias to receive proactive emails on the latest security patches.

Top Of Page
Conclusion

It is critical that when service packs, hotfixes, and security patches are required to be installed, that these best practices be followed. They will guide you through the successful deployment of an update, and will assist your enterprise's recovery should the update fail.
Top Of Page
Appendix A - Definitions
Service packs

Service packs correct known problems and provide tools, drivers, and updates that extend product functionality, including enhancements developed after the product released. They get you up to our current code base. Being on the current code base is important because that's where we fix the code.

Service packs keep the product current, and extend and update your computer's functionality. Service packs include updates, system administration tools, drivers, and additional components. All are conveniently bundled for easy downloading.

Service packs are product specific, so there are separate ones for each product. Being product specific does not however, mean that they are SKU (Stock-Keeping Unit) specific. For example, Windows NT 4.0 Server and Workstation will use the same service pack.

Service packs are cumulative - each new service pack contains all the fixes in previous service packs, as well as any new fixes. You do not need to install a previous service pack before you install the latest one. For example, Service Pack 6a contains all the fixes in SPs 1, 2, 3, 4, 5 and 6.
Hotfixes or QFE's

QFE (Quick Fix Engineering) is a group within Microsoft that produces "hotfixes" - code patches for products that are provided to individual customers when they experience critical problems for which no feasible workaround is available.

Hotfixes are not intended for general installation, since they do not undergo extensive beta testing when they are created. Microsoft targets hotfix support toward enterprise-level customers and designs it to provide an extra level of security for mission-critical software systems.

Groups of "hotfixes" are periodically incorporated into service packs that undergo more rigorous testing and are then made generally available to other customers.

They are not regression tested. Hotfixes are very specific - you should apply one only if you experience the exact problem they address and are using the current software version with the latest service pack.

General criteria to meet in order for an issue to be evaluated for a potential bug fix are:

Excessive loss of work or revenue to the customer

No reasonable, Customer accepted, workaround exists

Priority given to Premier accounts

Microsoft offers full n-1 QFE support. This means that we will support the current shipping version of a product and its predecessor. "Version" is defined as a new release with some added functionality and does not include "A" level releases, which are considered strictly maintenance releases. For example, if version 3.5 is superseded by version 3.5A, bug fixes will not be done on 3.5 since 3.5A is a maintenance release. On the other hand, if version 4.21 is superseded by version 6.0 (a functionality release), bug fixes will continue to be done against 4.21 until another version ships. If there is not an update to a product, (ex: LAN Manager) then we will continue to do bug fixes until such point when volume has significantly slowed. We will apprise our Customers at least 6 months in advance of us discontinuing QFE support.
Security Patches

Security patches eliminate security vulnerabilities. Attackers wanting break into systems can exploit these vulnerabilities. These are analogous to hotfixes but are deemed mandatory if the circumstances match and need to be deployed quickly.

The majority of security updates released are for client side (often browser) issues. They may or may not be relevant to a server installation. You need to obtain both the admin patch and the client patch as the client patch will retroactively update your client base and the admin patch will update your client build area on the server.

Great articles on security patches are available at:

Ask Us About... Security - August 2000

Microsoft Security site

As mentioned above, the admin patches are located in a different location to the client-side patches. For example, the admin Office Security patches are available from the Office Resource Kit Toolbox at http://www.microsoft.com/office/ork/2000/appndx/toolbox.htm.

You also need to be aware that Microsoft makes available four primary areas to obtain client software security patches for its products. This means that if users have access to the Internet, they may have updated their PCs using one of the four mechanisms.

Windows Update http://windowsupdate.microsoft.com/. It uses ActiveX technology to scan the PC to see what has been installed and presents a list of suggested components that need upgrading based on the most up-to-date and accurate versions.

Recent security bulletins can be found at http://www.microsoft.com/technet/security/current.aspx. This is the best place to search for purely security-related patches, especially since it was upgraded to allow searching by product or date.

You can also visit product-specific security patch download pages. They are available for Internet Explorer (IE) and Office Updates. The IE download page is a simple, chronological list of security patches that makes it easy to click down the list and get what you need. Unlike WU, however, there is no facility for identifying which patches have already been installed.

Finally, search the Microsoft Download Center (MDC) for security-related patches using the keyword "security_patch." MDC allows searches by product name, product category, or operating system. Unfortunately, you cannot search by both keyword and these other categories simultaneously, so it is not as effective a search mechanism as the security bulletins page. Use this one if you are only browsing, or if the other methods above failed to produce adequate results.

Test environments

Lets assume you have a great idea and you decided to work on it. Initially the whole team might be just you or may be a group of 2-3 people. You develop test and do everything in same machine and releases to the common environment. No one other than you guys is bothered about it.

Now your product went live. All going good until you found a bug. Now after fixing, as you doing have a testing environment, you push to the common environment. You made syntax error and whole system goes down. You cannot afford to have that and we are left with no other choice - a testing environment.

You have found interest from others on your product and the traffic has gone up. You income started to grow and 2-3 developers cannot maintain everything. Its when a QA joins you. The same issue comes again, tester wants to test a place where everything is stable. So developers do some coding and after doing a sanity, will push to testing environment with the consent of tester.

There can be other environments as well like

Integration Environment : A place for developers to test how different modules interacts before sending for testing

developer environment

testing environment
Staging Environment : A pre-release stage, where the release is done once QA's signs-off for release. It will be closest to production

The main purpose for having different environments is to provide stable and independent environments for all. There are companies which might have even 10 or more such environments with specific purpose for each like - functional testing, load testing etc.


Production data must be readily available for frequent and efficient access and is stored persistently. It is therefore often stored on high-performing Tier-1 storage that can be easily managed.


Should you use production data or generate test data for testing?
Posted on March 7, 2013

This post is part of the Pride & Paradev series.

Should you use production data or generate test data for testing?

You should generate test data for testing
You should use production data for testing

You should generate test data for testing

Generating test data is the only reliable way to accurately run tests repeatedly and consistently knowing that the input test data hasn’t changed.

Some applications rely upon specific data which is either hard to find, or hard to fake. For example, the web application I am working on displays different promotions based upon which day of the week you are using the system, and also changes prices depending on the day of week and time of day.

If you were using production data for testing, you would either have to run tests at specific dates/times to test different promotions/prices, or you would have to change the server date/time to test these. Changing the date/time on the server will effect anyone else using that server, so should be avoided. It also means that as you run your automated tests continuously against new check-ins, if you don’t use a known set of generated test data, you will get different results depending on time of day.

When developing an entirely new feature, there won’t be production data that you can use for testing, so you will need to generate some in this case.

Generating specific test data will often take longer sourcing production data, but will retrieve results over time as tests are run very consistently against a known data set.

You should use production data for testing

When you’re testing a web application, you’re as much testing the data as testing the application behavior. Using production data will ensure that what you are testing will be as close as possible to the actual behavior once the feature is released to production users.

If you generate test data and use it to test, who is to say that this test data is actually valid. If you generate test data through lower level means (such as SQL insert scripts), you may introduce test data that isn’t representative of that in production that may either introduce errors in functionality when actually running against production data, or errors in test that won’t actually exist in production. As your database schema updates and evolves, you will need to also keep your data generation scripts up to date so they are reflective of production at all times.

If you do use production data, you need to be clever about how to source data. Querying the database using SQL scripts is an effective approach as it will enable you to quickly find real data that you can use to verify a story has been implemented correctly.

It will also allow you to identify outliers and edge cases that can be tested using real production data against the system in development.

If there any concerns about using production data for testing, these can be mitigated by obfuscating the data so it is indistinguishable.