Problems when using Site Deployment from within a web application

From time to time I receive questions related to problems when using a web application to perform site deployment import or export operations – e.g. from within a web page or though a web service.

Running Site Deployment from within a web application sounds like a nice idea as it allows to use server side SDAPI locally on the server but start it from a client machine through a web browser.

Actually there are a couple of problems you should be aware of when considering this idea:

File Permissions

When a SDO file is exported SDAPI assigns permissions to the SDO file explicitly. It only grants rights to specific users:

• Builtin Admins
• Domain Admins
• Creator Owner (The MCMS user doing the export)
• Power users

Other users don’t have access to the file! The problem here is that when exporting the Creator Owner is the user used in AuthenticateAsUser against in your site deployment script.

But when running an import the first access to the file is done using the application pool account. As you can see an import of this file would not work if the application pool account is not at least a power user.

As it is recommended to use a low priviledged accounts as application pool for a web application this is a problem.

Memory Usage

Site Deployment is a very memory intensive process. We recommend to have 2 GB phyiscal memory in your machine in order to run site deployment import successfully.

The problem here is that ASP.NET web applications will run into problems when the applicaiton pool exceeds 800 MB in size (1800 MB when running the machine in /3GB mode). This is a known problem with the ASP.NET memory which is dicussed in the “private bytes” paragraph of the Process Counters section of the following document:

• ASP.NET Performance Monitoring, and When to Alert Administrators

Inside the application pool of an application pool of a MCMS web site you will find the memory cache of MCMS, the ASP.NET output cache, the managed heap for the web application and the memory allocated by the COM objects which represent the MCMS object model.

If you would use the same application pool for the site deployment operation as for your MCMS website site deployment would have to share the same 800 MB with your application pool which can influence the availibility of your website.

In addition: as ASP.NET has this limitation of 800 MB in /2GB mode you would not be able to benefit from the 2 GB installed in your box if site deployment is done from within a web application.

Serialization

MCMS site deployment operations must not be run in parallel. As a web site accepts and processes multiple requests in parallel you would need to implement your own mechanism to ensure that only one site deployment operation can be executed through a web request.

Conclusion

You should avoid to run site deployment directly from within a web application. A better approach would be to create a separate windows service independend from IIS and ASP.NET which does the site deployment import or export operation. You still can start the import or export from a web application by implementing some kind of interprocess communication – e.g. through named pipes. This would also allow to easy up the serialization as the service could read one order at a time from the named pipe.

If you still plan to run site deployment from within a web application at least

1. ensure to assign a dedicated application pool to the web application doing the site deployment job.
2. ensure that the machine is running in /3GB mode rather than in /2GB mode to be able to have 1,800 MB available for your site deployment operation
3. ensure that you have more than 2 GB memory installed in your box
4. implement a serialization mechanism to ensure that site deployment operations cannot be started in parallel.