Tuesday, January 8, 2008

SharePoint 2007 CSS friendly control adapters

ASP.NET 2.0 and MOSS 2007 provide great navigation controls, but the html that is emitted when those navigation controls are rendered is not the cleanest (for example, view the source of a MOSS page containing a menu and a treeview and you will see what I am talking about). The menu and treeview controls emit a bunch of table tags, which is not a best practice. There is a desire to control the output of these controls to make your pages more css based. It would be a shame to have to write your own menu control to control its HTML output.

ASP.NET's control adapters come to the rescue. When these are configured correctly, they can convert the table tags emitted by these controls to ul and li tags. I recently tried this out for making our menu control more css based and it worked wonderfully. The caveat is that this will change your css styles for the menu totally. Try it out, this works great and making your pages more css based is definitely a best practice.

Here are a couple of good resources to get you started down this path:
1. CSS adapters white paper.
2. A nice walk through by John Ross.

Musings on MOSS 2007 Content Deployment

So a few days ago I started playing with and testing the MOSS content deployment feature. From my previous readings, it seemed easy enough. My approach was to go at it from scratch so that I could understand what works and what doesn't. I got quite a few errors along the way, I wanted to publish those here so that you could learn from my mistakes. As I mentioned in my previous post, we will use a 3 stage topology for content deployment. I still have some other questions around this whole process, but I will update this post as I learn more.

The first scenario I tried was moving from one site collection to another in the same Web application. That did not work out so well. I got errors along the lines of "Unable to import the folder _catalogs/masterpage/Forms/Page Layout. There is already an object with the Id 853c8232-ae6d-4626-9cae-682xxxxxx in the database from another site collection." The other error I got was "Unable to import the folder WorkflowTasks/Office SharePoint Server Workflow Task. There is already an object with the Id 3d27c6ef-cc9c-4de5-b671-xxxxxxxxxxxx in the database from another site collection.". Supposedly this error occurs when the site collections share the database and an object already exists in the database due to the first site collection that the content is being exported from. The way I got rid of this error was to create a new Web application and move content between site collections that are in different Web applications.

Moving between site collections in different Web Applications did not work initially either because the destination site collection was based on a template other than the blank template. It is imperative that the destination site collection be based on the blank template for content deployment to work. The error I got was "Content deployment job 'Remote import job for job with sourceID = e94ecf30-33d2-498d-ae5c-xxxxxxxxxxxx' failed.The exception thrown was 'Microsoft.SharePoint.SPException' : 'Cannot import site. The exported site is based on the template XYZ but the destination site is based on the template ABC. You can import sites only into sites that are based on same template as the exported site.'". By the way, the error was confusing because it did not mention that the destination site needs to be a blank site.

The other task I had to complete was to disable all the features on the target site collection. For some reason that was causing a problem. More on this later, but keep in mind that you will have to probably deactivate the features on your destination site collection.

After these corrections, the content deployment between site collections in different Web applications worked. The next test was to move the content between farms in different domains :).

Initially this did not work and failed with the following error:
"Content deployment job '[jobname]' failed. The remote upload Web request failed.". The DNS was setup correctly (using the HOSTS file) and I could browse to the destination site from a browser on the source server. I looked in the event log for an explanation of the error and found the following.
"Failed to communicate with destination server for Content Deployment job '[jobname]'. Exception was: 'System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it".
This didn't make a lot of sense right away but then I realized the problem. In the target farm, we had one app server, 2 WFEs and 1 DB server. The account that was being used to authenticate against the central administration of the target server in "Content Deployment Settings" from the source did not have permissions in the destination site collection. I gave that account permissions to the site collection and voila..it worked.

Friday, January 4, 2008

MOSS 2007 Content Deployment Topologies

As you all may know, content deployment is a powerful feature in MOSS 2007 (this concept has been brought over from CMS 2002). With almost any site, you need authors to actually create and edit the content that the target users will see. If the site is internet accessible, then there are a host of security concerns associated with the content/application etc. So for an external facing site, it is best to have at least 2 separate farms - an internal farm where authors can create, modify and approve content as well as an external farm where the content will be pushed out to for external user viewing. There can also be three farms (authoring, staging and production) where the content follows the authoring --> staging --> production chain. The staging farm can be used to "stage" the content so that it can be reviewed one final time before it is pushed to production.

We recently reviewed the different farm topologies and decided to go with the 3 stage approach (authoring, stage, production). I will list the advantages and disadvantages of 2 vs. 3 stage topology as they applied to us. Keep in mind that your situation might be different as you might have different constraints.

Two Stage topology:

1) Simple content deployment strategy. Users approve pages in authoring farm and that content is pushed to the production farm.

1) Stage does not exactly mirror production in terms of content.
2) If business users need to view content, they must view it on the authoring server which might not have the same links or the same look and feel as production. (the master pages might be slightly different for an optimized experience etc.)

Three stage topology:

1) Stage is always a complete replica of production, in terms of content and applications. This will be imperative for testing a production-like environment, which may not be feasible on the internal farm.
2) In case of a disaster on production, you can simply change the external DNS entries to point to stage while you bring back production.
3) Authors and business users will get another chance to preview content on stage before it is pushed to production.

1) More complicated deployment strategy.
2) We will need to ensure that stage is used to review content or it becomes a redundant deployment hop.

Thus the 3 stage topology makes more sense for our business case. A recommendation I would make is to make sure you design your infrastructure correctly - ensure that you allocate budget for a dev, test, stage and production farms. This is the right way to do things and can make your life easier over the long term.

Migrating CMS 2002 to MOSS 2007

Recently I have been working on a project to migrate a CMS 2002 site to MOSS 2007 internet facing application. I will start posting those experiences here shortly.