Note: This article only applies to central admin server used for Application Tier in SharePoint Farm.
I recently came across very interesting error while deploying solutions and activating features using powershell on one of our farm’s central admin server. What surprised me that we were using same approach to deploy our code from central admin server since last couple of months and suddenly it’s stopped working while activating features and throwing error.
Enable-SPFeature : The Feature is not a Farm Level Feature and is not found in a Site level defined by the Url. At D:\Deploy\SPSolutionDeploymentScript.ps1:287 char:22 + Enable-SPFeature <<<< –identity $webFeatureName -URL $spWeb.url -Confirm:$false + CategoryInfo: InvalidData: (Microsoft.Share…etEnableFeature:SPCmdletEnableFeature) [Enable-SPFeature], SPCmdletException + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletEnableFeature
Looking at the error, it was clear that PowerShell wasn’t able to find SharePoint Features and Solutions framework API on the server. What I didn’t know was what would or which SharePoint Service application would enable this framework on the server. My first guess was to reach out to our SharePoint admin to see if he is aware of any recent changes on the central admin server configuration. Additionally, I tried to deploy and activate features through one of the WFE servers and it worked fine. As I was waiting for admin response, I have reached out to greater SharePoint community via twitter. My good friends from SharePoint Twitter communities, both Dan Usher (@usher) and Clayton Cobb (@warrtalon) came to rescue right away and first clue was SharePoint Foundation Web Application Service may not be running. While I was trying to confirm whether this service was running earlier and stopped recently causing feature activation issues, I received response from Admin that this service was indeed stopped and he may have stopped recently.
Well, problem is solved and resolution is clear. We just needed to activate the SharePoint Foundation Web Application Service to resolve the issue. But, as we were exchanging information on twitter, I have realized that this could be major SharePoint release management decision. As an Admin, we would like to disable the SharePoint Foundation Web Application Service on the central admin server. Disabling SharePoint Foundation Web Application Service on central admin server seems one of the best practices since it isn’t used to serve pages to the end-users and disabling this service would conserve server memory for other dedicated SharePoint application tier services enabled on Central Admin/Application Server.
In General, here are the guidelines I have came to conclusion whenever I come across similar situation in future.
- It is still best approach to deploy code and activate features from central admin. This would allow central admin server as a main administrative consoles for both configurations and custom deployment.
- It is still best practice to disable the SharePoint Foundation Web Application Service on the Central Admin Server to avoid additional performance overhead by running less SharePoint Web Application IIS worker processes
- Since you have to activate SharePoint Foundation Web Application Service on the Central Admin Server to deploy code from the Central Admin Server, It would be great practice to enable the Service during deployment process and disable during normal runtime. It would be nice to have a deployment tasks to enable the service, deploy custom solutions, and disable the service.
- One last point, there is nothing written on stone or as a best practice to deploy code from central admin, it is just my preferred method to centralize administrative tasks in one place. If your situation is different and able to deploy custom solutions from the WFE servers running SharePoint Foundation Web Application Service, you are covered.
Here is another great article recommendaed by Dan Usher and it provides same architectural insights faced by SharePoint Architects and IT Pros in real world – http://blogs.technet.com/b/speschka/archive/2010/11/27/beware-of-default-solution-deployments-for-custom-claims-providers-in-sharepoint-2010.aspx