(Drawn from: http://notgartner.wordpress.com/2006/12/16/getting-started-with-tfs-deployer/)
This document will describe the software and steps necessary to install TFSDeployer to machine(s) where builds must be deployed.
TFSDeployer is a deployment tool written by the people at Readify that integrates with TFS. It is designed to work with build quality change events that are initiated from TFS/Team Explorer. TFSDeployer has the following message flow:

There is more information about TFSDeployer at the following location: http://notgartner.wordpress.com/2006/12/16/getting-started-with-tfs-deployer/
The sequence of messages exchanged is as follows:

This file provides TFSDeployer the information about what type of build quality change events the Target machines should respond to. This file must be checked into a ‘well known’ location in TFS version control. The location should be in a ‘Deployment’ sub-directory under each Team Build Type directory. For example, in the screenshot below we have a Team Build Type called CrmOnTimeContinuous which is part of the CrmOnTime team project, so the path that TFS Deployer will look for its configuration/scripts is $/CrmOnTime/TeamBuildTypes/CrmOnTimeContinuous/Deployment. (Obviously, TFSDeployer is handed some information about the build type name when it receives the build quality change event.)

There should be one ‘Mapping’ element for each build quality transition for each Target server. Below is an example:

In this example we have four mappings. Each mapping has the same settings except for the ‘Computer’ attribute. This means that the ‘DeploytoBizTalkServer.ps1’ script will be run on both devbiztalkserver1 and devbiztalkserver2 when the build quality setting for the build transitions from ‘Unexamined’ to ‘In Dev’.
This is the basic configuration file used by TFSDeployer. It must be edited to provide information about the Target machine, email URLs, etc. Below is a description of which parameters must be edited:
This setting is the ‘default’ email address that will be used when deployments are completed (either successfully or not). This email address will only be used if there is no ‘NotificationAddress’ element in the DeploymentMappings.xml file for any particular mapping. In setting this value you should ask the question: “Who should know about deployments on this machine if there is no ‘NotificationAddress’ element for a particular mapping”.
This is the address that Team Foundation Server will use to publish build quality change events to the TFSDeployer service running on this Target machine. The address specified should be addressable from across the network so using ‘localhost’ is not acceptable.
This is the name of the account that the service process is running under and which the subscriptions will be assigned to in Team Foundation Server. See below for the permission requirements for this account.
This is the address at which TFS is addressable across the network. This is the URL that TFSDeployer will use to create a ‘build change event’ subscription in TFS and download files (DeploymentMappings.xml, etc) from.
Should always be set ‘True’, unless you are using TFSDeployer in a cross domain configuration.
This is the address that all deployment notification e-mails are sent from.
This is the address of the SMTP server used to send deployment notification e-mails.
The account that the TFSDeployer service runs under must have permissions to:
(The account needs to be a member of the ‘TFS Administrators’ group.)

i. Must be a member of the (domain-level) BizTalk Server Administrators group.
ii. Must be a member of the (domain-level) SSO Administrators group.
iii. Must be a local admin on the box or have sufficient permissions such that environment variables can be read from the powershell script.
iv. Must be able to create a WCF endpoint. If account permissions don’t already provide for this implicitly, this will be possible if permissions are granted to this account via the HttpConfig.exe program.
1. Start the HttpConfig.exe program (see http://www.stevestechspot.com/downloads/httpconfig.zip)
2. Press the ‘Add’ button.
3. Enter http://+:8999/+/ for the URL.

4. Add the account to the permissible accounts (make sure ‘Register’ is Allowed):

TFSDeployer uses WCF to create an endpoint that will be used by the TFS Event System to deliver events to TFSDeployer. Download here.
a. TFSDeployer will create Power Shell instances. Install the latest version for the OS you are deploying to. Download here.
b. Start a Power Shell instance and type the following command (do for both 32-bit and 64-bit):
set-executionpolicy remotesigned
1) Try stopping the TFSDeployer service, going to the command line, and running “TFSDeployer.exe –d”. This will give you feedback as to whether the service is successfully subscribing to TFS events and receiving the notifications. You likely want to run the command line via “runas” and specify the service credentials you are typically using.
2) Your Powershell script will be receiving the build number and drop location from TFSDeployer. If you structure your script as follows, you can launch it directly from the Powershell command line (with command line arguments) to help troubleshoot it:
$buildNumber = $TfsDeployerBuildData.BuildNumber
$dropLocation = $TfsDeployerBuildData.DropLocation
if($buildNumber -eq $null)
{
$buildNumber
= $args[0]
$dropLocation = $args[1]
}
If the service fails to execute your script, you can change to a directory similar to this one - this is where the service does the “get” of your deployment mappings and script:
C:\Documents and Settings\tfsdeployer_svc\Local
Settings\Temp\TFSDeployerConfiguration2
In this location you will be able to launch your powershell script directly and supply the required command line arguments.