Web Deploy iisApp Provider
Bijgewerkt: september 2009
Van toepassing op: Windows Server 2008
The iisApp provider synchronizes directory content to a folder and marks the folder as an application.
msdeploy -verb:sync -source:iisApp=c:\Contoso -dest:iisApp="Site1/ContosoApp"
The iisApp provider dumps, synchronizes, or archives the content of a physical directory or an IIS Web application like MySite/MyApp. The provider processes all content for the specified path. The iisApp provider is useful when the source is a directory that you want to make into an application on the destination. It is also useful when you do not know the physical directory of a source site or application and want to retrieve its content, but not its configuration data. By passing the site or application path to the provider, you can retrieve the content separately from certificates, assemblies, or IIS configuration data.
The iisApp provider uses the contentPath, createApp, dirPath, and filePath providers to implement its functionality. For more information, see Web Deploy contentPath Provider, Web Deploy createApp Provider, Web Deploy dirPath Provider, and Web Deploy filePath Provider.
The iisApp provider accepts the following arguments.
A directory path (for example, c:\mydirectory)
A site path (for example, "Default Web Site" or MySite)
An application path (for example, "Default Web Site/MyApp")
IIS 6.0 site paths or application paths of the form lm/w3svc/<siteID> can be used, but they must be preceded by a forward slash (for example, /lm/w3svc/1). If no forward slash is provided, the initial "lm" will be interpreted as a site name. If the path you specify contains a drive (for example, C:\), Web Deploy will assume that the path is a 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.
|Relative paths like ./mypath or . are not accepted.|
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, the specified directory and included file paths will be recursively returned. If you specify the -xml operation setting, the results are returned in XML format and include attribute information.
|Using the iisApp provider with the dump verb produces the same result as using the contentPath provider with the dump verb.|
In a sync operation, the iisApp provider copies content to a folder under the destination site that you designate and marks the destination folder as an application. The iisApp provider cannot create a site.
|If the source that you specify for iisApp is a Web site, the destination will be marked as an application. If you want to synchronize a Web site and its related configuration, use the appHostConfig provider.|
|The iisApp provider does not synchronize server or site-level configuration defaults. If the source and the destination configuration defaults are different, the synchronized application will inherit the application pool and other configuration defaults of its parent site on the destination.|
If a file or folder in the source 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 iisApp do not have to have the same name. If you specify an existing destination folder whose name differs from that of the source, the name of the destination folder will remain the same, but the contents of the destination folder will be updated to those of the source. If you do not specify a path for the source, no content will be synchronized, but the destination will be marked as an application.
|In a sync operation, the caller must have write permissions on the destination in order to create the application on the destination.|
For IIS 7, the iisApp 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 of the iisApp 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:iisApp=c:\ServerDir1\UserAppDir
msdeploy -verb:dump -source:iisApp="Site1/UserApp"
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:iisApp=c:\remotePath,computername=http://serverName/agent.mwd?Site=Site1/UserApp
File ownership information and the includeAcls provider setting
By default, the iisApp 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:iisApp=c:\inetpub\wwwroot -dest:iisApp=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.
|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.|
|Because the FAT file system cannot preserve NTFS file system ACLs, you should not synchronize 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.|
Custom Provider Settings
The iisApp provider has 4 optional custom provider settings.
The enable32BitAppOnWin64 provider setting checks whether the enable32BitAppOnWin64 attribute of the destination application pool matches the true or false setting that you specify. The value that you specify will be used only for comparison, and will not be set. If the attribute of the destination application pool does not match the value that you specify, the synchronization will fail. This provider setting has no default value and will have no effect if you do not specify a value for it. The enable32BitAppOnWin64 attribute does not apply to IIS 6.0 or earlier versions of IIS.
<BOOL> is either true or false. True if the enable32BitAppOnWin64 attribute of the destination application pool should be true; false if the destination attribute should be false.
The managedPipelineMode provider setting checks whether the managedPipelineMode attribute of the destination application pool matches the setting that you specify (Integrated or Classic). The value that you specify will be used only for comparison, and will not be set. If the attribute of the destination application pool does not match the value that you specify, the synchronization will fail. This provider setting has no default value and will have no effect if you do not specify a value for it. The managedPipelineMode attribute does not apply to IIS 6.0 or earlier versions of IIS.
Usage: ,managedPipelineMode=[Integrated | Classic]
The managedRuntimeVersion provider setting checks whether the managedRuntimeVersion attribute of the destination application pool matches the .NET framework version that you specify (for example, "v2.0"). The value that you specify will be used only for comparison, and will not be set. If the attribute of the destination application pool does not match the value that you specify, the synchronization will fail. This provider setting has no default value and will have no effect if you do not specify a value for it. The managedRuntimeVersion attribute does not apply to IIS 6.0 or earlier versions of IIS.
The skipAppCreation provider setting optionally specifies whether the destination of the sync operation will be marked as an application.
<BOOL> is either true or false. True if the destination of the sync operation will not be marked as an application; otherwise, false. The default value is false.
If skipAppCreation is set to true, the destination folder will not be marked as an IIS application, but the content and properties of the source will still be copied to the destination.
1) Synchronize all content from the source folder "C:\NewAppSource" to a folder called "My New App" under the home directory of the "Default Web Site", and mark that folder as an application in IIS. The new application will inherit the application pool settings from its parent application. In this example, the parent is the default Web site root application).
msdeploy -verb:sync -source:iisApp=c:\NewAppSource -dest:iisApp="Default Web Site/My New App"
2) Synchronize content as in example 1), but get the source content from the physical location of the "My Site/My Old App" application.
msdeploy -verb:sync -source:iisApp="My Site/My Old App" -dest:iisApp="default web site/My New App"
3) Leave the source path empty so that no content will be synchronized, but mark the destination as an application.
msdeploy -verb:sync -source:iisApp -dest:iisApp="Default Web Site/My New App"
4) Synchronize the content from the source folder "C:\OldApp" to a folder called "FutureApp" under the home directory of "MySite", but do not mark the folder as an application.
msdeploy -verb:sync -source:iisApp=c:\OldApp -dest:iisApp="MySite/FutureApp",skipAppCreation=true