Friday, January 4, 2008

MOSS 2007 Content Deployment Topologies

As you all may know, content deployment is a powerful feature in MOSS 2007 (this concept has been brought over from CMS 2002). With almost any site, you need authors to actually create and edit the content that the target users will see. If the site is internet accessible, then there are a host of security concerns associated with the content/application etc. So for an external facing site, it is best to have at least 2 separate farms - an internal farm where authors can create, modify and approve content as well as an external farm where the content will be pushed out to for external user viewing. There can also be three farms (authoring, staging and production) where the content follows the authoring --> staging --> production chain. The staging farm can be used to "stage" the content so that it can be reviewed one final time before it is pushed to production.

We recently reviewed the different farm topologies and decided to go with the 3 stage approach (authoring, stage, production). I will list the advantages and disadvantages of 2 vs. 3 stage topology as they applied to us. Keep in mind that your situation might be different as you might have different constraints.

Two Stage topology:

1) Simple content deployment strategy. Users approve pages in authoring farm and that content is pushed to the production farm.

1) Stage does not exactly mirror production in terms of content.
2) If business users need to view content, they must view it on the authoring server which might not have the same links or the same look and feel as production. (the master pages might be slightly different for an optimized experience etc.)

Three stage topology:

1) Stage is always a complete replica of production, in terms of content and applications. This will be imperative for testing a production-like environment, which may not be feasible on the internal farm.
2) In case of a disaster on production, you can simply change the external DNS entries to point to stage while you bring back production.
3) Authors and business users will get another chance to preview content on stage before it is pushed to production.

1) More complicated deployment strategy.
2) We will need to ensure that stage is used to review content or it becomes a redundant deployment hop.

Thus the 3 stage topology makes more sense for our business case. A recommendation I would make is to make sure you design your infrastructure correctly - ensure that you allocate budget for a dev, test, stage and production farms. This is the right way to do things and can make your life easier over the long term.


Anthony Grace said...

Hi Faraz,

We are going with the 3-stage model, like you. Question: does it make a difference if MOSS SP1 is applied to staging and production servers, but not on the development machine/VM?

Anthony :-)

Faraz said...

If you are just using the development machine to write code and build controls then you should be ok - just check the changes to the SDK.

For content deployment, I would not recommend using mismatched service packs on any of your deployment hops. SP1 changes the schema of the database as far as I know - also SP1 failed on a couple of our existing environments so we held back and just did the DST fix.

So bottom line, you can try it - but content deployment being as sensitive as it is, I would not recommend it.

Anonymous said...

Thanks Faraz :-)

Anonymous said...

Thanks for the information Faraz.

What do you recommend for handling the deployments between the dev/stage/prod? The built-in SharePoint deployment feature (and exe) or some 3rd party application?


lambrite said...

I am also curious about what you are using to handle deployment between servers.

(Sorry if you get multiples; having trouble with sign-in.)