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:

        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.

     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.  

        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.

 

      So I got the chance the other week to get into Linville river for those of you curious ( 36° 0'43.25"N 81°55'54.26"W as Google earth has it). It was about as cold as you can get but it is amazing what some decent equipment does for you. I was as warm as a summer day. The only problem was my pole kept freezing (which my uncle points to as a prime warning that it is too cold to fish). i managed to work around that and actually got a decent sizes Brown Trout about half way through the excursion. So being skunked was not a problem. Granted I did not fill the creel but I love stream fishing so much that even a day where I catch nothing (which thankfully does not happen much), is still a great day for me.

    I took a friend with me this time who has never been stream fishing. He is a Bass fisher usually from shore. He had a ball, but did get skunked. This time of year is pretty challenging so if you are new, you tend to not have much luck. But it is a good time to get to know the river, it is a bit lower than spring and summer so you can see some of the pools and holes you normally would not and get a feel for the river. Linville in particular is a nice river to fish. Not a lot of obstacles, good habitat, nice collection of riffles, pools, current, some good deep sections that serve you well in the summer when the trout go deep. In the area I tend to hit on Linville, there are a few good access points and specific routes you take depending on the company. From the coordinates I gave up abouve you can fish the from the low bridge upstream if you want some challenge and some really sweet wading (I woiuld rate the hike as moderate). If you go downstream to the next bridge you get the most production section for me. I have rarely been skunked on that route. 

    As a warning, if you ever do go there. pay some respect to the forestry service guys they do not have to let you trounce across their property to get to the river, so WALK the driveway and don't make a ton of noise and especially no messes. If you go downstream you will reach a white house which is almost right on the river, the dude has his property done up nice. I have met him a couple times. Sometimes his dog goes insane when you wade through so wade on by and leave the pool in front of his house for him. In NC they can post the streams and he ha sbeen gracious enough to not post despite some very inconsiderate folks going by from time to time.

  Anyway, if you ever do go this route, drop me a line and let me know how it goes. It is definitely a nice route, not as isolated as I would like but not too shabby either.

       Delving into MOSS 07 for the first time can be a daunting task. There is so much to the product that it is not too difficult to spin your wheels reading high level summaries of all the capabilities without getting anywhere in-depth.  As part of my own journey deeper into MOSS 2007 I am going to try and hit (more frequently) on topics as I learn them and HOPE it helps anyone listening out there as well as myself.

      Let's start off with a quick overview, and some more fun acronyms to add to the already annoying list you are likely carrying around in your brain. MOSS 2007 has incorporated a into it a large set of features around publishing and web content, most of which were adopted from an older MS product known as Content Management Server (CMS). As of now, CMS will cease to be an independant product and will be incorporated into the MOSS product line to power its WCM (Web Content Management) capability. WCM, combined with the records management feature, policy management, and document management are all rolled together into yet another acronym, ECM, or Enterprise Content Management.

     The goal of MOSS 2007 WCM is to enable an organization to manage web content and publishing in such a way that the appropriate entities have control over the apparopriate roles and no one roll stands as a bottle neck for the others. In a traditional WCM scenario we would have a site wholly owned by IT. When a content manager wanted updated content, they would have to submit it to IT, who would incorporate it into  the site, maintaining the corporate structure, look and feel, and navigation. IT would then reploy the site back to production. Since IT rarely sits around waiting for someone somewhere to send them updated content, there may be a delay in getting the content out and if this is time sensitive content (i.e. news release, event announcement, etc) that can be an issue. Also, the content may end up looking nothing like what the content manager intended as it is twisted and and tugged into the corporate standard for look and feel, navigation, structure, etc. If this site is frequently updated with new content well maintaining that content could end up being a full time job for a content manager AND an IT staffer, which creates issue as really there is ONLY a need for the content manager to be busy on this task.  

     MOSS 2007 provides a solution for this issue as it seperates the look and feel, navigation, and structure of the page from the content of that page. So IT can develop the look and feel, navigation and structure (implemented via Master Pages), as well as defining publishing rules and workflow around it. Once established content ,managers can modify their content directly in pages based on the templates and policies set forth by IT. In general, IT worries about IT stuff, content managers spend their time on content management, the site stays uniform, corporate policies are enforced, workflows are engaged that keep the content from being officially published until the correct managers, legal, etc approve it, then it is published to a public web site, and world hunger ends (alright maybe that is taking it a bit too far), but you have to admit this is cool stuff and to steal an old term we used to use at McD's, when set up properly it allows the organization to keep their aces in their places with the experts in the various areas focusing on JUST their specialities while automating what could end up being a very manual workflow with emails and meetings galore.

      Sound cool? Join us next week for a in-depth look at some deeper how-tos associated with this area.

 In case you care to read ahead:

   0-7356-2282-5 - MS Office SharePoint Server 2007 Administrators Companion

   MSDN Virtual labs - Enterprise Content Management with Office SharePoint 2007

   Mark Kruger SharePint MVP blog -  http://www.sharepointblogs.com/mkruger/archive/2006/05/25/7570.aspx

   

 

      So MS has announced that the GotDotNet site will be phased out of existence. I had to say I was sad to see it go. Since it's inception, I have directed more clients there than I remember. I have posted tons of technical questions, and some not so technical (OTD) and found the user base, in its heyday, to be considerably better than any others out there. I will miss it, it's simplicity and the lack of annoying monitors spending more time badgering me on whether an items fits into a specific thread or not, than on helping me find the answers to the questions.

     That being said, I can understand where MS comes from in this action. They already have MSDN boards, they have invested in refining them and to be honest I think they have made some excellent progress on those boards. IMO they still have a long way to go, but the fact that they are really trying to improve them, is a good sign and although I am reluctant to attempt to traverse them right now, that may change in then next couple years.

    I will miss some of the GDN users as well, especially those at OTD. They ran the spectrum. from extreme ultra conservatives to "nazi-liberals" and while I found time to disagree with most of them, I enjoyed (most times) the debates and even some of the arguments. But alas, the nature of this business is change. Every site, every piece of software, everything changes. As much as I once loved the old BBS I used to post to with my first 386 (a fact I try not to admit too often), they gave way to something better, and I am sure 10 years down the road I will laugh at posting on a site like GDN, provided that the high levels of caffeine I invibe every morning, my driving ability, meteors, or underpants gnomes do not take me out before then.

   

    R.I.P. GDN