Here is an example of an admin, fishing around for the correct parameters, and then forcing things just because PowerShell hinted so:
click on any of the pictures to see them bigger
High School Shop Teacher Advice: My High school shop teacher's advice holds true in this case as well. Mr. Spring said, " It's always best to avoid having to force things" and he was right!
So, in the example above, the admin should have determined where the solution was deployed before redeploying, by visiting Farm Solutions under system settings and looking at the solution, or by using the dot method with the deployedwebapplications property of the get-spsolution cmdlet.
Please Note: The driver behind the web.config corruption in this example was the admin service not having been started, not the -force; although, that is not to say that -force is without error causing or issues and there are times when it is absolutely necessary. The point I'm trying to make here is don't make it your first option.
After that the Admin should have determined that the status of the Microsoft SharePoint 2010 Foundation Administration service on the server running central admin was started, before re-deploying or taking any action on the solution.
Please Note: Sometimes it is necessary to totally remove and redeploy a solution when this happens. When you're about to retract a solution, It's always best to have gone into the site collection features and site features, and deactivate any features, starting with site features (_layouts/ManageFeatures.aspx) and progressing to site collection features (_layouts/ManageFeatures?Scope=Site), then retract solution from the farm after deactivation of features at the Site and Site Collection level.
This is so important, because if the farm solution is retracted without those precautions, often times this creates orphaned features that hinder re-deployment.
GUI isn't safe either
Corruption of the web.config can also occur when attempting to deploy the solution via the gui when the Microsoft SharePoint Foundation Administrative Service is not started
This is the message that is indicative of the type of web.config corruption that can occur when a solution deployment is attempted from a farm server in a farm that does not have Microsoft SharePoint Foundation Administrative Service properly configured to run under a domain account:
This is the error that'll result\be displayed when deployment is attempted via the GUI and Microsoft SharePoint Foundation Administrative Service is not started on the server running central admin. At this point, you're best bet is to determine how deep the corruption has went, hopefully it is just one web application's web.config.
Because this can corrupt the web.config file of one or more web applications, it is important:
- to check that the Microsoft SharePoint Foundation Administrative Service is configured to run with a domain account,
- to know where solutions are deployed,
- and to use correct parameters when deploying using Powershell.
- Schedule Job's to run in the future
If the error in the web.config persists, simplest way to correct this issue is to rejoin the server to the farm. Rejoining the server to the farm will give it a new web config.
IMPORTANT NOTE: this advice pertains to a farm with more than one web front end, where the corruption is present in a web front end that is not hosting central administration. Do not use this advice, without moving central admin to another server.
Once central admin is on a server that does not have a corrupted web.config, rtake the server with the corruption out of the farm and rejoin the farm.
1. Open the SharePoint 2010 Products Configuration Wizard and take the server out of the farm
2. Open the SharePoint 2010 Products Configuration Wizard and join the server into the farm
Long story short:
The result of not properly removing features either via powershell or the gui is some form of corruption of the web application. The same is true with deploying using incorrect parameters and forcing things - - >The web config may become corrupted as a result.
Make sure the server is not running central admin, if it is, switch central admin to a different farm server, if a single farm, use powershell to remove solution after, using powershell to remove features. Then in either case, remove and rejoin farm.