I just posted about one of my new commands, gl-activatefeature, which covers activating features at different scopes using STSADM. That article covers all the code necessary to not only implement the activation, but also the deactivation. So creating the next command, gl-deactivatefeature, was as simple as copying the container code for the activation command and changing a few simple lines of code. This command works exactly like the other except that it deactivates the Feature instead of activating it.
The help for the command is shown below:
C:\>stsadm -help gl-deactivatefeature
stsadm -o gl-deactivatefeature
Deactivates a feature at a given scope.
Parameters:
{-filename <relative path to Feature.xml> |
-name <feature folder> |
-id <feature Id>}
[-scope <farm | webapplication | site | web | feature> (defaults to Feature)]
[-url <url>]
[-force]
[-ignorenonactive]
The following table summarizes the command and its various parameters:
| Command Name | Availability | Build Date |
|---|---|---|
| gl-deactivatefeature | WSS v3, MOSS 2007 | Released: 11/15/2008 |
| Parameter Name | Short Form | Required | Description | Example Usage |
|---|---|---|---|---|
| filename | f | Yes, if -name or -id is not provided | Path to feature must be a relative path to the 12\Template\Features directory. Can be any standard character that the Windows system supports for a file name. Note: If the feature file is not found on disk, the following error message is displayed: “Failed to find the XML file at location 12\Template\Features\<file path>.” | -filename "MyFeature\feature.xml", -f "MyFeature\feature.xml" |
| name | n | Yes, if -filename or -id is not provided | Name of the feature folder located in the 12\Template\Features directory | -name "MyFeature", -n "MyFeature" |
| id | Yes, if -filename or -name is not provided | GUID that identifies the feature to activate. Note: If the ID is specified but the feature does not exist, the following error message is returned: “Feature ‘<id>’ is not installed in this farm, and cannot be added to this scope.” | -id "21d186e1-7036-4092-a825-0eb6709e9280" | |
| scope | s | No | The scope to look at when deactivating the Feature. Valid values are “Farm”, “WebApplication”, “Site”, “Web”, or “Feature”. If “Feature” is specified then the scope of the Feature will be used. Note: Be careful when using a scope of “Web” (or “Feature” when the Feature is scoped to Web) as this will work recursively upon not just the single web but all sub-webs as well. | -scope site, -scope s |
| url | No | URL of the Web application, site collection, or Web site to which the feature is being deactivated with respect to the provided scope. So if the Feature is scoped to Web and you pass in a scope of Site then all webs within the Site Collection of the provided URL will have the Feature deactivated. If the scope is Farm then an URL is not required. | -url http://portal | |
| force | No | Forces the deactivation of the feature if already deactivated. | -force | |
| ignorenonactive | ignore | No | This will prevent the Feature from attempting a deactivation if it is not already activated thus avoiding errors about the Feature not being activated at the particular scope. | -ignorenonactive, -ignore |
The following is an example of how to deactivate a Site Collection scoped Feature on every site collection within a web application:
stsadm -o gl-deactivatefeature -name MyCustomFeature -scope webapplication -url http://mysites -force
The following is an example of how to deactivate a Web scoped Feature on every web within a web application where the Feature is already activated:
stsadm -o gl-deactivatefeature -name MyCustomFeature -scope webapplication -url http://portal -ignorenonactive