But here’s the reality: SQL Server 2016 has reached end of life. And that shouldn’t be ignored.

What “End of Life” Actually Means

When Microsoft ends support for a product, it’s not just a technical milestone—it’s a risk shift. The list of ‘cons’ becomes much longer than the list of  ‘pros’ when deciding if an upgrade is neccesary yet, or if you can put it off another year. 

Officially SQL Server 2016 will have:

• No more security updates

• No bug fixes or patches

• No official Microsoft support

• Increased exposure to vulnerabilities and compliance risks

Even if your system seems stable today, it’s now operating without a safety net. And in today’s environment, that’s a serious concern.

The Hidden Cost of Staying Put

Delaying an upgrade might feel like the easier (and cheaper) option—but it often comes with hidden costs such as security risks, compliance issues, performance limiations and the need for emergency migrations.

Without ongoing patches, your database becomes more vulnerable to attacks, especially ransomware targeting outdated systems. Many industries require supported software. Running end-of-life systems can put you out of compliance with security standars. Older systems miss out on years of performance improvements, optimization features, and efficiency gains. Waiting too long often leads to rushed, reactive upgrades after a failure or breach—which are far more expensive and disruptive.

What You Gain by Upgrading

Moving to a modern platform like SQL Server 2025 isn’t just about staying supported, it’s about unlocking better performance, resilience, and flexibility. Newer versions bring query optimization, smarter resource usage, and faster processing, improving overall performance. There’s also some exciting new ways to make backup recovery smarter like: 

• True full and differential backups on secondary replicas

• Improved compression with ZSTD

• Immutable backup storage options

The new upgrade also means stronger security and cloud-ready flexibility. Modern encryption, threat detection, and tighter integration with cloud security tools help protect your data. And easier integration with Azure and hybrid environments gives you more options for scaling and disaster  recoverry.

Migration Doesn’t Have to Be Overwhelming

One of the biggest reasons businesses delay upgrading is fear of disruption. Downtime, data loss, compatibility issues, etc.  But with the right strategy migrations can be smoooth, controlled, and predictable.

A well executed upgrade includes:

• A full assessment of your current environment

• Compatibility and workload analysis

• A clear migration plan with rollback options

• Testing before going live

• Minimal downtime during cutover

How We Help

We specialize in helping businesses move from outdated systems to modern, optimized environments—without the chaos.

Our approach focuses on:

✔️ Safe, secure data migration

✔️ Minimal disruption to your operations

✔️ Performance tuning post-upgrade

✔️ Modern backup and recovery setup

✔️ Long-term scalability and support

Whether you’re running a single database or a complex environment, we make the transition manageable and worth it.

Ready to Modernize Your SQL Environment?

If you’re still on SQL Server 2016, now is the time to act. Let’s build a plan to upgrade your system, migrate your data safely, and set you up with a faster, more secure, and more resilient environment.

Reach out today to start your upgrade the right way.

The post Still Running SQL Server 2016? Here’s Why It’s Time to Upgrade appeared first on SQL Solutions Group.

The first thing to understand is that all linked server objects are accessible by everyone in the public database role (normally everybody). So what you are doing when you configure the security for a linked server is determining what the security context of the login will be on the remote server. The permissions of that login on the remote server will ultimately determine what the user can and can’t do.

A 750-point Health Check from SQL Solutions Group includes a security audit.

Find out how healthy your SQL Server estate really is.

Learn More

What we will be looking at is the Security tab of the linked server dialog. We’ll also look at the system stored procedures being executed behind the scenes. You can see these yourself by clicking the Script button after configuring the security in the GUI.

Default Behavior for Unmapped Logins

The top part of the dialog box allows us to map local logins to remote logins. This is fairly straightforward and not where the problem usually lies so we’re going to focus on what happens if there is not a mapped login.

We’ll look at the options one at a time.

Not be made

In this case, all that is done is to create the linked server with no login behavior specified. Without any mapped logins, the linked server is useless.

Source code
   
EXEC master.dbo.sp_addlinkedserver @server = N'SERVER1', @srvproduct=N'SQL Server'

If we try to execute a linked server query, we get the following results:

Source code
   
select name from SERVER1.master.sys.databases

Msg 18456, Level 14, State 1, Line 7
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.

It tried to make an anonymous connection to the remote server which thankfully did not work.

Be made without using a security context

In this case, it explicitly creates a mapped login of NULL with @useself = ‘False’. In other words we are explicitly telling it not to pass a security context to the remote server whereas in the first option it tried an anonymous connection.

Source code
   
EXEC master.dbo.sp_addlinkedserver @server = N'SERVER1', @srvproduct=N'SQL Server', @provider=N'SQLNCLI11', @datasrc=N'SERVER1'
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'SERVER1',@useself=N'False',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL

Let’s see what happens when we execute the query here.

Source code
   
select name from SERVER1.master.sys.databases

OLE DB provider "SQLNCLI11" for linked server "SERVER1" returned message "Invalid authorization specification".
Msg 7399, Level 16, State 1, Line 7
The OLE DB provider "SQLNCLI11" for linked server "SERVER1" reported an error. Authentication failed.
Msg 7303, Level 16, State 1, Line 7
Cannot initialize the data source object of OLE DB provider "SQLNCLI11" for linked server "SERVER1".

This option is more secure than the first one simply because it would not work even if the anonymous login worked on the remote server.

Be made using the login’s current security context

In this case, it is going to pass the security context of the local login to the remote login. If you have to have an option to connect without a mapped login, this is the best option. Note that the call to sp_addlinkedsrvlogin is almost the same as the last one. The only difference is that the @useself parameter is True.

Source code
   
EXEC master.dbo.sp_addlinkedserver @server = N'SERVER1', @srvproduct=N'SERVER1', @provider=N'SQLNCLI11', @datasrc=N'SERVER1'
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname=N'SERVER1',@useself=N'True',@locallogin=NULL,@rmtuser=NULL,@rmtpassword=NULL

Let’s see what happens when we execute the query here.

Source code
   
select name from SERVER1.master.sys.databases

It worked this time. The login used on the local server also existed on the remote server so the user connected as if they were directly connecting to the remote server. One thing to note is that with standard logins, this will only work if the login name AND password are the same on both instances. If the login name is the same and the password is different you will get the following error:

Msg 18456, Level 14, State 1, Line 11
Login failed for user 'UserA'.

For this reason, this is a lot easier to deal with when using Active Directory accounts. As long as the AD-based login has permission on both instances it should work just fine, with one caveat. Depending on the configuration of the AD environment you’re in, you may run in what is known as the Kerberos Double Hop issue. Typically you’d be going from a user’s workstation to the local server to the remote server. So two hops. A full discussion of this is beyond the scope of this article but suffice it to say that Kerberos delegation must be properly configured in the environment for this to work.

Be made using this security context

This is unfortunately both the most commonly used and the least secure way to address the security configuration of your linked server. What we are saying here is that every user who uses the linked server will be authenticated on the remote server using the credentials provided here. This is RARELY going to be the right thing to do in a secure environment. A user with public on the local server and nothing else will connect to the remote server using this login’s permissions which are usually higher than that. I’ve seen more than one environment using an account like linkedserver that exists and is a sysadmin on every server!

Source code
   
EXEC master.dbo.sp_addlinkedserver @server = N'SERVER1', @srvproduct=N'RKLAPTOPSS', @provider=N'SQLOLEDB', @datasrc=N'SERVER1'
EXEC master.dbo.sp_addlinkedsrvlogin @rmtsrvname = N'SERVER1', @locallogin = NULL , @useself = N'False', @rmtuser = N'UserA', @rmtpassword = N'password'

I won’t bother executing the query for this one because obviously it will work.

Remote Login Mapping

We didn’t spend a lot of time on mapped logins because that is fairly straightforward. We can map a local login to a remote login, providing the login name and password on the remote server. This is useful if we can’t control the login name and password on the remote server. It is also useful if we want to control exactly who on the local server can use the remote server. If you have logins mapped here and are using one of the first two options for the default behavior, only these users will have access to the remote server via the linked server.

The Impersonate option is just what it sounds like. This is effectively the same as the Be made using the login’s current security context but applies to a specific login, not all of them.

In this example, the only users who can access the remote server are UserA and UserB. For UserA, we have specified the login name and password on the remote server. UserB has the same login name and password on the remote server so impersonation can be used.

The post Security Configuration for Linked Servers appeared first on SQL Solutions Group.

Easy Permissions Audit

As the article title denotes, today I will be discussing a simple way to get quick permissions for various principals. If you are looking for a more comprehensive and human friendly report version, I recommend reading any of my many other articles on the topic such as the following article – here or here. In the second of those links there is a clue as to what tool we will be using in this easy version of the audit. That tool is called sp_helprotect.

The stored procedure sp_helprotect is a system stored procedure from Microsoft that can help divulge permissions for various principals in a simple table result set for you. Bearing in mind that I am keeping this to a simple audit, the examples will be simplistic in nature. Without further ado, here is the easy audit for your permissions.

sp_helprotect

This stored procedure was introduced in SQL Server 2008 and comes with a few parameters to help narrow the results down to a specific principal and even to any object to which that principal may have been granted permissions. Here are those parameters for quick review:

@name = This parameter is to filter your request down to a specific object or a statement that can be executed against that object (e.g. alter, create, drop)

@username = Is the name of the principal for which permissions are returned.

@grantorname = Is the name of the principal that granted permissions.

@permissionarea = This is the group of grant-able permissions. There are two types of groups: object and statement. The default setting here is to return both groups.

The easiest way to use sp_helprotect is as follows:

Source code

USE TestDB; --my test database...you need to change it
GO
 
EXECUTE sys.SP_HELPROTECT

Do you see how easy that is? This returns the following results for me.

Note from the results that I see results for roles and users for various different objects. This is due to how the procedure was executed – with no parameters. Using no parameters in this query, the default behavior is to return as much information as possible for all objects and principals within the database.

What if I only want the results for a principal named “Gargouille”? I can do that in the following way.

Source code

USE TestDB; --my test database...you need to change it
GO
 
EXECUTE sys.SP_HELPROTECT 
	@username = 'gargouille'

Now, I will receive the following results:

Recap

There are many ways to produce an audit. Today, I have shown how one can produce a permissions audit when in a hurry that will produce a simple result set for database permissions. I want to underscore that this was at the database level and not the server level. While this is an adequate means for a quick peek into some of the objects and granted permissions, I do recommend using one of the other methods I have introduced in the other articles for ongoing complex audits and results that are somewhat prettier and more human friendly to read.

The post Easy Permissions Audit appeared first on SQL Solutions Group.