Graham's Blog

Search walkthrough for CMS using SharePoint...

There are a few User Controls involved to provide the search functionality. The first is SearchInput.ascx and has the text input box and search button or image button. The only properties to change here are that only the button or the image button should be displayed at any one time, in our case its the image button. On click the GetSearchResultsPageUrl is called (from the SearchUtilites class). The search page URL is set as a property of ths SearchInput User Control via HTML. This page is then posted with the values required for the SearchResults user control to fire. How does the SearchResults.ascx user control work? On it's page_load() event it has a try catch to check if there are values in the Search Text Box. If not it returns appropriate error, but if it does it then builds the XML query for submission via the QueryService web method of the SharePoint search web service. Then a dataset is built with the results and sent to a datagrid. The Search.ascx control just pulls the SearchImput.ascx user control together with relvant HTML around it. All you change on the Search.ascx page is the SearchResultsURL property which is the URL to a posting that the above pages can use to send the results to. The posting can be any template in CMS, all it needs to have is the SearchResults.ascx user control in order to display the results. So basically the Search.ascx page takes an input from the user, and sends the query generated from the SPSSearch.xml file (along with the users free text) to a posting with the SearchResults.ascx user control via the SharePoint Search web service reference (called SPSSearch) to display the results. What we need to do now is programtically consume the SharePoint search web service for easy deployment to hosted environment.

posted by Graham Quinn @ 4:59 PM 1 comments  

Multiple Anonymous Read Only CMS Site hosting...

Well, over the past few days, I have spent many attempts at correctly configuring a CMS archiecture to accomodate one central publically available CMS server with multiple host header sites, who are updated by multiple distributed CMS authoring servers.

Here is the architecture:
Web DMZ - 1 front-end CMS Server with 3 IIS sites (initially) - 1 for the SCA on the CMS installed port, 1 for the Read Write configuration via Site Manager, and 1 for every other publically available host header website (e.g. www.site1.com)
Database DMZ - 1 shared back end SQL server to host CMS database via SQL Authentication through 2nd firewall
Remote LAN or VPN locations - 1 authoring CMS server which will publish it's content on scheduled intervals via vbscripts, 1 or more development CMS servers (usually locally installed on developers pc's, source code stored in VSS)

Now let me drill into the CMS configuration for the front-end CMS server.
Prior to hosting multiple public websites the following is required: Internal static IP addresses for each public site to be hosted, add all these ip addresses to the Windows 2003 network config, External static IP addresses for each public site to be hosted, registered domain names for each public site to be hosted, relevant domain name resolution for the the domain name to the external ip, and then relevant firewall mappings from this external ip to the internal ip.

Here is a sample of the local config for more than one site:
IIS sites
CMSSites - AllUnassigned - Port 80 - no host header info - Anonymous and Integrated Windows security, Home directory - Drive:\CMSSites
SCA - AllUnassigned - Port 81 - no host header info - Integrated Windows
www.site1.com - 192.1.1.1 - Port 80 - no host header info - Anonymous and Integrated Windows Security - Home Directory Drive:\CMSSites\www.site1.com
www.site2.com - 192.1.1.2 - Port 80 - no host header info - Anonymous and Integrated Windows Security - Home Directory Drive:\CMSSites\www.site2.com

SCA Configuration
CMSSites - Read Write
www.site1.com - Read Only
www.site2.com - Read Only
Within the General Tab set the Map Channel names to host header names value to Yes
Within the Security Tab set the Allow Guest Users value to yes and select the local IUSR anonymous account used by IIS

Either using the automatic scripts or manually, import the SDO from the authoring server, and xcopy the ASP.Net code to the relevant locations i.e. Drive:\CMSSites\www.site1.com and Drive:\CMSSites\www.site2.com

Site Manager
Channels -> Make sure the top level channel names are www.site1.com and www.site2.com
User Roles -> Subscribers -> New Rights Group
Call this rights group something like Anonymous Users -> set the account to be the local IUSR anonymous account used by IIS, and grant permissions to all top level Channels, Resources, Template galleries and their children

And that should be it.

Points to note:
During development of CMS using the PAPI, make sure you use web.config app variables for channel names etc, to avoid code issues on deployment from authoring to production servers.

posted by Graham Quinn @ 1:47 PM 6 comments