Thomas F. Abraham – On Technology

A co-worker asked me today about an issue in a Web app in which pages display correctly in IE 6.0 but incorrectly in IE 5.5.  He could duplicate the problem in IE 6.0 by changing the page’s <DOCTYPE> tag.  Sometimes issues like this are due to rendering engine differences (or bugs) in various browsers.  However, I very often see developers test the code and functionality of their Web pages, but fail to test the HTML.

There are far too many Web pages out there that have broken and/or sloppy HTML.  I know, I know, you have a deadline to meet and as long as it works on your computer it’s fine, right?  Hopefully that’s not your attitude.  There’s an excellent, free tool from the W3C that can quickly and easily validate your HTML and give you a list of errors and issues.  You can quickly jump to the trouble spots and make corrections.

The W3C (World Wide Web Consortium)’s free Markup Validation Service can validate HTML, XHTML, MathML, SMIL and SVG documents, and it is still being tweaked and improved.  I highly encourage you to add it to your Web development toolkit.

Helpful hint du jour — if you know what’s good for you, don’t change the service account of your master BizTalk 2004/06 Enterprise Single Sign On service.  If you insist on doing so, make SURE you have backed up your master secret first!  As you may know, BizTalk Server 2004/06 stores much of its own configuration in the encrypted SSO database.  If you change the service account, or even, I believe, its password, the service modifies the SSO database and will render your entire BizTalk group useless.  Supposedly, after you change the account you can restore the master secret from your backup to fix the destruction, but I think it depends how lucky you feel.  Go make sure your service account is set to “password never expires!”

One of my clients made this mistake, but thankfully the BTS group was not yet in production!

This Thursday is the latest Twin Cities BizTalk User Group meeting at Microsoft Bloomington at 6:30 PM.  Please join us!

Updated 08-28-2006

I suspect that Enterprise SSO uses DPAPI or the broader CryptoAPI for data encryption, and also probably to encrypt the master key itself in the service account user profile.  This explains why changing the service account causes the service to be unable to read the database.  The master key remains with the original user profile and does not exist in the new one.  I do not think that changing the service account password will have any effect, as long as you remember to update the password in the SSO service configuration.

The solution, as I originally mentioned, is to restore the master key while the service is running under the new service account.  This has the effect of copying the master key from the original service account user profile to the new user profile.

If you changed the service account and did not have a backup of the master key, you might have a chance of saving your configuration by switching back to the original account.  If that doesn’t work, you will have no choice but to completely reconfigure your BizTalk installation.

Here is a Microsoft KB describing the procedure to change the SSO service account.  This process works in 2004 or 2006.  The difference in 2006 is that you may choose to backup and restore the master key through the SSO Administration MMC snap-in (requires MMC 3.0).

Updated 1/20/2006

I hope you’re not still using the Microsoft Data Access Block and sibling Blocks in your code.  If you are, I hope you have a good excuse!  Microsoft released Enterprise Library for .NET 1.1 about a year ago to replace the old Blocks.  It was co-developed by Microsoft and Avanade, and Avanade still carries on a proprietary enhanced version called ACA.NET.  The former Blocks that were incorporated into Enterprise Library gained a more unified programming and extensibility model, improved documentation and samples and an extensible GUI configuration tool.  We used Enterprise Library throughout most of 2005 on a large WinForms app, and it worked great.  I recommend it to every .NET development team.

Since then, I’ve moved on to Visual Studio 2005 like many of you, and we’ve all been (patiently?) waiting for Microsoft patterns & practices to rework Enterprise Library for .NET 2.0.  A couple deadlines passed with no code, but it’s finally here.  You really owe it to yourself and your dev team to check out the excellent work being provided by the patterns & practices team.

With Microsoft buying up companies and not always merging them into the Microsoft brand, it’s easy to miss some great Microsoft services.  In November 2005, Microsoft purchased FolderShare, a service for synchronizing and sharing files across multiple devices.  FolderShare was a subscription service, but no more — Microsoft made it free.

FolderShare seems like a terrific service.  No more ZIPping and emailing large files!  No more burning CDs and then tossing them!  Forgot your USB key?  No problem.  FolderShare lets you share files up to 2 GB in size, and at least for now, there are no limits on quantity or size of files transferred.  Hard to believe it’s really free.  Maybe Microsoft will eventually make it a Windows Live subscription service.  Until then, enjoy!

For those of you thinking about upgrading a Visual Studio.NET 2003 ASP.NET 1.1 Web project to Visual Studio 2005 and ASP.NET 2.0, Microsoft recently released an updated version of the Visual Studio 2005/Visual Web Developer 2005 Web Project Conversion Wizard.  This is newer than the version included in the Oct/Nov 2005 RTM build!

Microsoft released SharePoint Portal Server 2003 Service Pack 2 (SP2) in October 2005, following the weeks-earlier release of Windows SharePoint Services Service Pack 2 (SP2).  I was hoping to get .NET Framework 2.0 installed on our SPS Web server for other purposes, so I was hoping that Microsoft addressed the .NET Framework 2.0 incompatibilities with SP2.  It looked promising because WSS SP2 specifically mentioned ASP.NET 2.0 support.

After reviewing the release notes and backing up the portals and sites with the SharePoint Portal Server Data Backup and Restore tool, I installed WSS SP2.  It installed cleanly with no issues, so I was off to a good start.

Next was the SPS SP2 install.  Microsoft’s Office team has produced a lot of complicated service packs in the past.  They should know how to do it right.  Clearly this is a different team, because the folks that signed off on QA and user experience for this one deserve to be fired.  Running this service pack produces the familiar Windows Installer progress dialog, which runs for a while and then disappears.  There is no confirmation when it finishes — no matter whether it succeeds, fails, or falls somewhere in between.

It turns out there are two phases to the SPS 2003 SP2 installer.  The first phase upgrades SharePoint Portal Server’s program installation with SP2 files.  The second phase goes through each of your portal sites and attempts a database upgrade on each one.  This is where my four hour struggle began.

The only way you can tell if your SP2 install succeeded, or to what degree, is to read the event log.  You MUST do this.  Search the Application event log for an event that contains text similar to this:

Attempted to apply update to SharePoint Portal Server 2003 portal sites.
Number of portal sites: value
Number of portal sites attempted: value
Number of portal sites successfully updated: value
Not run: value

In my case, this is what I found:

Attempted to apply update to SharePoint Portal Server 2003 portal sites.
Number of portal sites: 1
Number of portal sites attempted: 1
Number of portal sites successfully updated: 0
Not run: 0
Consult the ReadMe file included with this patch, or *_spsadmin.log for more details.

Once again, looking for this “successfully updated” mismatch with “attempted” in the Event Log is the only way you will know the result of your SP2 install.

Next stop was \Program Files\SharePoint Portal Server\Logs, where I found logs that contained the same text and some unhelpful .NET exceptions.  In order to make SPS retry the database upgrade, you have to edit the registry.  [WHAT?!?  Yes, it's true.]  Here’s a KB article that describes the registry modification.  I probably made this change 30 times over the next 3-4 hours.

I eventually found an obscure WSS/SPS KB article or two (unrelated to SP2) while grasping at straws, ended up restoring my sites and portal from the backup, and eventually managed to get it to upgrade the database successfully.  It was not a pleasant experience.  After all that work, it looks like SP2 may have added or modified one app.exe.config file for Framework 2.0 compatibility.  It’s possible that there were other changes, but SPS portals remain incompatible with ASP.NET 2.0.  Do not run your portal sites under ASP.NET 2.0 (I tried for a while).

Please do not skip your backups before these upgrades, and be ready for possible troubles.