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:
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
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.
Isolate Extranet Farm in DMZ Isolate authoring farm inside corpnet so outsiders can’t access it
Isolate Extranet Farm in DMZ
Isolate authoring farm inside corpnet so outsiders can’t access it
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 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
Partner1 publishing sub site for Partner1 Partner2 publishing sub site for Partner1
Partner1 publishing sub site for Partner1
Partner2 publishing sub site for Partner1
Partner1 role for employee in Partner1 Partner2 role for employees in Partner2 Admin role for the company employee that managing the DMZ
Partner1 role for employee in Partner1
Partner2 role for employees in Partner2
Admin role for the company employee that managing the DMZ
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)
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)
Partner1 publishing sub site only allows roles Partner1 and Admin access Partner2 publishing sub site only allows roles Partner2 and Admin access
Partner1 publishing sub site only allows roles Partner1 and Admin access
Partner2 publishing sub site only allows roles Partner2 and Admin access
User Windows authentication Mode instead of SQL Server Authentication for tighter data security.
Create special groups for accessing Backend Services Mapping user account to backend group using SSO Never open backend services to public
Create special groups for accessing Backend Services
Mapping user account to backend group using SSO
Never open backend services to public
Create special groups for search Do not use admin account for search. Admin account has too much power. Apply security trimming.
Create special groups for search
Do not use admin account for search. Admin account has too much power.
Apply security trimming.
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.
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.
Partner1Collaboration Site collection =>Partner1, Admin Partner2Collaboration Site collection =>Partner2, Admin Partner1 Publishing Sub Site =>Partner1, Admin Partner2 Publishing Subsite =>Partner2, Admin Central Admin =>Admin
Partner1Collaboration Site collection =>Partner1, Admin
Partner2Collaboration Site collection =>Partner2, Admin
Partner1 Publishing Sub Site =>Partner1, Admin
Partner2 Publishing Subsite =>Partner2, Admin
Central Admin =>Admin
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.
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.
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 http://www.codeplex.com/spg/Release/ProjectReleases.aspx?ReleaseId=22570.
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.
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.
You can only deploy to a blank site when you initially deploy to the production farm.
Allow Incoming Content Deployment Jobs in the Production Site by following steps
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:
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.
A technet article http://technet.microsoft.com/en-us/library/cc850698.aspx listed following 12 best practices for publishing portals:
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.
· http://blogs.msdn.com/sharepoint/archive/2006/05/02/588140.aspx
· http://blogs.msdn.com/jackiebo/archive/2007/02/26/content-deployment-step-by-step-tutorial.aspx
· http://technet.microsoft.com/en-us/library/cc627268.aspx
· http://blogs.msdn.com/gayanpeiris/archive/2008/03/24/content-deployment-in-wcm.aspx