LavaBlast Holiday Retreat First of all, let me wish you a Happy New Year!

Over the past couple weeks, we've been upgrading our server to a fresh install of Windows Server 2008 64-bit with more RAM and faster drives than our old Server 2003 32-bit. To make a long story short, this upgrade was much more painful than the one we did two years ago, which went flawlessly. I experienced so many pain points that, had I written them all down, you would have a 10 page blog post to read! I'll list a few things here that I remember off the top of my head (the main issues), hoping this will help some of you out there. 

IIS 6 32-bit to IIS 7 64-bit

  • Problem: Migrating the IIS configuration. Our metabase backups were of no use because we were upgrading IIS at the same time.
    • Solution: We used msdeploy to migrate our IIS.
    • Note: We didn't use msdeploy to migrate our files or databases, as we had already rsync'ed these over to the new server (~30 gigabytes).
  • Problem: Our application pools ended up being configured as 32-bit instead of 64-bit. Our sites wouldn't load.
  • Problem: Our applications pools ended up trying to use accounts from the old machine instead of the new one.
    • Solution: We changed these manually.
    • Note: Probably related to the same issue as above.
  • Problem: I had to install ASP.NET 1.1 for one of our customers. This and/or the previous tool ended up screwing up our IIS Handler mapping configuration. The applications were trying to use either the ASP.NET 1.1 or the 32-bit ASP.NET 2.0 dlls (can't remember which).
    • Solution: Not knowing of a better way, I ended up manually changing the defaults for the whole web server to (C:\Windows\Microsoft.NET\Framework64\v2.0.50727\aspnet_filter.dll) and using the "Revert to inherited" feature of IIS7 Manager for all our apps.
    • Note: I still don't know what the best practices are for installing ASP.NET 1.1 after a higher ASP.NET is installed, without breaking everything.
  • Problem: IIS7 screwed around with the formatting of my (dozens of) web.config files. We need to figure out what changed and bring these back into
  • Problem: Some web services that we use in our scripts were returning illegal protocol errors. We had to add the following code in our Web.config to re-enable GET and POST.
<webServices>    
    <protocols>        
        <add name="HttpGet"/>       
        <add name="HttpPost"/>    
    </protocols>
</webServices>

SQL Server 2005 32-bit to SQL Server 2008 64-bit

  • Problem: Reloading the databases on the new server via the command line.
  • Problem: ASP.NET could not access the imported databases.
    • Solution: We had to manually fix the security configuration for each database on the target machine so that ASP.NET could access it.
    • Note: I wonder if this is due to the way we are restoring our databases.
  • Problem: We had SQL Server Express installed. One of our demo applications used a connection string such as "Data Source=.\SQLEXPRESS;AttachDbFilename=|DataDirectory|\NORTHWND.MDF;Integrated Security=True;User Instance=True". The full-blown version of SQL Server doesn't support user instances.
    • Solution: We restored the database into SQL Server and are using it instead of the User Instance.
    • Note: I suppose you could also install the express version side-by-side if you wanted to.
  • Problem: We installed SQL Server Reporting Services (SSRS). By default, it binds to the ~/reports of all our websites, breaking a couple of our sites that were using the ~/reports subfolder. (It also binds to the ~/reportserver folder, but we weren't using that one).
    • Solution: We had to launch the SSRS manager to change the virtual directory that was used.
  • Problem: Some of our older applications used the SQLNCLI provider, but these now return "System.InvalidOperationException: The 'SQLNCLI' provider is not registered on the local machine.".
    • Solution: Installing the client (from the SQL Server 2008 DVD) only ends up creating a new provider "SQLNCLI10" that we can use in our connection strings instead of installing the older version.
    • Solution 2: We noticed that some code using SQLNCLI10 did not work properly. System.Data.OleDb.OleDbException: The fractional part of the provided time value overflows the scale of the corresponding SQL Server parameter or column. Increase bScale in DBPARAMBINDINFO or column scale to correct this error. We ended up changing providers, as this was too much of a pain.
  • Problem: We use automatic script generation in SQL Server Management Studio (SSMS). Tools ==> Options ==> Designers ==> Table and Database Designers ==> Auto Generate Change Scripts. However, the scripts that are now generated in our local SQL2k8 databases don't always work with the SQL2k5 databases we have deployed in the wild. We'd like the scripts to be compatible with both, so that we don't have to manually remove the problematic portions.
  • Problem: SQL Server 2005 cannot open our SQL Server 2008 backups, even if their compatibility mode appears to be 2005.
    • Solution: I don't know of a solution, do you? :)

Most of our other applications were transferred easily, except for TWiki which is always a pain to install on a Windows-based server. We still haven't resolved a CSS issue, but the tool now works! I hope this helps! Best of luck to you all in 2009! Feel free to comment about the problems you experienced during your recent migrations to these technologies.

kick it on DotNetKicks.com