First, we need to identify the root of our issue. In our case we are trying to update an existing deployment package (wsp file). This can be done easily through PowerShell. Basically, this process involves uninstalling the current package, remove it from the farm, add it again and install it for the different web applications.
These commands should work for all the packages that you have already installed in your farm. However, for some reason, sometimes the deployment process is scheduled and the timer job that manages this process never ends. Well, the job actually finishes, but not the deployment. So, we cannot see our package deployed and we cannot use its features in our solution.
(The status never changes)
If this happens once, we will not be able to run a successful deployment. So, our first possible fix is to restart the services “SharePoint Administrator” and “SharePoint Timer Service” in all the servers in the farm. Then, we can try the deployment process again.
In most cases, this will solve the issue. Nevertheless, there will be other cases where it will not be deploying the package yet. At this point, as the job is finishing, it seems like a problem deploying the new package, so we are going to check what it is the last updated content in the different servers in the farm. To do this, we need to access to this folder path:
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\FEATURES
In this folder, there will be a folder for each feature that has been deployed in that server. So, you need to check the features of the package you are trying to deploy and verify what it is the last modified date. If you follow this process through all the servers in the farm, probably you will find a server where the features are not being updated.
Why is this happening if this was working before?
Despite the server is already included on the farm (you can double check it in SharePoint Central Admin), the job that deploys the package is not able to contact the server and update the content for the features.
If we are at this point, the only solution is to remove the affected server from the farm and include it again. To avoid this process, it is possible to run a command that allows you to restart a service related with the belonging of the servers to the farm. So, if you restart this service, the farm will detect the server again.
To run this command, it’s required to use STSADM console. To find it, go to this path in one of the servers in the farm:C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\BIN
Open the file STSADM.EXE and run these commands:
stsadm -o provisionservice -action stop -servicetype spwebservice
stsadm -o provisionservice -action start -servicetype spwebservice
Repeat the process for all the servers in the farm.
Once you finish, update your package again and this time it will finish successfully, showing your package as deployed in the farm.