Background :
Approx. 9 year old ASP.NET website.
Originally ASP.NET 2.0 (or maybe even 1.1?), and upgraded over time to now being ASP.NET 4.0.
Running fine on a Windows Server (2003?).
We decide to virtualize our servers. The new virtual server is Windows Server 2012 R2.
I copy the ASP.NET files across and lose DAYS trying to get it working.
It was an unexpectedly painful process, with lots of obtuse error messages.
Here are a few of the "gotchas" that got me - and hopefully will help un-got you :
Bye bye DAO & 32-bit mode
Due to its age, the system was using DAO against a Microsoft Access database for part of the system (including integration with a third-party system).
DAO only has a 32-bit version.
For no apparent reason - and I've never had this problem on any other server - but when I put the application pool in 32-bit mode, I would get extremely strange errors I could not resolve.
How did I solve it?
Switch back to 64-bit mode, and modify the database connection string to use Microsoft's "ACE" library instead of DAO. (Scroll halfway down this article for example connection strings.)
This also requires installing ACE on the server - not installed by default. (Go here and download AccessDatabaseEngine_x64.exe)
No HTTP Handler For The Request Type 'GET'
This is up there with the weirdest problems I've seen.
Turns out - for no apparent reason - there can somehow end up being a deficiency in the configuration of ASP.NET. Copying web.config.default over web.config in the .NET Framework config folder magically solved the problem - thanks to these guys for saving me a huge bunch of frustration and time wastage!
Unhandled exceptions only intermittently going in to the Event Log
I wasted a lot of time trying to find details of error messages at the very start of my testing.
The web page returned to me would say that an unhandled exception had occurred and an unhandled exception had occurred in the error handler.
Not very useful, but exception details would sometimes appear in the Event Log.
Here's the big problem : it was highly unreliable.
Sometimes the .NET exception dump would appear in an Event Viewer entry pretty quickly.
Other times it seemed to take minutes.
And other times the error messages never appeared in the log at all.
I could not determine the cause of the inconsistency.
Fortunately, at some point I sufficiently adjusted file permissions to enable my web application's error handler to write its own exception dumps to text files in a log folder, and then with the detailed error messages available immediately after each page hit, I was able to solve the problems much faster.
(The error handler was quite complex and was still triggering its own unhandled exception, but after dumping the primary exception's details to text file.)
SMTP services installation was not obvious to me
I found lots of articles explaining that to use the IIS SMTP server with IIS 7.5, you need to install various things. I started using IIS so long ago and have done sufficiently little server administration that somewhere along the line I failed to notice that with the design of Windows Server these days I had to add the SMTP server as a feature not as a role. Why IIS is a role whilst SMTP is not, I don't know and don't intend to bother investigating, but that explains why after quite some minutes poring carefully over the list of installable items, I never saw SMTP. I had to click "Next" to go from the Roll selection page to the Feature selection page. That one was kinda-obvious, but it tripped me up, so I mention it in case it helps anyone else.
And I had quite a lot of other pain during the transition process - a process that I had naively imagined in advance might only take an hour or two. But those are the main ones that stick in my mind.
HTH!
No comments:
Post a Comment