Common Obfuscated Error Messages with IIS

I've noticed that IIS tends to obfuscate error messages - displaying messages that are different than the actual issue that is happening to the application.  This may very likely be because we are running a plethora of web sites with different architectures and history on one instance of IIS.  I thought I document some of those 'tricky' error messages here just in case someone else runs into them (or I forget what they really mean).

1. 'An existing connection was forcibly closed by the remote host'  I ran into this error numerous times trying to configure a WCF web service to bring back a large result set (60k + rows).  Playing with the values for maxBuffer PoolSize and MaxReceivedMessageSize in the web.config, I came to discover that this error was really seemed to be masking was an out of memory error that forced the shutdown of the AppPool that was serving the web service.

2. 'BinaryFormatter Version Incompatibility errror'  Generally I've seen this error when you have IIS site on a web server trying to communicate with another IIS site on an application server, and there is no response from the IIS site on the application server - either that web site isn't running, or your url pointing to the web site on the application server is wrong.

Some good links (to blog articles) on Configuration Management

Here's some good links to blog articles on Configuration Management.  The first is about the importance of a CM person in a company.  I would tend to agree with one of the comments that talks about the size of the company making a difference.  Obviously a smaller startup doesn't need a dedicated CM person.  However, larger enterprises like the one I'm at now with numerous development environments, multiple servers, a GIS infrastructure, a document management infrastructure, and a beomoth of a mainframe legacy system needs a dedicated CM team.  Here's the link:
http://evgeny-goldin.com/blog/2010/08/21/configuration-management-position/

 The other link considers adding database automated deployment to you CM system.  I would highly recommend when I contrast my experience over the last two years with my previous release management experience.  Previously we automatically deployed database schema and data changes. In my more recent experience the DBA group has flatly declined any encouragement and offer to do this.  The difference in the amount of time to do database refreshes and debug issues with them is stark - like hours vs. days.  Here's the link:

http://www.simple-talk.com/sql/t-sql-programming/when-database-source-control-goes-bad/

Testing with IE 6 (on Linux!)

I have a requirement from a client to ensure that their website looks good in IE6.  None of the machines I normally work on have IE6 installed. So I googled IE6 emulators as I had used one in the past that was pretty good, and came up with:
http://tredosoft.com/Multiple_IE 
and
http://www.browsercam.com/
However you have to sign up to get a free time trial and I thought maybe there was something better for me out there.  Some of the forums talked about having an old laptop that they keep around just for testing with IE6.  I do have an old desktop running XP, so I checked it.  It turned out I have been keeping up with all the updates for the most part and one of the service packs (I don't remember if it was 2 or 3) installed IE7.  Bummer. 
Googling a bit more, I discovered that you can install IE6 on Linux.  Pushing against this thread a bit more, I found this site:
http://www.tatanka.com.br/ies4linux/page/Main_Page
and went to this page:
http://www.tatanka.com.br/ies4linux/page/Installation:Fedora
followed the directions and IE6 was installed and running, properly displaying my client's website within 10 minutes.  The Tatanka gives you the option to install IE5.5 and IE5 as well, but when I tried them, the installations were corrupt.  Since IE6 was all I really needed, I was happy with leaving things the way they stood.

Active Directory SPOF

We had a great example of an AD SPOF (single point of failure) recently.  A vbscript had been written by someone with no malicious intent to (for some reason) hook into AD and check service accounts.  What this script ended up doing though was locking out said service accounts.  Within the span of 30 minutes we were well on our way to locking out 400+ service accounts in the enterprise, irrespective of environment.  This took production out of commission.
Seems like a bit of a hole to me.