Error in Deploying/Activating timerjob wsp feature in server farm env. How to deactivate the features from all web applications

Question

I have created a custom timer job in my SP 2013 SP1 on-prem env. when i tried to re-install/ update the wsp using powershell, am getting error:

A feature with ID 15/ab47de69-4189-41d5-a8a8-8414309453f6 has already been installed in this farm. Use the force attribute to explicitly re-install the feature.

Eventhough I have deployed this onto a web application scope,it seems, its[ the timerjob feature] deployed/available and activated in remaining web applications. I am stuck,why this happened? In the VS 2013, solution,I used to give the web application as the scope and deploy from visual studio give no activation.

       Add-SPSolution   –LiteralPath 
          "E:\PoCSolutions\\RILTTimerJob_NPD\bin\Debug\RILTTimerJob_NPD.wsp"  
        -ErrorAction SilentlyContinue

       Install-SPSolution -Identity "RILTTimerJob_NPD.wsp" -GACDeployment 

Answer 1

Targeting a WSP to a given "Web application" does not mean features it contains will only be available at those Web applications you deploy to.
A WSP can contain different types of artefacts:

1. Features. Features are always deployed to the disk of the servers, in the "hive". This means that, no matter how you deploy the WSP, the features are available everywhere (i.e. Web application feature are available on all Web application for activation, Site features are available on all site collections, etc.).
2. Common "supporting" files like DLL, aspx pages, CSS, JavaScript or resources (resx) files deployed into the hive (or into the GAC for DLL). They're flat, "inert" files, referenced by the features.
3. DLL to be deployed to the BIN folder of the Web application (this scenario is quite seldom these days).
4. Declarative elements from the solution manifest. Most of the time this is modifications (such as SafeControl entries) to be propagated to the web.config file of the Web application.

The important is: if your WSP contains at least 1 element listed falling under #3 or #4 points above, you'll need to target specific Web application when you deploy (aka "install") it. That's because these elements will have a direct impact on the Web application.

However, even if this occurs, the other elements from categories #1 or #2 are still universally available in your farm.

One other thing to note: Web application-scoped features are (by default, this can be changed in the feature property in Visual Studio) automatically activated when the solution is deployed (more precisely: when the feature is installed).

In your case, you can easily revert back by:

1. Installing the WSP back with the `-force- parameter (this will override the existing feature definition).
2. Deactivate the Web application feature on every Web application you don't want it to be activated on.

Later, you can change the setting of the feature (in Visual Studio) so it's not automatically activated.

Answer 2

To Deploy to a Specific Web Application:

The custom timer job I was recently working on for SP2016 on prem was deployed globally in its early versions. I wanted to change it to instead target just one Web Application. I changed the Scope in the manifest to 'WebApplication', recompiled, retracted and deployed with PowerShell to the Web Application and I got the following error:

This solution contains no resources scoped for a Web application and cannot be deployed to a particular Web application

After googling for the error message, I tried the technique described here and also in this blog at the bottom. Once I added a dummy safe control, SharePoint let me target deployment to a Web Application instead of globally.

Best Practices for successful deactivation and redeploy:

I dont recommend update-spsolution either. I have always retracted/redeployed which is frustrating because it can be very time consuming. I (and other colleagues) often experience SharePoint will hang on to a previous versions of a WSP when a new version is redeployed and the old code would be executed. A colleague came up with the following best practice:

Stop all timer jobs in your farm at once, then clear the config cache, then restart all of the timer jobs. This is a painful but necessary step depending on your situation (what your code is trying to do and your Farm configuration).

The timer jobs are resilient and can get passed from server to server in your Farm depending on the server state. So its best to bring them all down to remove all doubt.

Another best practice for timer job or farm solution development is to develop and test deployment against a multi server Farm in development if possible. Often times deployment issues can be masked if you only code and deploy to a singer-server Farm.

And a final tip if your solution is in a bad state and nothing else works is to try and run the SharePoint Product Configuration Wizard on each server in the Farm. It can often repair the low level items and get you back to normal running state.