SharePoint 2007 Local vs. Global deployments

Technorati Tags: Sharepoint,Development,Deployment

Solutions are deployed in one of two ways: either locally or by using a timer service.
This applies both to new deployments, as well as to deployments of solution upgrades.
Both local and timer-based deployments can be triggered either by using command-line instructions or programmatically by using the object model.

Local deployments that are initiated from the command line by a user with administrator privileges run in the context of the administrator. If initiated by using the timer service, however, the deployment runs in the context of the timer job itself, which uses administrator pool account credentials. Either set of credentials should be sufficient to read and write to the configuration store.

Local Deployment

In a local deployment, solution files are deployed only to the computer from which the deployment operation was initiated. Under this scenario, the solution is not marked as "deployed" in the configuration database until the solution files are deployed to all applicable servers in the server farm. Then, in the case of new solution deployments, solution features are registered, and schema and definition files are committed to the configuration store.

Timer Service Deployments

In deployments that use the timer service, the deployment creates a timer job. This timer job is picked up by the timer service on each Web server in the server farm. The timer job uses the Windows SharePoint Services Administrative Web service to access appropriate privileges to deploy solution files to each computer.

Initially, manifest and feature manifests are parsed to find assembly and _layouts files, which are copied to the appropriate locations. All other files contained within a feature directory are copied to the feature directory. After solution files are copied to the target computers, a configuration reset is scheduled for all front-end Web servers; the reset then deploys the files and restarts Microsoft Internet Information Services (IIS).

For upgrades, the deployment has no impact to the end user experience. The new versions of the solution files do not overwrite the old files; therefore, if a computer is restarted, or the upgrade process is aborted, the servers are synchronized with their other data files.

Finally, for new solution deployments, solution features are registered, and schema and definition files are committed to the configuration store.

I recently cam acroos the following issue:

stsadm -o deploysolution -name "my_solution.wsp" –url "https://server.somedom.net" -local –allowGacDeployment

This command fails, the following message is displayed:

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

While this command completes successfully

stsadm -o deploysolution -name "my_solution.wsp" -local –allowGacDeployment

When looking at the manifest.xml and feature.xml files for this package, we can figure out this package has no “resources”, which means no content has to be copied to a particular web application virtual directory.

The bottom line is that if your solution specifies elements (a.k.a. "resources") that need to be merged into a Web.config file (i.e. "for a Web application") then you must specify the url parameter. If your solution does not have an assembly or if your solution contains workflows, then you cannot specify the url parameter.

The same goes for packages that would not contain an assembly.

Comments

• Anonymous
  January 01, 2003
  Hi, small world indeed  :-) You could use this for sure. Local deployments are useful when it comes to deploying solutions to many WFEs or when deploying a lot of solutions. Now, I would only rely on this for initial solutions deployment and stick to global deployments for upgrades which do not require IIS to be reset. I would also stick to global deployments when deploying one or two solutions only and have a time window for resetting IIS.

• Anonymous
  June 11, 2010
  Hi Pascal, about Local Deployment. Is this a usable and supported way of deploying into a multi-WFE farm for providing no service disruption during solution deployment by using local deployment on each WFE server separately after having been removed from the load balancer pool? thanks and good luck with the Blog :) Dirk

• Anonymous
  February 15, 2011
  HI Pascal and Dirk, Small world :-) I'm searching the Internet to find answer to the exact same question. Our SP2010 webhosting farm will host 15+ sites and I'm trying to find out the best approach to minimize downtime in a multi WFE env. during solution deployment. Thanks and hope you are going very well. Laurent