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.
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.
Last night I had the pleasure to assist to the official opening of the new co-working space opened here in Joliette. The mayor of Joliette M. René Laurin was there to officially launch the project along with eighty people who were there to visit, drink wine, and exchange business cards. The new co-working space is located right on top of Librairie René Martin in downtown Joliette.
We want to encourage this kind of project because we think it encourage entrepreneurship here in Joliette. It enables small companies to have an affordable office space and enables entrepreneurs to meet new people with different work specialities.
Readers who have followed our blog for some time now know that we have done the software for The Code Factory, a co-working space for software startups in Ottawa. Co-Working Joliette has a different approach than The Code Factory for its pricing model and doesn't focus exclusively on software startups. Joliette (~100,000 inhabitants) is not Ottawa or Montreal, so it doesn’t have the affluence of new people that those two cities may have, but Joliette still has many entrepreneurs who need office space and want to meet new people. For this reason, entrepreneurs can work at Co-Working Joliette by purchasing a daily pass or rent office space on a monthly or yearly basis. You can have your own closed office or share a work table with other people. You can access your office 24/7, have a free parking space, and, of course, unlimited Internet access.
According to Benoit Grenier of Communication 8020, this is the second co-working space in the province of Quebec. They already have partnerships with two other co-working spaces: one in New York, the New Worker, and one in Vancouver, WorkSpace. They are in talks with a co-working space in London right now but nothing has been signed as of yet.
To me, the opening of a co-working location in a smaller community confirms what we've been claiming on our blog for the past two years. The Internet has made it possible to have clients all over the world, regardless of your company size and location. We've seen this first hand in the software world, but it also applies to firms specializing in marketing, translation, etc.
Good luck to all involved and let’s hope this project becomes a success in Joliette.