Adding Metadata to a MOSS 2007 Publishing Portal

I found a way of adding MetaData to each page within a public facing website. There are still discussions on whether it is of any value, as some search engines don't always read it, to change the description and keywords.

In the Content Type(s) that the pages use add three fields - one for page title that will appear in the browser and will not affect the title used for the .aspx and in menus, one for the description as for some reason the description added when the page is created is not used (though I don't know it is crawled and returned in search results) and keywords.

I didn't add these fields to the page layout as there are lots of pages for our Marketing department, who own the content, to redo.

I'll post up the rest of the code tomorrow as I don't have the code at home.

Deployment of Reusable Content pt2

It has been confirmed that the issue with versioning of automatically updateable reusable content within content deployment is a 'known issue' and will be addressed as either a hotfix or within the next service pack.

Publication End Date displayed

I've just had a request from our tester that the PublishingConsole.ascx control display the publication end date. Looking at the code, I thought no problem, as the publication start date, version and status are displayed, the end date must be exposed as well! Quick trip into MSDN to see the properties of the Microsoft.SharePoint.Publishing.WebControls to see the name guessing that it would be something similar the the PagePublishDateIndicator or the PublishingPageVersionIndicator and, you've guessed it, the end date is not exposed as an indicator.

http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.publishing.webcontrols.aspx

More Deployment Issues

Having struggled with this for what seems like an eternity - and has since resulted in the project being put back by some considerable margin - it was reading through some more blogs that I came across what seemed to be the solution to the Masterpage problem (see previous posts).

By developing a feature that will create a site based upon a specific Masterpage and have it deploy correctly, the feature creation was OK and seemed to work but the associated contentTypes I could get to be created at the same time. After a lot of time yesterday the feature installed, but only at a site level because if the scope is changed to 'Farm' or 'Web' it would not install. So with this in mind I copied the relevant files to the WFE and installed/activated the feature. Created a new site on the backend as it was created as required and then ran the deployment - guess what the Masterpage was reset again!!!!

This has gone beyond a joke and I would recommend anyone thinking about going down the customization and deployment routes to seriously consider the time and resources required.

We will be raising this issue with our Gold Supplier and get them to raise a ticket with MS.

Cross Farm Deployment pt 3

We've got our base sites ready and the deployment process completed. The next step is to get our UAT and system testing complete. These tests were the ones that threw up the problems we had with recursive workflows and inherited permissions on lists.

If all goes well then we should be ready for the end of the week to go live - thankfully someone else is looking at the URL and Host Header mapping and DNS changes required.

Cross Farm Deployment pt 1

I haven't posted in a while because I have been stuck in the 'hell' that is content deployment in MOSS 2007.

We've a 3 tier environment - one for development, one for staging and one for live. As these environments were not all available at the time of initial construction it has been a pain to get the deployment working. I think I have described the topology that we have but I'll quickly run through it again. In dev we have 2 x virtual MOSS boxes, in staging we have 1 x MOSS box and SQL in the domain and 1 x WFE in the DMZ, in live we have 1 x MOSS box , 1 x SQL cluster in the domain and 2 x WFE in the DMZ with a Domain Controller.

The initial pain was to get all the boxes talking to each other through the relevant ports - this is where if you have a third party running your firewalls you'll need them on call to create the relevant rules for the traffic(port 80, 433, 1433 etc). Once this was done it was the tedious process of getting each of the boxes into the relevant farm and get the services running - so far so good.

Once this was done the deployment process was started from between the development servers. If you running these as virtual machines ensure that the SQL box is a physical box as the processes will grind to a halt/very slow with the disc read/write operations in the virtual environment. This is where we are at the moment - the deployment has been proven between all the boxes as necessary.

We have a publishing site which has been heavily customized and needs to be deployed between the two development boxes and it has failed a number of times. It appears that the customization of the base pages etc is causing an issue. I'll write some more later in the week.

MOSS 2007 Internet Development

We've got a deployment going on here that has the WFE's in a DMZ and an application server and SQL server on the LAN.

The installation of MOSS is fine on the LAN as you get authentication from the Domain Controllers - when you add the WFE in the DMZ you don't!! A trust relationship has to exist between the DMZ and the LAN - OK so far but if you have more than 1 WFE in the DMZ you can't run PSConfig to use SQL authentication. So our solution is to have a Domain Controller in the DMZ and establish trust back to the LAN, use Port 1433 for SQL and Port 80 as per normal and use content publishing between the application server (where users will edit content) and the DB's that the WFE's are pointing to.