In part 1, I detailed the different complementing features of both SharePoint Technologies & Content Management Server. In part 2, I’ll address the different types of solutions as well as choosing a product that will serve as a primary point of entry for end users.
There are two types of situations where the two products (Microsoft Content Management Server & SharePoint Technologies) can be leveraged to implement a solution:
- Multiple front-end entry points
- Single front-end entry point
A multiple front-end entry point solution would likely be implemented with MCMS 2002 taking the role in one or more entry points and SharePoint taking the role in one or more entry points. This provides a content publishing entry point where one type of user will need little to no collaboration with other users; they are there simply to consume what’s being published. Another entry point would be for a different set of users who would require more interaction and collaboration. Both entry points could pull content from either entry point. To me, this isn’t a single integrated solution. A classic example would be an Internet site implemented with MCMS and an Intranet site implemented with SharePoint. The MCMS site could pull documents from libraries in SharePoint as well as lists. The Intranet could pull press releases from the Internet site. I think it was Microsoft’s intention for the MCMS Connector for SharePoint Technologies to assist and satisfy this type of a solution. It contains MCMS placeholders that will display documents in a SharePoint library, a web part that will display a list of postings from a MCMS channel, and a search component for a MCMS site that will search SharePoint portal search groups. I’ll go into more detail with the Connector in part 3 of this series.
Unfortunately this solution does not provide a truly integrated solution. The single solution is where I think there is a severe lack of integration support out there (articles, downloads, placeholders, controls, etc). A single integration solution is the driving force behind this blog series.
Let me take a second to explain the difference in building a site & adding/managing content in the two products:
When you build an MCMS project/site, you built the actual site using the capabilities and functions MCMS provides to facilitate the content within the site. You’re responsible for building the UI, navigation, functionality, content templates, custom placeholders for unique content, user controls for additional componentized functionality or navigation, etc. Nothing is provided for you, granted, you could use 3rd party provided collections of site templates and/or base it off Woodgrove except the MCMS author console.
When you build a SharePoint portal/site, you create list content using browser based authoring capabilities. You could use VS.NET to build custom web parts… you can use FrontPage 2003 (or by hand-editing) the site definitions… but you aren’t building the site; the site is already built. You’re simply adding content around a site structure that’s already defined. To me, this is what content owners do in a MCMS site: they select the templates & add content just like you select web parts and add content.
After making the decision to use Microsoft Content Management Server & one or more of the SharePoint Technologies in an integrated solution, the next bit step is determining which of the two products will serve as the primary entry point. MCMS has a very modular architecture in that it’s very easy to use multiple placeholders to makeup a single posting and group multiple postings in channels. SharePoint is not set up in this modular sense. While you have areas and these areas contain multiple web parts, it’s not so easy to move things around. I think it’s much easier to incorporate MCMS postings & channels within SharePoint areas for many reasons, however there another deciding factor when choosing which product will “take the lead”: the web part framework only operates within a SharePoint environment. While ASP.NET 2.0 will bring web parts to other .NET implementations, it will not work within v1.0 or 1.1 of the .NET Framework with the exception of SharePoint. In addition, I find most sites I interact will contain some content surrounding the functionality. Take the Microsoft support site… there’s introductory & help content surrounding the search, list, and knowledge base articles.
This is not to say that it’s not possible to implement a single solution with MCMS taking the lead. I just think it’s easier to incorporate parts & pieces of MCMS (workflow, content authoring, content organization, etc) into SharePoint sections, like web part zones and web parts. Incorporating web parts into MCMS templates is a much more daunting task… if possible at all.
Microsoft MVP, Full-Stack Developer & Chief Course Artisan - Voitanos LLC.
Andrew Connell is a full stack developer who focuses on Microsoft Azure & Microsoft 365. He’s a 20+ year recipient of Microsoft’s MVP award and has helped thousands of developers through the various courses he’s authored & taught. Whether it’s an introduction to the entire ecosystem, or a deep dive into a specific software, his resources, tools, and support help web developers become experts in the Microsoft 365 ecosystem, so they can become irreplaceable in their organization.
