Applies To: Windows 7, Windows Server 2003, Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Vista, Windows XP
Before using Web Deploy to perform a sync operation, you will need to find any applications on which the source Web site or Web server depends—that is, "dependencies"—that need to be manually installed on the target server before the operation is run.
By default, Web Deploy automatically checks for dependencies during sync operations. To control which dependencies are flagged, you can enable or disable Web Deploy's built-in dependency check rules by using the enableRule and disableRule operation settings. Each dependency check rule has an associated failure level of Warning or Error. By default, a sync operation will fail if any dependency check rule throws an Error. If you enable the DependencyCheckFailOnWarning rule, either a Warning or an Error thrown will cause the operation to fail. For more information about dependency check rules, see Web Deploy Rules. For more information about enableRule and disableRule, see Web Deploy Operation Settings.
If you want to discover these dependencies before starting a sync operation, use the Web Deploy getDependencies operation. This will let you know what applications to install on the destination. The output from getDependencies includes information about authentication-related dependencies, ISAPI and CGI component information, and application pools that are being used.
This topic will show you how to call the getDependencies operation, analyze and verify its output, and take actions accordingly. Because every server and site is different, the output will differ depending on what you have installed and configured.
Getting Dependency Information
To view all of the dependencies for an IIS 6.0 Web site before synchronizing it to IIS 7, run the following command (for the "1" in
lm/w3svc/1, enter the site ID of the site that you want to analyze).
msdeploy -verb:getDependencies,alltrigger -source:metakey=lm/w3svc/1
Sample output follows.
<dependencyInfo> <dependencies> <dependency name="AnonymousAuthentication"> <trigger absolutePath="/lm/w3svc/1/ROOT/AuthFlags" /> </dependency> <dependency name="WindowsAuthentication"> <trigger absolutePath="/lm/w3svc/1/ROOT/AuthFlags" /> </dependency> <dependency name="FrontPageServerExtensions"> <trigger absolutePath="/lm/w3svc/1/ROOT/FrontPageWeb" /> </dependency> <dependency name="ServerSideIncludeDisabled"> <trigger absolutePath="systemInfo scriptmaps" /> </dependency> <dependency name="ASP"> <trigger absolutePath="systemInfo scriptmaps" /> </dependency> </dependencies> <apppoolsInUse> <apppoolInUse name="DefaultAppPool" definitionIncluded="False"> <trigger absolutePath="/lm/w3svc/1/AppPoolId" /> <trigger absolutePath="/lm/w3svc/1/ROOT/AppPoolId" /> </apppoolInUse> <apppoolInUse name="MSSharePointAppPool" definitionIncluded="False"> <trigger absolutePath="/lm/w3svc/1/ROOT/_vti_bin/AppPoolId" /> </apppoolInUse> </apppoolsInUse> <isapis> <isapi dll="C:\WINDOWS\system32\inetsrv\httpodbc.dll" enabled="False"> <trigger absolutePath="systemInfo scriptmaps" /> </isapi> </isapis> </dependencyInfo>
Analyzing the output
<dependencies> section contains built-in IIS components that are identified as "in use." The
<trigger> elements identify the locations where the dependencies were detected. The sample output shows that Anonymous authentication, Windows authentication, FrontPage Server Extensions, and ASP are being used, and that server-side includes (SSI) are disabled.
<apppoolsInUse> section identifies the application pools that the site is using. A separate
<apppoolInUse> element appears for each application pool. For the default application pool, the
definitionIncluded="False" attribute indicates that the application pool will not be included in the synchronization.
<cgis> element is present in the dependencies, it will contain the CGI script maps that are on the source computer. The attribute value
Restricted="Unknown" means that the tool could not check the Web Service Restriction List and that you will have to check it manually.
<isapis> element contains other script maps that are not recognized as built-in IIS components (for example, Fcgiext.dll, the FastCGI DLL). Custom ISAPI or CGI script maps will be listed here.
Verifying output accuracy
After running getDependencies, you should take additional steps to verify the accuracy of the dependency information that has been reported.
If the source is an IIS 7 Web site, make sure that you examine the Web.config file for script maps. The getDependencies operation will not detect any script maps that are in a Web.config file.
When you specify
alltrigger, every dependency element will contain a
<trigger> element that shows the path to the dependency’s location. You can use this information to determine where the dependency is. For example, the trigger element for Anonymous authentication in the sample output shows
/lm/w3svc/1/ROOT/AuthFlags. For more information about using trigger elements, see Controlling the Output of Trigger Information.
It is possible for a dependency to be identified that is not being used or that may not be required. The tool will show all possible dependencies that might be required, but it is up to you to determine the dependencies that you really need.
Actions to perform based on the output
Based on the sample output, you should pre-install or configure Anonymous authentication, Windows authentication, and ASP on the destination server. Front Page Server Extensions are not supported for synchronization to IIS 7, so you must install them manually on the destination server. Web Deploy reports "ServerSideIncludeDisabled" as a dependency if the source script map contains server-side includes (SSI) but SSI is disabled in the Web Service Extension Restriction list. For increased security in a case like this, make sure that SSI is not installed on the destination server.
The <apppoolsInUse> section shows that two application pools are being used for the site. Because their definitionIncluded attribute is set to false, they will not be synchronized. By default, application pools are not included in a site-level synchronization. To include the application pools, you can add the
-enableLink:AppPoolExtension operation setting to the command (for more information, see Web Deploy Link Extensions and Web Deploy Operation Settings). Alternatively, you can synchronize the application pool first in a separate operation by specifying
metakey=lm/w3svc/apppools/DefaultAppPool as the source, or you can manually create the application pools on the destination server prior to the synchronization.
The <isapis> section lists the httpodbc.dll ISAPI file as a dependency. Because this ISAPI is not enabled, its installation on the destination server is probably not required.
Because the synchronization of some extensions is a more complex process than a simple file copy, the files associated with each script map or Web Service Extension will not be synchronized automatically. You can synchronize such extensions by specifying their files or folders in a manifest, or by installing them on the destination server. For more information about manifests, see Creating and Synchronizing a Custom Manifest.
Resolving conflicts and unsupported components
The getDependencies operation may find some components that are not supported for synchronization to IIS 7 or that require special workarounds on the destination. For example, WebDAV and FrontPage Server Extensions are no longer integrated into IIS 7 and are not synchronized. Front Page Server Extensions must be synchronized manually. For information on how to manually install an updated version of WebDAV on IIS 7, see Installing and Configuring WebDAV on IIS 7.0.
The IIS 6.0-based FTP server can be installed on IIS 7 but requires IIS 6.0 metabase compability. Web Deploy does not support synchronizing the sites that used earlier versions of FTP to sites that use the new Microsoft FTP Services for IIS 7.
If you specify webServer60 or webServer for the -source argument, the getDependencies operation will not show FTP Server as an IIS 6.0 dependency. To return this dependency, you must use the metaKey provider, as in the following example.
msdeploy -verb:getDependencies -source:metaKey=lm/msftpsvc -xml
This topic showed you how to call getDependencies, how to analyze and verify the output, and how to determine the actions to take based on the output. Because all servers and sites differ, your output will look different depending on what you have installed and configured.