Sometimes, the problem with our application isn't in our code; the environment it lives in has to be taken into consideration as well.

With my projects pushing and exceeding my current skillset, I'm constantly learning new things. I've spent all morning reading error logs, as I've inadvertently caused sleepless nights for my system admins. Thanks to a quick fix in web.config and an IIS restart, those guys should get their sleep back.

So what happened? I was developing for an unfamiliar playing field. I've always developed on a single server environment, and my test areas are set up the same way. My end product, however, is hosted on a clustered environment with network load balancing (NLB). Having never dealt with clusters from a developer's perspective, my train of thought treated the site like a single server deployment.

Now I understand how clusters work and just how NLB comes into play. Too much information for a dev? Not in my book. If you're developing an application, you need to understand your environment so that you can develop with the appropriate precautions and methods. Had I understood my environment, I would have also known to check the <machineKeys> and made sure that they matched, so that my WebResource.axd files wouldn't have had issues in the first place.

My sys admins were happy to have a quick turnaround time from me. Having done server administration as part of my last job, I understand the frustrations of pages in the middle of the night for errors that can't really be worked out at that time. I'm just glad that they finally brought it up with me, as I don't have access to the logs to watch them on my own.

That's twice in the same week where my IT background has been helpful, and it's only Tuesday! Yesterday, I managed to shed some light on a problem with NTLM Authentication and fully qualified domain names (FQDNs). When another of my applications went live, we noticed that my Windows Authentication code didn't behave as expected. Our sys admins were aware of the issue, as they had run into it but hadn't figured out what was going on. Since there wasn't anything different in the IIS configuration across the servers, I had to do some investigating on my own. (I wrote that feature so that users wouldn't have to type in their credentials, and I'm a lazy end-user who loved that feature in my test environments, so you can bet that I want my feature working on the live side.) Long story short, (1) Firefox just needs the hosts added to a key in about:config, (2) FQDNs throw Windows Authentication for a loop because of a period in the host name, and (3) Internet Explorer doesn't like the periods in the hostname and sees anything with a period in the host name as general Internet traffic instead of Local intranet, until you specify that it belongs in Local intranet. Once again, my technical tendencies really helped me out.

I never really suspected that my IT background would come into play, but yet, I'm finding it helping when I least expect it.