“You are making my point!”

I was trying to install SharePoint Designer 2007 as well as Expression Web on my Vista Business today, and I kept getting the following error when I launch the setup.exe.

“Setup is unable to proceed due to the following error(s): The 2007 Microsoft Office system does not support upgrading from a prerelease version of the 2007 Microsoft Office system. You must first uninstall any prerelease versions of the 2007 Microsoft Office system products and associates technologies.”

Well, I definitely don’t remember installing any Office 2007 beta product, and I already have the full suite of Office 2007 final release installed, and it didn’t complain when I installed them. So what is happening? A quick search on the Microsoft site revealed that the Office 2003 Web Components might be the problem. So I went into the control panel and removed it, but the installation program still complained with the same error.

Finally, I found Scott Hanselman’s blog on this very same issue. As he suggests, I download the “must-install tool” MyUnInstaller, and lo and behold, there is the “Save as PDF for Office 2007 beta” entry listed in MyUninstaller list. Now I remember installing this handy little tool after I found PDFCreator is not available for Vista. I also installed the final release of this plug-in, but I must have forgot to remove the beta version of it. And for whatever reason, it never showed up in the Control Panel Uninstall Program list. After I uninstall it, my SharePoint Designer and Expression Web all install properly.

After a few frustrating hours of searching and experimenting, I have come to the conclusion that the Business Scorecard Manager Server cannot be installed on a 64-bit Windows 2003 server running 64-bit MOSS. Let me explain.

We have a pair of network load balanced 64-bit Windows 2003 Servers running as the Web front-end server components for a 64-bit MOSS deployment. We also want to install BSM Server on these servers, serving up scorecards for BSM web part in MOSS to consume. Mauro Cardarelli has a very good post on installing BSM sp1 on MOSS. But I guess it is dealing with 32-bit system since there is no mentioning on the IIS mode which I will explain.

It turns out that BSM is compiled on .NET 1.1, so it depends on a 1.1 runtime to function. However, there is no 64-bit support for 1.1 runtime. In fact, the 64-bit Windows Server 2003 does NOT even come with .NET 1.1 Framework installed. You can download the 32-bit .NET 1.1 Framework Redistributable to install on the server. During the installation, it prompts you to turn on a registry key to run IIS on 32-bit mode by running the following command.

cscript %SYSTEMDRIVE%\inetpub\adminscripts\adsutil.vbs SET W3SVC/AppPools/Enable32bitAppOnWin64 1

As soon as I do this though, the 64-bit MOSS stops working. This is because according to Microsoft, IIS on a 64-bit Windows Server can either run on 64-bit mode or 32-bit mode, but not both. This basically means 64-bit MOSS and Scorecard Manager Server cannot co-exist on a 64-bit Server, short of running two IIS instances, which I haven’t seen anyone be able to do that. Bugger!

So what are the alternatives? Well, here is what I come up with:

1. Run BSM on a separate 32-bit server. In our case, we would have to set up two servers just for BSM since we are trying to create a fault-tolerant environment using NLB. A single BSM server will become a single point of failure. However, dedicating two web servers just for BSM seems very excessive.
2. Use the new MOSS KPI list feature to replace the BSM web part. This can display some simple KPIs (manual KPIs or driven from SSAS), but it seems to lack the drill down functions BSM offers.
3. Wait for the next release of BSM – PerformancePoint Server.

Lately I have been working on an enterprise-level MOSS deployment. One of the questions pop up during the site structure architecture design is how to structure the department sites. Should I create one site collection as the “mother of all sites”, then create sub sites for each department, or should I create individual site collections for each department?

Functionality-wise, the site collection is not much different from a sub site. Here are some of the issues to consider.

1. Backup and restore. Essentially, you can only back or restore a site collection; but you can’t backup or restore a sub site. This might make a lot of difference depending on the size of the department site you anticipate. Joel Oleson has an excellent post on the MOSS site collection sizing issue. It gives you some idea as to how long it typically takes to backup and restore a site collection. For a 15GB site collection, a stsadm backup will run under an hour, a stsadm restore takes about an hour, and a stsadm delete takes about 19 minutes. If you go with sub site approach, you have to live with the fact that if one of your departmental sites needs a backup/restore, you have to backup/restore the whole site collection. The important decision criterion here is obviously whether or not you can afford that down time.
2. Navigation. The benefit of creating sub site instead of site collections for department is that the site navigation you create for the root site collection is automatically propagated through all sub sites, whereas departmental site collection will NOT inherit the navigation links. There is no list automatically created for site collections from the default site collection, which means you have to manually create links from your root site collection to link to your departmental site collections. Further more, there is no “Home” link automatically created from your departmental site collection back to the root site collection. You have to manually add them and maintain them. That is not to say it cannot be done with some automation through API, but it is one more thing you need to worry about.
3. Share WSS elements such as Content Type, Workflow, Security Group, Feature Set, Search Scope etc… It is easy to share them across sub sites within the same site collection. But it is much harder if not impossible to do that across site collections.

In the end, I decided on choosing sub sites instead of site collections for departments, simply because the ease of maintenance and feature deployment outweighs the restore and backup requirements. The environment also calls for a more centralized management as opposed to delegate the tasks to departmental administrators. Microsoft also has a good article discussing this issue.

Recently I have been working on a fairly large MOSS deployment for a large financial firm in Boston. They have great needs in integrating SQL Server 2005 Reporting Services Reports with MOSS. Microsoft released a Reporting Services Add-in for Microsoft SharePoint Technology for this purpose. However, getting it to install properly isn’t exactly a cake walk. Liam Cleary has a 3-part post details the installation steps.

Post #1: Installation

Post #2: Configuration

Post #3: Report Builder

This helped a lot. However, you still need to be careful. When deploying reports from Visual Studio, you need to setup the targets for both the data source and the report. These should be two separate SharePoint document libraries. This way, you can control the permission to the data sources and the permission to the actual reports independently. It is a good practice for an organization to have much tighter control over the data sources than the reports themselves, especially given the fact that the data sources are usually shared among many reports, and they themselves carry credentials used to access the databases.

One more thing to note is that after the Add-in is installed, the Report Viewer Web Part is not deployed. You have to manually enable it through Web Part Gallery before you can create Report Viewer Web Parts on your WSS portal page.

I was watching Ted Pattison’s MOSS screen casts. And I discovered that you can actually blog directly out of Word 2007. So here it is, my first Word 2007 Blog!

Basically, you create a new document from Word 2007 by going to Start (the big Office icon) àNew, and select “New blog post” option, and hit the “Create” button. If this is the first time you use Word blog function, it will prompt you for setting up your blog account. It supports Windows Live Space, Blogger, MOSS, Community Server, TypePad and WordPress out of the box. And I am sure you can customize for more options if you don’t find yours in there. The rest should be fairly straightforward. This is exact the functionality w.bloggar gives you. But now it is integrated in Word, and it just feels very natural.