TSQL-SQL_Server_Endpoint by yvtong



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

Platform : MS SQL Server 2008

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.


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


    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.


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

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

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.


Now I will demonstrate how to connect a SQL Server instance using different communication
   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
               <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
   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.


   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.


                  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.


      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.

                 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

                                             SQL Server

                 TSQL Default
                 (port 1433)

                       TSQL Named

                                              TSQL Default


    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.


                  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


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
                 TSQL Default
                     TCP                                                     (port 50103)

                  (port 1433)

                        TSQL Named

                                                TSQL Default


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.

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

                  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:

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 -

                                   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

A. Creating a TSQL TCP Endpoint
   1. Log into a SQL Server instance and run this command to create a new TSQL TCP
       AS TCP
       FOR TSQL();


   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 -

      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:

   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
      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 -

   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 -

    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.

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 -

To top