March 12, 2006 at 1:04 am
Ok, this is my first post on this site. Please excuse me if I am asking a question that has already been asked a dozen times on this site. I have been beating my head against the keyboard for so long now that I no longer have time to browse the thousands of posts on this site. That said...
I am running SQL Server 2000 SP4 (Enterprise Ed) on Windows Server 2003 SP1 (Enterprise Ed) on a Windows NT domain. I have installed SQL Server according to the default settings on setup, including setting TCP/IP on port 1433 (it is a closed DoD network, so I'm not too worried about Slammer). The problem is that I cannot get the server to listen for inbound TCP requests on port 1433, no matter what I try.
I have installed all of the applicable security patches and re-checked to make sure that none of them inadvertently blocked TCP traffic on 1433 (none of them do). I have checked the Server and Client network utilities to ensure that 1433 is the port set for TCP and it is. I have ensured that the box "Hide Server" is not checked. I have checked the properties of the SQL Server instance to make sure that it showed 1433 as the port for TCP, just like the Server and Client network utilities do. I have checked the SuperSocketNetLib for the SQL Server instance in the Windows Registry and TCP is set on port 1433.
But when I check the SQL Server logs, I get only that the Server is listening on Shared Memory and Named Pipes (no TCP!!). I also get no error message that SQL Server failed to bind TCP on port 1433. Also, when I run netstat -an in cmd, it clearly shows that the system is not listening on port 1433.
Thinking that perhaps it was a conflict with the NT domain and the fact that Windows 2003 is looking for the Active Directory for inheritable policies, I have tried removing the system from the domain, but with the same results. I have ensured that a local policy set by default (or conflicting because it is not defined) in Windows 2003 has not interfered.
I have scoured the net looking for an answer, but everything I find tells of people having problems with WinXP SP2 and firewalls, SQL Server 2000 pre-SP3a, or SQL Server 2000 Standard Edition, but nothing for my configuration.
Any help anyone could lend would be greatly appreciated. I am truly at my wit's end. Thank you.
-Captain D
March 13, 2006 at 7:03 am
Is the Windows Firewall on ?
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
March 13, 2006 at 10:39 am
Was the IP address changed? We got the same errors after changing the IP on a SQL cluster even after using KB 244980. We had to manually clean up the Registry and restart SQL Server in order to listen on IP address.
March 16, 2006 at 5:40 pm
God bless you all!
Ralph, in the link located at the bottom, you can find information about a tool called Microsoft Security Configuration Wizard.
The main purpose of this tool is to provide to the administrators a guideline that you can use to implement Microsoft's legacy applications with the minimum risk of security (I prefer to say it this way, because the only server 100% logically secured , is the one that is shutted down, power disconnected, network disconnected, and without wireless NIC installed).
Well, the point is that you can use the recommendations that it will give you, so you can be sure that your SQL Server will be successfully implemented, and no security/blocking issue will be around, because MSCW will tell you the services and resources that you need to be sure that your server will be up and running, and accessible. So you can use this information and compare the results with your actual configuration.
*MSCW is included in Service Pack 1 for Windows Server 2003, which you have already installed on your server.
http://www.microsoft.com/windowsserver2003/technologies/security/configwiz/default.mspx
Hope this help you & Good Luck.-
March 17, 2006 at 12:25 pm
Indeed, God bless you all. The problem was not an IP address, not a security policy or other obscure setting. It was, in fact, one of those Microsoft Service Pack anomalies.
It turns out that my brother-in-law is also a DBA and he had the exact same problem when his SP4 didn't take properly. Despite reinstalling SP4 over the existing installation, it still didn't take. Since most of what I found online mentioned that SP3a fixed the problem, I installed SP3a AND THEN installed SP4 and it worked like a charm.
I do appreciate all the good ideas you folks came up with, esp. the MSCW, which I will be sure to check out. Thanks again.
-R Nader
April 24, 2006 at 10:33 pm
Ralph, thank you for posting your follow up message. your original post described exactly the same issue i was having, and nothing out there on the net i came across was able to resolve my tcp issue.....until i came across you post/response. installing sp3a over top of sp4 did the trick for me also. so thank you again for posting your reply! hopefully this thread can help others, i know it saved me. take care.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply