Graham's Blog

CMS deployment process from authoring to production...

Rcently I have been trying to finalise the deployment process from our CMS authoring environment to that of our shared production environment (which I talked about in a previous post).

The manual process (as I see it) consits of the following tasks:
Authoring Server
1. Do a "Get Latest" from Visual Source Safe, for the up-to-date CMS ASP.Net code base.
2. Build the Visual Studio .Net solution
3. Using the Site Deployment Wizard, Export the Channel, Resource Gallery and Template Gallery structures of the authoring environment into an SDO
4. Create a compressed folder of the ASP.Net code and SDO file
5. FTP the compressed folder to the production servers ftproot

Production Server
1. Export current live CMS content strucutre to a backup folder
2. Move current live CMS ASP.Net code base to a backup folder (apart from our web.config, because of local variable settings)
3. Decompress compressed folder in ftproot
4. Copy new CMS ASP.Net code base to home directory of live virtual directory.
5. Delete existing CMS Content structure in Site Manager.
6. Using the Site Deployment Wizard, Import the authoring servers SDO and CMS content into the production environment
7. Rename top level channel and resource gallery to that of your host header (i.e. www.site1.com)
8. Regrant permissions to newly imported CMS content strucutre to existing Subscribers (i.e. annonymous users) rights group

Now in an ideal world, I would like for CMS to be able to automatically deploy both content and code base, between authoring and production environment, as soon as a new posting is created on the authoring server.

This isn't the case and as such (or is it?), scripts need to be generated and scheduled to accomplish same. How much can we automate?

Well if we take the authoring server first, steps 1 and 2, will be done manually anyway once the code base has been modified. Step 3 is possible either using .Net com interop or vbs/wsh scripts. The standard compressed folder functionality in Windows XP/2003 doesn't seem to be available from vbs/wsh via a windows API call. So with Step 4, we will need to use a command line compression utility like winzip, and call via a wsh shell command. Similarly with Step 5, a wsh shell command for "ftp -s scriptfile.txt" would work.
As vbs\wsh seems to be the common denominator, this would seem to be the best option, and to schedule it using NT Task scheduler.

Now onto the production server, step 1 as with the authoring server is possible in a few ways. Steps 2 and 4 are straight forward command line copies. Step 3 is again similar to the authoring server, in that a winzip command line will probably be best. Steps 5, 7 and 8 would be very straight forward if a web instance of the CMS CurrentHTTPContext was avaialable. But from a vbs/wsh, how would you do this? And finally Step 6 is possible in a couple of ways.

As you can see, the deployment process is not straight forward.
And my current questions include:

Apart from introducing massive licensing costs, does an automated process exist, to accomplish what I am describing, or is there a simple architecure change (say shared SQL) that would do it?

Can you call the publishing API from vsb/wsh, to rename channels, delete channels etc?

Is the standard Windows compressed folder functionality available from vbs/wsh or .Net?

Will the ftp wsh shell command work over a secure ftp connection?


Any CMS or WSH guru's out there? Anybodys thoughts on this would be greatly appreciated

posted by Graham Quinn @ 10:15 AM 5 comments

MCMS Connector for SharePoint Technologies

What I originally thought and read about the MCMS connector for SharePoint technologies, wasn't actualy the same once I began to install and configure it....

To configure SharePoint and MCMS on the same box (which is the recommendation), involves a good few changes.

Why would you do this you may think (well I did), the reason is that if you want to use the document library placeholder for editing purposes, then SharePoint will need to be installed on your MCMS authoring server, otherwise if the placeholder will be read only (say for your MCMS production server).
But that's not all, you can only point the webparts at local MCMS content, and similarly you can only point the SharePoint Document Library placeholder control at a local SharePoint site. So to me, this throws away any chances of having an integrated server farm of SharePoint and MCMS servers, connected using the connector. I hope I'm wrong in my understanding here, anyone out there know?

Firstly, the order in which the server applications are installed is important. Obviously standard OS configuration first then, pre-requisites for MCMS, MCMS 2002 Sp1a, SharePoint 2003, any SharePoint 2003 sp's and finally the MCMS connector for SharePoint itself.

Next, there is a requirement for the Connector, that MCMS and SharePoint both use the same IIS application pool and identity. OK fine, but what about the forms based authentication and login I wrote for my authoring server. Turns out, you cannot use Forms based authentication if you have SharePoint and CMS on the same box, only windows. Damn...

Now you have to tell SharePoint that it has some standard ASP.Net applications within it's website to render. The MCMS connector will automatically add existing (at time of install) ASP.Net apps as excluded paths within SharePoint, which is useful. But you should consider this for any future apps you may have to create.

Now to your existing web applications, you will have change the trust level setting within their web.config's, to full, again so that SharePoint can render them as safe.

All these changes had to be made before I even began to use any of the funtionality the connector would give me.

More about the SharePoint Document Library placeholder control... I originally thought that, similar to the Word Authoring Connector Client, when you use this placeholder to "link" to an existing SharePoint document, that if this document is changed in the future, it maintains a reference to this "link" and prompts the user to update. This turns out not to be the case, what it actually does is make a copy of this document in MCMS, and you use a command line utility called "WssDocumentUpdater" to synchronise updates, which would be a scheduled process.

My current thinking is not to use the MCMS connector for SharePoint at all, and just use the Word Authoring Connector Client (with documents stored in SharePoint) to publish to MCMS.

That's next, an I'll update you all as to what happens.

posted by Graham Quinn @ 2:20 PM 5 comments