MOSS 2007 – Web Site Publishing

Posted: February 26, 2007 in MOSS 2007

       The first step to look at is the structure of a publishing site. First of all, as you will see later in this post, the publishing process requires you to specify a site collection from which you will be publishing (You do not need to publish the ENTIRE site collection however.)  A publishing site itself is a site within a site collection, it in turn may contain a number of additional publishing sub-sites which may contain their own publishing sub-sites, and so on. Each publishing site contains its own pages library which contains the page layouts developed for the site. It is common for the development staff to set up the pages layout to enforce a common look and feel for the site and to set the field areas where the content owners/editors can insert their content. These specific layouts are associated with a content type which the developer can also customize and develop. This way when a new page is need the content editor will choose the content type and the template will automatically be loaded for them to insert their content.
         So assuming we have already developed our publishing sites, we are almost ready to deploy them. We will have a couple tasks to prepare for deployment:
Configuring Deployment Settings
        First of all, we need to be sure we need to be sure first of all that we have turned on the publishing feature on our source and destination sitecollections. Stroll over to your target/destination server. We will need to set it up so that we can actually publish to it.  This is done in central administration –> Operations Tab (Content Deployment section) –> Content Deployment Settings, this will bring up the Content Deployment Settings Management page. You will need to  ensure that the "Accept incoming content deployment jobs" is checked. Ensure you have the correct servers( on the import server and Export server settings). Now set the connection security item. Be careful here. The default value is to Require encryption. Now if you are playing around and deploying from a site collection on one server to a site collection on the save server, or within a corporate firewall, there is probably a good chance, that you do NOT have SSL setup internally. In this case if you require encryption on this server NONE of your deployment jobs will work as this server will put the smack down on them without SSL. So you may want to set this to Do not require encryption. Now for production environments, you will want to revisit this. There is a reason MS uses require encryption as their default setting.
      Next determine the location for your temp files and the number of reports you want to maintain. One of the real sweet things with MOSS and what could end up being a living hell is the number of points that is allows for reports to be generated. It would be a good idea to think through what reports you need as you move through MOSS. You could easily end up with a report tidal wave with a vast amount being generated, stored, and not ever used. Having unnecessary reports sitting around for no reason into eternity just bugs me, always has, and it is one of those things that in some cases could give a hacker unnecessary information on your system and its operation.
     Now click OK and your destination server will be ready for publishing.
Configuring Paths and Jobs
     The next step is to configure PATHS and JOBS on your source server. A path defines the source site collection, the destination server (not the destination path, but the URL to the servers central admin web application) and the connection info for hooking into the destination server since in general a MOSS server does not appreciate receiving publishing jobs from random useraccounts. A path is as it sounds, the definition of the path that a publishing job will take the source sitecollection being your origin point and destination being your target server. As well as the flag you will be flying while you do the action.
     The Job on the other hand is the action actions being taken. It defines the specific site(s) being pushed out and the schedule under which it will be done as well as the ancillary information we will be publishing (such as user names).
    Before you set up your path, one word relax. You are going to be defining it at the site collection level in your path. Your first thought may be to throw a few expletives towards the MOSS team since you want to ONLY publish site A and not the entire collection. You CAN do this, but you do it in your JOB configuration. The MOSS team has been looking out for you on this one so be calm and continue reading.
    To set up our path(s) we will need to go to Central administration –> Manage Content Deployment Paths and Jobs –> Create Path. This will take you to the "Create Content and Deployment Path" page. First you will enter the Name and Description. It is highly recommended you think a bit on this. First of all use the description field. Remember when you set these up someone has to come behind you some day and figure out what your path does, it would be much easier for them to have this filled out intelligently so they can see why you have created it. on that note, it is a good idea to adopt a naming convention for these paths. something that defines the site being published, the destination and perhaps the date of creation. Something that when seen in a listing of 20-30 publishing paths will help someone understand what that job does (PATH-A is nice and simplistic but it does not help those who come after you). Whatever you decide on be consistent.
     Now that your name and description are in there, enter the source web application and site collection. MS has been nice enough to provide dropdowns for this so you are not cutting and pasting URLs out of IE (since I KNOW none of us would be using a NON-MS browser). Next, enter the URL for the destination servers Central Administration web application. This is the URL that comes up when you launch the admin tool on that server and yes this is one of those IE URL copy and paste operations I was talking about. While you are over there cutting and pasting, find a user who has Write access to the destination site collection. This is the account you will be specifying in the next section.
Now click "connect"  You need to have a successful connection here to proceed further on your configuration.
    Once the connection has succeeded you will need to specify the destination web application and site collection. Whether or not you’d like to deploy the user names and security information, then click OK. Congrats your path is configured.
   Next we will need to set up the job(s) to do the publishing for the path(s) you have configured. To do this: Central administration –> Manage Content Deployment Paths and Jobs –> Create Job. You will need to specify the job name and description I would caution you the same way I cautioned on these field for paths. Since I am not in to overly badgering folks we will continue. Select the path, you will find the wonderfully descriptive name you entered as a result of my previous badgering. Now you can enter the scope. This is where you specify whether you want to entire site collection or just specific sites from within it.
    Next you set up the schedule for this job to run (are don’t specify a schedule and leave it as a manual job). The cool part here is you set up 1 path for that site collection now you can set up 1-x jobs to manage publishing of different sites within your site collection. You can have jobs that deploy SiteA manually, and another that does a daily diff publishing for siteA another for full, Just a number of variations to allow you to set up a flexible set of publishing jobs.  
Job and Path creation recommendations
        Now that we know how to set these jobs and paths up, we can take a look at some guidelines in doing so. So lets say I have a HUGE site collection that repesents the whole of my corporate extranet. I have a number of subsites such as Corporate news, activities, clients, about us, production listing, employment listings. Each of which has its own set of content owners, and publishing approval processes. Generally, you will also have a QA requirement that requires all content being deployed as the public face of the corporation to go through a QA process.
       It is expected that some areas will be quite volatile, while others will not. corporate news, and activities will likely change more frequently than the about us section or product listings. At any given time  the news, employment listing, activities may be in various states of update. Content editors in the various departments are busy updating their content oblivious to the other department content owners updating theirs. Frequently a news article or corporate announcement may be drawn up, approved and pushed to the Dev site a day or 2 before it is to be actually published to the public extranet (perhaps waiting for the official press release to be sent out).
       For these types of scenarios, it is a good idea to break the publishing jobs up into various chunks to publish only specific sections of the site. This way we do NOT need to be running QA on the about us section when all we have done is added an activity. We also do not need to delay the work being done on corporate news and have them rushing the last minute to get their news ready or delay publishing another section  because of the news needing that delay. A good guideline would be to break those jobs up to specific content ownership groups so you can allow those groups to define the schedule and publishing policies for their own content and NOT have their guidelines impact other content ownership groups.
      In large organizations this could be a delicate balancing act. You could easily have so many content ownership groups that your list of jobs quickly becomes unmanageable. This is where your job/path naming convention, usability, and job compartmentalization needs converge and it is important you reach an appropriate balance for your organization.
 
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s