Sorry it's been so long
Well I know it's been a while, but I've been, ahem, busy...
Ok what's been happening that would be of interest in a techie blog about SharePoint and CMS...
Firstly I've finished a big MCMS project available at
www.anpost.ie. Architecture includes separate Authoring, Development, QA, and Production environments, been updated using scripting process I explained in a previous post, and search been provided by an excellent product in Mondosofts MondoSearch.
Well what more did I find out about MCMS, well it doesn't like been tied down security wise. The less said about this the better.
SharePoint, in my honest opinion, is far too expensive to use solely as your MCMS search mechanism, I think a better licensing programme should be available to expose this kind of functionality without paying way over the odds for it.
We found a somewhat major issue with MCMS SP2, in that you cannot rerun the DCA against another SQL server using SQL authentication. Known issue with a hotfix, but due to our tight deadlines we didn't have the luxury of waiting for the fix. Invloved us uninstalling SP2, rerun DCA and install SP2 again. Very annoying when we were moving images of QA servers(with hardenend security) into new Production environment.
Well thats a quick update for now, have some good stuff on SharePoint coming up soon that I'd like to share, stay tuned.
CMS deployment process from authoring to production...
Rcently I have been trying to finalise the deployment process from our CMS authoring environment to that of our shared production environment (which I talked about in a previous post).
The manual process (as I see it) consits of the following tasks:
Authoring Server
1. Do a "Get Latest" from Visual Source Safe, for the up-to-date CMS ASP.Net code base.
2. Build the Visual Studio .Net solution
3. Using the Site Deployment Wizard, Export the Channel, Resource Gallery and Template Gallery structures of the authoring environment into an SDO
4. Create a compressed folder of the ASP.Net code and SDO file
5. FTP the compressed folder to the production servers ftproot
Production Server
1. Export current live CMS content strucutre to a backup folder
2. Move current live CMS ASP.Net code base to a backup folder (apart from our web.config, because of local variable settings)
3. Decompress compressed folder in ftproot
4. Copy new CMS ASP.Net code base to home directory of live virtual directory.
5. Delete existing CMS Content structure in Site Manager.
6. Using the Site Deployment Wizard, Import the authoring servers SDO and CMS content into the production environment
7. Rename top level channel and resource gallery to that of your host header (i.e.
www.site1.com)
8. Regrant permissions to newly imported CMS content strucutre to existing Subscribers (i.e. annonymous users) rights group
Now in an ideal world, I would like for CMS to be able to automatically deploy both content and code base, between authoring and production environment, as soon as a new posting is created on the authoring server.
This isn't the case and as such (or is it?), scripts need to be generated and scheduled to accomplish same. How much can we automate?
Well if we take the authoring server first, steps 1 and 2, will be done manually anyway once the code base has been modified. Step 3 is possible either using .Net com interop or vbs/wsh scripts. The standard compressed folder functionality in Windows XP/2003 doesn't seem to be available from vbs/wsh via a windows API call. So with Step 4, we will need to use a command line compression utility like winzip, and call via a wsh shell command. Similarly with Step 5, a wsh shell command for "ftp -s scriptfile.txt" would work.
As vbs\wsh seems to be the common denominator, this would seem to be the best option, and to schedule it using NT Task scheduler.
Now onto the production server, step 1 as with the authoring server is possible in a few ways. Steps 2 and 4 are straight forward command line copies. Step 3 is again similar to the authoring server, in that a winzip command line will probably be best. Steps 5, 7 and 8 would be very straight forward if a web instance of the CMS CurrentHTTPContext was avaialable. But from a vbs/wsh, how would you do this? And finally Step 6 is possible in a couple of ways.
As you can see, the deployment process is not straight forward.
And my current questions include:
Apart from introducing massive licensing costs, does an automated process exist, to accomplish what I am describing, or is there a simple architecure change (say shared SQL) that would do it?
Can you call the publishing API from vsb/wsh, to rename channels, delete channels etc?
Is the standard Windows compressed folder functionality available from vbs/wsh or .Net?
Will the ftp wsh shell command work over a secure ftp connection?
Any CMS or WSH guru's out there? Anybodys thoughts on this would be greatly appreciated
MCMS Connector for SharePoint Technologies
What I originally thought and read about the MCMS connector for SharePoint technologies, wasn't actualy the same once I began to install and configure it....
To configure SharePoint and MCMS on the same box (which is the recommendation), involves a good few changes.
Why would you do this you may think (well I did), the reason is that if you want to use the document library placeholder for editing purposes, then SharePoint will need to be installed on your MCMS authoring server, otherwise if the placeholder will be read only (say for your MCMS production server).
But that's not all, you can only point the webparts at local MCMS content, and similarly you can only point the SharePoint Document Library placeholder control at a local SharePoint site. So to me, this throws away any chances of having an integrated server farm of SharePoint and MCMS servers, connected using the connector. I hope I'm wrong in my understanding here, anyone out there know?
Firstly, the order in which the server applications are installed is important. Obviously standard OS configuration first then, pre-requisites for MCMS, MCMS 2002 Sp1a, SharePoint 2003, any SharePoint 2003 sp's and finally the MCMS connector for SharePoint itself.
Next, there is a requirement for the Connector, that MCMS and SharePoint both use the same IIS application pool and identity. OK fine, but what about the forms based authentication and login I wrote for my authoring server. Turns out, you cannot use Forms based authentication if you have SharePoint and CMS on the same box, only windows. Damn...
Now you have to tell SharePoint that it has some standard ASP.Net applications within it's website to render. The MCMS connector will automatically add existing (at time of install) ASP.Net apps as excluded paths within SharePoint, which is useful. But you should consider this for any future apps you may have to create.
Now to your existing web applications, you will have change the trust level setting within their web.config's, to full, again so that SharePoint can render them as safe.
All these changes had to be made before I even began to use any of the funtionality the connector would give me.
More about the SharePoint Document Library placeholder control... I originally thought that, similar to the Word Authoring Connector Client, when you use this placeholder to "link" to an existing SharePoint document, that if this document is changed in the future, it maintains a reference to this "link" and prompts the user to update. This turns out not to be the case, what it actually does is make a copy of this document in MCMS, and you use a command line utility called "WssDocumentUpdater" to synchronise updates, which would be a scheduled process.
My current thinking is not to use the MCMS connector for SharePoint at all, and just use the Word Authoring Connector Client (with documents stored in SharePoint) to publish to MCMS.
That's next, an I'll update you all as to what happens.
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.
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.
Couldn't upload a 5MB file into the CMS Resource Gallery
Just yesterday, I was trying to upload a PDF document into our Resource Gallery of CMS2002 development instance. But IE kept throwing a Page Not Found error each time. Any PDF's under 5MB were fine, which made me think there must be a file size limit.
Sure enough there is, and to set your own, you need to modify your web.config (the one within your VS.Net Solution for your CMS site) to add the following tag and elements.
httpRuntime executionTimeout="3600" maxRequestLength="1024000" useFullyQualifiedRedirectUrl="false" minFreeThreads="8" minLocalRequestFreeThreads="4" appRequestQueueLimit="100"/
Which means the execution timeout will be 3600 seconds which is one hour, and the max file size to upload will be 51200KB which is 1/2GB.
If you don't have this xml tag already, add it just beneath the httpmodules tag...
WSS Search not working!!
As some of you may be aware, WSS (Windows SharePoint Services) and SPS2003 (SharePoint Portal Server) don't use the same indexing and search technology. WSS uses SQL based full-text searching and SPS uses the MSSearch service.
We had 2 similar issues (but will explain individually) with 2 separate WSS and SPS servers recently.
One of the servers is our development instance of SPS2003 and the other is our newly migrated production intranet SPS2003 server.
On the development server we noticed that when you search for content that would exist in a WSS site from the portal, the search would return the expected results, but when you use the Search from the WSS site itself, it would not return anything.
Resolution here was to rebuild the Full-Text Catalog that WSS creates in the PortalName_Site database. It is usually called ix_PortalName_Site.
On the production intranet server however, the portal returned no results from the WSS sites aswell as the WSS site search themselves. Upon closer inspection I noticed that there was no full-text catalog created in the PortalName_Site database. Worse still if I manually tried to create it, I got the following error:
So I found on the web a way to reinstall the Full-Text Catalog component on a SQL server, to do this I had to spoof the install into thinking that full-text catalog was not installed. How? Well all you do is locate the following key in the Registry:
{E07FDDA7-5A21-11d2-9DAD-00C04F79D434} which is in HKEY_LOCAL_MACHINE\SOFTWARE \MICROSOFT\MSSQLSERVER\Tracking
and rename or delete it (I renamed it with an X in front)
Then insert the SQL Server installation CD again and modify/add components to existing install. Select Full-Text Search as the component, and continue with the installation wizard.
Now we had an instance of Full-Text searching that we could create catalogs in without error.
I then let WSS create its own Full-Text Catalog. To do this, go to SharePoint Central Administration of your SPS portal and then select Windows SharePoint Services. Click on "Configure Full Text Search" and then disable the checkbox "Enable full-text search and index component" and click OK.
Then go back in and re-enable it, this will then go off and create the full-text catalog that should have been there in the first place.
Weird I know but true (make sure to reapply the SP3a after re-installing the full-text search component)
