Cannot compare two elements within an array

I had this error message appear whilst moving between our development and staging environments. I had created a backup of the site I wanted to move and copied it over to the staging environment. Created the sites, there were four host headed sites to be created on staging to replicate our production environment. On three of the sites the stsadm -o restore command worked fine and on the fourth it would not. So after much scratching around comparing features, using utilities such as WssAnalyzeFeatures and FaultyFeatures, there was nothing obvious or indeed showing up as an error.

So to resolve the issue I used the stsadm -o export, to get a cab file and used the stsadm -o import -versions 2 and everything was fine.

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.

Create a Custom Site Definition

I just came across this article by Eric Shupps on how to create a custom site definition. It looks as though it may help in the deployment issues where custom masterpages are not carried across to the WFE.

More Content Deployment Errors

Yesterday I created a deployment job, for our system tester, that deployed from one box to another within our domain. Everything worked fine but overnight it decided that our farm administrator account was not an administrator!

After rebooting the boxes it accepted the account but would not deploy, throwing the usual 'helpful' error messages into the log files and event logs. As it was the development environment I tore down the site on the WFE and recreated the job and ran it - guess what no luck. It seemed that my 'error' was to recreate the WFE site on the same port number, by changing this the deployment worked. This doesn't fill me with confidence for when we move to our staging environment and ultimately production. 

I'm guessing that with the issues with workflow and deployment have cost the project over 15 days to date. So I would suggest that in your project plan to add some extra days for these kind of gotchas.

So I'll end this post with a 'thank you' to the developers of the deployment and workflow process for all the helpful error messages that must be getting thrown but never caught!

User security information cannot be properly imported without setting UserInfoDateTime option to ImportAll.

After running a deployment the error message 'User security information cannot be properly imported without setting UserInfoDateTime option to ImportAll.' appears.

Despite setting the 'Security information in the deployment' to 'All' the message still appears, though the deployment still goes through. I've changed the setting to 'Role Definitions Only' and - guess what - it still appears. If the selection is reset to 'All' it is still there. The reason for resetting it was to check that it was actually being set, but from the tests it appears that the value is never actually passed.

Updating web.config with SafeControl entries

I've had to find a method for updating web.config with a SafeControl entry programmatically. Whilst searching I found this article by Mark Wagner http://www.crsw.com/mark/Lists/Posts/Post.aspx?ID=32

It updates all the web.config files for the farm web applications so I'll have to look at another method, maybe just use a straight forward Xml update.

We have a setup file that creates and adds features and also restores from a backup - this is so we have a clean installation for use. In some cases where features/solutions have already been added but this is a new site rather than rely on the creators to add the SafeControl entry I was looking at a way of doing it within the setup file.

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 2

The issue with the failure of the export/import was due to some pages that had been approved/published had a parent that had not been approved/published. So much for asking the rest of the team to ensure all content was ready for the deployment.

On another issue we have a number of custom groups that are used where we have broken inheritance on reuseable content and image libraries so that the end users cannot delete or edit these. When the deployment is run to the WFE these custom groups are not exported, the deployment runs but warns that groups could not be imported. No matter which options you select in the deployment process nothing happens. You will not notice this if the default groups are only used.

As a work round we have backed up and restored the site to the staging and production servers and users will edit content from there and the deployment will be to WFE's and anonymous access turned on so it will not matter. But it is a gotcha!

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.