Sent: 08/07/2006
From: Niels Immink
Message:Hi Blake,
Yes, a standard install of SQL should open the standard SQL ports. Probably
when running a netstat -a you will see a :ms-sql-s LISTENING entry. At least
you should see one. It will not show up in a standard netstat query since it
is not being actively used.
What happens when you try to register your virtual SQL server on a remote
machine? Does an error message pop up at all? Can you open shares on the
machne at all? Can you ping it?
Regards,
Niels
"Blake" wrote:
Show quoted text
> We are running SQL Sever 2000 on a virtual instance of Windows 2003 R2 (we
> are running Virtual Server 2005 R2).
>
> I can log onto the virtual server via RDP and then use Enterprise Manager to
> connect to the local SQL instance. However I cannot use Enterprise Manager
> on another system and connect to SQL server via the standard port. In fact,
> running netstat on the virtual machine gives the following:
>
> Active Connections
>
> Proto Local Address Foreign Address State PID
> TCP dogbert:epmap dogbert.longwood.edu:0 LISTENING 716
> TCP dogbert:microsoft-ds dogbert.longwood.edu:0 LISTENING 4
> TCP dogbert:1025 dogbert.longwood.edu:0 LISTENING 464
> TCP dogbert:ms-wbt-server dogbert.longwood.edu:0 LISTENING 1676
> TCP dogbert:ms-wbt-server lu40704.longwood.edu:1144 ESTABLISHED
> 1676
> UDP dogbert:microsoft-ds *:* 4
> UDP dogbert:isakmp *:* 464
> UDP dogbert:1026 *:* 772
> UDP dogbert:ipsec-msft *:* 464
> UDP dogbert:ntp *:* 796
> UDP dogbert:ntp *:* 796
>
> Should a 'standard' install of SQL Server 2000 running on a virtual instance
> open the standard SQL ports? Shouldn't I be able to connect to that
> instance via remote Enterprise Manager?
>
> It isn't a firewall issue - both (host and client on the virtual boxes) are
> turned completely off.
>
> Thanks
> Blake
>
>
>
Sent: 08/07/2006
From: "Ronny Ong" <(email address - cut out)>
Message:"Niels Immink" <(email address - cut out)> wrote in message
news:(email address - cut out)...
It used to, but this behavior was changed in SP1 for WS2003 and SP2 for XP.
This is a completely separate issue from the firewall.
When you install the RTM version of any edition of SQL Server 2000 on
WS2003SP1 or XPSP2, the OS automatically blocks all network access to that
instance until you update SQL to SP3a or higher (current is SP4). Note that
this is per-instance, so if you have multiple instances, you must apply the
SP to each instance. This is a special case of blocking which Microsoft has
hard-coded into the OS; there is no setting to override it.
Once you have applied SP3a or higher, you may also need to verify that
TCP/IP has been enabled (along with any other protocols you may need such as
Named Pipes) in SQL Server Network Utility (svrnetcn.exe). But until you
have applied SP3a or higher, enabling protocols here will not matter.
Show quoted text
> Yes, a standard install of SQL should open the standard SQL ports.
> Probably
Sent: 08/07/2006
From: "Blake" <(email address - cut out)>
Message:The copy/paste from my original post WAS using netstat with the -a flag.
I don't see any ports open for SQL (default or otherwise)
I configure Enterprise Manager to prompt me for credentials - when I try to
connect it says
"A connection could not be established to DOGBERT\MSSQL3
Reason: Specified SQL server not found.
ConnectionOpen (Conect())..."
ping - yes, the virtual box replies fine
I CAN RDP to the box andI CAN ennumerate the shares on it (after I enabled
file/printer sharing)
Ideas?
"Niels Immink" <(email address - cut out)> wrote in message
news:(email address - cut out)...
Show quoted text
> Hi Blake,
>
> Yes, a standard install of SQL should open the standard SQL ports.
> Probably
> when running a netstat -a you will see a :ms-sql-s LISTENING entry. At
> least
> you should see one. It will not show up in a standard netstat query since
> it
> is not being actively used.
>
> What happens when you try to register your virtual SQL server on a remote
> machine? Does an error message pop up at all? Can you open shares on the
> machne at all? Can you ping it?
> Regards,
>
> Niels
>
> "Blake" wrote:
>
>> We are running SQL Sever 2000 on a virtual instance of Windows 2003 R2
>> (we
>> are running Virtual Server 2005 R2).
>>
>> I can log onto the virtual server via RDP and then use Enterprise Manager
>> to
>> connect to the local SQL instance. However I cannot use Enterprise
>> Manager
>> on another system and connect to SQL server via the standard port. In
>> fact,
>> running netstat on the virtual machine gives the following:
>>
>> Active Connections
>>
>> Proto Local Address Foreign Address State
>> PID
>> TCP dogbert:epmap dogbert.longwood.edu:0 LISTENING
>> 716
>> TCP dogbert:microsoft-ds dogbert.longwood.edu:0 LISTENING 4
>> TCP dogbert:1025 dogbert.longwood.edu:0 LISTENING
>> 464
>> TCP dogbert:ms-wbt-server dogbert.longwood.edu:0 LISTENING
>> 1676
>> TCP dogbert:ms-wbt-server lu40704.longwood.edu:1144 ESTABLISHED
>> 1676
>> UDP dogbert:microsoft-ds *:* 4
>> UDP dogbert:isakmp *:*
>> 464
>> UDP dogbert:1026 *:*
>> 772
>> UDP dogbert:ipsec-msft *:*
>> 464
>> UDP dogbert:ntp *:*
>> 796
>> UDP dogbert:ntp *:*
>> 796
>>
>> Should a 'standard' install of SQL Server 2000 running on a virtual
>> instance
>> open the standard SQL ports? Shouldn't I be able to connect to that
>> instance via remote Enterprise Manager?
>>
>> It isn't a firewall issue - both (host and client on the virtual boxes)
>> are
>> turned completely off.
>>
>> Thanks
>> Blake
>>
>>
>>
Sent: 08/07/2006
From: "Blake" <(email address - cut out)>
Message:Ronny,
This is good to know. It IS the RTS version without any service pack. I
cannot even fathom why our highly paid DBA didn't install any SPs (and
completely ignored the message saying to install at least SP3a)
I'll try that after I wring his neck and let you know.
And thanks
Blake
"Ronny Ong" <(email address - cut out)> wrote in message
news:(email address - cut out)...
Show quoted text
> "Niels Immink" <(email address - cut out)> wrote in message
> news:(email address - cut out)...
>> Yes, a standard install of SQL should open the standard SQL ports.
>> Probably
>
> It used to, but this behavior was changed in SP1 for WS2003 and SP2 for
> XP. This is a completely separate issue from the firewall.
>
> When you install the RTM version of any edition of SQL Server 2000 on
> WS2003SP1 or XPSP2, the OS automatically blocks all network access to that
> instance until you update SQL to SP3a or higher (current is SP4). Note
> that this is per-instance, so if you have multiple instances, you must
> apply the SP to each instance. This is a special case of blocking which
> Microsoft has hard-coded into the OS; there is no setting to override it.
>
> Once you have applied SP3a or higher, you may also need to verify that
> TCP/IP has been enabled (along with any other protocols you may need such
> as Named Pipes) in SQL Server Network Utility (svrnetcn.exe). But until
> you have applied SP3a or higher, enabling protocols here will not matter.
>
>
Sent: 08/11/2006
From: "Blake" <(email address - cut out)>
Message:Ronny was 100% on the money. Thanks so much.
Blake
"Ronny Ong" <(email address - cut out)> wrote in message
news:(email address - cut out)...
Show quoted text
> "Niels Immink" <(email address - cut out)> wrote in message
> news:(email address - cut out)...
>> Yes, a standard install of SQL should open the standard SQL ports.
>> Probably
>
> It used to, but this behavior was changed in SP1 for WS2003 and SP2 for
> XP. This is a completely separate issue from the firewall.
>
> When you install the RTM version of any edition of SQL Server 2000 on
> WS2003SP1 or XPSP2, the OS automatically blocks all network access to that
> instance until you update SQL to SP3a or higher (current is SP4). Note
> that this is per-instance, so if you have multiple instances, you must
> apply the SP to each instance. This is a special case of blocking which
> Microsoft has hard-coded into the OS; there is no setting to override it.
>
> Once you have applied SP3a or higher, you may also need to verify that
> TCP/IP has been enabled (along with any other protocols you may need such
> as Named Pipes) in SQL Server Network Utility (svrnetcn.exe). But until
> you have applied SP3a or higher, enabling protocols here will not matter.
>
>
Wiki