The ever-tiny blockade

We’re on our insane crunch period trying to push out the latest release of our case management software for the Kentucky Department of Public Advocacy. We finally got a build together after many long hours, late nights, and weekend toil. A very frustrating and work-intensive time. So, today we finally start deploying our software to the client’s SQL Server environment, and all is going very well. The software is prepped, the environment is set up, files are transfered, and the databases are installed. We are moments away from showing the customer the software they’ve been patiently waiting on for many months.

Then, as is typical in software development, the last minute blockade appears. In this case, it was TCP port 1433. The SQL Server instance, despite being rigged to listen to TCP port 1433, would not listen to TCP port 1433. Was it the firewall? No. Some kind of network configuration error? No. SQL Server’s error logs show nothing. I keep looking, and looking, and still nothing. Valuable time drips away. The customer’s still waiting. I conference in with their network administrators, who are as baffled as me about what could possibly be causing this problem. I read several troubleshooting guides. Nothing. Then, I decide to look in the Event Viewer, and I find this gem:

You are running a version of Microsoft SQL Server 2000 or Microsoft SQL Server 2000 Desktop Engine (also called MSDE) that has known security vulnerabilities when used in conjunction with the Microsoft Windows Server 2003 family. To reduce your computer’s vulnerability to certain virus attacks, the TCP/IP and UDP network ports of Microsoft SQL Server 2000, MSDE, or both have been disabled. To enable these ports, you must install a patch, or the most recent service pack for Microsoft SQL Server 2000 or MSDE from

Our little software development army was pressed up against tiny, insignificant port 1433, simply because Microsoft had enough foresight to realize that maybe they shouldn’t allow their own virus-vulnerable product to sit naked on port 1433 inviting malware to feast on the server. Which, of course, made it useless to our app, since we need to connect to that port.

We lick our wounds and carry on, waiting for the next inevitable encounters with Murphy’s Law and Hofstadter’s Law.

5 responses to “The ever-tiny blockade

  1. You should try developing training for case management instead. Pays me better than when I actually messed with SQL Server 🙂 Plus as an added bonus, to build training (written by someone else) does not require true knowledge of the system!

  2. After this last crunch period, that is definitely a tempting option. Our own training person gets the crappy deal this time around, since she hasn’t been able to see the working system until our delivery to the customer. So she has a very short amount of time to 1) develop the training materials, 2) learn the system herself, 3) teach the customer. And we’re still changing the software as she’s documenting it, making it particularly frustrating for her.

    The software I am working with is one of the most complex systems I’ve ever been involved with. There are a lot of really cool aspects to it. At the same time, it is very challenging to manage.

  3. Sounds like the Case Managment system here. Except I don’t get to look at code or affect the website or anything.. but they’ll say, change the order of some buttons around.. which can create hours or even days or weeks of extra work……..

  4. Thank you very much for this blog entry. This led me to the cause of the exact same problem I’m currently experiencing with a MSDE database, after searching the Internet on how to enable the tcp/ip 1433 port…

    Would’ve been nice from Microsoft to show this error somewhere else than as an INFO event in the Event Viewer.

    Best regards,

  5. P.S. Would you like to touch my monkey?

Leave a Reply