www.tobuku.

com

UNDERSTANDING SQL SERVER ENDPOINT

May 2011 Level: √
By : Feri Djuandi Beginner Intermediate Expert

Platform : MS SQL Server 2008

Introduction
The Endpoint in SQL Server refers to the gateway of the SQL Server clients to access the SQL
Server instance. I understand for some people including me at first, this definition is a bit
confusing and somewhat needs efforts to digest it because of all documentations I found, they
gave me obscure notions. Until I managed to read many papers from various sources finally I
was able to draw common understandings and had a clear picture of the concept. Let me share
with you from what I understand, hopefully I can explain it well.

Endpoint

In the above picture we can imagine that an SQL Server instance is a city surrounded by the
walls that protect the objects inside from outsiders that wish to enter. The city walls cannot be
broken through and the only way to enter the city is only through the gate. There could be some
different gates that allow the people to come in and out, but notice that those gates are
protected by the guards so only people granted with valid accesses are able to pass the check
points. So hence we understand that an Endpoint is a entrance with a security mechanism.
There are four types of Endpoints known in MS SQL Server 2008:
1. Tabular Data Stream (TDS) Endpoint also known as TSQL. Please don’t be confused with
T-SQL (Transact SQL). Those two terms are different meanings.
2. Database Mirroring

-1-
www.tobuku.com

3. SOAP
4. Service Broker
These various types of Endpoints represent the numerous ways to access the SQL Server
instance, i.e. the communication protocols used for each different type. For example when we
use the SQL Query Analyzer program to run a query from the PC against the SQL Server or
develop a database application using Visual Basic, actually we do the communication with the
server through the TSQL Endpoint and use the TDS protocol. In the meantime if we activate the
database mirroring feature to set up a stand-by server, then the primary server and the stand-by
server talk to each other via the Database Mirroring Endpoint. Those are pretty much the same
with the rests, each Endpoint has a specific method to work.
This document will not explain all types of Endpoint because each one has a different
configuration and implementation. In this occasion we only discuss TSQL as the simplest
Endpoint and the one that we’re most familiar with all this time. But before we go further with
Endpoints, there is something that you should know regarding to the SQL Server Network
Communication, which are the various communication protocols used by SQL Server to
communicate with the clients. This is very important for the basic knowledge in order to have
better and easier understanding when we talk Endpoints later. Let us take one step back.

SQL Server Network Communication

In general SQL Server supports four types of communication protocols:
1. Shared Memory
This protocol can only be used by local connection, i.e. the SQL Server and the client are
the same computers – for instance you open a SQL Server Management Studio to access
the SQL Server in the local computer. Another example use of the Shared Memory
protocol is the SQL Server Express installation. This SQL Server edition only allows the
local connection where a stand alone database application accesses the SQL Server
instance that resides in the same computer. Other remote computer that tries to
connect the SQL Server Express most likely will end up with the “server not found” error
because the instance is not accessible through this protocol.
2. TCP/IP
This protocol is the primary and preferred protocol for most SQL Server installations.
TCP/IP allows both local and remote connections.
3. Named Pipes
Similar to TCP/IP, this protocol supports the inter-server communication as well as Local
Area Network (LAN) communication. Normally this protocol is used by specific design
applications that want to take the advantage of the Named Pipes protocol (e.g. local
network implementations, a single security domain and not exposed to external traffic).
4. Virtual Interface Adapter (VIA)
VIA is a protocol which is dependent on vendor implementations and specific devices.

The see the configuration of those network protocols, please open the Configuration Manager
from the MS SQL Server 2008 menu, Configuration Tools SQL Server Configuration Manager.

-2-
www.tobuku.com

This program is used to configure the communication protocol for both the server and the
client.

To manage the server protocol, expand the SQL Server Network Configuration node and then
point to the Protocols for <instance name>. It is a SQL Server instance which installed on the
server. In this example there is only one SQL Server installation named SQL2K8 – that is the
name I gave for my installation. The configuration above may be shown differently on your
computer, according to the installation in the computer. In this example we have only one
instance, however if you have more than one SQL Server instance in the computer, then all
names will appear in the list. In the right pane there is a list of protocol supported for the
respective SQL Server instance along with their status. In the above picture it is clear that the
protocols enabled are Shared Memory and TCP/IP only. That is the view from the server side.
Now let us look from the client side. In this example I will use the same computer, but you are
free to do this step from the other computer so you will see the real separation between server
and client sides. Please Go to the SQL Native Client 10.0 Configuration and point the Client
Protocols.

There are four client protocol names similar to those we’ve seen in the server side earlier. Here
the enabled client protocols are only Shared Memory and TCP/IP. The Order number in the right
column indicates the preference of the protocol to be used when establishing the connection. In
this case the Shared Memory more likely will be used first rather than the TCP/IP. If enabled,
normally the Shared Memory always has the first number among the enabled protocols. If the
other two protocols are enabled, then the order number can be arranged among them. The sort
order of the protocols determines which communication protocol to be used by the client when
making a connection to the SQL Server instance. When Shared Memory is enabled, by default it
is the one that will be used for a local connection. For remote connection typically TCP/IP or
Named Pipes will be chosen.

-3-
www.tobuku.com

Now I will demonstrate how to connect a SQL Server instance using different communication
protocols.
1. Open SQL Server Management Studio and connect to a Database Engine.

Enter the SQL Server instance name in the Server name column. In this example, I have
an instance name called SQL2K8 on my local computer.
For Shared Memory protocol, there are numerous ways to specify the server name as
follow:
<server name>\<instance name>
(local)\<instance name>
localhost\<instance name>
.\<instance name>
If the instance is the default instance, then you may ignore the “\<instance name>” part.
From the formats above, you can choose either one as a reference to an instance name.
For TCP/IP, commonly the instance name is begun with the computer name or the IP
Address.
2. Click the Options button to open the Connection Properties tab as shown in the
following picture. For the Network protocol we can choose the communication protocol
to be used. Be noted that these protocols are in accordance with the enabled Client
protocols in the “SQL Server Configuration Manager” window explained earlier. The
Named Pipes and VIA are hidden because they are disabled.
Commonly the selected option is <default>, in this way the protocol used is the first
order in the Client protocol list, i.e. Shared Memory – so typically without changing the
selection, Shared Memory should be used by default. Nevertheless you still have the
option to change the selection to Shared Memory for you to be sure.

-4-
www.tobuku.com

3. Click Connect to establish a connection to the SQL Server instance.

4. To verify which communication protocol is being used, execute the following query. The
result will confirm the selection.
SELECT net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

You may repeat the steps above and try for the other protocol.

-5-
www.tobuku.com

NOTE:
Different SQL Server client applications may behave in a different way from
what has been explained previously. For instance the Query Analyzer (from
SQL Server 2000) acts differently from the SQL Server Management Studio.
Besides Query Analyzer doesn’t provide the options to select the
communication protocol, it seems Query Analyzer doesn’t follow the
preference order of the client protocol list.

When I connect the same SQL Server instance earlier, Query Analyzer chooses
to use TCP rather than Shared Memory protocol. This is a quite interesting
finding, but unfortunately I don’t have the opportunity yet to observe this
matter in more detail - so I leave it to you.

That is the brief and practical information about the SQL Server communication protocol that
enough for you to know. Now we shall go back to the main topic that we’re discussing.

TSQL Endpoints
As you already learn, the TSQL is the Tabular Data Stream (TDS) Endpoint. This Endpoint is
distinguished into two forms:
1. Default TSQL. This is the standard TSQL Endpoints that automatically created during the
SQL Server installation. There are five Default TSQL Endpoints:
a. TSQL Default TCP
b. TSQL Default VIA
c. TSQL Named Pipes
d. TSQL Local Machine
e. Dedicated Admin Connection (DAC)
As you may guess, the first four Endpoints correspond to the supported protocol by SQL
Server which is TCP, VIA, Named Pipes and Shared Memory. They are automatically
configured to listen on port 1433 for default instances. The fifth Endpoint is created to
support an administrative connection – we don’t discuss this one at this moment.
The Endpoints configuration can be simply viewed by executing the following query.

-6-
www.tobuku.com

Please don’t be confused by communication protocol and Endpoints, they are different
things although they are still related. While the Named Pipes and VIA protocols are
disabled in our example, but the TSQL Named Pipes and TSQL Default VIA can be started
because the configuration is independent. However in overall both the protocol and
Endpoints should be enabled and started in order for the instance to be accessible.

NOTE:
If you are unsure what the number of the Default TCP port that a SQL Server
instance uses is, then you can verify the port number using the Windows
registry editor (REGEDT32.EXE) in the following path:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL
Server\<instance name>\MSSQLServer\SuperSocketNetLib\TCP

The following picture represents an illustration of the available Default TSQL Endpoints.
Each Endpoint serves as a gateway to handle clients’ connections and each one works
based on a specified communication protocol.

TSQL Local
Dedicated Machine
Admin
Connection

SQL Server
Instance

TSQL Default
TCP
(port 1433)

TSQL Named
Pipes

TSQL Default
VIA

-7-
www.tobuku.com

2. TSQL TCP
Apart from the standard TSQL Endpoints, additional user defined TSQL TCP Endpoints
can be created. Commonly these TSQL TCP Endpoints are created to support special
security or application requirements.

Creating TSQL TCP Endpoints

Following is an example to create custom TSQL TCP Endpoints.
CREATE ENDPOINT DagobahEP
STATE=STARTED
AS TCP
(LISTENER_PORT=50102, LISTENER_IP=ALL)
FOR TSQL();
GO

CREATE ENDPOINT BelzagorEP

STATE=STOPPED
AS TCP
(LISTENER_PORT=50103, LISTENER_IP=ALL)
FOR TSQL();

NOTE:
As the CREATE ENDPOINT command is successfully executed, SQL Server will
return a message something like this:
Creation of a TSQL endpoint will result in the revocation
of any 'Public' connect permissions on the 'TSQL Default
TCP' endpoint. If 'Public' access is desired on this
endpoint, reapply this permission using 'GRANT CONNECT ON
ENDPOINT::[TSQL Default TCP] to [public]'.

Important to note, that when a new TSQL TCP Endpoint is created, SQL Server
automatically revokes all connect permission to the default Endpoint. If the
connection support is still required for the default Endpoint, then explicit
GRANT CONNECT permissions is necessary to recover the revocation.

To verify the creation, run this query and evaluate the result.
SELECT * FROM sys.tcp_endpoints

-8-
www.tobuku.com

Alternatively we can use SQL Server Management Studio to view the existing Endpoints, either
the system or user defined Endpoints.

The following illustration shows what happens after we create other Endpoints. In this case
there are two additional gateways named DagobahEP and BelzagorEP, both are using TCP.

TSQL Local
Dedicated Machine
Admin DagobahEP
Connection (port 50102)

SQL Server
Instance
BelzagorEP
TSQL Default
TCP (port 50103)

(port 1433)

TSQL Named
Pipes

TSQL Default
VIA

-9-
www.tobuku.com

If you pay a close attention on the CREATE ENDPOINT commands earlier, you will notice that
DagobahEP is created with a STARTED state, meaning the gateway is open since it is created –
like the other default Endpoints. On the other hand, BelzagorEP is created with a STOPPED state
which indicates that the gateway is closed at this moment.
To change the state of an Endpoint, we can call the ALTER ENDPOINT followed by the Endpoint
name and the state like an example below.
ALTER ENDPOINT DagobahEP STATE = STOPPED
GO
ALTER ENDPOINT BelzagorEP STATE = STARTED
GO

Although the state of an Endpoint is STARTED, it doesn’t mean the gateway is open for the client
to enter. The gateway is guarded and the access is not allowed until the client is granted
permission.

NOTE:
When configuring the port for a SQL Server instance, it is a best practice to
choose a port number above 50000 because many ports bellow 50000 are
associated with other applications. To retrieve a list of reserved and well
known port number, please visit the Internet Assigned Number Authority
(IANA) website at http://www.iana.org/assignments/port-numbers.

Granting the Connect Access

An Endpoint is an object in a SQL Server instance. When it is firstly created, there is no client’s
access permission associated to that Endpoint so there is no way for anyone to enter the SQL
Server instance through the Endpoint except the sysadmin (the sysadmin is a super user who
always has superior rights to do most of the things in SQL Server). What happens to ordinary
users when they are not able to access the new Endpoint is they don’t have the Connect
permission of the Endpoint object, therefore the database administrator should explicitly grant
the permission to the authorized client.
Following is a command example to grant an Endpoint to a specified SQL Server Login:
GRANT CONNECT ON ENDPOINT::[DagobahEP] to testuser

If you wish to grant an Endpoint openly to public access, then replace the Login name with the
public reserved word:
GRANT CONNECT ON ENDPOINT::[BelzagorEP] to public

Conversely to revoke the Connect permission from a user, please do the following command:
REVOKE CONNECT ON ENDPOINT::[BelzagorEP] from public

Once the Endpoint has been granted, the client is surely able to log into the SQL Server instance
through the respective Endpoint.

- 10 -
www.tobuku.com

Exercise
For the last part of this article, I add a simple exercise that you
might want to follow. Rather than just reading this document, I
think it is better for you to have your own hands-on
experience.

A. Creating a TSQL TCP Endpoint

1. Log into a SQL Server instance and run this command to create a new TSQL TCP
Endpoint.
CREATE ENDPOINT DagobahEP
STATE=STOPPED
AS TCP
(LISTENER_PORT=50102, LISTENER_IP=ALL)
FOR TSQL();

GO

2. Verify if the Endpoint is created successfully. Ensure that the new Endpoint is shown in
the list.
SELECT * FROM sys.tcp_endpoints

Please notice, that the state of the new Endpoint is STOPPED.

B. Logging in through the Endpoint

1. Try to connect the instance through the port specified for the Endpoint.

Click the Options button.

- 11 -
www.tobuku.com

Go to the Connection Properties tab. Select the Network protocol as TCP/IP.

Press Connect.
Verify if you are able to connect the instance. The normal response should be an
“Invalid Connection” error because the Endpoint has not been started.
2. Start the Endpoint using the following command:
ALTER ENDPOINT [DagobahEP] STATE = STARTED

3. Try again to connect the instance. Most likely you still face the connection error
although the Endpoint has been started. Why? We have started the Endpoint, haven’t
we?
The reason why the error still appears is because the TCP/IP protocol is not open yet for
the new port number. By default SQL Server is only open for port number 1433.
4. Open the SQL Server Configuration Manager and configure the TCP/IP protocol by
adding the new port number after the existing standard port number. Separate the port
numbers with a comma as shown in the following picture.
Click OK to save the configuration. The SQL Server service needs to be restarted to take
the effect.

- 12 -
www.tobuku.com

5. Try again to connect the instance. This time it should be success. Verify that you are
logged in using the TCP protocol.
SELECT net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

C. Granting the Connect permission

1. Create a new SQL Server Login in the instance using SQL Server authentication and
name it as testuser.
2. Log in again to the SQL Server instance through the same Endpoint using the new Login.
The normal response should be a “Login failed” error.
The reason why you are unable to log in is because the new user has not obtained the
Connect permission of the Endpoint. If previously you successfully logged in, that’s
because you used the sysadmin role. At this moment the Connect permission is not
granted yet to ordinary users.
Grant the Connect permission to public using the following command:
GRANT CONNECT ON ENDPOINT::[DagobahEP] to public

- 13 -
www.tobuku.com

3. Please try again to log in using the new Login, this time it should be success.

I hope the explanation that you have read so far is enough to give a clear understanding of the
SQL Server Endpoint especially for the TSQL type. I would like to take a chance to discuss about
the other types of Endpoints in separate articles.

Reference
Brewer, William. “SQL Server Endpoints: Soup to Nuts”. http://www.simple-
talk.com/sql/database-administration/sql-server-endpoints-soup-to-nuts, July 2007.

Wood, Dan; Chris Leiter; Paul Turley. “Beginning SQL Server 2005 Administration”. Wiley
Publishing, Inc., 2007.

Mat 10:8 “…Freely you have received, freely give”

- 14 -