Tuesday, 16 December 2008

WSS 3.0 vs MOSS 2007

The Microsoft WSS/MOSS product comparison table can be found here:


WSS doesn't include the features listed here:



Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com

Friday, 12 December 2008

Search 2 Launched on westernaustralia.com

It's been a busy week at Tourism! In addition to pushing out new web sites, my team has also been busy launching the next iteration of search on www.westernaustralia.com. Although wa.com is a MOSS-based web site, it uses a custom search system built in-house to meet an exacting set of requirements and keep half the planet happy. 

Search 2, as it's known internally, started out as a retrofit of the tours search sub system but quickly evolved into a full rewrite to make search faster, more accurate, and more configurable while introducing new features like spelling suggestions. 

Tourism WA has a paid membership model where tourism operators pay an annual fee to join the Tourism WA Network in return for a listing on westernaustralia.com. As a result, everyone wants to see their product listing on top of the pile when it comes to search results. We also have a lot of custom content on the web site: if you search for "Perth", the MOSS content page related to Perth is listed first; if you search for "hotel", you're probably after accommodation products but the display of the hotel listings in WA are randomised to ensure fairness. Trust me, these are some simple examples--what we end up with is a complex business logic that dictates how search results are weighted and ranked. 

The search implementation on wa.com has a long and sordid history. We started out using the in-built MOSS search and the BDC, crawling MOSS page content and tourism product stored in the Australian Tourism Data Warehouse. The BDC is a great tool for unifying disparate data sources but MOSS search simply didn't give us the configurability required to deliver on the business requirements. 

When panic set in, a Google search box was evaluated. While it did search, as you might expect, it only searched the Google way; it's still sitting in the server room, unused. As everyone fretted over the many problems we were facing, Rick, the developer working on search, went "underground" and built the RDC--or Rick's Data Catalog. The RDC would eventually replace the BDC and MOSS search in our little world. wa.com was launched with this solution, which is actually build on SQL Server Full Text indexing.

The RDC got us across the line after a never ending round of user acceptance testing but fell down in the tours category. It also abused some of the more horrific technologies from some of our older sites like XSLT and inline C#. It was also just a messy proof of concept at the code level and had some major design flaws. An example of the latter was a crawler that couldn't be scheduled and cleared the main index table before initiating the crawl; the problem with this approach was no search results would be returned while the crawler was run--apart from the manual administrator intervention required to actually kick it off and verify the results.

Search 2 is one of those engineering marvels you come across so rarely in the software world. The underlying design is fairly straightforward for what it does and it uses the chosen technology set appropriately--judiciously and as required. In other words, it's not over-engineered and gets on with the job in a logical, unobtrusive way. The grunty data work is relegated to the database where it belongs and the main UI is composed of configurable web parts. 

That's not to say Search 2 didn't take a while to build. Nico, one of most experienced team members when it comes to MOSS and search, has been hard at work on this project since April. UAT progressed over a month and deployment took three days! 

We're already building on top of the Search 2 fundamentals Nico has in place. An online booking engine has passed the proof of concept stages and a new itinerary planner should be out in the new year. Search 2 will also form the basis for a search re-release on the partner sites, which adds another few dimensions to the mix. Working with the Search 2 code base to integrate these components has almost been pleasurable. Either way, who can complain when all of the project stakeholders are happy?!  

Nico's off for a well-deserved Christmas break and I'm quietly confident we won't have any major bedding in problems during the four weeks he's away (unless the database server dies but that's another story). Meanwhile, Search 2 should be humming happily along--have a look for yourself!


Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com

Fourth Internet-Facing MOSS 2007 Site Launched!

I'm happy to announce we rolled out our latest MOSS 2007-based internet facing web site yesterday afternoon. The Australia's Coral Coast site is the latest (and greatest?) web site to re-launch on the Tourism WA partner site platform, as it's known internally, since June. The dev team did most of the hard development work earlier in the year and we've pretty much handed over to the service delivery and content management team; SDCM are now restructuring each site's information architecture and updating and SEO-ing the content as it's brough across from a corresponding, legacy MCMS site. Even though the dev effort is tapering off (we're still fixing bugs and tweaking), it's amazing to see these templated but distinct internet sites rolling off the line without a hitch.

This site is the last of the regional tourism organisation sites to be relaunched this year but we've got two more to go before this phase of the project wraps up and we move forward with the stack of visitor centre sites and campaign sites. Compare the new Coral Coast site with the MCMS-based Experience Perth site and let me know what you think.


Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com

Tuesday, 9 December 2008

No mapping between account names and security ids was done

Ran into a bit of stupid today--I doubt the details matter too much but I was attempting to install the Hyper-V MSU and the Hyper-V role in Windows Server 2008 when I came up against this message in both cases:

No mapping between account names and security ids was done

Naturally I told Windows I don't care and to sort itself out but it wouldn't listen.

I finally realised I'd renamed the Administrator account as I normally do but hadn't logged off or rebooted. I rebooted just to be safe and that fixed the problem.


Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com
 

Windows Server 2008 with Hyper-V vs VMWare Server

Back in March I wrote about my first experience with Windows Server 2008 RTM and the pre-release version of Hyper-V. Despite a fiddly installation issue with my locale set to Australia, I eventually got the problem sorted out and declared that I liked Hyper-V. Then I read Andrew Connell's post extolling the virtues of VMWare Server 2.0 and I abandoned Hyper-V to try it out (we run ESX at Tourism and I'd already noted the portability issues with a Hyper-V-based VM during my own trial). I didn't have a ton of joy with the 2.0 beta so stuck with v1.x while v2.0 RTMd--haven't tried it again since. 

I'm an Andrew Connell fan and when he mentioned he was switching back to Hyper-V I figured I'd revisit. The first real version of Hyper-V has now been released and I was curious to see whether the locale issue went away. AC also cited performance and since I had some gripes with the VMWare Server web interface I wanted to see how it would fare. 

The installation was painless today. Install W2k8 x64, install the MSU, install the Hyper-V role and hey presto. I'm currently installing a W2k8 x86 VM and haven't run into any problems with the VMM service not starting or anything else for that matter. My aim is to build out a base image of the OS, copy or snapshot it, and then go from there with a small farm MOSS build out for dev purposes. 

I'm also very curious to find out for myself how easily I can move VMs around and how far I can get with VPC 2007 VMs under Hyper-V... and maybe vice-versa if possible.


Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com

Wednesday, 3 December 2008

Christmas Came Early

We're in the throws of all sorts of things physcial here at Tourism WA. Apart from an office refit (no more trestle tables but the dev team is currently stuck in the training room with no windows), the ICT team are completely rebuilding our virtual environment.

So what does that mean? To start with, redundancy in terms of mirrored setups at head office and the data centre. Each environment is getting a rack full of new blades and some of these things shown in the picture--$170k worth of SAN or 10 usable terabytes of storage.

On the software side, we're going VMware ESX 3.5, Windows Server 2008 x64, SQL Server 2008 , MOSS 2007 x64, and .NET 3.5 SP1 (upgrading from Windows Server 2003 x86, SQL Server 2005, MOSS 2007 x86, and .NET 3.0). Should be interesting. 


Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com

Thursday, 13 November 2008

Fixing the IE7/MOSS/HTTP 413/Client SSL/View State White Screen of Death

Content on the Tourism WA partner sites like Australia's Golden Outback needs to be accessible by content editors over the internet. To facilitate this, we use client certificates over SSL to authenticate users. Each certificate is additionally mapped to an Active Directory account to support granular control over specific assets and provide standard "auditing" (in the MOSS version history sense) of user activity. Users additionally benefit from a single sign-on experience since IE hands off the client certificate in a relatively seamless manner.
In the image below the first box describes how client certifcates are created and provided to the content editors; the second box describes how IE and IIS authenticate the user to MOSS via AD.

This approach looks pretty nice on paper apart from the manual task of creating the client certificate and the potential distribution security. Our external content editor user base is fairly small and well-known, however.

Following the launch of the first partner site using this security model, we came across a painful situation I'll describe here but hope you never encounter in the field. If you have come across this problem, hopefully this post will steer you in the right direction. 

So the problem: 

When attempting to save, check in, or publish a page, IE content editors were presented with a white screen (a page with nothing in it, more specifically) in a relatively short timeframe. The problem appeared to be sporadic and definitely affect some pages but not others.

Inspecting the content editor's machine revealed no hardware or software issues and nothing was logged to the client's event logs. The HTML source was nothing special with the IE Dev Toolbar telling the same story:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=windows-1252"></HEAD>
<BODY></BODY></HTML>

Although some basic IE security and JS settings were tweaked, friendly error messages were already turned off. As our initial user base was regionally-based and we mistakenly believed we couldn't reproduce the problem on the local network, we initially ascribed the problem to a lousy, congested regional network connection. I say we mistakenly believed we couldn't reproduce the problem because we generally use the non-SSL-secured internal site at head office due to an unrelated issue. 

This wasn't a lot to go on and we struggled to diagnose the problem while waiting for the installation of a WAN accellerator upgrade to our own regional office to prove or disprove our theory about the network infrastructure. Meanwhile, our third partner site came online and the content editors logged the same issue; this time, those content editors were sitting in Perth on metropolitain ADSL 2+ wires.

With the installation of a broadband connection at home I decided to see what I could find out outside the corporate environment. I logged into to one of the secure sites and got lucky--I was finally able to reproduce the problem on one of every five or so attempts to save a rather large page. 

With that achievement under my hat I fired up my trusty friend Fiddler 2 and reloaded the site. As I mentioned above, the partner sites are delivered to content editors over an SSL-secured (443) connection; in other words, that means inspecting the HTML request/response data outside the browser would normally be a bit tricky. Luckily Fiddler 2 makes this easy--you simply need to check the Decrypt HTTPS traffic checkbox in the Fiddler settings (under Proxy Settings) and Fiddler will present you with the goods. 

In my case that was step one but step 2 meant I'd also have to hand over a valid client certificate since Fiddler essentially does the man in the middle thing to pull off the SSL decryption bit. Fiddler's documentation is pretty good on this subject so after exporting my existing certificate with a .cer extension I dropped it into My Documents\Fiddler2\ClientCertificate.cer (named exactly as shown). At long last I could not only reproduce the problem but I could even see under the covers of the HTTP protocol!

And it was that simple: hitting the same problem page a few times and Fiddler told me it was all about a lousy HTTP 413 error--all this for a bloody error code IE should have been showing me in the first place. 

Here's the request:

POST /en/ThisPageIsTroubba.aspx HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, application/x-shockwave-flash, application/x-silverlight, application/x-silverlight-2-b2, */*
Referer: https://edit.problemsite.com/en/ThisPageIsTroubba.aspx
Accept-Language: en-au,en-GB;q=0.5
Content-Type: application/x-www-form-urlencoded
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.2; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022)
Host: edit.problemsite.com
Content-Length: 71069
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: WSS_KeepSessionAuthenticated=443; MSOWebPartPage_AnonymousAccessCookie=443; s_cc=true; s_sq=%5B%5BB%5D%5D
 
HTTP/1.1 413 Request Entity Too Large
Content-Length: 0
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Sun, 02 Nov 2008 10:47:22 GMT
Connection: close

"What is an HTTP 413 error," I asked, just like you may be doing now? It means the server rejected the request because it considered it too big. Weird, considering the request was only just over 71KB but at least we could rule out the network--a good thing because a lot of our future content editors are very much regional.

The w3c tells us the following about HTTP 413:

"The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
 
If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again."

I mentioned page weight previously and the title of this posting also ties in viewstate. Why? I've already suggested the white screen problem seemed to affect some pages but not others. While investigating this problem, I noted the viewstate on most of the anonymous partner site pages is very low at a <2KB.

Still with me? 

We're currently running on Windows 2003 and IIS 6.0. When IIS has to deal with client certificates, the server uses the UploadReadAheadSize metabase property during the SSL preload process to determine the maximum buffer size for the incoming request. The default buffer size is 48KB to prevent denial of service attacks and for that reason Microsoft doesn't recommend setting it too high. In our case, the 71KB request was considered too large and IIS wouldn't let it through. Why the save/check-in/publish worked sporadically I can't say, but increasing the value assigned to this property instantly fixed the problem. We increased this setting on every relevant IIS web site using this command:

cscript adsutil.vbs set w3svc/1/uploadreadaheadsize 204800

Note the setting represents bytes, not kilobytes, and the TechNet article on changing this is incorrectly specifies a value of 200.

In theory the HTTP 413 should have come up in the server logs but if it did, we never caught it. 

For more information about the metabase changes, the following blog posts may be of use:

Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com

Great SQL Server Database Performance Article

Zach Nichter has written a very approachable article for TechNet Magazine on the subject of SQL Server performance measurement. It's brief and very much to the point, covering performance counters, profiling, and dynamic management views. It's by no means MOSS-specific but nonetheless applicable and the author obviously has a wealth of experience on this topic.

"Optimizing SQL Server CPU Performance"

http://technet.microsoft.com/en-us/magazine/cc137784.aspx


Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com

Tuesday, 11 November 2008

Firefox 3 Penetration

I was vaguely surprised when I checked our Omniture stats for the last three months: 58.6% of Firefox users visiting all of the eMarketplace sites over the last three months were using version 3. So it's official, we're now supporting IE6/7 and FF2.x/3 across the MOSS-based anonymous sites.


Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com

Stacking Windowed Elements and Flash Movies with z-index and wmode in IE

There exists a common misconception z-index will solve all of your DHTML stacking problems. While this is true for DHTML elements, the assumption falls down in the face of Internet Explorer and the way this browser treats "windowed" components like drop down lists based on the select tag. Flash objects aren't immune but for different reasons. Firefox will honour stacking orders for all elements but this is not the case when you're dealing with IE6/7. Windowed elements maintain a different stacking order than DHTML elements (they're added to a different plane than your windows elements) and therein lies the problem.

IE7 is better than IE6 when it comes to the select element but Flash requires some additional finessing, which I'll detail below. If you're still supporting IE6, consider using an IFrame (perhaps dynamically positioned) between your windowed component and your DHTML object to mask the underlying windowed component. The concept is generally referred to as an "IFrame shim". Don't forget, IFrames can be configured with a transparent background; either way, simply point the IFrame URL at nothing. The IFrame is no longer a windowed element as of IE5.5; although some people don't like IFrames for security and because they're frames, in this case the IFrame is your friend because it bridges the gap between windowed elements and windowless elements. The one main gotcha with this approach is how the user interacts with an IFrame: button clicks and mouse actions will be sent to the IFrame and the underlying content won't be interactive while the IFrame is visible.

Flash--being Flash and an ActiveX-wrapped plugin--is a different beast. IE places embedded content in a DHTML layer above all other layers by default and this is not always where you want your Flash content. On the westernaustralia.com home page, a fancy combination of DHTML and Flash elements known as the Tourism Australia overlay sits above the wa.com Flash banner (it's only visible to international site visitors); the DHTML-based navigation likewise has to sit above the central "experience panel" and the global site selector drop down in the right column.

To reign in your Flash objects and their stacking order you need to use an extra parameter named wmode:

&lt;param name="wmode" value="opaque" />

By doing so the Flash object and surrounding DHTML elements will team up to honour z-index styles as you intend. It's also a good idea to add a corresponding wmode="opaque" attribute to your element tag. Opaque and transparent modes may compromise your animations and video--we haven't had any problem on our sites, however, and use both animations (the wipe) and video. 

Here are a few additional tips for dealing with Flash:
  • Add Flash elements to a predefined placeholder element using JavaScript to ensure the object is activated automatically (otherwise users will have to click the Flash movie to run it and movies that should play automatically without user interaction may not start when the page loads). SWFObject will do this for you but it's really easy to write the JavaScript into your existing .js files, thereby avoiding the need to weigh down your page with yet another script library.
  • Don't rely solely on the embed tag. Use the object tag for IE and nest an embed tag within it for Mozilla and everyone else.
  • Always explicitly configure the wmode parameter as a child of the object tag and an attribute of the element tag.
  • Avoid the wmode "transparent" setting unless your Flash movie actually has transparent sections. Use "opaque" in most cases to increase rendering performance. The default is "window".
  • Consider a Flash alternative like Silverlight ;-)
Microsoft's windowless vs windowed summary:

Adobe's semi-useful KB article about wmode:

How to create an IFrame shim:


Custom-Built Microsoft Office SharePoint Server 2007 Branded Sites and Webpart Development - info@mediawole.com