Time to Stop Deploying SQL Server 2016 and Windows Server 2016

By: on July 13, 2021 in SQL Server 2016, Windows Server 2016 | 2 Comments

Today is July 13, 2021. Besides the anniversary of Live Aid in 1985 (had to sneak a music reference in somewhere!), today marks an important date: the end of mainstream support for SQL Server 2016. The last Cumulative Update was CU17 released on March 29, 2021. UPDATE: Thanks to Glenn Berry (Twitter | Blog), he pointed out that Microsoft announced that SQL Server 2016 Service Pack 3 is coming around September 2021 give or take.

Windows Server 2016 is on a similar trajectory. It is out of mainstream support on January 11, 2022 – less than six months from now.

What does this mean for you?

Getting Support

A key aspect of being mission critical is having platforms that are supported. In other words, if your business critical systems have an issue, you want to be able to pick up the phone and call Microsoft or whoever to get help. All help for the next five years will be paid. Keep in mind as time goes on, people who know this version of the product well will become smaller.

Getting Updates

Both SQL Server 2016 and Windows Server 2016 fall under the Fixed Lifecycle Policy. When things transition from mainstream to extended support, that means no more updates outside of security for the next five years. The aforementioned SQL Server 2016 SP3 is more of a one off exception. While getting security updates is a good thing, that means if you encounter a bug in SQL Server 2016, unless you’ve paid Microsoft bigger money for the right type of support contract, you are out of luck. The core, mission critical platforms in your company should be in mainstream support if possible and receiving regular updates – not just security.


Applications, whether homegrown or purchased, need to be checked. What version of SQL Server are they running now and what do they support? Will you need a new application version to support a later version of SQL Server? Do you need to do extensive testing or fix things if homegrown? What else is involved to get you from here to there to ensure the application can work with a later version of SQL Server and/or Windows Server?

Plan an Upgrade/Migration Strategy

First and foremost, if you are still deploying either of the 2016 versions for brand new deployments, you should stop or have a plan to wind that down. For SQL Server, you should strongly consider SQL Server 2019 as SQL Server 2017 going out of mainstream support is not far behind SQL Server 2016. SQL Server 2019 can run on Windows Server 2016, but you should really be deploying it on Windows Server 2019 these days.

If you are currently using SQL Server 2016 (or WIndows Server 2016), do you have a timeline, strategy, and plan to get off of them? If yes, great. If not, what are you waiting for? I am not saying you need to upgrade tomorrow but do you want to become a victim of technical debt more than you probably already are?

Next Steps

SQLHA can help you evaluate where you are, help you plan to get off of older versions, and get you safely and efficiently to newer versions with minimal downtime and risk. We get there are more than technical factors at play when it comes to any upgrade/migration scenario and that it takes time to plan and get it right. Stay ahead of the curve. Reach out to us today and start your journey whether it is on premises (physical or virtual) or up in a public cloud.

Remembering Brian Moran

By: on July 12, 2021 in Other | 2 Comments

Friend. Mentor. Colleague. Husband. Father. Parrothead. Lover of Hawaiian shirts, Crocs, and boats.

While not in any specific order, those are just some of the words that could describe Brian Moran. Brian passed away suddenly this past weekend. He touched many people in the SQL Server community over the years and this loss is a tremendous one. I do not know what happened nor does it matter; my condolences to his family and anyone whose life he touched.

My history with Brian goes back at least 20 years, if not more. I’m pretty sure I met him at one of the early PASS Summit events as I was becoming active in the community. He was just always around at that time. We got to know each other.

Over the years his involvement with PASS waned but his enthusiasm for SQL Server did not. He still participated in the community, albeit more locally to where he lived. I went down to his user group in I believe Reston, VA, to speak a few years back.

Brian played an instrumental part in me becoming the consultant and business owner I am today. He is also a reason I give back and mentor when I can. For that I cannot be more grateful. One example: when I was transitioning consulting jobs in the early 00s, Brian helped me out with some small engagements to tide me over. We worked together on and off.

Most importantly, he would always lend an ear or support if you needed it. He would make the time. Brian was there for me in a few situations over the years and I was happy to provide the same for him. He was never judgemental and even if you disagreed, Brian was the type of guy where you agreed to disagree and remained friends.

Brian was one of the friendliest people you could ever meet. He always cared about others and would help when and if he could which is one of the reasons this is so shocking; one of the good ones is gone.

While he and I lost touch the past couple of years, that did not make him any less of a friend. In the “should have” category, I was thinking of checking in on him recently to see what he was up to. He was on my mind.

Our time on this spinning blue ball is short. Make it count. Don’t leave important things unsaid. Let some stuff go and forgive if you can (not saying it’s always possible). Hug your loved ones a bit tighter. Be a mensch – Brian certainly was.

Rest in peace, Brian.

If you knew Brian, you have your own memories. Feel free to share down below.

Ignite Announcements – What’s New for Windows Server 2022 and SQL Server

By: on March 4, 2021 in AWS, Azure, GCP, SQL Server, Vmware, Windows Server 2022 | No Comments

At Ignite this week, Microsoft officially announced Windows Server 2022. This version follows the three year pattern for the long term servicing channel (LTSC) branch of Windows Server. What does this mean? Some point later this year or early next year you will be able to deploy SQL Server using Windows Server 2022 on premises (physical or virtual) as well as using Infrastructure as a Service (IaaS) in your cloud provider of choice.

In this post I’ll be highlighting the things I think are important from a SQL Server perspective that were announced this week at Ignite.

Windows Server 2022

VMware and Cloud Provider Support

Outside of Azure where you can spin up a preview IaaS VM, I have not seen anyone announce even preliminary support for Windows Server 2022. This will be crucial for adoption. I would not expect that VMware would certify going back to even vSphere/ESXi 6.5. For example, the VMware Compatibility Guide only lists through Windows Server 2019.

Windows Server 2022 is not RTM yet. Be aware supportability must be on your radar map especially in non-physical architectures.

SQL Server Support

It is unknown which versions of SQL Server will be certified for use with Windows Server 2022. Based on prior releases, assume the following:

  • Any new version (if there is one) released in Windows Server 2022’s mainstream lifecycle (i.e. first five years) will be supported
  • You will get one, possibly two versions of SQL Server that are currently in support at the time of Windows Server 2022 RTM. SQL Server 2017 and 2019 come to mind as those versions.
  • I would not expect SQL Server 2016 and earlier to be supported since SQL Server 2016 will be out of mainstream support this summer (July 13, 2021 to be specific).

I am not Microsoft and those types of announcements will most likely be made closer to release.

More Memory and CPU

With Windows Server 2022, you can have bigger deployments of SQL Server. Windows Server 2022 supports up to 48TB of memory as well as 64 sockets and 2048 logical processors. That is a lot of compute power. Of course licensing a server that big will be fun. If you are using virtualization or IaaS, check your hypervisor or cloud provider to see what the maximum VM size is.

For ESXi 7.0, you can see the maximum of what a VM can support with the VMware Configuration Maximums web-based tool. With vSphere 7.0, you can currently (as of the writing of this post) use 24TB of memory and up to 768 vCPUs. Both require virtual hardware version 18. As it stands today, even when VMware supports Windows Server 2022, you would not be able to use all of what this new version supports.

Improved Security

One of the pillars of Windows Server 2022 is security. There are a few things that will potentially impact SQL Server.

Group Managed Service Accounts v2

Group managed service accounts (gMSAs) are also improved in Windows Server 2022. Not much detail is out there at the moment. gMSA v2 does allow Active Directory-dependent apps like SQL Server to work on non-domain joined hosts. The scenario I saw has to do with Windows Server-based containers (not really a SQL Server scenario at the moment), so again, this is a “stay tuned” thing for me.

If you want to understand more about gMSAs, read Steve Syfuh’s (Twitter | Blog) blog post “How Managed Service Accounts in Active Directory Work“. In general I recommend you follow Steve if you care about Windows Server and security.

Secure Computing

If you are using Intel’s Ice Lake (and obviously later) processors, Windows Server 2022 supports confidential computing with Intel Secure Guard Extension (SGX). This combination means applications can be isolated.

For SQL Server, this is supported via the Always Encrypted Enclaves in SQL Server 2019 or later. It works in VMs in Azure (on premises under, say, VMware is unknown) but I’m unsure how it is enabled.

Secure DNS

Windows Server 2022 will feature encrypted DNS name resolution. While not SQL Server specific, this is just a good general improvement.

Server Message Block

Windows Server 2022 supports SMB with AES-256 encryption. The most immediate impact will be for both Always On features, but most likely Always On Failover Cluster Instances since they can use SMB for storage.

Any east-west (i.e. intra-node) Windows Server Failover Cluster (WSFC) communications will now be able to be more secure.

I have not received confirmation if a file share witness in Windows Server 2022 will use the new SMB encryption.

TLS 1.3

By default, Windows Server 2022 will use TLS 1.3. While in theory this should not affect SQL Server, past history tells us it will – here’s some proof with older versions. The impact to SQL Server – if any – is unknown at this time. Stay tuned.

Hotpatch Windows Server

Before you get too excited, understand this is what everyone has been asking for but many may not be able to use. Yes, it means that Windows Server can be patched with no downtime. However, it is currently only for Azure-based IaaS VMs. It is in preview now and here is the documentation. I had a Twitter conversation with Carmen Crincolli who confirmed this initial rollout is for Windows Server 2019-based VMs.

What does this mean for you? Simple. If you’re not in Azure and not running the right version of Windows Server you’re not getting the ability to hotpatch.

Don’t misunderstand me  – I love this feature but I hate its scope is currently very limited.

Windows Server Azure Edition

I thought this was some sort of typo or mistake dropped in the hotpatch documentation. Nope! It’s apparently a confirmed new variant of Windows Server per this Twitter thread from Ned Pyle. More on this as I find out. Here is what you see in the Azure Portal. Of course what is in the hotpatch documentation (Windows Server Azure Edition) does not match what is in the GUI (Windows Server 2019 Datacenter: Azure Edition). That stuff drives me bonkers but at the same time, it’s so Microsoft to do things like that.


Azure portal showing the new edition of Windows Server

Azure portal showing the new edition of Windows Server

Windows Admin Center

I did an unscientific poll recently on Twitter. 94% of the people responding do not use Windows Admin Center (WAC). I have a blog post coming on why I find WAC poor for SQL Server-based deployments.

Event Viewer functionality was added to the newest version(s) WAC. They’re slowly trying to sunset existing admin tools in the OS.

Here’s the reality: Microsoft is not really investing much in improving existing tools if they are not WAC-ready. Failover Cluster Manager may not be updated or just get minor things while WAC will get the majority of attention for any GUI-based administration.

Windows Admin Center is also in preview up in the Azure portal.


Unfortunately, PowerShell 7/Core versions are not fully integrated in Windows Server 2022 nor is the WSFC module ported to them. I believe there are dependencies such as WMI that make some of that challenging right now. I’m a bit disappointed but also understand. Maybe someday that module will be modernized.

Azure SQL

High Availability for Azure SQL Managed Instance

Microsoft also announced that Azure SQL managed instance can now be deployed with additional replicas using Azure Arc. Underneath the covers it’s using Always On availability groups. This is obviously a good thing but there’s one major difference from on premises: it includes the system databases. Maybe we’ll finally get that ability on premises (i.e. “in the box”) sooner rather than later …

Long Term Backup Retention for Azure SQL Managed Instance

Sometimes you need to keep backups of databases around for various purposes, not the least of which is regulatory. Yesterday, Microsoft announced that if you are using Azure SQL managed instance, you now have a way to retain your backups up to ten (10) years.

Maintenance Windows for Azure SQL Managed Instance and Azure SQL Database

A common problem many customers face is restricting maintenance to a certain period of time. Now in preview, Microsoft has added the ability to have some control over when maintenance can happen if you are using Azure SQL managed instance or Azure SQL Database. For more information, read the blog post published a few days ago.

The Bottom Line

There were quite a few things announced that flew under the radar. Some of it is very cool.

Windows Server 2022 is more evolution than revolution for SQL Server. I expect once released, it will be at least 2024 (the year) before any kind of widespread adoption. We’re just starting to see Windows Server 2019 gain meaningful traction and adoption with customers. As things are revealed in more depth over the coming months, I may address specific features of Windows Server 2022 that will have significant impact on SQL Server.

To get started with Windows Server 2022 today, you must be a Windows Insider to get access to the builds for use on premises or try it as a VM up in Azure (see picture above).

Let me know down below – are you even looking to the future? Struggling to get to Windows Server 2019 or do not plan on upgrading at all? Are you willing to use Azure just to get hotpatching?

WARNING: Distributed Network Names and Distributed Availability Groups

By: on February 23, 2021 in Availability Groups, Distributed Network Name, SQL Server 2019, Windows Server 2016, Windows Server 2019, Windows Server Failover Cluster | No Comments

Distributed Network Names (DNNs) are a relatively new Windows Server Failover Cluster (WSFC) concept. Up in Azure, DNNs effectively eliminate the need for an internal load balancer (ILB). The ILB allows applications and end users to be able to connect to an AG’s listener or the FCI after failing over to another Iaas VM. You should not really be using DNNs for any on premises deployments.

DNNs are supported as of SQL Server 2019 CU2 and require Windows Server 2016 or later. I wrote more about them in my blog post Configure a WSFC in Azure with Windows Server 2019 for AGs and FCIs. Go there if you want to see what they look like and learn more.

Right now, I cannot wholeheartedly recommend the use of DNNs for listeners or FCIs if you are using Enterprise Edition. Why?

DNNs do not work with a distributed AG which is an Enterprise Edition only feature. A distributed AG is something nearly many customers who have Enterprise Edition implement either for disaster recovery andor migration. If you want to use a distributed AG, you will need an ILB for the underlying AGs and/or FCIs. As far as I know, this is not officially documented anywhere on Microsoft’s site. I did confirm this limitation of DNNs with them.

If you use Standard Edition or think you will never use a distributed AG, you can use a DNN for AGs and FCIs in Azure. For D/R across regions (or on premises to Azure), that means deploying a stretched WSFC which is inherently a more complex architecture or using something like log shipping.

If anything changes, I’ll be sure to update this blog post.

In the meantime, if you would like Microsoft to add support for distributed AGs with DNNs, go add your vote over at Uservoice.

Technical Debt – The (Not So) Silent Crisis

By: on February 16, 2021 in Advice, Business Continuity, Technical Debt | No Comments

Here in the USA, many are experiencing unprecedented winter weather. For example, parts of Texas are without power and heat and experiencing blackouts. A big focus of what I do for customers – business continuity – has to account for things like the power going down. A few years ago California had rolling blackouts in the summertime. Austin tried that in this 2021 storm – and stop me if you’ve heard this before – the plan did not work since what happened isn’t what they expected. From this Austin-American Statesman article:

Austin Energy’s plan was to rotate the outages, meaning more neighborhoods would’ve shared the no-electricity burden for the entire city, for a period not to exceed 40 minutes. But the rotation was not possible, Sargent said, because it would have disrupted service for those critical operations.

There is a reason I strongly recommend testing all continuity plans. For IT folks, you do not just want your servers literally powering off. If that happens, pray you experience no data corruption. How are your backups? Test them recently?

Having said that, the Houston Chronicle wrote a damning article. Here’s the part I want to focus on:

“The ERCOT grid has collapsed in exactly the same manner as the old Soviet Union,” said Hirs. “It limped along on underinvestment and neglect until it finally broke under predictable circumstances.

“For more than a decade, generators have not been able to charge what it costs them to produce electricity,” said Hirs. “If you don’t make a return on your money, how can you keep it up? It’s like not taking care of your car. If you don’t change the oil and tires, you can’t expect your car to be ready to evacuate, let alone get you to work.”

Some of what is happening in Texas is not only due to Mother Nature but also partially because of technical debt. Old, aging infrastructure eventually buckles and sometimes fails. Technical debt is not just an IT problem. Real life examples such as this bring the concept front and center.

Kicking the proverbial can down the road and saying things like “We’ll worry about that later, it’s fine now” is often what makes the end results so painful. Neglect increases risk whether it is intentional or not. Max and I help customers so these big leaps incur less risk and pain including managing external dependencies.

Look at your company if you are a FTE or your customers if a consultant. How many applications and servers have not been even looked at because they “just work” and “it/they is/are fine”? Budget is always a concern, but to paraphrase the old adage, you will pay now or pay later. Paying later is often more expensive. Insert your own scenario or question here but answer this:

What is the actual cost if that system/application/server fails or is unavailable? I bet it is more than if things had been dealt with all along or right from the start. You can sometimes avoid a quadruple bypass.

For those of you affected by this weather, my heart goes out to you. Stay safe and warm. Even though we are in the midst of a pandemic, please check in with neighbors and loved ones.

We must be prepared both in life and in business to handle both the expected and unexpected which also means managing your technical debt. This is what we help our customers do every day at SQLHA, so if you want to ensure your business can not only be resilient but also in a good place to manage handle technical debt, contact us today.