Web Deploy contentPath Provider
Applies To: Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Vista, Windows XP
contentPath
The contentPath provider synchronizes Web site content.
Example
msdeploy.exe -verb:sync -source:contentPath="Default Web Site" -dest:contentPath="MyNewSite"
The contentPath provider enables you to dump, synchronize, or archive all content of the path that you specify. The path that you specify can be a physical directory path, file path, or an IIS Web site or application path like MySite/MyApp.
By specifying an IIS Web site or application path, you can retrieve content separately from certificates, assemblies, or IIS configuration data. This capability is useful when you do not know the physical directory to which a site maps and just want to get the content and not the configuration data.
The contentPath provider uses the dirPath and filePath providers to implement its functionality. For more information about these providers, including information about how to use the ignoreErrors provider setting with contentPath, see Web Deploy dirPath Provider and Web Deploy filePath Provider.
Arguments
The contentPath provider accepts the following arguments.
A directory path (for example, c:\mydirectory)
A file path (for example, c:\mydirectory\test.htm)
A site path (for example, "Default Web Site" or MySite)
An application path (for example, "Default Web Site/MyApp"or MySite/MyApp/default.htm)
If the path you specify contains a drive (for example, C:\ ), Web Deploy will assume that the path is a file or directory path. If the path contains a share (for example, \\server), Web Deploy will assume that the path is an application or site path and will attempt to map it to a physical path. UNC paths and mapped network drives are supported. Environment variables like %windir% are supported, but wildcard characters are not. If the path contains spaces, the path must be enclosed in double quotation marks. Trailing backslashes are not permitted.
Note
Relative paths like ./mypath or . are not accepted.
dump
In a dump operation, if the path that you specify is an application or Web site, the directory and file paths of the content for the application or Web site will be recursively returned. If you specify a directory or filepath, the specified directory or file path will be recursively returned. If you specify the -xml operation setting, the results are returned in XML format and include attribute information.
sync
In a sync operation, if the source file or folder does not exist on the destination, the provider creates the folder and any subfolders that have the corresponding files and attributes. If the destination folder already exists, the provider updates only those objects that do not match the source. This means that in some cases only one file or folder will be updated. Files on the destination that do not exist on the source will be deleted. The source and destination folders for contentPath do not have to have the same name. If the name of the destination folder differs from that of the source, the name of the destination folder will remain the same, but the contents of the folder will be updated to those of the source.
Permissions
For IIS 7, the contentPath provider relies on the ability of the caller to read the ApplicationHost.config file whenever you specify an application path. Impersonation of a user account that has access to read properties in the ApplicationHost.config file is required. For IIS 6.0, this provider relies on the ability of the caller to read the MetaBase.xml file. Because there is no impersonation service on IIS 6.0, you may have to run this provider as administrator when you specify an application path.
Non-administrative users
Non-administrative users of the contentPath provider will not have direct access to IIS configuration. For example, the first command may succeed for a non-administrative user, but the second will fail.
msdeploy -verb:dump -source:contentPath=c:\ServerDir1msdeploy -verb:dump -source:contentPath="Site1"
In a case like this, non-administrative users can use the Web Deployment Handler syntax (computerName=<URL>) if they have been delegated appropriate permissions as IIS Manager Users. For example:
msdeploy -verb:dump -dest:contentPath=c:\remotePath,computername=https://serverName/agent.mwd?Site=Site1
File ownership information and the includeAcls provider setting
By default, the contentPath provider does not synchronize ACLs, attributes, or ownership information. This is because the permissions are copied as security identifiers (SIDs) and may not work uniformly on all computers.
If you need to synchronize both permissions and content, you can use the optional includeAcls provider setting to include ACLs in the sync operation. By default, includeAcls is false. If includeAcls is set to true, ACLs will be copied as SIDs. For the permissions to be set correctly, you must use domain accounts or have local accounts with matching SIDs on both the source and destination computers.
In a sync operation in which includeAcls is set to true, parent folders on the destination will continue to inherit their permissions as they did before the synchronization. For example, in the following command, if the folder c:\inetpub on the destination already exists, it will retain its ACLs, but the subfolder c:\inetpub\wwwroot will have its ACLs set by the source.
msdeploy -verb:sync -source:contentPath=c:\inetpub\wwwroot,includeAcls=true -dest:contentPath=c:\inetpub\wwwroot,computerName=Server1
This is because directory paths may contain multiple levels above …\wwwroot or the specific directory that you are synchronizing. The permissions and attributes of \wwwroot will always be replaced, but permissions and attributes above this location will be set only if the parent folders do not already exist. Similarly, files that are created on the destination will inherit their ACLs from the parent directory on the destination if the parent directory already exists on the destination.
Note
If the source or destination is a drive letter (for example, "E:") without an additional path, the contents of the E: drive will be synchronized, but permissions will not be set on the drive itself.
Warning
Because the FAT file system cannot preserve NTFS file system ACLs, you should not synchronize files from an NTFS file system to a FAT file system. If you do so, no warning will be issued. Note that, in any case, Windows Server® 2008 (and IIS 7) cannot be installed on FAT32 file systems. For security reasons, the use of IIS 6.0 on FAT file systems is not recommended.
Example usages
1) Dump a Web site path.
msdeploy -verb:dump –source:contentPath=MySite
2) Dump a Web site's contents with the XML flag, showing attributes.
msdeploy -verb:dump -source:contentPath=MySite –xml
3) Dump the contents of an application path.
msdeploy.exe -verb:dump-source:contentPath="MySite.com/My App"
4) Synchronize the contents of a directory to an application path.
msdeploy.exe -verb:sync -source:contentPath="C:\compiledappdir" -dest:contentPath="MySite.com/My App"
5) Synchronize the contents of a directory to a remote directory, setting includeAcls to true to specify that ACLs will be copied from the source to the destination.
msdeploy.exe -verb:sync -source:contentPath=C:\TemplateApp1,includeAcls=true -dest:contentPath=C:\contosoApp,computerName=Server1,username=admin,password=pass
6) Synchronize the default Web site to another Web site.
msdeploy.exe -verb:sync -source:contentPath="Default Web Site" -dest:contentPath="MySite.com"
7) Synchronize a file path to an application file path.
msdeploy.exe -verb:sync -source:contentPath="C:\CompiledApp\MyApp\default.htm" -dest:contentPath="MySite.com/contoso/MyApp/default.htm"
8) Unpackage the contents of the Package.zip file and put them in the C:\temp folder. Do not delete any files that already exist in the destination folder.
msdeploy.exe -verb:sync -source:package=C:\package.zip -dest:contentpath=C:\temp -enableRule:DoNotDeleteRule