This article will guide you through the process of reviewing the dependencies for a website.
Article Goal: View the dependencies for my web site on IIS 6.0 so I know what I’d need to install on another machine in order to migrate or sync my site. I want to learn how to use getDependencies for a web site and how to analyze the output.
Prerequisites
This article requires the following prerequisites:
• .NET Framework 2.0 SP1 or greater
• MS Deploy Beta 1
Note: If you have not already installed MS Deploy, see Installing MS Deploy.
Before performing a migrate or sync operation by using MS Deploy, it is important to find out what dependencies exist on the source Web site or Web server. You will use this information in order to determine what features are in use, the disk space that is required, and what additional components to install on the target computer.
This walkthrough will show you how to call the getDependencies method, analyze and verify its output, and take actions accordingly. Because every server and site is different, the output will look different depending on what you have installed and configured. This walkthrough will use getDependencies to analyze an IIS 6.0 Web Site in preparation for migrating it to IIS 7.0.
Dependencies on IIS 6.0 - Because IIS 6.0 installed most components even if they were not in use, the tool may return components that you are not currently using. It may also return components that are not supported on IIS 7.0, such as WebDAV.
Dependencies on IIS 7.0 - Currently MS Deploy will detect IIS 7.0 built-in components as dependencies, such as Windows Authentication. However, because the tool is unaware of current and future out-of-band IIS extensions such as WebDAV, on IIS 7.0 these will be returned as native or managed modules, instead of installed components. This includes FPSE, WebDAV, Bitrate Throttling and other similar extensions.
Getting Dependency Information
To view the dependencies for an IIS 6.0 Web site, 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 -source:metakey=lm/w3svc/1 -param:alltrigger
The output will look like this:
<dependencyInfo>
<dependencies>
<dependency name="AnonymousAuthentication">
<trigger absolutePath="/lm/w3svc/AuthFlags" />
</dependency>
<dependency name="ASP">
<trigger absolutePath="systemInfo scriptmaps" />
</dependency>
<dependency name="ServerSideIncludeDisabled">
<trigger absolutePath="/lm/w3svc/ScriptMaps" />
</dependency>
<dependency name="AspNet1.1">
<trigger absolutePath="/lm/w3svc/ScriptMaps" />
</dependency>
</dependencies>
<apppoolsInUse>
<apppoolInUse name="DefaultAppPool" definitionIncluded="True">
<trigger absolutePath="/lm/w3svc/AppPoolId" />
<trigger absolutePath="/lm/w3svc/1/AppPoolId" />
<trigger absolutePath="/lm/w3svc/1/ROOT/AppPoolId" />
</apppoolInUse>
</apppoolsInUse>
<isapis>
<isapi dll="C:\Windows\system32\inetsrv\httpodbc.dll" enabled="False">
<trigger absolutePath="/lm/w3svc/ScriptMaps" />
</isapi>
</isapis>
<drives totalSpace="28163">
<drive name="C:" size="28163" sizeWindir="0" sizeInetpub="28163" />
</drives>
</dependencyInfo>
Analyzing the output
The <dependencies> section contains built-in IIS components that are identified as "in use". In this case, we see Anonymous and Windows Authentication. ServerSideIncludeDisabled indicates that server side includes are disabled. ASP and ASP.NET 1.1 are also indicated as dependencies.
The <apppoolsInUse> section identifies the application pools that the site is using. The definitionIncluded="False" attribute indicates that the application pool is not included in the source. This means that if you migrate only the value metakey=lm/w3svc/1, the application pool will not be included. To move the application pool, first specify that the default application pool be migrated by using metakey=lm/w3svc/apppools/DefaultAppPool.
Note: You can use a custom manifest to specify that the application pool will always be included in the scope of your operation. For more information, see Using Custom Manifests.
The <cgis> element contains 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 to see if this is allowed. In this case, you will have to check it manually.
The <isapis> element contains other script maps that are not recognized as a component (for example, the FastCGI DLL file fcgiext.dll). Custom ISAPI or CGI script maps will be listed here.
The <drives> element contains the drive space needed by the site in bytes and is reported by drive letter.
The <trigger> element identifies the location where a dependency was detected. A common question when looking at dependencies is what caused the dependency to be reported. The trigger path shows the location at which MS Deploy detected the dependency.
Verifying the output
After running the getDependencies method, you should take additional steps to verify the accuracy of the dependency information that has been reported.
First, if the status of a scriptmap for a Web site is unknown, you should look at the Web Service Extension list and check if the script maps or components referenced are allowed on the server. If a script map is not allowed, it is unlikely to be in use by the Web site.
Second, look at the script maps for the site. If they are being inherited from the parent, you might not see that you need other script maps. For example, if ASP.NET 2.0 is installed and configured at the W3SVC level, it may not be reported by getDependencies.
Third, you can use trigger elements to determine why a dependency was reported. For example, if Anonymous authentication was identified as a dependency, it will have a corresponding trigger with the path to where it is in use. Because a trigger is listed for every identified dependency, you can use triggers to figure out where a component is in use.
Due to the nature of these checks, it is possible for a dependency to be identified that is not in use or may not be required. MS Deploy will err on the side of reporting more dependencies than required so that you can determine what is needed.
Actions to perform based on the output
Based on this sample output above, you should install ASP.NET 1.1 and Classic ASP on the destination server, as well as the other dependencies listed (Anonymous and Windows authentication).
Important Note: Because the migration of some extensions is more complex than a simple file copy, the files associated with each script map or Web Service Extension will not be migrated automatically. You can migrate such extensions by specifying their files or folders in the manifest, or by installing them on the destination server.
Resolving conflicts and unsupported components
The getDependencies method may find some components that are not supported for migration to IIS 7.0 or that require special workarounds on the destination. For example, WebDAV and FrontPage Server Extensions are no longer integrated into IIS 7.0 and do not migrate.
Note: The IIS 6.0-based FTP server can be installed on IIS 7.0 but requires IIS 6.0 Metabase Compability. MS Deploy does not support migrating legacy FTP sites to the new FTP 7 out-of-band release.
Summary
In this walkthrough, you learned how to call getDependencies, how to analyze and verify the output, and how to determine what actions to take based on that output. Because every server and site is different, the output will look different depending on what you have installed and configured.
Comments