Web Deploy On Demand
Updated: March 22, 2010
Applies To: Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Vista, Windows XP
The tempAgent provider setting enables synchronization operations to run from a temporary, "on demand" installation of Web Deploy.
msdeploy -verb:sync -source:webserver -dest:auto,computername=destinationComputer1,username=administrator,password=<password>,tempAgent=true
The Web Deploy tempAgent feature provides administrators with a way of synchronizing computers without having to permanently install Web Deploy (and its Web Deployment Agent service, MsDepSvc) on any computer. When you set tempAgent to true in a sync operation, temporary program binaries are copied to an administrative share or shares, and WMI (Windows Management Instrumentation) is used to install a GUID-based URL registration at the directory location %windir%\temp\msdeploy\<GUID>. A temporary version of MsDepSvc performs the sync operation. After the operation completes, all temporary files are removed.
The tempAgent feature has the following advantages over the Web Deployment Agent service.
A separate installation of the Web Deployment Tool is not required. Use of MsDepSvc requires that you install Web Deploy on each computer that you want to synchronize. Using the tempAgent feature will save you this step.
When Web Deploy is installed on multiple computers, a recommended best practice is that all versions of Web Deploy be the same. Each upgrade to a newer version of Web Deploy therefore requires you to upgrade all the computers to the latest version of Web Deploy. With tempAgent you can avoid these multiple upgrades.
To run Web Deploy by using the tempAgent setting, the following conditions must be met.
Ensure that the credentials in the Web Deploy command are from a user account that is a local administrator on any remote computer that is a source or destination in the operation. If the user who runs the command is also a local administrator on the remote computer or computers, the credentials do not have to be specified on the command line.
Ensure that the firewall of any source or destination remote computers allow HTTP traffic through port 80. On IIS Web servers, port 80 is open by default, so normally this will not be a concern. However, if you want to check whether TCP is listening on port 80, you can run netstat –anop TCP at an elevated command prompt, and to open the port, type netsh firewall add portopening TCP 80. The firewall must be configured locally on the remote computer.
Ensure that the WMI service on any remote source or destination computer is running and that the firewall of the remote computer allows Windows Management Instrumentation (WMI) traffic. In Windows Vista and later versions of Windows, the WMI service is started, and WMI traffic is allowed through the firewall by default. If you have to start the WMI service, type net start winmgmt at an administrative command prompt.
Important If you are using an operating system earlier than Windows Server 2003 Service Pack 2, you must also configure the firewall to allow DCOM traffic. To do this, type the following at an administrative command prompt.
netsh firewall add portopening TCP 135 DCOM_TCP135
|Use of the tempAgent provider setting is not supported when the Web Deployment Agent Service (MsDepSvc) is already installed on a remote source or remote destination computer. This usage is not supported even if the installed service is not running.|
There are two ways to use the Web Deploy tempAgent on demand feature:
Run Web Deploy from a local folder.
Run Web Deploy from a network share.
Neither use requires that the Web Deployment Tool program files be installed; you only have to copy them to, and run them from, a folder or share to which you have access. The folder that contains the program files does not have to be on the source or destination computer of the Web Deploy operation.
To run Web Deploy with tempAgent from a local folder, create a folder on the local computer, copy the Web Deploy program files to it, and run Web Deploy from the folder directly. To obtain the Web Deploy program files, you can copy them from a computer on which Web Deploy has already been installed, or extract them from one of the .msi installation files for the Web Deployment Tool. On computers on which Web Deploy has been already installed, the installation path is %programfiles%\IIS\Microsoft Web Deploy. tempAgent requires following files:
If you do not have access to a computer on which Web Deploy has already been installed, you can extract the required files from the 64–bit or 32–bit Web Deploy .msi installation file. For the download location of the Web Deploy installation files, see Web Deployment Tool Installation. To extract the files, use the following syntax at an administrative command prompt.
msiexec /a <PathToWebDeployMsiFile> /qb targetdir=<ExtractionFolder>
For example, if the WebDeploy.msi file is on the C:\ drive, the following command extracts the Web Deploy files to the D:\msiextract folder.
msiexec /a C:\webdeploy.msi /qb targetdir=D:\msiextract
The folder D:\msiextract\x64\IIS\Microsoft Web Deploy\ or D:\msiextract\x86\IIS\Microsoft Web Deploy\ folders will contain the necessary extracted files for the 64-bit or 32-bit version. The respective x86 and x64 subfolders of the same directory will contain the Axnative.dll files.
The following example uses the program files in the C:\WebDeployDir folder to synchronize site-level configuration from the local computer to the remote computer WebServer1.
C:\WebDeployDir>msdeploy.exe -verb:sync -source:apphostconfig -dest:auto,computername=Webserver1,username=administrator,password=<password>,tempAgent=true
If the .NET Framework version 3.5 Service Pack 1 or later version is installed on your computer, you can run Web Deployment Tool directly from the share that contains the Web Deployment Tool program files. To install version 3.5 SP1, see Microsoft .NET Framework 3.5 Service Pack 1.
If you use a version earlier than 3.5 SP1 of the .NET Framework, you will need to override the code access security policy for the share by running the .NET Framework Code Access Security Policy Tool (Caspol.exe). The command you use will depend on whether the system is 32–bit or 64–bit. In the following examples, the network share is \\IISExtensions\WebDeploy\. The first example is 32–bit; the second example is 64–bit. Notice that the forward slashes are deliberate.
32–bit Caspol.exe command
%systemdrive%\Windows\Microsoft.NET\Framework\v2.0.50727\CasPol.exe -q -m -ag 1. -url file://IISExtensions/WebDeploy//* FullTrust
64–bit Caspol.exe command
%systemdrive%\Windows\Microsoft.NET\Framework64\v2.0.50727\CasPol.exe -q -m -ag 1. -url file://IISExtensions/WebDeploy/* FullTrust
The following example uses the program files on the \\IISExtensions\WebDeploy\x86\ share to synchronize site-level configuration from the local computer to the remote computer WebServer2.
C:\>\\IISExtensions\WebDeploy\x86\msdeploy.exe -verb:sync -source:apphostconfig -dest:auto,computername=WebServer2,username=administrator,password=<password>,tempAgent=true
If you use the tempAgent provider setting in a command as a non administrative user, but specify administrative credentials in the Web Deploy command, the command may fail with the error "The remote directory <DirectoryName> could not be created because of a login failure." This issue is more likely to occur in workgroup environments.
To resolve this issue, either run the command directly from a user account that has administrative privileges on the remote computer, or, before you run the Web Deploy command, run a
net use command such as the following to specify an administrative share and administrative credentials on the remote computer.
net use "\\Server1\C$\WINDOWS" /USER:Server1\administrator
You may receive an out of memory exception in a sync operation when the remote computer is Windows Server 2003 or Windows XP Professional. When using tempAgent, Web Deploy calls WMI to remotely start the Web Deployment Agent Service (MsDepSvc). By default, processes that are started by using WMI under Windows Server 2003 or Windows XP have a memory quota per host of 128 megabytes. You can change this limit by modifying the MemoryPerHost WMI property on the remote computer. For more information, see Memory and Handle Quotas in the WMI Provider Service. For Windows Vista®, Windows® 7, Windows Server® 2008, and Windows Server® 2008 R2, the limit is 512 megabytes.