I just released a new stsadm command in the Trentacular SharePoint 2007 Features CodePlex project called smartsolutionupgrade. The purpose of this command is to perform Solution upgrades in a smart manner by performing the following actions:
- Accepts as input either a single Solution filename or a filename of a text file containing a list of Solutions to be upgraded
- Extracts and parses the Solution manifest file from each existing Solution to be upgraded in order to determine the Features that will be affected by the upgrade
- Inventories the deployment states of the existing Solutions
- Inventories the activation states of the affected Features at all scopes within the SharePoint Farm
- Deactivates all affected Features
- Retracts each of the existing Solutions and deletes them from the Solution store
- Adds the updated Solution to the Solution store
- Deploys each of the upgraded Solutions according to their previous deployment state
- Activates all affected Features according to their previous activation state
Usage
stsadm -o smartsolutionupgrade [-filename <Solution filename>] [-filenamelist <Path to text file containing each of the solution filenames on separate lines>]
Job Definition Execution
Included in the project is a Job Definition Executor that takes care of running one-time scheduled service jobs and waiting for their completion before releasing control. One particular issue addressed by the Job Definition Executor is the “A web configuration modification operation is already running” error caused by successive execution of the stsadm -o activatefeature command on Features that perform web configuration modifications.
In a multi-server farm, web configuration modifications are delegated to Timer Jobs; therefore, the return from execution of the activatefeature command does not mean the Feature activation (and thus the web configuration modification) has completed. So you might say, well duh, you need to also execute the execadmsvcjobs command, but this command simply kicks of the job execution and returns from execution while still not waiting for the jobs to actually complete.
The Job Definition Executor solves this problem by kicking of the jobs and monitoring for their completion. We can now safely execute multiple web configuration modification Features in sequence.
Update
I just released a second stsadm command called smartexecjobdefs that simply wraps the Job Definition Executor and can be used as a substitute for the execadmsvcjobs command.
SharePoint solutions are either deployed globally or targeted to a particular web application, depending on whether the solution contains web application scoped Features. 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. I now even trick my solutions to be web application targeted that otherwise would be deployed globally by including a dummy web application scoped feature in them.
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 deployment 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. 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.
Recent Comments