Partager via

How to Publish SharePoint Content from an Authoring Farm inside Corporate Network to a Production Farm in DMZ

  • Article

How to Publish SharePoint Content from an Authoring Farm Inside Corporate Network to a Production Farm in DMZ

Introduction

This article is based on my experience on development and testing Microsoft SharePoint Guidance 2.0 for Microsoft Patterns and Practice team. We are writing a reference implementation for MOSS 2007. The RI simulates a company named Contoso with two downstream partners: Partner1 and Partner2. Contoso is deploying a MOSS extranet application for Partner1 and Partner2 to use. The extranet will have a publishing site collection with two sub sites, one for Patner1 and the other for Partner2. The extranet will also have two collaboration sites, one for each partner.

In summary, there will be three site collections in the production farm:

  1. A publishing site collection (shared by all partners, each has a sub site)
  2. A collaboration site collection between Contoso and Parnter1
  3. A collaboration site collection between Contoso and partner2 

MOSS Version Requirement

  • Microsoft Office SharePoint Server 2007 Enterprise version is required for content publishing and BDC feature to work.
  • Authoring farm and the production farm should have the same MOSS version.
  • Infrastructure Update for Microsoft Office Servers (KB951297) should be installed on both farms for the deployment to work cross machine boundary. If you don’t install the infrastructure update on the production farm, the content deployment from authoring farm to production farm may not work.

Farm Topology

This article assumes you have two server farms: one internal farm in your corporate intranet dedicated to your authors/editors/designers and a second farm in the Internet-facing network DMZ that hosts your production site. Your internal farm is read/write, while your production farm is read-only for the publishing site collection and read/write for the two collaboration site collections. The DMZ and intranet are separated by a fire wall such as an ISA server. The following is an example topology:

A Simple Back-to-back Perimeter Topology with Content Publishing for MOSS

image

This is a simple farm without much redundancy. You can make you DMZ farm smaller by combining Central Admin and Web Server in to one. But most probably, you may want to expand it to have the following.

  • Add more web servers to the load balanced clustered web servers. We chose to have two web servers to demonstrate the distributed session cache. For the performance purpose, this may not be enough for you business.
  • Clustered SQL servers.
  • Dedicated app servers for indexing, querying, excel calculation, and etc. It is also common to add indexing or querying roles to web front end servers. If you do that, make sure that querying and indexing role are deployed in different servers.
  • For the performance reason, you may have a clustered ISA servers facing the internet for redundancy and caching purpose.
  • The Perimeter Network should allow data flow from Corporate Net.
  • The authoring farm is usually simpler than the production farm unless you need to do performance test. Since the production farm is already very simple, the authoring farm is configured identical to the production farm.

Security Considerations

Security by Isolation
  • Isolate farm into different network

Isolate Extranet Farm in DMZ

Isolate authoring farm inside corpnet so outsiders can’t access it

  • Isolate web collection in the different IIS application pool and different DB

Isolate Publishing Site collection in its own publishing application pool and its own DB

Isolate Partner1 collaboration site collection in its own Partner1 application pool and its own DB

Isolate collaboration site collection in its own Partner2 application pool and its own DB

  • Isolate publishing content in different sub site under the publishing site collection

Partner1 publishing sub site for Partner1

Partner2 publishing sub site for Partner1

  • Isolate people in to different roles in the aspnet authentication provider

Partner1 role for employee in Partner1

Partner2 role for employees in Partner2

Admin role for the company employee that managing the DMZ

Security by authentication and Access Control
  • Control access to SharePoint content by divide web application into different zones

Web application in DMZ is separated into default zone and extranet zone.

Extranet zone uses form based authentication (FBA).

Default zone uses windows authentication.

Both zones access the same content.

Authoring->Publishing will be between the authoring farm and the DMZ’s default zone (not the extranet zone)

  • Control access to publishing sub site by only authorizing appropriate roles

Partner1 publishing sub site only allows roles Partner1 and Admin access

Partner2 publishing sub site only allows roles Partner2 and Admin access

  • Control Access to SQL Database

User Windows authentication Mode instead of SQL Server Authentication for tighter data security.

  • Control Access to Backend Services

Create special groups for accessing Backend Services

Mapping user account to backend group using SSO

Never open backend services to public

  • Control Search Access

Create special groups for search

Do not use admin account for search. Admin account has too much power.

Apply security trimming.

  • Block security holes

Consider block cross site, cross site collection, cross webapp query for important list.

Consider block important content from been searched. Require credential for search important content.

Security for the Servers
  • Harding windows server 2003 sp1 by running the security configuration wizard.
  • Shutting off Unnecessary Services in the server
  • Implement File level security
  • Running windows server update services
  • Verify security using the Microsoft Baseline security analyzer (MBSA)
Security in Transport
  • Consider Using SSL
Security Hardening SharePoint Sites
  • Given only appropriate access the following site or site collection:

Partner1Collaboration Site collection =>Partner1, Admin

Partner2Collaboration Site collection =>Partner2, Admin

Partner1 Publishing Sub Site =>Partner1, Admin

Partner2 Publishing Subsite =>Partner2, Admin

Central Admin =>Admin

Setup the authoring and production farm for Non-publishable Components

Deployment will not deploy Programs, Assemblies, Features, Configuration information such as Web.config files. They have to be set up separately. You have to install all required WSPs, and assemblies, and features. You need to setup you configuration files correctly.

  • Manually set up the farms

You often need to start from a clean server, install SharePoint, create web applications, extend web application to various zones, install SharePoint WSPs, create web collections and web sites, enable features, start work flows, populate users in local machine or in a security provider database, create SharePoint user groups and individual users, and etc.

Sometimes you need to install in various configurations such as such as Win2K3, Win2k8, 64 bit, 32bit PC, and various farm configurations. It may be too time consuming if you have to run of the setup steps manually. Fortunately, there are ways to automate some of those steps.

  • Using STSADM and custom console app to automatically setup SharePoint Site

STSADM tool can complete many of your setup steps. For those tasks you cannot achieve with STSADM, one solution is to write a console application. This is the method we chose. We wrote a console app to modify the web.config file in the Central admin web app and extranet web app. You can download the setup batch file and custom console app source code from SPG v2 Iteration 2 Drop https://www.codeplex.com/spg/Release/ProjectReleases.aspx?ReleaseId=22570.

  • Extending STSADM to set up SharePoint Site automatically

Instead of writing your custom console application to carry out tasks that can not be done by STSADM, you can extend STSADM yourself or use third party STSADM extensions.

  • Using Backup-Restore to automatically setup SharePoint Site

You can use STSADM backups, automated SQL Backups, integrated IISBack.vbs script to automate your restore for setup. However, you need to use other methods (including manual) to setup your farm and then create the backup.

I recommend you at least perform manually setup once in your dev/test environment. Once it comes to setup the authoring and production farm, you should automate your process.

Prepare Production Farm for Content Deployment

Create Blank Site Collection by following steps

You can only deploy to a blank site when you initially deploy to the production farm.

  • Start Central Administration in the Production Farm
  • Under Application Management
  • Select Create or extend Web application
  • Select Create a new Web Application
  • Choose an easy to remember port number
  • Type in a user name and credentials to create a new app pool
  • Type in a descriptive database name
  • Leave all other settings at the default and click OK, then wait for the Web application to be created
  • Click Create Site Collection
  • Ensure that your new Web Application is selected
  • Type in any name for the Title (it will be overwritten later)
  • Select "Blank Site" as the template. This step is IMPORTANT, because Blank Site is the only template that you can import any other template into
  • Type in the names for the site collection owners
  • Click OK

Allow Incoming Content Deployment Jobs in the Production Site by following steps 

  • Start Central Administration in the Production Farm
  • Select Operation
  • Select Content deployment settings
  • Select Accept incoming content deployment jobs
  • Select Do not require encryption and click OK

Prepare Authoring Farm for Content Deployment

Create Content by following steps
  • Create site collections
  • Create sub sites
  • Create pages
Create Content Deployment Path in the Central Admin of the Authoring Farm by following steps
  • Start Central Administration in the Authoring Farm
  • Select Content deployment paths and jobs
  • Click New Path
  • Type a descriptive name for the path. Select the web application and site collection for the staging site. Then type in the URL of the Central Administration web site of the production site.
  • Click Connect
  • Once you see "Connection succeeded", select the web application and site collection that you created for production. You can also choose to deploy user names and security if you want the new site to have the same users and permissions
  • Click OK
Create Content Deployment Job in the Central Admin of the Authoring Farm by following steps
  • Click New Job
  • Type a name, and then select the path you created
  • Keep all other default values, and click OK

Run Content Deployment Job in the Authoring Farm

  • From the context menu on the job, select Run Now
  • Refresh the page, and then click on the text Running
  • Watch the status of the job
  • When the status changes to Succeeded, you can click on the URL to the production site to verify that the content was deployed

Considerations when Updating Features and Installing WSP in the Production Farm

You need to be careful when installing a WSP, updating/activating features, changing web.config files, or running other jobs that might change the SharePoint behavior in the production farm. Immediately after installation and before the new content is deployed, your production site may be broken. For example, a feature activation might add/hide/modify a column in a list, and make the list broken before the new content gets deployed.

It it is recommended that after making any changes to the SharePoint, you should immediately deploy you content from the authoring or staging server to assure that the contents are in synch with other non-content artifacts such as web configurations files, assemblies, activated features, the files in the 12 hive . You should keep the time interval as small as possible.

Core Concept on Content Publishing

Path: A path is a connection between a source farm and a destination farm. The path contains information about which source web application and site collection you are deploying, authentication information for the destination farm, and the web application and site collection on the destination farm. In short, a path represents the mapping between your authoring and production site collections.

Job: A job is associated with a path, and it determines exactly which sites in the source site collection will be deployed and on what schedule. You can have many different jobs for a given path, each running on different schedules and deploying specific sections of your site.

Schedule: a job has a schedule and can deploy content updates regularly without the need to manually kick it off every time. For example, let’s say you have a Press Releases site that needs to be updated every hour, and an Employee Bios site that only needs to be updated every month. You would create two different jobs, one that runs every hour and deploys the Press Releases site, and another that runs monthly and deploys the Employee Bios site.

What will get deployed? By default, deployment only deploys the changes since the last successful deployment. If there aren’t any changes, the deployment will complete without redoing any unnecessary work. Deployment automatically picks up the dependent page layout or images and packages them up along with the page itself – even if the dependent resources aren’t in the same site. Full deployments every time can also be configured which will deploy everything even there is no change.

Deployment copies only content such as web pages and resources used by the copied pages. When a web page is deployed, any items in the content database that the page depends on, such as images, style sheets, or layout pages, are also deployed.

Content deployment deploys only the last major and the last minor version of each item where versioning is enabled.

You have option to deploy the entire site collection or a selection of sets.

What will NOT get deployed? Deployment does not deploy any of the following file types:

  • Programs
  • Assemblies
  • Features
  • Configuration information, such as Web.config files
  • In progress workflows, such as workflows designed with SharePoint Designer
  • Items in the recycle bin

Quick Deploy: It is a special job called that is automatically created for every path in any site collection with the Publishing Resources feature enabled. This job, once enabled in a path, wakes up every few minutes (15 minutes, by default) and checks a special list for content that should be deployed. If the site owner has rights, he or she can deploy pages quickly to production by using the “Quick Deploy” link on the Page Editing toolbar. This adds that page to the special list, which the Quick Deploy job will check the next time it wakes up. By default, only the site owner has the Quick Deploy right. In order to give other users the same privileges, you simply add them to the Quick Deploy Users group.

Best practices for publishing portals

A technet article https://technet.microsoft.com/en-us/library/cc850698.aspx listed following 12 best practices for publishing portals:

  1. Deploy at least three front-end Web servers

Make query-driven Web Parts efficient

Make sure that lists and databases follow recommended limits to optimize query performance

Separate authoring and publishing environments

Separate your staging environment from the authoring environment

Make sure you have the latest updates installed!

Do not edit the destination site directly

Avoid management tasks and bulk operations in the authoring environment during peak hours

Use caching!

Start with a well-configured infrastructure that uses recommended hardware

Set application pool recycling settings for better availability

Monitor key counters to manage performance

Notes

It is important to note that content deployment is a one-way process: content is copied from a source site collection to a destination site collection. The content deployment feature does not support round-trip synchronization from source to destination and back again. Therefore, any changes that are made to the destination site collection will remain on the destination site collection only until they are deleted on the destination site collection, or are overwritten by a content deployment job that is set to deploy all content, including content that was previously deployed. Because of this, you should consider restricting permissions on the destination site collection so that users cannot make changes directly to content stored within that site collection.

One limitation in creating content deployment paths is that the source and destination path must exist in different content databases. This is because all of the GUIDs that are used to define sites, Web pages, lists, and items will be transferred with the site when it is deployed. For this reason, you cannot deploy a site to the same database as the source site.

If you create a sub site in the destination collection without using the content publishing feature, it will NOT get wiped out by the deployment.   If you happen to have a sub site in the authoring farm with the same path name, your deployment will fail with error “The specified name is already in user …”. The best practice is Not to create sub site directly in the production destination site.

Background Info:

· https://blogs.msdn.com/sharepoint/archive/2006/05/02/588140.aspx

· https://blogs.msdn.com/jackiebo/archive/2007/02/26/content-deployment-step-by-step-tutorial.aspx

· https://technet.microsoft.com/en-us/library/cc627268.aspx

· https://blogs.msdn.com/gayanpeiris/archive/2008/03/24/content-deployment-in-wcm.aspx

Comments