Remember When…
Back in late December of 2015, a challenge of sorts was issued by Tim Ford (twitter) to write a blog post each month on a SQL Server Basic. Some have hash-tagged this as #backtobasics. Here is the link to that challenge sent via tweet.
While the challenge may have been for the year 2016 and I haven’t contributed in several months, it is still a worthwhile effort. In that vain, I am adding this article to that series.
With this being another installment in a monthly series, here is a link to review the other posts in the series – back to basics. Reviewing that link, you can probably tell I am a bit behind in the monthly series.
Endpoints
You may have heard the term endpoints thrown around in technical discussion and wondered “what the heck is an endpoint?” Well, that is a good question. An endpoint in the simplest form is a connection or point of entry into SQL server.
Another way of thinking about an endpoint is to look at the ends of a line. Generally speaking, there is a stop point at each end of the line. At this stopping point, the line may connect to something else and therefore be a point of entry into that “something else”.
When we deal with SQL Server there is a handful of default endpoints and then a handful of other types of endpoints. To figure out what the default endpoints are, it is pretty easy. The following query will expose the default endpoints.
USE master; GO SELECT e.name, e.protocol_desc, e.type_desc FROM sys.endpoints e WHERE e.endpoint_id < 65536;
Executing that query will produce results similar to the following:
Some of those might look pretty straight forward and then you get to that VIA endpoint. Don’t worry about that endpoint. The VIA endpoint is on the deprecation list. All of these default endpoints will be owned by sa and don’t require you to do anything with them per se other than to understand they exist. You may have noticed that I filtered my results by looking only at endpoints with an id of less than 65536. Any endpoint id lower than this number is a default endpoint. All others are user defined endpoints.
Endpoint Owners
So far so good. This is pretty straight forward to this point. If you have implemented anything like mirroring, Availability Groups, or Service Broker, then you may be interested to know that you have also created additional endpoints in the Instance. When you create an endpoint, did you know that you become the owner of that endpoint by default? It is very similar to when you restore a database or create a database – the default owner of that database will be the person that restored/created it.
Do you know who owns your endpoints? Did you create all of the endpoints? Do you know if you have any additional endpoints beyond the default endpoints? If you cannot answer yes to all of these questions, then you will probably want to figure out what the endpoints are and who owns those endpoints. Let’s try that with a slight modification to the previous query.
USE master; GO SELECT ISNULL(e.name, 'Unused PayloadType') AS EndpointName , e.endpoint_id , sp.name AS EndpointOwner , CASEWHEN e.protocol IS NULL AND oa.typeid = 1 THEN 1 WHEN e.protocol IS NULL AND oa.typeid = 3 THEN 2 WHEN e.protocol IS NULL AND oa.typeid = 4 THEN 2 ELSE e.protocol END AS protocolid , CASE WHEN e.protocol IS NULL AND oa.typeid = 1 THEN 'HTTP' WHEN e.protocol IS NULL AND oa.typeid = 3 THEN 'TCP' WHEN e.protocol IS NULL AND oa.typeid = 4 THEN 'TCP' ELSE e.protocol_desc END AS protocol_desc , oa.typeid , oa.PayloadType , e.state , e.state_desc , e.is_admin_endpoint FROM sys.endpoints e INNER JOIN sys.server_principals sp ON e.principal_id = sp.principal_id RIGHT OUTER JOIN ( VALUES ( 1, 'SOAP'), ( 2, 'TSQL'), ( 3, 'SERVICE_BROKER'), ( 4, 'DATABASE_MIRRORING') ) AS oa ( typeid, PayloadType ) ON oa.typeid = e.type;
This will yield results similar to the following:
I took the script a step further than necessary. I wanted to illustrate potential endpoint types that may not be in use. This script covers both in use endpoint types and those not used. In my results you may note that I have a DATABASE_MIRRORING endpoint. As reality would actually have it, it is an Availability Group endpoint but those are presented as DATABASE_MIRRORING endpoints.
Note that my mirroring endpoint (aka Hadr_endpoint) is owned by “YourDomain\DBAdmin”. What if the owner of that particular endpoint was no longer present in the organization and I wanted to change it to something more sustainable? Well, I could do the following:
USE master; ALTER AUTHORIZATION ON ENDPOINT::Hadr_endpoint TO sa;
In this case, the default endpoints are owned by sa and it does make enough sense to assign the owner to be sa for the mirroring endpoint. Take notice that the name of the endpoint is required in order to reassign the owner. The name of the endpoint follows the :: in the script. So, whatever your endpoint name happens to be, just place “Hadr_endpoint” that follows the :: in my script.
Recap
Endpoints are a fundamental piece of the puzzle with SQL Server. Getting to know your endpoints and the owners of those endpoints is an essential component of knowing your environment. Who knows, it may come to pass that the owner of an endpoint may no longer exist in your environment or possibly lose permissions along the way. Knowing who owns the endpoint may just save three or four grey hairs when that day comes.