Enable Canonical URL in IIS7 for SEO

What is URL Canonicalization? – Its just nothing but you are making sure that your users and the search engines are accessing your websites on your preferred domain name only like either  www.website.com or website.com.


Why URL Canonicalization? – Well Its for avoiding the confusion of Search Engines that you are having a duplicate website where you are really having one. If you keep allow accessing your website by both www.website.com and website.com separately search engines will think both are different websites. So its mainly for SEO purpose we do canonicalize the URLs. Search Engines treat websites that can be accessed by more than one domain name, such as   www.website.com and website.com, as if they are two different sites. This affects the page ranking for the website.


Enable canonical url in IIS7 simply by pasting the below code to your web.config.

Code for URL Canonicalization :

<configuration>
    <system.webServer>
      <!--Code for URL Canonicalization Starts Here-->
        <rewrite>
            <rules>
                <rule name="CanonicalHostNameRule1">
                    <match url="(.*)" />
                    <conditions>
  <add input="{HTTP_HOST}" pattern="^www\.website\.com$" negate="true" />
                    </conditions>
                    <action type="Redirect" url="http://www.website.com/{R:1}" />
                </rule>
            </rules>
        </rewrite>
      <!--Code for URL Canonicalization Ends Here-->
    </system.webServer>
</configuration>

This permanently redirects (301 redirect) every requests comes to smartadmins.org or its sub-urls to  www.website.com and its corresponding sub-urls seo friendly.

You can use it by just replacing the domain name with your own, in your shared hosting easily on following conditions.
1. Your hosting server must be installed with URL Rewrite Module
2. Managed Pipeline Mode of your Application Pool must be Integrated

So what if you are having a new Windows Dedicated Server, well lets do that easily by few clicks as shown below, but ofcourse only if you have administrator access 

Steps to Enable Canonical URLs in Dedicated Windows Hosting

First you need to download IIS URL Rewrite Module
Download URL Rewrite Module for your 32bit Server Edition (x86)
Download URL Rewrite Module for your 64bit Server Edition (x64)

Check your Server edition and download corresponding msi packages and just install it by double clicking the downloaded msi and by following the steps.

Now after finishing the setup just open your IIS Manager and expand your sites section and click on your domain name you need to enable canonical URL.

Step 1: Now as shown in the below screenshot click on the URL Rewrite option under IIS section of your website

Step 2: On the URL Rewrite window click on Add Rule on the top right corner, and the Rules window just click on the Canonical domain name under Search Engine Optimization (SEO) section and click OK

Step 3: Now select your preferred domain name to set as canonical url (either www url or non-www url as primary domain name) and click OK

Thats it!!! You just activated canonical url for your ASP.Net website 

How to disable web.config Inheritance for Child Applications in sub folders in ASP.NET?

Each ASP.NET Web Application has its own configuration file called web.config file. 

In fact every directory in ASP.NET application can have one. Settings in each web.config file apply to the pages in the directory where its placed, and all the subdirectories of that directory.

This is called Configuration Inheritance. 


So if you create an ASP.NET application and set its web.config file, add custom HttpHandlers, UrlRewriting module etc and try to create another ASP.NET Web Application in the subfolder, you can end up having problems because application in the subfolder will inherit all the settings from its parent  web.config.


So if you for example setup UrlRewriter module in your root web applications like this:

       <httpModules>

             <add name="UrlRewriteModule" type="UrlRewritingNet.Web.UrlRewriteModule, UrlRewritingNet.UrlRewriter"/>

                <add name ="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

      </httpModules>

And in your child web application (in subfolder) you are not using UrlRewriteModule, then if you try to run the child Web Application in your browser, you will get error like this:




Configuration Error:


Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately. 


Parser Error Message: Could not load file or assembly 'UrlRewritingNet.UrlRewriter' or one of its dependencies. The system cannot find the file specified. (d:\Projects\VS\AspDotNetFaqProject\Website\web.config line 89)


Source Error: 


Line 88: <httpModules>
Line 89: <add name="UrlRewriteModule" type="UrlRewritingNet.Web.
              UrlRewriteModule, UrlRewritingNet.UrlRewriter"/>
Line 90: <add name="ScriptModule" type="System.Web.Handlers.ScriptModule,
             System.Web.Extensions, Version=3.5.0.0, Culture=neutral,  
             PublicKeyToken=31BF3856AD364E35"/>
Line 91: </httpModules>

What happens here is that because UrlRewriteModule is configured in the parent's folder web.config file, this setting is inherited by the child application's web.config file, and because of this ASP.NET is looking for the UrlRewriteModule DLL file in the BIN directory, and off course its not there.


Luckily, there is a easy solution to this problem.


First thing you can do is to remove the problematic HttpModule in your child application web.config file using the remove command like this:


      <httpModules>

        <remove name="UrlRewriteModule" />

      </httpModules>

This would remove the handler and your application would run fine.
Or you could use <clear/> command like this:


       <httpModules>

            <clear/>

       </httpModules>

This would clear all the HttpModules in your child application.


But what to do when there are many settings in your root web.config file that you don't want to be propagated to your child applications?


Here is the solution:
With the <location> attribute with  inheritInChildApplications  set to false  in your root web.config file you can restrict configuration inheritance. 
So, by wrapping a section of your web.config file in <location> attribute you can instruct ASP.NET not to inherit those settings to child applications/folders and their web.config files.


In fact  you can wrap the whole <system.web> section in one <location> attribute and disable configuration inheritance so none of the parent settings from <system.web> will be inherited to the child applications you create in subfolders.


Here is how to use this in practice:

 <location path="." inheritInChildApplications="false">

    <system.web>
    ...

    </system.web>
  </location>

  
NOTE: Do remember that if you do this, you need to manually insert all the settings you need in the <system.web> for your child applications because none of the settings from the root web.config will be propagated...

New in IIS 7 - App Pool Isolation

In previous versions of IIS, it has sometimes been difficult to isolate web application pools from each other. If multiple web application pools are configured to run as the same identity (e.g. Network Service) then code running inside one web application pool would be able to use File System objects to access configuration files, web pages and similar resources belonging to another web application pool. This was because it was impossible to allow one process running as Network Services access to a file, but prevent another process also running as Network Service access to the same file.

In IIS 7.0 it is possible, with some work, to prevent this from occurring. As part of IIS 7.0 inbuilt functionality, each web application pool has an application pool configuration file generated on-the-fly when that application pool is started. These are stored, by default, in the %systemdrive%\inetpub\temp\appPools folder. Each web application pool has an additional SID (Security Identifier) generated for it, and this in injected into the relevant w3wp.exe process. The application pool's configuration file is ACLed to allow only that SID access. Since each w3wp.exe process has it's own SID, each application pool's configuration file is ACLed to a different SID:

Using the icacls.exe tool it is possible to determine the SID applied to any given application pool's configuration file. This can be done by using the command:

icacls.exe %systemdrive%\inetpub\temp\appPools\appPool.config /save output.txt

The actual SID always starts with the well-known identity prefix: S-1-5-8-82 followed by a hash of the Application Pool's name.

The retrieved SID can now be used to secure web site content in the same way. To do this:
Edit: Thomas Deml (from the IIS Product Group) has shown me an easier way to perform Step 4 below

1. Configure each website (or web application) to run in its own web application pool
2. Configure anonymous authentication to use the application pool identity rather than the IUSR account (this can be done by editing the Anonymous Authentication properties for the website in question)
3. Remove NTFS permissions for the IUSRS group and the IUSR account from the website's files and folders.
4. Use the icacls.exe tool to permit the App Pool's individual SID Read (and optionally Execute and Write) access to the web site's files and folders. You don't need to initially retrieve the SID using iCacls. Instead simply use: IIS APPPOOL\ApplicationPoolName as the user to grant read permissions to (see screenshot below for an example for the Default App Pool)

After configuring these NTFS permissions, only the SID that has been injected into a particular w3wp.exe process will be able to read the contents of the website in question. All code running in other w3wp.exe processes, even though the process identity may also be Network Service, will be unable to read this particular website's content. This technique may be most useful to web hosters or similar administrators, that need to accept content from various external or untrusted parties.

Edit #2: Here's a screenshot of the dynamic SID injection in action for the Default App Pool (using the excellent Process Explorer tool). The username highlighted can be used with icacls.exe to ACL your web content.

Application Pool Identities

Introduction

IIS introduces a new security feature in Service Pack 2 (SP2) of Windows Server 2008 and Windows Vista. It's called Application Pool Identities. Application Pool Identities allow you to run Application Pools under a unique account without having to create and manage domain or local accounts. The name of the Application Pool account corresponds to the name of the Application Pool. The image below shows an IIS worker process (W3wp.exe) running as the DefaultAppPool identity.

Application Pool Identity Accounts

Worker processes in IIS 6.0 and IIS 7 run as NETWORKSERVICE by default. NETWORKSERVICE is a built-in Windows identity. It doesn't require a password and has only user privileges; that is, it is relatively low-privileged. Running as a low-privileged account is a good security practice because then a software bug can't be used by a malicious user to take over the whole system. 

However, a problem arose over time as more and more Windows system services started to run as NETWORKSERVICE. This is because services running as NETWORKSERVICE can tamper with other services that run under the same identity. Because IIS worker processes run third-party code by default (Classic ASP, ASP.NET, PHP code), it was time to isolate IIS worker processes from other Windows system services and run IIS worker processes under unique identities. The Windows operating system provides a feature called "Virtual Accounts" that allows IIS to create unique identities for each of its Application Pools. Click here for more information about Virtual Accounts.

Configuring IIS Application Pool Identities 

If you are running IIS 7.5 on Windows Server 2008 R2, you don't have to do anything to use the new identity. For every Application Pool you create, the IIS Admin Process (WAS) will create a virtual account with the name of the new Application Pool and run the Application Pool's worker processes under this account.

If you are running Windows Server 2008, you have to change the IdentityType property of the Application Pools you create to "AppPoolIdentity". Here is how:

• Open the IIS Management Console (INETMGR.MSC).
• Open the Application Pools node underneath the machine node. Select the Application Pool you want to change to run under an automatically generated Application Pool Identity.
• Right click the Application Pool and select "Advanced Settings..."

• Select the "Identity" list item and click the ellipsis (the button with the three dots).
• The following dialog appears.
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  
  • Select the Identity Type "ApplicationPoolIdentity" from the combo box.

  To do the same step by using the command-line, you can call the appcmd command-line tool the following way:

  %windir%\system32\inetsrv\appcmd.exe set AppPool <your AppPool> -processModel.identityType:ApplicationPoolIdentity
  

  Securing Resources

  Whenever a new Application Pool is created, the IIS management process creates a security identifier (SID) that represents the name of the Application Pool itself. For example, if you create an Application Pool with the name "MyNewAppPool," a security identifier with the name "MyNewAppPool" is created in the Windows Security system. From this point on, resources can be secured by using this identity. However, the identity is not a real user account; it will not show up as a user in the Windows User Management Console. 

  You can try this by selecting a file in Windows Explorer and adding the "DefaultAppPool" identity to the file's Access Control List (ACL).

  1. Open Windows Explorer
  2. Select a file or directory.
  3. Right click the file and select "Properties"
  4. Select the "Security" tab
  5. Click the "Edit" and then "Add" button
  6. Click the "Locations" button and make sure you select your machine.
  7. Enter "IIS AppPool\DefaultAppPool" in the "Enter the object names to select:" text box.
  8. Click the "Check Names" button and click "OK".

  By doing this, the file or directory you selected will now also allow the "DefaultAppPool" identity access.
  
  

  

  You can do this via the command-line by using the ICACLS tool. The following example gives full access to the DefaultAppPool identity.

  ICACLS test.txt /grant "IIS AppPool\DefaultAppPool":F
  

  On Windows 7 and Windows Server 2008 R2, the default is to run Application Pools as the Application Pool Identity. To make this happen, a new identity type with the name "AppPoolIdentity" was introduced. If the "AppPoolIdentity" identity type is selected (the default on Windows 7 and Windows Server 2008 R2), IIS will run worker processes as the Application Pool identity. With every other identity type, the security identifier will only be injected into the access token of the process. If the identifier is injected, content can still be ACLed for the AppPool identity, but the owner of the token is probably not unique. Here is an article that explains this concept.

  Accessing the Network

  Using the NETWORKSERVICE account in a domain environment has a great benefit. Worker process running as NETWORKSERVICE access the network as the machine account. Machine accounts are generated when a machine is joined to a domain. They look like this:

  <domainname>\<machinename>$,

  for example:

  mydomain\machine1$

  The nice thing about this is that network resources like file shares or SQL Server databases can be ACLed to allow this machine account access.

  What about AppPool identities?

  The good news is that Application Pool identities also use the machine account to access network resources. No changes are required.

  Compatibility Issues with Application Pool Identities

  Guidance Documentation 

  The biggest compatibilty issue with Application Pool Identities is probably earlier guidance documents which explicitly recommend that you ACL resources for NETWORKSERVICE, that is, the default identity of the DefaultAppPool in IIS 6.0 and IIS 7.0. Customers will have to change their scripts to ACL for "IIS AppPool\DefaultAppPool" when running on IIS 7.5 (see the example above for how to do this).

  User Profile

  IIS doesn't load the Windows user profile, but certain applications might take advantage of it anyway to store temporary data. SQL Express is an example of an application that does this. However, a user profile has to be created to store temporary data in either the profile directory or in the registry hive. The user profile for the NETWORKSERVICE account was created by the system and was always available. However, with the switch to unique Application Pool identities, no user profile is created by the system. Only the standard Application Pools (DefaultAppPool and Classic .NET AppPool) have user profiles on disk. No user profile is created if the Administrator creates a new Application Pool.

  However, if you want, you can configure IIS Application Pools to load the user profile by setting the "LoadUserProfile" attribute to "true".

  Summary

  Application Pool Identities are a powerful new isolation feature introduced for Windows Server 2008, Windows Vista, Windows 7 and Windows Server 2008 R2. It will make running IIS applications even more secure and reliable.

Ensure Security Isolation for Web Sites

Introduction

The recommendation for isolating Web sites in a shared hosting environment is consistent with all general security isolation recommendations for Internet Information Services 7 (IIS 7). In particular, it is recommended to:

• Use one application pool per Web site.
• Use a dedicated user account as an identity for the application pool.
• Configure anonymous user identity to use the application pool identity.
• Ensure that FastCGI impersonation is enabled in the Php.ini file.

An architectural view of application pools appears in the figure that follows.

Create Application Pools

You can create application pools from the UI or the command line.

1. From the IIS Manager, navigate to the Connections pane.

2. Choose the Application Pools option, and then choose Add Application Pool to open the Add Application Pool dialog box.

3. Enter a unique name for the application pool.

4. Choose the version, if any, of the Microsoft® .NET Framework for the application pool to use, and then choose your pipeline mode.

Once a pool is created, you can change its settings whenever necessary.

1. From the Connections pane, choose Application Pools.

2. In the Work pane, choose the application pool you would like to configure.

3. From the Actions pane, choose Basic Settings. Note that with the exception of the dialog box title, the Basic Settings dialog box and the Add Application Pool dialog boxes look identical.

You can also use the command line. Use:

appcmd add apppool /name:string

Note that string is the name of the application pool.

The Edit Application Pool dialog box lets you configure how IIS 7 handles worker process recycling for the application pool.

Application Pool Identities

Application Pool Identities is a new security features that lets you run application pools under a unique account without having to create and manage domain or local accounts. The name of the application pool account corresponds to the name of the application pool. The figure that follows shows an IIS worker process (w3wp.exe) running as the DefaultAppPool identity.

Application Pool Identity Accounts

Worker processes in IIS 6 and IIS 7 run as NETWORKSERVICE by default. NETWORKSERVICE is a built-in Windows® identity. NETWORKSERVICE does not require a password and has only user privileges (it is relatively low privileged). Running as a low-privileged account is a good security practice because this prevents malicious users from using software bugs to take over the system.

Over time, however, more and more Windows system services have been run as NETWORKSERVICE, and these services can tamper with other services running under the same identity. Because IIS worker processes run third-party code by default (PHP, classic ASP, and Microsoft® ASP.NET), it became necessary to isolate IIS worker processes from other Windows system services and to run IIS worker processes under unique identities. The Windows operating system provides a feature called virtual accounts that lets IIS create unique identities for each of its application pools.

Whenever a new application pool is created, the IIS management process creates a security identifier (SID) representing the name of the application pool itself. For example, if you create an application pool with the name "MyNewAppPool," a SID with the name "MyNewAppPool" is created in the Windows Security system. Resources can be secured using this identity. Note that the identity is not a real user account, however; it will not show up as a user in the Windows User Management Console.

Try selecting a file in Windows Explorer® and adding the "DefaultAppPool" identity to its Access Control List (ACL):

1. Start Windows Explorer.

2. Select a file or directory.

3. Right-click on the file name, and then click Properties.

4. Click the Security tab.

5. Click Edit, and then click Add.

6. Click Locations, and select your computer.

7. In the Enter the object names to select text box, type iis apppool\defaultapppool

8. Click Check Names, and then click OK.

The file or directory you selected now also allows the DefaultAppPool identity access.

You can also use the command line with the Icacls.exe tool. The following gives full access to the DefaultAppPool identity:

ICACLS test.txt /grant "IIS AppPool\DefaultAppPool":F

On the Windows® 7 and Windows Server® 2008 R2 operating systems, the default is to run Application Pools as this security identifier (as the Application Pool Identity). A new identity type with the name "AppPoolIdentity" is available. If the "AppPoolIdentity" identity type is selected (this is the default on Windows 7 and Windows Server 2008 R2), IIS will run worker processes as the Application Pool identity. With every other identity type, the security identifier is only injected into the access token of the process. If the identifier is injected, content can still be ACLed for the AppPool identity, but the owner of the token is probably not unique. See the section Isolate Application Pools that follows.

Accessing the Network

Using the NETWORKSERVICE account in a domain environment has a great benefit. Worker process running as NETWORKSERVICE can access the network as the machine account. Machine accounts are generated when a machine is joined to a domain:

<domainname>\<machinename>$,

For example:

mydomain\machine1$

Network resources such as file shares or Microsoft® SQL Server® databases can be ACLed to allow access for this machine account. Application Pool identities also use the machine account to access network resources. No changes are required.

Compatibility Issues with Application Pool Identities

A challenge with Application Pool Identities is that guidance documents explicitly recommend to ACL resources for NETWORKSERVICE (the default identity of the DefaultAppPool in IIS 6.0 and 7.0). Users must change their scripts to ACL for "IIS AppPool\DefaultAppPool" when running on IIS 7.5.

IIS does not load the Windows user profile, but certain applications (such as Microsoft® SQL Server® 2008 Express) might use it anyway (for example, to store temporary data). The user profile must be created to store temporary data in the profile directory or in the registry hive. The user profile for the NETWORKSERVICE account was created by the system and was always available. A user profile is not created by the system, however, when switching to unique Application Pool identities. Only the standard application pools (DefaultAppPool and Classic .NET AppPool) have user profiles on disk. No user profile is created if the administrator creates a new application pool.

Note that IIS application pools can be configured to load the user profile however by setting the "LoadUserProfile" setting to "true".

Isolate Application Pools

Separating applications into multiple application pools not only can improve performance but also improves server and site reliability. However, in previous versions of IIS, it has sometimes been difficult to isolate Web application pools from each other. If several application pools are configured to run with the same identity, then code running inside one application pool could use file system objects (FSOs) to access resources belonging to another.

In IIS 7, each application pool has a configuration file that is generated when the application pool is started. These files are stored by default in the %systemdrive%\inetpub\temp\AppPools folder.

Each application pool also has a Security Identifier (SID) that is added to the relevant w3wp.exe process. The application pool’s configuration file is access control listed (ACLed) to only allow access to that SID.

You can use the Icacls.exe tool to identify the SID applied to any given application pool’s configuration file with:

icacls.exe %systemdrive%\inetpub\temp\appPools\appPool.config /save output.txt

A user can use the application pool SID to ACL their contents and secure their Web site. This is useful for Web hosters who need to accept content from various external sources.

1. Configure each Web site (or Web application) to run in its own Web application pool.

2. Configure anonymous authentication to use the application pool identity, rather than the Industry Usability Reporting (IUSR) account by editing the Anonymous Authentication properties.

3. Remove NTFS permissions for the IUSRS group and the IUSR account from the Web site’s files and folders.

4. Use the Icacls.exe tool to give the application pool’s SID “read” (and optionally “execute” and “write”) access to the Web site's files and folders. You can use IIS APPPOOL\ApplicationPoolName as the user to grant read permissions.

After configuring the NTFS permissions, only the SID that has been injected into a particular w3wp.exe process will be able to read the contents of the Web site. All code running in other w3wp.exe processes (even if running with the same identity) will not be able to access this Web site’s content.

Getting Started with AppCmd.exe

Overview

AppCmd.exe is the single command line tool for managing IIS 7 and above. It exposes all key server management functionality through a set of intuitive management objects that can be manipulated from the command line or from scripts.

AppCmd enables you to easily control the server without using a graphical administration tool and to quickly automate server management tasks without writing code.

Some of the things you can do with AppCmd:

• Create and configure sites, apps, application pools, and virtual directories
• Start and stop sites, and recycle application pools
• List running worker processes, and examine currently executing requests
• Search, manipulate, export, and import IIS and ASP.NET configuration

AppCmd also allows server administrators to build advanced management tasks simply by combining multiple simpler AppCmd.exe commands, or reusing the output of the tool inside another program.

How to Use AppCmd.exe

The AppCmd.exe command line is built on top of a set of top level server management objects, such as Site and Application. These objects expose methods that can be used to perform various actions on those objects, and object instances expose properties that can be inspected and manipulated.

For example, the Site object provides methods to list, create and delete site instances (these are standard methods that are present on almost all objects), as well as stop and start sites. Each site instance in turn will contain properties, such as site name and site id, that can be inspected, searched for, or set. The output of each command is always a list of object instances.

Note: AppCmd.exe is located in the %systemroot%\system32\inetsrv\ directory. Because it is not path of the PATH automatically, you need to use the full path to the executable when executing commands like in "%systemroot%\system32\inetsrv\AppCmd.exe list sites". Alternatively, you can manually add theinetsrv directory to the path on your machine so that you can access AppCmd.exe directly from any location.

The tool works by executing a command on one of the supported management objects, with optional parameters used to further customize the behavior of the command:

APPCMD (command) (object-type) <identifier> < /parameter1:value1 ... >*

Where <COMMAND> is one of the commands supported by <OBJECT>. Most objects support this basic set of commands:

• LIST  Display the objects on the machine. An optional <ID> can specify a unique object to list, or one or more parameters can be specified to match against object properties.
• ADD  Create a new object with the specified object properties to set during creation.
• DELETE  Delete the object specified by the <ID>.
• SET  Set parameters on the object specified by <ID>.

An object will often support additional commands, such as START and STOP for the Site object.

For example, the current set of objects available through AppCmd is (where <OBJECT> is one of the management objects supported by the tool):

Object	Description
Site	Administration of virtual sites
App	Administration of applications
VDir	Administration of virtual directories
Apppool	Administration of application pools
Config	Administration of general configuration sections
Backup	Management of server configuration backups
WP	Administration of worker processes
Request	Display of active HTTP requests
Module	Administration of server modules
Trace	Management of server trace logs

Where <ID> is the object-specific identifier for the object instance you want to specify for the command. The format of the identifier is specific to each object type. For example, the Site object uses the site name, the App object uses the application path, and the AppPool object used the application pool name.

Where [ /parameter:value ]* is zero or more parameters for the command. Each command supports a different set of parameters, depending on the object. Typically, commands that search for objects or manipulate object properties will allow any of the object's properties to be specified as a parameter.

The tool itself also supports a number of parameters that affect the general command execution, and are not specific to any of the objects. These are listed in the top-level help page available from "AppCmd.exe /?", and include parameters such as /text, /config, and /xml for controlling tool output, and/commit for controlling the location of configuration changes.

Getting Help

AppCmd provides self-describing help that can be used as a reference for all of the supported objects and commands. There are three types of help available as you drill into the task you would like to do.

General Help

The general help screen shows the objects supported by the tool, as well as generally applicable tool parameters. To display general help:

APPCMD /?

The first few lines of output are:

General purpose IIS command line administration tool.

APPCMD (command) (object-type) <identifier> < /parameter1:value1 ... >

Supported object types:

  SITE      Administration of virtual sites

  APP       Administration of applications              
...            

Object Help

The object help screen shows the commands supported by a specific object. To display object help:

APPCMD <OBJECT> /?

where <OBJECT> is one of the supported object types. For example, this command-line will display help for the site object:

APPCMD site /?        

Command Help

The command help screen describes the syntax for a specific command and object, including the parameters it supports and examples of common tasks. To display command help:

APPCMD <COMMAND> <OBJECT> /?

For example, this command-line will display help for the LIST command of the App object:

APPCMD list app /?

Finding Objects with the LIST Command

The LIST command is the most versatile command, and is supported by all objects. The purpose of this command is to find instances of the object based on the criteria you specify. The output of this command is a list of object instances, which you can inspect by viewing their properties, export for future re-creation on another machine, or use together with another command to perform actions on them.

Listing All Objects

The simplest way to use the LIST command is with no parameters, which simply lists all known instances of the object:

APPCMD list <OBJECT> 

For example, to list all sites on the machine, use this command-line:

%systemroot%\system32\inetsrv\APPCMD list sites

The output will be similar to:

SITE "Default Web Site" (id:1,bindings:HTTP/*:80:,state:Started)

SITE "Site1" (id:2,bindings:http/*:81:,state:Started)

SITE "Site2" (id:3,bindings:http/*:82:,state:Stopped)

By default, each object is shown on a single line, specifying its object-specific identifier (such as "Default Web Site") and one or more important properties (such as id, bindings, and state).

Listing a Specific Object

The LIST command can be used to find an instance of a specific, named object by using a command-line in this form:

APPCMD list <OBJECT> <ID>

For example, use this command-line to find the site with a unique id of "Default Web Site":

%systemroot%\system32\inetsrv\APPCMD list site "Default Web Site"       

Listing Objects That Satisfy a Query

To find all object instances that match particular criteria, specify one or more parameters that indicate property values of the objects to match. For example, use this command-line to find all sites that are stopped:

%systemroot%\system32\inetsrv\APPCMD list sites /state:Stopped

You can specify any number of property-value pairs, and the tool will make sure that the returned objects satisfy all of the specified criteria. For example, use this command-line to find sites that are both stopped and configured to not start automatically:

%systemroot%\system32\inetsrv\APPCMD list sites /serverAutoStart:false /state:Stopped

Manipulating Objects with ADD, SET, and DELETE

In addition to LIST, most objects also support ADD, SET, and DELETE commands.

Adding New Objects

The ADD command creates a new instance of an object. For example, this command-line will create a new Site:

%systemroot%\system32\inetsrv\APPCMD add site /name:MyNewSite /bindings:"http/*:81:" /physicalPath:"C:\MyNewSite"

Depending on the object, some parameters will be required in order to set required properties on the new instance, and other properties may be optional. An error will be returned if a required parameter is not specified.

The command help screen indicates which parameters are required. For example, use this command-line to see what parameters are required to add a Site:

%systemroot%\system32\inetsrv\APPCMD add site /?

Read on for more information on creating sites, applications, virtual directories and application pools with AppCmd.

Changing Existing Objects

The SET command sets one or more properties on a specified object instance. This command requires the object-specific identifier to be specified. For example, to change the id property of the "Default Web Site", use this command-line:

%systemroot%\system32\inetsrv\APPCMD set site "Default Web Site" /id:200

Use a form of the command help syntax to see what properties can be set on a particular object. For example, to see the properties supported by the Default Web Site use:

%systemroot%\system32\inetsrv\%systemroot%\system32\inetsrv\APPCMD set site "Default Web Site" /?        

Deleting Objects

The DELETE command deletes an instance of an object. Like SET, this command also requires the object-specific identifier to be specified. For example, use this command-line to delete the site named "MyNewSite":

%systemroot%\system32\inetsrv\%systemroot%\system32\inetsrv\APPCMD delete site "MyNewSite"      

Managing Backups

AppCmd allows you to create and restore backups of global server configuration. You can use this to recover from unwanted changes to server configuration, and return to known-good server state. It is a good idea to create a backup before changing server configuration, or installing a component that changes it. Each backup contains the copy of the current ApplicationHost.config root configuration file, as well as other related server-wide state including FTP configuration and the IIS Administration Tool configuration.

To create a backup, use the ADD command of the Backup object:

%systemroot%\system32\inetsrv\APPCMD add backup

BACKUP object "20060519T172530" added

This created a backup with an auto-generated name that represents the date and time of backup.

A specific name for the backup can be specified like this:

%systemroot%\system32\inetsrv\APPCMD add backup MyBackup

BACKUP object "MyBackup" added

You can display a list of available backups using the LIST command of the Backup object:

%systemroot%\system32\inetsrv\APPCMD list backups

BACKUP "20060519T172530"

BACKUP "MyBackup"

Finally, to restore a backup use the RESTORE command with name of the backup:

%systemroot%\system32\inetsrv\APPCMD restore backup "MyBackup"

Restored configuration from backup "MyBackup"

Restoring a backup stops the server and restores global configuration to its state at the time the backup was created.

In Windows Server® 2008 and Windows Vista SP1, AppCmd will also be capable of working with periodic configuration backups made by the configuration history service. These backups will show up in the AppCmd list of backups and will be available to restore the same way as backups you made manually through the tool. 

Working with Sites, Applications, Virtual Directories, and Application Pools

Creating and managing sites, applications, and virtual directories are the most common tasks administrators face. IIS 7 and above uses a stricter containment hierarchy than previous versions that works like this:

1. Web Site  A Web site receives requests on particular binding endpoints defined by IP addresses and host headers. For example, this url represents a Web site bound to port 81: http://www.mysite.com:81
   A Web site contains one or more applications.
2. Application  An application is represented by its virtual path within a Web site's url namespace. For example, an application with a virtual path of "/app1" may be represented by this url: http://www.mysite.com:81/app1
   An application belongs to one application pool.
   An application contains one or more virtual directories.
3. Virtual Directory  A virtual directory is represented by its virtual path within an application's url namespace. For example, a virtual directory with a virtual path of "/vdir1" may be represented by this url: http://www.mysite.com:81/app1/vdir1
   A virtual directory maps to a physical location on disk.

This hierarchy is in contrast to IIS 6.0 where a Web site can contain a mix of virtual directories and applications, and applications are just specially marked virtual directories.

Application Pool  An application pool specifies a group of settings for the worker processes that perform request processing for the applications in that application pool. Application pools are not part of the site-app-vdir hierarchy. Each application specifies which application pool it will run in, or it runs in the default application pool. The application pool defines a number of worker process settings, such as the version of the CLR loaded by it, the .NET integration mode, the account under which the worker process runs, and process recycle settings.

By default, IIS 7 and above are installed with a Web site named "Default Web Site" that listens on port 80 with no IP address nor host header restrictions. This Web site has a root application, and that application has a root virtual directory. There is also an application pool named "DefaultAppPool" which is used by all new applications by default.

This command-line will list all Sites, including the Default Web Site:

%systemroot%\system32\inetsrv\APPCMD list sites

SITE "Default Web Site" (id:1,bindings:HTTP/*:80:,state:Started) 

Let's examine the applications that belong to the Default Web Site by specifying the site.name property when listing Apps:

%systemroot%\system32\inetsrv\APPCMD list apps /site.name:"Default Web Site"

APP "Default Web Site/" (applicationPool:DefaultAppPool) 

A similar command will list the virtual directories inside the "Default Web Site/" application by specifying the app.name property when listing Vdirs:

%systemroot%\system32\inetsrv\APPCMD list vdirs /app.name:"Default Web Site/" 

VDIR "Default Web Site/" (physicalPath:C:\inetpub\wwwroot) 

Finally, let's examine the application pools:

%systemroot%\system32\inetsrv\APPCMD list apppools

APPPOOL "DefaultAppPool" (MgdVersion:v2.0,MgdMode:Integrated,state:Started)

APPPOOL "Classic .NET AppPool" (MgdVersion:v2.0,MgdMode:ISAPI,state:Started)

Creating Sites, Applications, Virtual Directories, and Application Pools

Now, we will create a new Web site named "MySite", with site id of 2 that listens on port 81 for all IP addresses and host headers:

%systemroot%\system32\inetsrv\APPCMD add site /name:MySite /id:2 /bindings:http/*:81: /physicalPath:C:\inetpub\mysite

SITE object "MySite" added

APP object "MySite/" added
VDIR object "MySite/" addedThe name parameters must be specified to create a Web site. The id parameter is optional, and will cause AppCmd to generate the next available site id for the new site if omitted. We also specify the bindings and physicalPath parameters, which are explained below. You can also specify additional properties to set their values.

The bindings property uses the format of protocol/bindingInformation, where bindingInformation is specific to the protocol. For HTTP, it is in the format of IP:PORT:HOSTHEADER.  You can specify multiple bindings by using a comma to separate each definition.

We also specified a physicalPath property for the site. While a Web site itself does not have a physical path, this short form is used to conveniently create a Web site with a root application and a root virtual directory mapped to the specified physical path.

If you do not specify a physical path, the Web site will be created with no applications; an application and virtual directory will need to be created for it explicitly.

Let's go ahead and add another application to the Web site:

%systemroot%\system32\inetsrv\APPCMD add app /site.name:MySite /path:/app1 /physicalPath:C:\inetpub\mysite\app1

APP object "MySite/app1" added
VDIR object "MySite/app1/" added

This created a new application with virtual path "/app1" belonging to the site we created above, with a root virtual directory pointing to "C:\inetpub\mysite\app1". The required path parameter specifies the virtual path of the new application, and the required site.name parameter specifies the site to which the application will belong. The optional physicalPath parameter is a shortcut, much like in the Site case, that creates a root virtual directory together with the application.

If you do not specify the physicalPath parameter, or would like to add another virtual directory to the application, use a command-line like this:

%systemroot%\system32\inetsrv\APPCMD add vdir /app.name:"MySite/app1" /path:/vdir1 /physicalPath:C:\inetpub\mysite\app1\vdir1

VDIR object "MySite/app1/vdir1" added

This created a new virtual directory with virtual path "/vdir1" belonging to the application we created above and pointing to "C:\inetpub\mysite\app1\vdir1". The required path parameter specifies the virtual path of the new virtual directory, and the required app.name parameter specifies the application to which the virtual directory will belong. The physicalPath parameter specifies the physical location of the virtual directory.

Finally, let's create a new application pool:

%systemroot%\system32\inetsrv\APPCMD add apppool /name:MyAppPool

APPPOOL object "MyAppPool" added

This created a new application pool named "MyAppPool".

Configuring Sites, Applications, Virtual Directories, and Application Pools

Previously, we added a new Web site, complete with a few applications and virtual directories. Now, we will use AppCmd to modify some of their properties. All AppCmd objects support the same standard syntax for setting properties:

APPCMD SET <OBJECT> <ID> [ /property:value ]*

First, let's display the applications available on the machine:

%systemroot%\system32\inetsrv\APPCMD list apps

APP "Default Web Site/" (applicationPool:DefaultAppPool)

APP "MySite/" (applicationPool:DefaultAppPool)

APP "MySite/app1" (applicationPool:DefaultAppPool)

Notice the two applications we created earlier under the Web site "MySite". Both of these applications are set to use the DefaultAppPool application pool. Let's change the applicationPool property of the "MySite/" root application to use the new application pool we created earlier named "MyAppPool":

%systemroot%\system32\inetsrv\APPCMD set app "MySite/" /applicationPool:MyAppPool

APP object "MySite/" changed

This changed the value of the applicationPool property of the "MySite/" application to the new value, effectively moving the application to the new application pool.

The reason we moved the application to the new application pool is so that we can change some of the runtime parameters of the worker process within which this application will run. To do that, we will change some of the properties on the "MyAppPool" application pool. Before changing property values, it if often useful to first display the available properties and their current values. We can do that by listing our application in detailed view:

%systemroot%\system32\inetsrv\APPCMD list apppool "MyAppPool" /text:*

APPPOOL

  APPPOOL.NAME: MyAppPool
  managedPipelineMode: Integrated
  managedRuntimeVersion: v2.0
  state: Started
  [add]
    name:"MyAppPool"
    queueLength:"1000"
    autoStart:"true"
    enable32BitAppOnWin64:"false"
    managedRuntimeVersion:"v2.0"
    managedPipelineMode:"Integrated"
    passAnonymousToken:"true"
    [processModel]
      identityType:"NetworkService"
      userName:""
      password:""

...
      pingingEnabled:"true"
...

Notice the number of properties on the application pool object; the full output is not shown here.

We are interested in changing the managedRuntimeVersion property to "v1.1" in order to run our applications in this application pool with ASP.NET v1.1. Here is the command-line to do that:

%systemroot%\system32\inetsrv\APPCMD set apppool "MyAppPool" /managedRuntimeVersion:v1.1

APPPOOL object "MyAppPool" changed

You can see from the List output above that there are numerous properties available on the application pool object, and some of the properties are nested within a configuration sub-element. For example, process options are nested below the "processModel" sub-element.

If you want to set a nested property, address it with element path notation like this:

%systemroot%\system32\inetsrv\APPCMD set apppool "MyAppPool" /processModel.pingingEnabled:false        

Other Configuration Elements

In addition to manipulating configuration properties with the top-level AppCmd objects, you can set configuration properties on any configuration section, including the ones associated with the top-level AppCmd objects. This is covered later in the section named "Working with Configuration".

Inspecting Server State

AppCmd provides functionality for inspecting various aspects of the runtime state of the server, including:

• site state
• application pool state
• active server worker processes
• currently executing requests

In addition, some objects provide commands that allow you to control their runtime state, such as the STOP command of the Site object and RECYCLE command of the AppPool object.

Inspecting Site and Application Pool State

The state of sites and application pools is reported from the state property of each object. When listing sites or application pools, the state is displayed in the default output. For example:

%systemroot%\system32\inetsrv\APPCMD list apppools DefaultAppPool

APPPOOL "DefaultAppPool" (MgdVersion:v2.0,MgdMode:Integrated,state:Started)

The state property can also be used to search for sites or application pools that are in a specific state. For example, to find all started application pools:

%systemroot%\system32\inetsrv\APPCMD list apppools /state:started

APPPOOL "DefaultAppPool" (MgdVersion:v2.0,MgdMode:Integrated,state:Started)
APPPOOL "Classic .NET AppPool" (MgdVersion:v2.0,MgdMode:ISAPI,state:Started)                          

Inspecting Running Worker Processes

You can use the WP (worker process) object to list running worker processes:

%systemroot%\system32\inetsrv\APPCMD list wps

WP "3577" (apppool:DefaultAppPool)

Each WP object has an apppool.name property, which allows you to list all of the running worker processes for a particular application pool:

%systemroot%\system32\inetsrv\APPCMD list wps /apppool.name:DefaultAppPool

WP "3577" (apppool:DefaultAppPool)

Inspecting Currently Executing Requests

The Request object allows you to inspect the currently executing requests on the server:

%systemroot%\system32\inetsrv\APPCMD list requests

REQUEST "fb0000008000000e" (url:GET /wait.aspx?time=10000,time:4276 msec,client:localhost)

The list can be restricted to the requests of a particular site, application pool, worker process, or url by using the appropriate property to filter the results. Here are some examples:

%systemroot%\system32\inetsrv\APPCMD list request /apppool.name:DefaultAppPool

%systemroot%\system32\inetsrv\

APPCMD list requests /wp.name:3567

%systemroot%\system32\inetsrv\APPCMD list requests /site.id:1      

Working with Configuration

IIS 7 and above feature an XML-based hierarchical configuration system similar to the ASP.NET configuration system that stores server configuration in schematized XML sections. The configuration can be located at the server level ApplicationHost.config file, or placed in distributed Web.config configuration files within your application hierarchy.

AppCmd allows full inspection and editing of the configuration hierarchy from command-line via its Config object. In addition, AppCmd provides other useful functions such as clearing configuration, locking and unlocking it, and searching it.

Viewing Configuration

AppCmd works with configuration at the level of configuration sections. Each configuration section typically describes a server feature, and may contain one or more sub-elements and collections.

Configuration can be set for an arbitrary url namespace, such as for a site, application, or url. Configuration settings set at a higher level are inherited by all lower levels unless they are specifically overridden at lower levels.

To display effective configuration for particular url level, use the LIST command of the Config object as follows:

%systemroot%\system32\inetsrv\APPCMD list config <URL> /section:SectionName

Where <URL> is the configuration path at which the effective configuration should be read, such as "Default Web Site/" or "Default Web Site/app1/hello.html". If not specified, it defaults to server level.

The section parameter specifies the configuration section you would like to read. If not specified, all configuration sections effective at the URL level will be displayed. For example, this command-line displays all effective configuration for the root application of the Default Web Site:

%systemroot%\system32\inetsrv\APPCMD list config "Default Web Site/"

To list a specific section, use a command-line like this:

%systemroot%\system32\inetsrv\APPCMD list config "Default Web Site/" /section:asp

<system.webServer>

  <asp>
    <session />
    <comPlus />
    <cache />
    <limits />
  </asp>
</system.webServer>

By default, AppCmd displays only configuration that is explicitly set. If you would like to display the effective configuration including inherited or default values, specify the /config:* parameter:

%systemroot%\system32\inetsrv\APPCMD list config "Default Web Site/" /section:asp /config:*

To display a list of available configuration sections, use this command-line:

%systemroot%\system32\inetsrv\APPCMD list config /section:?

Editing Configuration Properties

In AppCmd, each configuration section is exposed as an instance of a configuration object that exposes properties that represent the underlying configuration section. Use the SET command of the Config object to change these properties. The syntax is:

APPCMD set config <URL> /section:SectionName [ /property:value ]+

<URL> is optional; it specifies at what configuration path the change should apply. It omitted, changes will be applied at the server level, to be inherited by all URLs.

The section parameter is required; it indicates the section that is being edited.

For example, to set the appAllowClientDebug property of the ASP section for the http://localhost/app1 url:

%systemroot%\system32\inetsrv\APPCMD set config "http://localhost/app1" /section:asp /appAllowClientDebug:false

CONFIG object "asp" changed

To set configuration properties nested within sub-elements of the configuration section, use this element path notation:

%systemroot%\system32\inetsrv\APPCMD set config "http://localhost/app1" /section:asp /limits.requestQueueMax:4000

CONFIG object "asp" changed

Specify more than one property in a single command-line to make multiple edits within the same configuration section.

To display all of the properties that can be set on a particular configuration section, use this command-line:

%systemroot%\system32\inetsrv\APPCMD set config /section:asp /?

NOTE that the asp section is locked by default, so executing these commands will return a lock violation error. You can either unlock this section first, set the configuration at the server level by omitting the<URL>, or commit them to the server level location tag by using /commit:apphost. See controlling location of configuration further in the article.   

Editing Configuration Collections

AppCmd also provides support for editing configuration collections. A configuration collection can contain multiple elements — for example, thesystem.webServer/modules configuration section contains a list of module configuration elements specifying the modules executed by the server.

To set a property on a collection element, specify the particular collection element to edit by using a collection indexer expression within the element path notation. The collection indexer expression uses key values to identify a specific collection element. The indexer has the following format:

[key1='value1',key2='value2',...]

The number of keys required to uniquely identify an element depends on the collection. Most collections require only one key.

For example, in order to set the type property on the collection element with the key name property equal to "FormsAuthentication", use this command-line:

%systemroot%\system32\inetsrv\APPCMD set config /section:system.webServer/modules /[name='FormsAuthentication'].type:System.Web.Security.FormsAuthenticationModule

To add a new collection element, prefix the element path notation with a plus sign, +. Within the collection indexer expression, provide the values for each key property. Additional, non-key properties may also be included within the collection indexer expression. For example, this will add a new module collection element:

%systemroot%\system32\inetsrv\APPCMD set config /section:system.webServer/modules /+[name='MyModule',type='MyType']
To delete a collection element, prefix the element path notation with a minus sign, -: 

%systemroot%\system32\inetsrv\APPCMD set config /section:system.webServer/modules /-[name='MyModule']

Controlling Location of Configuration

The configuration system is hierarchical, allowing configuration settings to be written at multiple levels ranging from the server-level ApplicationHost.config file to distributed Web.config files that can be present at the site, application, or virtual directory levels.

When the configuration is written at a particular level, it is inherited by all URLs at that level and lower. For example, configuration set in the Web.config configuration file at the root of the site in inherited by all URLs of the site.

By default, AppCmd will write configuration at the level at which it is being set. For example, if you are setting configuration for the "Default Web Site/", it will be written in a Web.config file at the root of that site.

However, it is possible to write configuration at a higher level, and only apply it to a particular subset of URLs below by using a location construct. For example, the application Web.config can contain configuration that is applied to only a single directory within that application. AppCmd provides this capability through its commit parameter.

The commit parameter can be set to one of the following:

• (omitted) — default; write configuration at the level for which it is set
• url — same as default; write configuration at the level for which it is set
• site — write configuration in the Web.config at the site root of the url for which it is set
• app — write configuration in the Web.config at the app root of the url for which it is set
• apphost — write configuration at the server level, in the applicationHost.config file
• <PATH> — write configuration at the specified config path

For example, this command-line turns directory browsing off for an application, and writes that configuration within the Web.config file of the site root:

%systemroot%\system32\inetsrv\APPCMD set config http://localhost/app1/ /section:directoryBrowse /enabled:false /commit:site

Locking and Unlocking Configuration

The configuration system allows configuration sections to be locked at a particular level, preventing their properties from being overridden at lower levels. This can be used to prevent applications from changing settings that the server administrator wishes to enforce.

By default, most of the IIS configuration sections are locked at the server level. In order to configure these sections at lower levels, they need to be unlocked. AppCmd provides the UNLOCK command for this purpose:

%systemroot%\system32\inetsrv\APPCMD unlock config /section:asp

Use the LOCK command to lock a section:

%systemroot%\system32\inetsrv\APPCMD lock config /section:asp

Note that if you lock a configuration section, all applications that may have already configured that section at a lower level will experience a lock violation error when they try to access the configuration section.

Searching Configuration

AppCmd can search the distributed configuration hierarchy for all locations that set particular configuration properties or property values. The configuration search feature can be used to pinpoint locations where a particular feature is being enabled, or to insure compliance with a particular configuration requirement.

To search the server for all locations that define configuration, you can use the SEARCH command with no arguments:

%systemroot%\system32\inetsrv\APPCMD search config

To search all locations under a particular configuration path, such as all configuration locations for a particular site, include the path on the command-line:

%systemroot%\system32\inetsrv\APPCMD search config "Default Web Site/" 

To search for locations that configure a particular configuration section:

%systemroot%\system32\inetsrv\APPCMD search config "Default Web Site/" /section:directoryBrowse

To search for locations that set a particular property, include the property name:

%systemroot%\system32\inetsrv\APPCMD search config "Default Web Site/" /section:directoryBrowse /enabled

And finally, to search for locations that set a property to a specific value:

%systemroot%\system32\inetsrv\APPCMD search config "Default Web Site/" /section:directoryBrowse /enabled:true

Working with Tool Output

Earlier, we mentioned that the output of the LIST command is a list of object instances. AppCmd offers different output modes that allow control over the level of detail displayed about each object.

Default Output

Let's take LIST Sites as an example. By default, AppCmd uses a compact output format:

%systemroot%\system32\inetsrv\APPCMD list sites

SITE "Default Web Site" (id:1,bindings:HTTP/*:80:,state:Started)
SITE "Site1" (id:2,bindings:http/*:81:,state:Started)
SITE "Site2" (id:3,bindings:http/*:82:,state:Stopped)

In this output format, each object instance is on one line, specifying the object type (SITE), and the object's identifier ("Default Web Site"). Several common or important properties are generally also output (id, bindings, and state for the Site object).

Detailed Output

Most objects support significantly more properties than are presented in the default output. To display all of the object properties, specify the text:* parameter. The properties of each instance will be displayed in a hierarchical tree format:

APPCMD list site "Default Web Site" /text:*

SITE
  SITE.NAME: Default Web Site
  SITE.ID: 2
  bindings: http/*:80:
  state: Started...

In the example above, the output has been abbreviated — the actual output includes many more properties.

Output for Working With Other Command-line Tools

AppCmd provides an output mode that displays only a specific property of each object instance. Specify the name of the property to display with the text:<PROPERTY> parameter. For example, this command will return all of the virtual directory instances available, displaying only the physicalPath property of each:

%systemroot%\system32\inetsrv\APPCMD list vdirs /text:physicalPath

C:\inetpub\wwwroot

C:\inetpub\vdir1
D:\vdir2

You can, of course, display any of the valid property of the object-type being listed.

It is sometimes desireable to use the output of AppCmd with existing command line tools and shell commands, such as the FOR command and FINDSTR.EXE. These tools often work best when each data item of interest is located on a separate line.

As an example, imagine a command-line that produces a directory listing of each IIS virtual directory. The command-line needs to acquire a list of physical paths from each of the virtual directories of interest, and then execute a DIR command on each of those paths using the FOR command to loop though them:

FOR /F %f IN ('%systemroot%\system32\inetsrv\APPCMD list vdir /text:physicalPath') DO CALL DIR %f

Configuration Output

Many of the objects contain configuration data that comes directly from the associated configuration sections. The Config object is the main example of that, and serves as a direct wrapper over the IIS configuration system — each object instance returned by the Config object is a configuration section. Other objects, such as Site, also contain configuration information as part of the object properties.

If you would like to display the configuration information for the returned objects in the raw XML format of the configuration system, you can use the configparameter. For example, to display the XML configuration information for the site object, use a command-line like this:

%systemroot%\system32\inetsrv\APPCMD list site "Default Web Site" /config        

<site name="Default Web Site" id="1">

<bindings>
        <binding protocol="HTTP" bindingInformation="*:80:" />...

XML Output

The tool also supports its own XML output format, which generates well-formed XML result sets for the objects returned from the command execution. This enables some exciting capabilities that distinguish AppCmd from any previous command line tools provided by the IIS team.

• Building complex management tasks. The main purpose of this ability is to enable the result sets generated by AppCmd to be input to another AppCmd command. This enables you to quickly execute complex management tasks without writing application code.
• Performing batch operations efficiently. Executing the tool a large number of times when performing a large number of operations (for example creating 10,000 sites) may be slow due to the overhead of process creation and initialization for each operation. Instead, a single tool command can execute over input data contained within an XML data set, dramatically reducing the execution time of processing the input data.
• Exporting data to other tools. The XML format enables the data sets generated by AppCmd to be used with other tools in order to process, store, or provide reporting. For example, AppCmd data can be used with XSLT transforms to general HTML management reports, imported into SQL Server 2005 for further analysis, or loaded by ADO.NET for programmatic processing.

For example, to output the list of sites in XML mode:

%systemroot%\system32\inetsrv\APPCMD list sites /xml