“You are making my point!”

If you want to expose SAP data to your SharePoint portal, here is a new tool that you should consider adding to your weaponry: BizTalk Server WCF-based SAP Adapter. Check out my MSDN article on this subject. BizTalk Adapter Pack: Connecting LOB Systems (SAP) and Microsoft Office SharePoint Server.

I was working on some BizTalk/SharePoint integration demo today when I discovered a bizarre bug in SharePoint. In your SharePoint server URL, if your server name carries underscore (”_”), yes underscore, your form services InfoPath form will not render! It will says some gibberish like “Session cookies must be enabled in your browser.”

Fortunately you don’t have to rename your computer (or in my case my VPC) to work around this problem. (I shudder at the thoughts of renaming my VPC and all the problems it might create to my other applications and servers). In SharePoint Central Administration site, in the Operations tab, there is a link named Alternate Access Mappings. All you have to do is to create a default public URL using a server name without the underscore sign. Of course you’d also have to go to your network administrator and ask for a new DNS entry of this new server name to map to this IP address. But it sure beats the hell out of renaming the computer. And in my case since I am doing all my demos on the VPC I didn’t even have to do that. I simply create a map to “localhost”. Problem solved.

I wonder if this bug is fixed in the SP1 of MOSS.

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.