IE8 not recognized in ASP.Net 1.1 applications

As always, I install the latest versions of anything when they become available (sometimes even betas). So did I for Internet Explorer 8.0 when it was released... And all of a sudden, my trusty applications made with ASP.Net 1.1 went berzerk. Things that used to work with IE7 and Firefox simply stopped working. This included external components we bought, like the ComponentArt suite. NavBars could not be clicked, drop-down menus behaved in strange ways, and so on.

I dug a bit and found the problem. My browser was not detected as it should. The
"Request.Browser.Browser" command returned "Unknown" instead of the expected "IE". But why?

I remarked that on my Vista x64 machine, the 32 bits browser would have these issues, but not the 64 bits version of IE. I compared the "User-Agent" HTTP header and saw these values:

32 bits:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; WOW64; Trident/4.0; GTB6; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; InfoPath.2; .NET CLR 1.1.4322; .NET CLR 3.5.21022; .NET CLR 3.5.30729; .NET CLR 3.0.30618; FDM; OfficeLiveConnector.1.3; OfficeLivePatch.0.0)

64 bits:
Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Win64; x64; Trident/4.0; .NET CLR 2.0.50727; SLCC1; Media Center PC 5.0; .NET CLR 3.5.30729)

I checked the browscap.ini and machine.config files on the server, but couldn't change them in any useful way.

Could the difference in length be the problem? In a Microsoft article on TechNet (http://technet.microsoft.com/en-us/library/bb496341.aspx) they say that the length of this header should remain shorter than 200 characters. In the first case, it is definitely longer...

So I dug further, looking for ways to shorten that User-Agent string. Many articles and blog talked about the following key to change in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post Platform

I did this, but only the User-Agent of the 64 bits instance of IE seemed to care. I searched through the registry for the "OfficeLivePatch" key I can only see in the 32 bits instance, and found it it the following key:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Post Platform

As you can see, there is "Wow6432Node" in there, which corresponds to 32 bits applications running on a 64 bits OS. Exactly my case ;-)

I renamed the "Post Platform" key into "Post Platform-" and restarted the browser and... bingo :-) The browser is detected as IE 8.0 and everything works fine...

Now I need to find out why, when I open a new tab or a new instance of IE 8, the content is not loaded, as it continuously shows "Connecting...". I need to open one or more tabs before a connection can be made. It also happens when opening popup windows, which is even more annoying (in that case, I need to reopen the popup with Ctrl-N until it works).

To be continued...

Installation of SQL Server 2005 x64 / Windows 2003 in cluster on HP ProLiant DL380 G5 servers

We recently had to install a brand new 2-node cluster made of HP ProLiant DL380 G5 (2 x Intel Xeon X5450 3.0 GHz QuadCore + 8 GB RAM). As there are many things to keep in mind before going for the installation (and a few problems too), I made a quick summary of things to remember in case I have to do it again some day (and can be helpful to you reader of this post).

• Configure the basis of the cluster. SQL will need 2 important things: an MS DTC resource (don't forget to enable the network DTC access in Windows Components/Application Server, cfr. screenshot) and a resource group with the drive(s) you'll want to use with SQL. You don't need to create IP addresses and names, SQL will create them during the installation.
  


• Configure security options of DTC, in Administrative Tools / Component Services. This is done on the cluster node having the DTC resource at the moment. In 'My Computer', select the 'MSDTC' tab and click on 'Security Configuration'. In the dialog box that appears, tick all option boxes.
  


• Care should be taken when configuring the network card used for intra-cluster communication. An MSDN article explains everything clearly: http://support.microsoft.com/kb/258750. Additional steps, suggested by Microsoft Support, include changing the priority of the cards so that the card used between the cluster nodes has a higher priority than the one connected to the network.
  

So far, this would be sufficient on a typical Windows Server 2003 . In our case, an additional hurdle was present, due to the specific NIC present in our machines, the NC373i. For no apparent reason, the setup would crash with the plain "There was an unexpected failure during the setup wizard. You may review the setup logs and/or click the help button for more information". And sometimes, just crash silently, leaving a MiniDump I can't make anything with behind... The only helpful message in the log files was:

Failed to find property "ComputerList" {"SqlComputers", "", ""} in cache
Source File Name: datastore\clusterinfocollector.cpp
Compiler Timestamp: Fri Sep 16 13:20:12 2005
Function Name: ClusterInfoCollector::collectProperty
Source Line Number: 182

Microsoft Support helped me on this one, and led me into the source of the problem: the advanced features of Windows 2003 SP2, the Scalable Networking Pack. Used with compatible hardware (like our NC373i NIC), it can increase networking performance greatly. But in the present case, it can cause some clustering features to stop working. MS issued a patch to disable these features (accessible here: KB 948496), but this was not enough.

To disable these options at the NIC level, you need to use the HP Networking Configuration Utility (cfr. screenshot below), and disable all options with 'offload' at the end of their name. I had also disabled RSS (Receive-Size Scaling) as per MS Support recommandations, but I see that after several updates and subsequent reboots, the option has magically been reenabled, but without negative effects. I left it activated. I only changed these settings on the private (for intra-cluster communications) card, the card connected to the network was left alone.

We have lost around 4 weeks with this issue, not knowing where to look. We hope this post will make you lose less time on this problem ;-)

Update: when we finally got a scheduled maintenance day, we launched the setup to install the new cluster in production, and guess what, same error!! Something happend since then... But it is certainly related to the TCP Offload Engine and Receive Side Scaling stuff, so I Googled a bit and found this article: http://forums12.itrc.hp.com/service/forums/bizsupport/questionanswer.do?admit=109447627+1209987026791+28353475&threadId=1153566

What worked for us this time is: reset everything to default in the HP Network Configuration Utility (even TOE and RSS), but disable these features using the NETSH command:

Netsh int ip set chimney DISABLED

After a reboot, setup performed its duty as expected. What a mess...