SharePoint and MCMS-Managed URLs

Microsoft’s SharePoint is implemented by inserting ISAPI filters into IIS virtual servers. These ISAPI filters intercept all inbound requests as all URLs are managed unlike a typical website where the folder structure is somewhat mirrored in the URL. SharePoint’s managed URLs tell it which portal or WSS site and list, document library, or Web Part the user is interacting with.

Microsoft Content Management Server (MCMS) also utilizes ISAPI filters that are configured as global filters for all incoming requests. One of these ISAPI filters checks each HTTP request against the MCMS database to determine if it is an MCMS request or not. If the MCMS ISAPI filter determines the URL is not an MCMS request, it passes it on to IIS or lower priority ISAPI filters for further processing.

On its own, each product works perfectly. However, when they are used together on the same server, there may be conflicts. For example, if the SharePoint ISAPI filters determine a URL is not consistent with a SharePoint request, it returns an HTTP status code of 404 – File Not Found, as SharePoint assumes all requests are to be consumed by its ISAPI filter, unless explicitly excluded. We’ll go into excluded paths later in this appendix.

The order of steps in configuring a virtual server for hosting a SharePoint site (WSS/SPS) and MCMS is very important. The following assumes Windows SharePoint Services (including SP1), SharePoint Portal Server (including SP1), and Content Management Server (including SP1a) are all installed as well as all requirements for these installations being met.

In this appendix, we will create a SharePoint portal in a virtual server. We’re creating a portal because it provides necessary features, such as customizable search, that we use in Chapter 5, Searching MCMS with SharePoint. Note that all the limitations and steps outlined here apply to WSS as well because SharePoint Portal Server (SPS) relies on the WSS engine to process all URLs.