You are here: > Windows Server Products > SharePoint Server
[By: Peter van Mol]

Microsoft SharePoint Portal Server uses the power of Microsoft's robust search technologies to create an intranet site that lets you easily access key content from a broader set of enterprise information. In addition, you can rapidly deploy an out-of-the-box portal site and easily use Web-Parts technology to customize a Web-based view of your organization.

SharePoint Portal Server is a portal server built on Windows SharePoint Services (WSS), which bundles with Windows 2000/2003 Server. WSS itself provides portal functionality, and can be extended using the .NET Framework and ASP.NET. SPS is in fact a WSS application.

SharePoint Portal Server provides more traditional portal functionality and look-and-feel with less work than a portal built with MCMS. Out of the box, SharePoint Portal Server looks more like Yahoo and other portal sites, and provides similar functionality. By implementing the Microsoft equivalent of portlets -- what SharePoint Portal Server calls "Web Parts" -- business users can create their own dashboard pages, quickly and easily pulling together the varied resources they need and formatting them as they desire. Information may also be grouped and targeted, including across multiple hierarchies. You can also drop in special functional areas, including surveys, document libraries, meetings, and alerts, creating a typical portal dashboard.

Most importantly for web content management, SPS also extends WSS by providing document management, single sign-on, and indexing and search technology. To make document management as convenient as possible, SPS integrates tightly with the Microsoft office tools – Word, Excel, PowerPoint, Outlook, Access, and InfoPath. While most of the functionality SPS provides in this area is around document management, it can also help manage other assets. As with WSS, SPS can be extended using the .NET Framework and ASP.NET. One of the most powerful extensions, Single Sign-On, allows the mapping one business user login to the appropriate logins for all of the applications that they need to access.

SPS indexes and provides search results -- not just for its own repositories, but optionally for other websites as well, inside and outside the enterprise. It is this functionality that can be leverage to provide search functionality for an MCMS site.

MCMS Connector for SharePoint Technologies

The MCMS Connector for SharePoint Technologies provides three integration points between MCMS and SPS

  • Web parts (portlets) for managing MCMS postings (postings are MCMS lingo for pages) within an SPS portal, which is especially helpful if you are using the portal's single sign-on capabilities
  • SPS search query and response controls that can be implemented within MCMS templates, and
  • Document library controls that can be implemented within MCMS templates.

The web parts modules can be handy, but these can be built rather quickly from scratch as well. They serve as useful examples and starting points for subsequent web part development to expose CMS services via your SPS portal.

It is the latter two controls that are extremely useful. Displaying document content within MCMS from documents managed in SPS is a very helpful integration point as MCMS does not provide any document management functionality and moreover, SPS implements document and asset workflow. Document content can be displayed inline or in an attachment. This functionality can useful for managing images and other assets as well. Those assets can be checked in and out and versioned, allowing you to manipulate them with your editor of choice. The inline display functionality, however, only works with XML, so you will not be able to display images and other media assets as anything more than attachments in a MCMS posting.

Querying and returning search results is another powerfully useful -- in fact almost essential -- feature, as MCMS has no such capabilities natively.

To be sure, these tools could be built from scratch if required, but doing so would take some time. Moreover, the documentation around these areas, especially SPS search functionality, is somewhere between fuzzy and nonexistent.

So let's first explore getting the Connector up and running, and then evaluate the three integration points in more detail.

Installing and Running the Connector

The Connector is easy implement, if you follow the directions. And there are lots of directions. You need to read every single document Microsoft provides on the Connector when you download it. Then you need to read them again. Then you need to read every single knowledge base article on the Connector. And while you are at it, search some

SPS works in one of three scenarios – small, medium, and large server farms. The documentation defines these, and for the purposes of evaluation, we will assume that you will use a small server farm. There are three flavors of small server farms – one-, two-, and three- machine scenarios. The one-machine scenario has everything installed on one server. The two-server scenario simply has MS SQL Server 2000 installed on a separate server. The three-server scenario takes the two-server scenario one step farther and has MCMS and SPS on two separate boxes. You will want to determine which of these scenarios you are likely to use, keeping in mind maintaining the most straightforward, easy to reproduce setup for evaluation purposes.

Note, however, that you can only use the SPS Library placeholder control if SPS and MCMS are installed on the same machine. Therefore, I am tempted to recommend using the one-server scenario for evaluation purposes. But this is a limitation worthy of repeating: the document library control -- which is the integration point that allows documents and assets managed in SPS to be included in MCMS postings -- can only be implemented in the least scalable, least architecturally-sound solution. While the "small server farm – one machine" variant architecture is fine for evaluation purposes, it is not an architecture that you would want to deploy in a production environment. This means that there is a low likelihood that you will be able to implement the Library functionality after evaluating it. But it is still worth investigating, because once you have played with the Connector and investigated how it works, you can use it as a starting point for implementing this integration point using custom code.

Once you have done all of this, lay out an installation plan. Literally, determine which functionality you want to explore, define which servers you need – machines and software – and write down an entire installation plan. I would recommend building a virtual machine using appropriate software like Microsoft’s Virtual PC with Windows 2003 OS, which is required by SPS 2003. Then install all the service packs, .NET Framework 1.1, VS.NET, and MS SQL Server 2000. Once you have done this, save the completed disk file for later reuse. The virtual machine can be used as a starting point for any of the servers in any one of the small server farms scenarios; you simply determine which machine will be your MS SQL Server 2000 and ignore the others.

Assuming the one-server scenario, install MCMS, its service packs, and an MCMS site. Avoid undertaking the integration before you have built out some reasonable CMS functionality and populated the repository with content. Having an actual site running within MCMS gives you the ability to:

  • test the search results,
  • have postings in which to place the search and document controls, and
  • manipulate real MCMS content within SPS.

Once you have completed this, install SPS. It is very important that you exclude all of your MCMS paths from SPS. Until you do, none of your MCMS sites will function. This procedure is well documented in the installation instructions. Finally, install the Connector. Follow the instructions in the Connector’s help file for implementing each piece of functionality.

Next comes configuration, and it is here that the Connector falls down a little bit, because you need to have some idea of the target you are shooting for when it comes to completing the set-up. Specifically, you need to understand how to add web parts to an SPS page and why you would want to do so. You may need to have some level of comfort registering web parts with SPS in case this does not happen correctly during the install. You also need to understand template-building in MCMS so that you can implement, evaluate, and fully test the controls that are provided. You need to be comfortable with setting permissions both within MCMS and SPS. The entire process, from reading all the material to installation to configuration to implementation for evaluation purposes on a single machine, will take between two and four days, depending on your comfort level with all of the software, and assuming you have a working MCMS implementation.

Developers can extend the controls to provide the look and feel that they want. No source code is provided for the any of the controls, so while you can extend them, you cannot not re-engineer them.

How well do the controls work? They do exactly what they advertise and do it predictably and correctly. They also provide you with the opportunity to extend the functionality even farther -- kind of a jump start on the process. Let’s discuss each one in a little more detail so that you can get a feel for implementing each.