SharePoint: Differences Between Global and Web Application Targeted Solution Deployment

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.  Certain items in the solution manifest such as SafeControl entries result in modifications to a Web application’s web.config file.  Only when a solution manifest does NOT contain any of these types of entries will the solution be globally deployed.

The deployment process behaves differently based on the type of deployment for the solution, and these differences have caused me quite a headache. Here are my findings that I think any SharePoint developer or administrator should be aware of when performing solution deployments.

Globally Deployed Solutions

When a solution is deployed globally, 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.

In my particular case, I am working with a SharePoint administrator to deploy a globally deployed solution that is used by only a single web application. It is fine for this web application to be unavailable, as we have cleared it with our change control process and made announcements of the downtime, but we haven’t announced to users of the other SharePoint web applications in the Farm that their sites will be coming down along with it. So be forwarned.

Web Application Targeted Solutions

I have become fond of web application targeted solutions because they offer me a workaround to the above availability problem.  When a web application targeted solution is deployed or retracted, only the application pools of the targeted web applications are recycled.

Enterprise Farm Strategies

  • When upgrading solutions, the upgradesolution stsadm command only gets you so far. I’ve found it is best to fully retract and remove the old solution and then add and deploy the new solution in order to be sure your upgraded features actually take.
  • Avoid the -allcontenturls switch – 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. I was being lazy in my retraction script and instead of specifying the particular web application url, I used the -allcontenturls switch to retract my solution, hoping SharePoint would be smart enough to recycle only the application pools of the web applications the solution was actually retracted from. Bad assumption. They all get recycled.

A Big Gotcha that Got Me

If you are upgrading a web application targeted solution using the retract, remove, add, deploy strategy mentioned above and your web application scoped Features have associated Feature Receivers, then you must recycle the Central Administration application pool after removing the old solution and before adding the new solution if you intend to use the Central Admin Web application features page to activate your solution’s Features.  In this case, it is the Central Administration application pool that executes your web application scoped Feature Receivers, and if not recycled, it will continue to use the loaded cached old versions of assemblies updated by your solution.

The same also goes for powershell.  If within a powershell console you deactivate a Feature having a Feature receiver, the assembly containing the Feature receiver will be loaded and cached by the powershell App domain.  After retracting, removing, adding, and redeploying the solution in the same powershell console, it will still be the previous version of the assembly that is cached.  If you were to attempt to script the activation of your Feature, your updated Feature receiver’s code is never executed, rather the previous version from the cached assembly is used.  To get around this dilemma, you can either increment your assembly version or start a new powershell console before deploying and activating your updated solution’s Features.



    I am new at Sharepoint, I write to you because you are an experienced developer and I wanted to know if you could guide and help me to solve the following problem:

    I have my main web application. Within it I have another application that uses a separate virtual directory.

    The problem comes when I try to install any webpart, it doesn’t installed and gives me this error:

    Some of the files could not be copied during the deployment of the solution.
    Details of the latest operation: MAD-SIS-VM-001: https: /myapplication/: formularios: Error: cannot find the web.config file section of this site. The controls specified assembly cannot be marked as .

    I don’t want to be placed in “formularios” (it’s the app inside of my main app).
    I also have another environment for testing and when I install it, I have no problem, but in this environment doesn’t works!
    I don’t want to install the webpart (or feature) on “formularios” … I am avoiding something?
    how can I fix it?

    First of all thanks for your time, and we apologize for the inconvenience!

    PD: sorry is my English is not so good



    Let me try to understand better what you are trying to do …

    You’ve created a SharePoint Web Application called “myapplication”, and then within the “myapplication” node in IIS, you’ve created a new virtual directory for hosting a separate web application?

    I am hoping I’ve misunderstood you, but in case I haven’t, I have never tried creating a new virtual directory within a SharePoint Web Application and I wouldn’t recommend approaching it that way, as SharePoint has its own mechanism for rewriting paths that I imagine would not place nice with a non-SharePoint virtual directory.

    Hopefully you mean that “formularios” is a Site Collection using a Managed Path within the Web Application. Let me know if this is the case, and we can go from there.


    Hi Trent,
    Thanks for this interesting article. In my company, when developers deploy their solutions to the production Farm, they encapsulate the deployment process in their own installer.exe. During the process they need to manually do iisreset on all Web front end nodes (we use NLB for 2 Web Front End) When you do iireset, all Application Pools are recycled right? Why do we need to do iireset on each web front end? Could you please help me to understand this requirement? I am wondering if it is just “superstition” or in some case it should be necessary. I would like to adopt the Web Application Targeted deployment as a strategy for the Farm, but I need to understand why at the moment people have to do iireset explicitly on each front end at each deployment. Thanks for your help.


    @Nuvoletta –

    “When you do iireset, all Application Pools are recycled right?” Yes

    “Why do we need to do iireset on each web front end? Could you please help me to understand this requirement?” Whenever your solutions deploy assemblies to the GAC, any application pools that rely on those assemblies must be recycled in order to load the new versions of the assemblies.

    The SharePoint solution framework actually recycles the Application Pools automatically when the solution has installed assemblies to the GAC. Resetting IIS is most likely unnecessary, but there may be situations where the SharePoint solution framework may not recycle an Application Pool (likely because the solution was not deployed to the particular Web application), but the Web application may still rely on an assembly that is updated.

    Have you noticed that when a solution is deployed to a single Web application on a WFE, its Feature Definitions are now available on all the Web applications on the WFE. This is just one case where the SharePoint solution framework may fail us and iisreset may save us. To avoid these strange cases, you can just about always count on iisreset to set things straight (at the expense of making every one of your Web applications unavailable).

    At my current client, we are developing point solutions that we deploy to only a single Web application in our Farm. Since we know that only that single Web application uses the DLLs we are deploying, we only want to recycle the Application Pool for that Web application and no others.

    As much as I would like to say this never happens, there have been occasions when we need to deploy emergency fixes. Being able to deploy a fix to just the single Web application becomes especially useful in this situation. We can now address the issue outside the maintenance window, without affecting the other Web applications in the farm.


    Hi Trent,

    Nice description of the undocumented gotchas but I’m still seeking some practical guidance on how to deploy a particular solution I have which contains 5 features.

    Three are site scoped and intended for contenturls and two are webapplication scoped, intended for Central Administration. I’m rapidly reaching the conclusion that the features destined for CA should be moved to a separate solution. Otherwise I simply don’t understand how I can avoid deploying it to CA as well as allcontenturls.

    Any advice you can offer?



    I retracted it and deleted the current deployment. Then added and deployed only to the relevant content urls (web app root sites). Both the CA features were installed.

    One was available for activation, while I used the AutoActivateInCentralAdmin=”TRUE” parameter in thwe other which also activated the feature.

    Given that the solution wasn’t even deployed to the CA web application I’m left perplexed but very pleased by this discovery.

    Looks like I answered my own question. 🙂



    There is a disconnect in SharePoint where while Solutions are deployed to Web applications, Features are installed on Servers.

    With this in mind, deploying a Solution to a single Web Application on a Web Front End (WFE) server means all Web applications running on that WFE now have that Solution’s Features available to it. You are able to get away with what you mentioned above when your Solution does not contain any BIN or 80 deployed resources.

    From your scenario mentioned above, I assume your CA Web application is running on the same WFE and your Features do not rely on any BIN or 80 deployed resources (referring to virtual directory resources).


    Hi Trent, you’ve reaised some interesting points there.

    To answer your question, this is a multi-server farm. The solution includes several features and assemblies which get deployed to the GAC only.

    I’m aslo deploying from a sever which serves as both a WFE and CA host. No doubt this is why I have managed to get away with this.

    Getting back to my original suggestion, do you think the CA features should be stripped out as a separate solution? Or should I be safe to keep doing things the way I have within my current environment?

    Brian Spurlock

    I’m a graphic designer wanting to deploy my masterpages and pagelayouts to a particular web application. Do I deploy my feature receiver to the global gac or do I need to deploy it to the web application’s bin folder? When I deployed my solution to a certain web application with the feature reciever going to the global gac then my feature is still available to all the other web applications as well. Is this normal? Or am I doing something wrong?



    I don’t know how to create a globally solution.

    What I only know about it is adding ” DeploymentServerType=”ApplicationServer”” in the root element of the solution manifest.xml file. But it doesn’t work, and the solution deployment server type is Front-end Web Server.

    Thanks a lot!



    I relatively new in SharePoint Admin side. I need help.

    I have a existing MOSS 2007 PRODUCTION intranet server name “SPServer” and the default web application (port 80) is also “http://SPServer”.

    I built new SharePoint 2010 server Farm server name SPServer2010. The Default web application (port 80) is also “http://SPServer2010”.

    I want keep the same name of URL after moving to production.

    Do I need to change the server name and url from SPServer2010 and url to http://SPServer2010 or redirect with AAM usding DNS? What is the standard practice?

    How can I change the server name and default application name From “SPServer2010” and web aplication “http://SPServer2010” to “SPServer” and “http://SPServer” on cut off date? These new 2010 will become production server.




    Datta – While both options you mentioned are possible, using an alternate access mapping and DNS is the easiest, most flexible path. This also makes cutting over as simple as updating a DNS entry.


    Thanks Trent,

    Can you please provide me some steps involves using AAP with DNS.
    Also we are thinking about implementing Kerberos authentication for futre integration with other application. Using AAM with DNS approach will have any issue in implementing that?


Leave a Reply

Your email address will not be published. Required fields are marked *