I'm finally getting ready to install my new Server and after some back and forth and testing on Windows 2008 I decided to go ahead and bite the bullet and go with the 64 bit version of Server. I've had mixed feelings about installing 64 bit given that I have had exactly zero experience running under 64 bit. I've not really seen a compelling reason on the desktop to run a 64 bit OS especially given the many reports of hardware and software incompatibilities.

So, I got my Dell T300 server last week. It's a Xeon quad 2.5ghz, 4 gig, 2 250gig drives. The machine is sweet and screams, but I didn't realize what a freaking beast it would be. It's insanely huge and weighs nearly 50 pounds (no shit - the package weighed 58 pounds!). It's a full size box and looking inside it uses that space - the cooling tower is as high as the full height of the case, with 6 fans and wind tunnels to route air that make the thing sound like jet when starting up and testing all the fans at once. Entertaining - good thing it's going into a server room and not into an office <s>... In retrospect it might have been smarter to buy a rack server box, but prices for a similarly configured machine are nearly triple.

When the box arrived I was still on the fence whether to install 32 bit or 64 bit Server 2008. I still have a host of 32 bit server apps and so I've been reluctant to go 64 bit. But  Microsoft's been saying all along that this version of server will be the last 32 bit version and most of the server products are going to be 64 bit probably before the next version of the server OS. Time to get familiar with 64 bit it seems.

So I installed the 64 bit version right away to 'play' with my existing server apps to see how they'd fare on a 64 bit box. The initial verdict was - no problems and a few pleasant surprises - at least so far (Murphy will come a knocking I'm sure). Today the final pieces of extra hardware (more memory and a 10k boot drive) arrived and now I'm knee deep in reinstalling the box from scratch for the live machine.

Here are a few thoughts and comments that might be interesting to some of you as well.

Memory usage in 64 Bit

Since I started the install with 64 bit I figure I need more memory for the server. Currently there are 4 gigs loaded and it looks pretty comfortable but with memory as cheap as it is it's a good idea to fill 'er up.

One thing that I had thought - maybe naively - is that with 64 bit applications memory usage would nearly double overall memory consumption. While 64 bit definitely uses more memory it's not anywhere near double the memory size. 64 bit's big draw is being able to address scads more memory, and so pointers to memory take up more space. What I didn't catch immediately is that actual memory used for data does not use any more space since it's just binary data represented the same way it's always been. So while there's definintely an increase in memory usage it's nothing near double. In real terms it looks like typical applications run with roughly 25-35% more memory than their 32 bit counterparts. But hey, memory is cheap.

Although not as cheap as I'd hoped for this server. The T300 requires 'registered' memory - apparently there's some sort of marker int the chips to identify them and if not present the chips won't be recognized. I actually bought just 4 more gig run of the mill PC2 5300 modules from Kingston (for $70!) only to find that those actually won't work in the server. Grrr. Nice racket to wring out some extra cash for vendors and chip makers. I ended up ordering more properly 'registered' memory from Kingston for $215 which is still not bad. Bottom line: if you have servers check that memory will work before just plunking just anything in the box. Even at 200 odd dollars memory is still a bargain and there's room for lots more - room to grow.

32 Bit Mode for Application Pools in IIS 7 - Yeah!

My biggest original concern against installing a 64 bit version of Windows Server is that I have a number of older COM and ISAPI based applications running on my site. In IIS 5/6 that would have been a fatal issue given that IIS 6 and 5 required that the Web server is switched into 32 bit mode entirely in order to run ANY 32 bit applications, like my ISAPI assembly.

It turns out IIS 7 makes this process much more granular with the ability to switch an IIS Application Pool into 32 Bit mode rather than the entire Web Server:

Cool that and that 'little detail' right there addressed my biggest concern about the old apps running on the 64 bit version of Server.

I hooked up this Application Pool in the original test builds of the OS I had created and ran a two day load test on the existing West Wind Web Connection sites and the apps chugged away at outrageous speed on this hardware mind you and without any hiccups. Looks like the 32 bit apps (West Wind Web Connection ISAPI + Visual FoxPro COM) will have no issues whatsoever on the 64 bit server.

The new quad processor is going to help these older apps tremendously too. There are a few rather slow requests that have been chugging up the CPU to near 100% levels at times for a handful of particularly long queries, but with the quad these queries will no longer hold the entire machine at ransom. Testing those particular scenarios resulted in smooth operations which solves yet another issue that has been the cause of occasional server lockups in the past.

ASP.NET apps can run just fine in 64 mode unless there are special circumstances (like the app is accessing some 32 bit inprocess COM components!) so none of this applies for typical ASP.NET apps, but it's a life saver for my 'other' apps.

[updated]

This process is indeed working out great with one exception: I had a few of these requests running COM object mapped to the root site. There are about 5 pages that use this old stuff and because I've set up the root site without 32 bit compatibility these request are now failing.

I can't change the root site to 32 bit tough because this would affect several other applications that are now running in integrated mode at the 'root' level. So switching to 32 bit mode is not an option.

My solution to this problem is to create a new script map to Classic ASP for these pages with .wst extension which is mapped normally to my custom ISAPI handler.

I then create an ASP page that does the following:

<%

  Response.Redirect("/wconnect/westwindnews.wst")

%>

The redirected URL is in another virtual that does have the 32 bit flag set and can also process this extension.

I realize this is pretty ugly but it works and solves an important link problem temporarily until I can re-write this page with ASP.NET code. Unfortunately IIS 7 seems to have lost (or at least I couldn't find it) the redirection option that can be set at the IIS level. Unfortately I can't find an equivalent option in IIS 7, so the above approach of using an ASP page and redirecting through it works well enough.

A few 64 Bit Application Gotchas

I did run into a few utility applications that failed to run under 64 Bit Windows Server. Systernals AutoRuns bonked a bunch of times when I originally ran it, although that magically cleared itself up (possibly after turning UAC off). One other small internal application (an old VB configuration app) also choked and died unceremoniously, but all minor issues.

I also ran into a problem with my own West Wind Web Monitor utility which is a .NET application. The app would start and immediately crash after startup with an error about side by side configuration. A look in the event log brings this:

It turns out this problem is related to a reference in the Assembly manfiest file (WebMonitor.exe.manifest) which includes a reference to the above DLL and so fails.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1"

          manifestVersion="1.0">

  <assemblyIdentity

    version="1.0.0.0" 

    name="Westwind.WebMonitor.WebMonitor"

    type="win32"

/>

  <description>West Wind West Wind Web Monitor</description>

  <dependency>

    <dependentAssembly>

      <assemblyIdentity

        type="win32"

        name="Microsoft.Windows.Common-Controls"

        version="6.0.0.0"

        publicKeyToken="6595b64144ccf1df"

        language="*"

    />

    </dependentAssembly>

  </dependency>

</assembly>

This is an old left over from the days when Application.EnableVisualStyles would crash apps frequently and using the assembly manifest would allow for Windows Theming without this Application call. Removing the .manifest file made the app run both as a desktop app and as a Windows Service. Alternately removingjust the reference to the above assembly worked.

One odd thing about this though: The error occurs only when running running West Wind Web Monitor out of the x86 (32 bit) Program Files path. When running from 64 bit (just plain Program Files) path (more on that below) the manifest file is not a problem.

Which made me go back to my installer (I use and love Tarma Installer) and changed the installation to create output into the 64 bit folder if available for the installation :

Now on 64 bit machines the app installs properly into Program files instead of Program Files (x86).

Running a .NET app as 64 bit

It is kind of cool to see your .NET app running as a 64 bit app, without having done anything special to work in 64 bit mode. It just works:

ASP.NET Applications - No Problem

The final big chunk of functionality that needs to work is of course ASP.NET applications. Since these apps are .NET 64 bit should be no problem and it looks like this is indeed the case. I'm half way through moving sites and getting them back up and running and they are all chugging along happily in 64 bit mode without any issues.

There's some setup I had to go through with this however, because I decided to move all apps to integrated mode in IIS 7. Integrated mode use the new integrated ASP.NET style IIS pipeline that natively runs managed code inside of the IIS engine itself which allows runnning managed modules and handlers directly from the server. This allows for lower level request interaction such as filtering ANY content - not just ASP.NET mapped extensions - through .NET based code modules at the Virtual Application level.

IIS 7 can still run in the same 'Classic' mode as IIS 6 did, but I figure it's a good idea to move apps consistently over to the integrated pipeline.

The biggest issue in this regard is that Web.Config requires a few small changes. Namely modules and handlers need to be moved into the <system.webServer> section.

<?xml version="1.0"?>

<configuration>

  <system.web>

... Remove these:
    <httpHandlers>

      <add verb="GET" path="wwBanner.ashx" type="Westwind.Web.Banners.BannerHandler, Westwind.Web.Controls" />

      <add verb="POST" path="MetaWebLogApi.ashx" type="Westwind.WebLog.MetaWebLogApi,WeblogFramework" />

    </httpHandlers>

    <httpModules>

      <add name="PostRedirector" type="Westwind.WebLog.PostRedirector,weblog" />

      <add name="wwScriptCompression" type="Westwind.Web.Controls.wwScriptCompressionModule,westwind.web.controls" />

    </httpModules>

...

  </system.web>





... Add here:

  <system.webServer>

    <validation validateIntegratedModeConfiguration="false" />

    <handlers>

      <add verb="GET" name="wwBanner" path="wwBanner.ashx" type="Westwind.Web.Banners.BannerHandler, Westwind.Web.Controls" />

      <add verb="POST" name="metaweblog" path="MetaWebLogApi.ashx" type="Westwind.WebLog.MetaWebLogApi,WeblogFramework" />

    </handlers>

    <modules>

      <add name="PostRedirector" type="Westwind.WebLog.PostRedirector,weblog" />

      <add name="wwScriptCompression" type="Westwind.Web.Controls.wwScriptCompressionModule,westwind.web.controls" />

    </modules>

  </system.webServer>

</configuration>

Basically IIS 7 doesn't like the <httpHandlers> and <httpModules> in system.web and they have to be moved to <system.webServer> instead. There are slight changes in the way the attributes are set so it's not just a plain copy. You can remove the old section or - if you need to support the app in multiple locations (say dev and live with one running IIS 5/6 the other IIS 7) you can use the validateIntegratedModeConfiguration attribute to disable the validation which allows the sections to exist in both places.

I'm doing this manually when I see failures on sites because I tend to want to apply the validateIntegratedModeConfiguration flag, but there's also an IIS utility that can migrate web.config for you automatically

%systemroot%\system32\inetsrv\APPCMD.EXE migrate config "West Wind Dev Site/wwstore"

where West Wind Dev site is the name of the site and wwstore is the virtual. You can find out more on this process here.

This is tedious as you might imagine regardless of whether you do it manually or with the utility because you have to find each app. I have somewhere around 80 virtuals on my site and remembering all of them is definitely time consuming. We'll see how much content will get fucked up here on the site once it goes live <g>...

SQL Server 2008

The final piece to install was SQL Server 2008 which showed up - very timely - on MSDN yesterday. The installation went surprisingly smooth. I say this because I had lots of issues with SQL 2005 installations in the past where the installer failed or failed to install vital pieces etc. SQL 2008's installation process feels much more streamlined and is loads faster than the interminable SQL 2005 install that used to take an hour or more. The setup and configuration console finally puts all the things you need to configure in one place instead of in obscure utilities that aren't linked or referenced anywhere. It also looks like SQL 2008 has connections open out of the box unlike SQL 2005 which had to explicitly enable external connections.

I haven't had much time to play with SQL 2008 yet - I just installed attached my existing databases of a few apps (more coming) and everything just worked. Performance is excellent (as mentioned earlier) but it's hard to tell whether there are improvements in SQL or whether it's merely the hardware. <g> SQL Management Studio looks mostly unchanged so it's not a 180 degree change again - everything's still where I'd remembered it being. One thing though I noticed that's really cool is that the Query editor now has Intellisense support built in and it's even pretty snappy.

One thing that is a problem though is that you need the SQL 2008 client tools to administer SQL 2008 - the 2005 tools do not work. Not surprising, but I didn't think of that. So I went to install SQL 2008 on my laptop as well and there is where I ran into problems. The install failed with .NET 3.5 SP1 failing to install. Looks like there's some conflict with some Visual Studio Hot fixes according to Microsoft. Scary - after screwing around with this last night for a couple of hours I had to give up. Word is that the Visual Studio 2000 SP1 installer will deal with the hotfixes properly and so - hopefully - this will work better. I'll have to wait until next week.

In the meantime I can only administer the SQL 2008 server via Remote Desktop...

But of course that issue has nothing to do with the server install. This is a client configuration issue on my end.

So far so good

So far things are looking very good for the new server. I'm pretty stoked and I wish I could get this thing online as soon as possible. All the things I was potentially worried about running under 64 bit are running without any issues which is a relief. However, I'm not even close to done. So far I've only installed the core applications - the bread and butter apps that keep the business running. All the little sample apps and obscure little places where code is running are probably what's going to take most of the time to configure. There are also 4 more sites (which are really just single apps) to configure. Ugh, it's going to be a long process. Still I hope to get the server online by early next week...

Wish me luck.