There are different levels of scope for deployment, but I have not been able to find a definitive explaination of when each applies and what the restrictions are that require loosening (or tightening) the scope.

I've looked around for some time, and have found tidbits of information here and there, but so far I have not found a definitive explaination.

For features, I know I can set the feature scope in the feature properties page. For the most part I try to deploy to the smallest scope possible and only increase it if, while developing, I receive the error that I must deploy at a feature at a specific scope.

For solutions, there is the WebApplication to deploy to. I would prefer to deploy most of my solutions to just one web application, but that is often disallowed with a PowerShell window full of red text that tells me I must deploy to all web applications. Similarly, I am often forced to deploy to the GAC when I don't see any reason for the requirement.

So to frame this as a question that I hope can be answered; can someone explain (or direct me to a page that explains) when each scope is required and what conditions need to be met to restrict a solution to a specific scope?


  • 1
    You can find answer in this post.
    – Alexander
    Commented Feb 1, 2012 at 14:29
  • Thanks for your detail reply . I’m having a issue with Web application scope solution that not appearing in Timer Job definitions under CA , Operations Tab. Deployed the solution with out and issue //Deployed Solution with PowerShell 01 Uninstall-SPSolution -Identity Solution.wsp -WebApplication "webapplication" 02 Remove-SPSolution -Identity Solution.wsp –force 03 net stop sptimerv4 04 net start sptimerv4 06 Add-SPSolution e:\solutions\Solution.wsp 07 install-spsolution Solution.wsp -webapplication "webapplication" -GACDeployment –force 03 net stop sptimerv4 04 net start sptimerv4 05 iisreset Commented Oct 10, 2013 at 0:56
  • @variable I don't get it, why you opened a bounty on this question when it already has an accepted answer with 34 votes ?
    – MdMazzotti
    Commented May 28, 2015 at 7:10
  • @MdMazzotti Hello. One or more of the answers (Falak Mahmood's answer) is exemplary and worthy of an additional bounty. This is the reason I think it deserves more points and I am awarding it to the answer.
    – variable
    Commented May 28, 2015 at 8:52

3 Answers 3


For Features

SharePoint Features can be scoped to the Farm, Web Application, Site Collection, and Web Site level depending on the purpose of the feature. The Feature scope is determined by the setting of the Scope attribute in the Feature element defined in the feature.xml file.

A sample Feature element tag is given below:

<Feature Id="F62C96CF-79FD-44be-8882-E9BFBD199184" 
    Title="Feature Title" 
    Description="Feature Description" 

Web Site scoped Feature (Scope="Web"):

A Web Site scoped Feature is one that can be activated only at the individual Web site level. List templates, list instances, custom actions, event receivers, etc are the some common elements for web site scoped features. Web Site scoped features can be activated by using:

Run the following STSADM command:

stsadm -o installfeature -name FeatureFolderName –url http://servername/site/subsite

Site Collection scoped Feature (Scope="Site"):

A Site Collection scoped Feature is one that can be activated at the site collection level and contains items that apply to the site collection as a whole (for example, content types that are shared across the site collection), as well as items that can be activated per site (for example, list instances, etc). Site Collection scoped features can be activated by:

Run the following STSADM command:

stsadm -o installfeature -name FeatureFolderName –url http://servername/site/sitecollection

Web Application scoped Feature (Scope="WebApplication"):

A Web Application scoped Feature is one that can be activated at the web application level and contains items like administrative web application links, delegate control registrations, feature/site template association, document form registrations, etc. A farm Feature can contain, for example, links to /_layouts pages and files, /_admin pages, and other elements. Web Applicationscoped features can be activated by using:

Run the following STSADM command:

stsadm -o installfeature -name FeatureFolderName -url http://servername

Farm scoped Feature (Scope="Farm"):

A Farm scoped Feature can be activated at the server farm level. A farm Feature contains a number of elements that are critical for implementing applications and logic anywhere within a deployment. A farm Feature can contain, for example, links to /_layouts pages and files, /_admin pages, and other elements. Farm scoped features can be activated by using:

Run the following STSADM command:

stsadm -o installfeature -name FeatureFolderName

For solutions SharePoint solutions are either deployed globally or targeted to a particular web application. The decision of which is made automatically by the SharePoint Solution framework depending on the contents of the solution manifest. Exception to this rule are Sandbox solutions which are managed on the site collection level.

Globally Deployed Solutions

When a solution is deployed globally, the assembly DLL file will go and sit under windows\assembly folder. All SharePoint application pools, including Central Administration’s, are recycled automatically. This can be good and bad. This is good because any GAC installed DLL that has been upgraded needs to be reloaded. This can be bad though with regards to the availability of your entire SharePoint Farm.

Web Application Targeted Solutions

When a web application targeted solution is deployed or retracted, the assembly DLL file will go and sit under the inetpub\websitename\bin folder. Only the application pools of the targeted web applications are recycled. When deploying and retracting a web application targeted solution, deploy or retract it only to those web applications that will use it … thus preventing unnecessary recycling of application pools.

Sandbox Solutions

Sandbox solutions are deployed to the site collection. This new mechanism has been introduced in SharePoint 2010 to provided more isolation between deployed components. Sandbox Solutions deployment does not require application pool recycle and does not allow deploying DLLs into the GAC, as everything is stored in content database where site collection resides. These solution also provide much more restrictive execution model and limited access to SharePoint API.

PowerShell Code to deploy solutions (WSP) :-

PowerShell to deploy the WSP to the GAC on server and deploy to all URLS

Add-SPSolution -LiteralPath $path
install-spsolution -Identity $solution  -GACDeployment

PowerShell to deploy the WSP to the GAC on server and deploy only to 1 specific web application (not in bin folder)

Add-SPSolution -LiteralPath $path
install-spsolution -Identity $solution -WebApplication $oURL  -GACDeployment

PowerShell to deploy to specific webapplication at bin folder on server

 Install-SPSolution -Identity $solution -WebApplication $webApp

PowerShell to deploy to all the webapplication at their bin folders on server

Install-SPSolution -Identity $solution -AllWebApplications

Reference: Understanding Scope of SharePoint Features

  • 1
    Thanks. Trying to target solutions for specific web applications, but being required to deploy for all is what started this quest to understand why. It is what triggers this automatic decision by SharePoint that I'm after. Essentially, what is it about hour the feature elements are grouped into features and packaged into solutions that require the solution to be deployed to all web applications? This question, when I looked into it, quickly expanded to understanding feature scoping as well...
    – David Culp
    Commented Jan 21, 2012 at 19:16
  • 1
    "Globally deployed" only applies to solutions that don't have web controls and web parts in them. These cannot be "Globally deployed", because the web.config of the web application you choose to deploy to is changed, i.e. entries are inserted in order to register your .dll's containing web controls and web parts. Disadvantage is that deploying solutions globally will cause all webapplications on the farm (including central administration) to be targeted and thus receive an IIS Pool recycle. Even though your solution was specifically for one web application Commented Jan 22, 2012 at 18:23
  • 1
    However, the the solutions can be chosen to be Global or Web application specific at the time of packaging/development. Commented Jan 22, 2012 at 18:24
  • 1
    Thank you -- this last pointed me in the right direction to find a setting on the package in VS I hadn't noticed before -- the one that determines if it is deployed to globally or to a single web application.
    – David Culp
    Commented Jan 29, 2012 at 5:41
  • What about Web Application Targeted Solutions which are installed as 'install-spsolution -Identity $solution -WebApplication $oURL -GACDeployment'? Although they are targeted to 1 web app, they are not going into the BIN folder. Please note this.
    – variable
    Commented Apr 25, 2014 at 7:13

Elements by Scope helps you understand what elements are allowed for each scope. That also means that solutions can be developed and SharePoint architecture allows them to be deployed at any of the scope documented.

Most solutions use FEATURES that are targeted at web or site collection level and when an element is allowed at both web and site level, it depends on design of your solution. It's hard to provide a generic answer but following examples helps:

  1. If you want some lists to be created only at site collection level, you may either include them at site scoped feature or allow it to be created at root web only.

  2. Content Types are allowed at site or web level but most people create content types and site columns at web scoped feature

  3. Some solutions require same sets of lists/configuration required for all webs created under a site collection. Such artifacts should be scoped at web level even though they can be created at site collection level.

In general, I would deploy elements at Site collection level if 1) SharePoint force me to do it or 2) my solution design is such that the elements make sense at site collection/root web level only.

You can also understand/learn by observing how SharePoint's OTB FEATURES are scoped.

Web Application level FEATURES: Since they can be activated only by Farm Administrators, I would consider using them when they are truly reusable or to follow/enforce governance plan.


Process of changing feature scope from old one (e.g. Web) to a different one (e.g. Site) involves several steps

  1. Deactivate feature with old scope wherever it's been used throughout the whole farm
  2. Uninstall feature with old scope
  3. Install feature with new scope
  4. Activate feature with new scope

Without aforementioned procedure, installing feature with the same ID and with different scope using 'force' attribute can cause unexpected problems (in my case it was content database upgrade failure).

  • Thx for this additional color to the conversation. This very much applies to my current scenario, which is why I went digging for this thread.
    – bkwdesign
    Commented Dec 31, 2012 at 14:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.