Why use an authoring server *and* a production server

Question

I've been reading the topology document for SharePoint 2010 content deployment and am trying to explain the benefits of a 2-stage (authoring and production) or even 3-stage (authoring, staging, production) farm topology to others. One advantage is security; you lock your production box down tightly. However, what are the advantages if everything is based in the intranet and nothing in SharePoint is facing the Internet?

Also, if you've locked down permissions to prevent editors from doing any admin tasks, does the authoring instance still make sense? Your guidance is much appreciated.

Answer 1

I happen to have a great exposure working with the Content Deployment in an authoring and production topology:

Authoring and production farm The two-farm topology is a standard Internet site topology, and it is typical of topologies that are used to publish an Internet site. It includes two server farms: one to host the authoring site collection along with other sites that are used by the authoring team, and the other to host the production site collection. Users of the production server farm belong to a separate Active Directory® domain, and some production farm users might be anonymous.

Recommended for: Internet-facing sites. Extranet sites with read-only access.

Authoring, staging, and production farm A three-stage topology includes an authoring farm, a staging farm, and a production farm. The staging farm is used to test or review the content, in addition to custom Web Parts or code, before it is published to the production farm. The site collections for authoring and staging can be located within the same farm.

Recommended for: Environments where a multistage approval process is a business requirement. Validating content in an environment that more closely reflects the production environment before deploying it to production. Testing the content with custom Web Parts and code before moving it to the production farm.

Single publishing farm Recommended for: · Intranet environments. · External environments in which staging verification is not a business requirement. · Segregating security settings and authentication between two locations, when only one farm is available or necessary.

Some experiences: I happened to have worked with content deployment topologies including two or more server farms in both MOSS 2007 and SP2010, to separate the authoring environment from the production environment. Typically, the destination server farm (the "production" farm) has tightened security to minimize the actions that can be done in the production environment. It is not expected that authoring will be done on the production server, because changes to content on the production server might be overwritten by a content deployment job. The OOTB content deployment usually set-up to run after every 15 minutes. On the other hand, a custom code approach can be used to set up the process with some detailed settings.

CD in MOSS 2007 has a lot of problems while pushing down the content during creating/editing/deleting. However, SharePoint 2010 is shipped with some more features provided in Content deployment and migration API.

Answer 2

I would think that a 3 stage environment would make a lot of sense if you were developing an internet. The staging environment gives you complete control over the page authoring environment. As you indicated you have a separate set of permissions for the users involved with authoring. In addition, when the pages are approved in the staging environment, the content deployment scheduling functionality will take care of promoting to the production environment. If your Intranet has a lot of custom page development than this would also be an applicable topology to follow.

Answer 3

The advantages of multiple instances are limited in the scenario you've given.

You are correct in what you're implying - that you could simply have one farm, with no content deployment. Editors could see unpublished content, and other users see published.

Or, as the document you linked to says, you could have one instances and deploy to a different site collection within it; Site collections do offer a pretty good security boundary