Demystifying SQL Server Licensing: Key Insights & Cost-Saving Strategies

All right, Good afternoon, everybody. I apologize for the delay or Jay was good. Jay Bishop was going to kick things off and host, but he seems to be having some technical challenges. So I'm just going to get started here this afternoon. So the first thing to note is that all attendees are muted during the webinar. But if you have questions, either if you want to send them either via the question box in the GoToWebinar or GoToMeeting Council or during the chat or in the chat box, I'll be watching those throughout the presentation this afternoon and I'll try and answer questions as I go. We're also going to try and leave a few minutes at the end for questions. I actually anticipating that we'll probably have a number of questions today because SQL is probably one of the most complicated licensing models that Microsoft actually has. I'd also say I encourage you guys to ask questions because in software audits with Microsoft, this is probably the number one product that we see attributed to dollars that are associated with audit settlements because it is so confusing. Because getting at the data that you need to do licensing correctly is confusing and challenging. It is definitely an area that auditors really key in on on SQL servers. So I'd like to try and help you guys out if you have any questions as best as possible today. So please feel free to put those in the chat box throughout. The PowerPoint that I'm using probably has a little bit more, if you've attended some of my sessions in the past, probably has a little bit more details in it that I normally give in terms of words on slides. I'm not going to be reading, you know, kind of verbatim the slides, but I've done that because we will be sending these out after and there's a lot of good information in, in here that you can use as reference, you know, as you're looking at your own environments and things of that nature. So I have done that on purpose today for that, for that reason. Like I said, one of the most challenging things with SQL really is the data gathering. And so today I'm going to be focusing primarily on probably more on licensing than on the data pieces itself. But I am going to try and talk to data, how you get at these things, how you protect yourself when you're doing certain things, when it comes to audits and the things that we see, as well as talk a little bit about how we see things, environments that could potentially be costing, you know, a ton of money if and if potentially done slightly differently, could potentially save Money. So for those of you that aren't familiar with the with myself, I'm Mike Austin, I'm the founder and CEO of Metrics Data360. We're a firm that does consulting engagements around software contracts. So helping you negotiate, you know, Microsoft contracts, IBM contracts, those sorts of things. And as well as do audit assistance. So if you are getting audited by software publisher, we can help you defend through that audit. Or if you want to do an internal self assessment just to get an understanding of where you sit on certain things, we can assist you in taking a look at how an auditor would actually look at your environment and making some recommendations from a licensing perspective and things like that. We run sort of a gamut of services from sort of point projects like that either help with an audit, internal assessment negotiation right up to where we do fully managed SAM offerings or software as a management software, asset management as a service now so I'll leave that as the commercial pitch. But today we're here to talk about SQL servers. And I'm not going to go into some of the details on this, but I think one of the things to sort of note on where I want to start is that SQL, probably prior to 2008 or two, 2012, I would probably say that it was considered a departmental application database. Microsoft has been growing its functionality quite substantially. You can see that early on it was like a three to four year release cycle, but they've gone down to a two year period. We had SQL 2012, 14, 16, we had 17 and 19. So they're releasing new versions of this product quite quite frequently now. And you know as they do that, they're adding new functionality into into the product. And so the key thing to note is that it's changed from sort of a departmental use to now where we're actually starting to see it in big data scenarios and things like that. And I'm going to talk about that today because there are some licensing implications there. But you can kind of see what they've done is they sort of had just sort of a departmental database, they moved it to cloud to mission critical. And then in 2017 they added a little bit more in terms of some features around availability and performance and management tools and things like that. And then in 2019 version they've made some big changes. Now they're looking at working with some of the newer technologies out there. So you can now put SQL and containers and Dockers and things like that. But the big thing is their big data play that they have with it. So this Slide is sort of just an eye chart really. But the key thing that I want to get across here is that SQL has really evolved and we are seeing things where people are using it to create data lakes and things like that that primarily in the past were probably more the domain of Oracle and maybe IBM DB2, much more so than they were SQL. But we are starting to see that adapt. We are seeing containers and containerization of SQL Server Server become a play and things like that. So I think you're going to see more and more of this. If your organization hasn't started to look at SQL as a platform for these things, it's probably going to come if you're sort of playing in those spaces. Okay, so this slide here is for SQL 2016. So just sort of some of these slides are older on the older products. And the reason I'm just using them is just it's what I could find in the public domain. So this is the same for 2019. I'm not really looking at this from a feature perspective, but really what I want to get across is that there's really kind of three, I'd say actually probably four real additions of SQL. You have Express, that's free, you have Standard, you have Enterprise, and then you also have the Developer Edition. And I'm going to talk about the Developer Edition a little bit later as well. But you have basically four different varieties of it. There is a web Edition that you can only get through a hoster, and that's for primarily hosting websites. If you're using the backend database, your website is as a sequel. But the key thing is, as all of you know, there's Enterprise and Standard, and there's Express, that's free. And there's a big delta in terms of pricing. Express being free, Enterprise being up to about $8,000 or more per core from a licensing perspective. Okay. And so in 2019 edition, they've added another. I don't want to kind of call it another addition because it is licensed as SQL Enterprise or Standard. But they have added on sort of the big data version of SQL that is licensed, where the master. And I'm going to get into this in a little bit of detail here later, but that is licensed, where the Master is licensed, either with SQL Standard or Enterprise Edition, then they have these big data node licenses. Now for the nodes, when you're into a big data architecture, another license type has been added to the product mix. These big data nodes. Again, I'm going to talk about that in a little bit of detail. Here the one thing to note is that if you are doing SQL in a big data implementation, that you still can do standard server Cal Enterprise only per core. So it's per core licensing primarily. Here I'm going to talk the generics of SQL licensing. I'm going to assume most of you are aware of how this works, but I'm going to talk about it in some detail and talk about where people get tripped up on these different licensing models when it comes to SQL. The first thing is that there's. This is one of the areas that people sort of get tripped up on when they're looking at their estate and trying to figure out licensing right away is there are a few different terms or I don't know if it's. Technology is the right word, but terms that you need to understand the implement implications from a technology perspective. Right. So you have a physical server, which I think we all know what those are. Those are the hardware. You have a physical processor. So that's the processor in the box, the cpu. You have physical cores. So your processors are broken down into cores and then you have virtual cores. And so a virtual core is when you virtualize, it's a basically virtual CPU that's assigned to a database. And then you got a hardware thread that's either a physical core or hyper thread of the physical processor. And so this concept actually gets a little confusing between cores and threads sometimes and actually causes some data challenges too. If you're using hyper threading, SCCM sometimes for instance will over report the number of cores that are in a physical server. So you know, it's not uncommon to see like, I don't know, two processor eight core box show when hyper threading is on that the physical attributes of that box are 32. So you know, and one of the things that we do when we look at our data of our clients are we're gonna look for processor counts that look strange because this is one area where that over licensing happens quite often is because hyper threading is used and it's over counting the number of cores. So we go into our data sets and we look at a couple of different things. We actually created a catalog of processors that when we grab the processor information from a hardware perspective, we've cataloged how many cores are on those processors. So we do a cross check there. But we also look at just the data itself because if it's to look and see if there's any odd number of cores that are showing up or if it just looks like servers got a lot of Cores, we would go back and validate that. So definitely one thing to be careful of there when you're looking at inventory data is if you know that hyper threading is going on, is to double check the number of cores that are being reported in your management tools. The other concept is this concept of a physical operating system environment or an OSE that can be run on a physical box. It could be your Windows Server on a physical box, or it could be a Windows Server that's running in a virtual environment on a vm. OSC has become important because that's how everything gets tied back when you get into the licensing is where's the OSC reciting? And then how are you counting these things? So whether they're virtual cores, physical cores, depends on what's going on. And I'll talk about that in a little bit more detail. But these are the key concepts. When we look at doing an assessment, one of the things that we're going to look at is do we have all this information when we're looking at your SQL databases to make sure that we have all of this to give us a complete picture before we start actually looking at licensing. There's a couple other things that I would say that we include when we look at that guest to host relationships and clustering and things like that. But these are the core things that you need to understand from a licensing perspective. The Server CAL model from a licensing perspective for SQL Server is something that's not seen very often anymore. Most people are licensing this on a core basis, although there are still some customers that do server cal. And there are some scenarios where maybe you do a subset of server cal. The way that a server CAL licensing model works is you buy a SQL Server for the ose, whether it's a physical or virtual. You buy a SQL Server license for the OSE and then you buy client access licenses either for every device or every user that actually accesses the server. Okay, so you can either divide device CALs or user CALs. You could do combinations. Maybe some scenarios where you've got users that have multiple devices, you'd buy user cals. And then maybe in a manufacturing facility, you might divide device based cals for your shared workstation or kiosk environment. So the server CAL model, it's fairly straightforward. I look at The OSE where SQL's installed, that's standard. I can assign the server license, and then I have to be able to count the number of users or devices that are accessing that database. Now the only server CAL license I can buy today is standard Enterprise does not come in this model anymore. Now, there are a number of people that potentially carry SA, because when Microsoft discontinued the server CAL model in 2012 for SQL Enterprise, if you had active SA, you could continue to carry it. Some people still have active SA on SQL Enterprise, and so that would still work. Here. You do get four VMs per SQL Enterprise license instead of it being per VM as a standard. Enterprise does have a little bit of an advantage there. The issue and the challenge that we see, in fact, in most of the audits that we've done, if you have server CAL models, auditors don't even really look at it. They won't even accept the Server CAL licensing model. And the issue really becomes what Microsoft refers to as multiplexing. And that's where you might have a database where you can say, okay, it's a departmental database. I know that I have 10 users that use it. So instead of buying cores, I'm just going to buy a server CAL model because I can buy a server in 10cals for a lot cheaper than buying, you know, four cores of SQL standard. And so, you know, in that scenario, it makes sense. But the challenge becomes, is that database or the application that is utilizing that database providing information to another system, Right? So an example of this might be hospital, where you go in and you check in, and the badge system where they give you the band that they put around your wrist when you go in. You know, it's only used by a few different people, right? So they might say, okay, well, in the hospital, we know that it. Or maybe it's only done on 50 computers. So we'll buy 50 device licenses because we know that those devices are the only ones that have access to that application. The challenge becomes is that information, the patient's information is then fed into other systems like hospital management systems and things like that. And so there you can't. You would have to buy client access licenses for. For all devices or users that access that because it's feeding it. And so Microsoft kind of use that as multiplexing. And so it becomes very difficult to actually control or prove that you have controlled that access. And so that's why a lot of people don't use this model anymore, because the management of it can become difficult. It's also difficult to tell. There's no logging of or no easy way to do logging of users or devices that access a SQL database. So it's hard to prove that, you know, even if you said it was only 10 users or 10 devices, it's hard to prove that sometimes you can go in the application and show where applications done or through Active directory groups potentially or things like that. But it's very difficult to actually control this. And so this is one of the reasons why a lot of people don't use it. Although it could be a very cost effective manner in certain scenarios to license SQL in order to actually be able to prove that you're compliant from a license compliance perspective, you'd have to be able to demonstrate control and that multiplexing is not going on. And so this is one of the reasons why a lot of people don't license in this model anymore. The other thing as well is if you've got external access it becomes difficult because you would have to have client access licenses for non, like for anybody that's accessing externally. So again it's really difficult to manage this. But again we do look at this because it can be a very cost effective manner if you have the controls in place to demonstrate that multiplexing is not going on and you know exactly who has access. So the other model that Microsoft licenses from is the per core model. Right now I'm going to talk a little bit about processor licenses because a lot of organizations, although it's come to end of support 2008 SQL, there's still a ton of it out there in people's environments and they're perpetual. If you have perpetual licenses that you didn't carry software assurance on, then you could still have processor licenses. So processor licenses were fairly straightforward. Basically you looked at the number of processors in the server and you bought the number of processors that you had and then if it was standard or enterprise and then any number of users can access. So I don't have to have that client access license. I don't have to worry about whether it's device or user based licenses. With cores any number of people can access, I can have external people coming in and things like that. So this model of processor which is now converted to cores was fairly straightforward, right? Because I could just buy the per processor licenses or now it's cores and so cores basically the core model basically works that for every processor, physical processor in the box in the server, the physical server I need to have a four core minimum. If I have a one processor, two cores, I actually have to buy four core licenses and it's a two processor minimum type thing as well. So I'd actually have to have eight cores license where it says four core licenses. The slide is they're sold in two packs. So to confuse everything, you got to kind of either multiply or divide by two. Okay? And so other than that, I just look at, if I'm licensing, it's on a physical environment. I'm just going to look at the number of processors in the box, remember the four core minimum and determine the number of core licenses I need. So if I've got two two core processors, I need eight cores. If I've got one eight core processor, I need eight cores. If I've got two eight core processors, I need to buy 16 cores, convert that to licenses at eight in a virtual machine model. So in a VM where I'm virtualized, the way that it works with server cals is again I talked about it briefly in that other slide there is that I basically look at the OSE. So the virtual operating system environment, if SQL's installed there, I assign a server license to that. If it's a SQL standard, I assign SQL standard. And then I have to go through that exercise of figuring out how many cals that we talked about, either user or device based. If I have SQL essay on Enterprise, I get the four VMs up to a maximum total of 20 virtual cores. They do put a little bit of a limit on there that Enterprise can only go up to a maximum of 20 virtual cores. So as long as they got 44 core or less VMs or 5 core, I guess, but 44 core less VMs virtual cores, then I'm okay there. Okay, so again, that one's fairly easy. I look at the OSC, I see if SQL's installed, if it's standard, I can assign a standard license. Then I gotta go do the work to look at user and device calls. If it's SQL Enterprise, as long as I have SQL Enterprise SA that I've continued or own a perpetual license, I guess I can assign it to that. But I also can assign it to cover four different, four different VMs. Okay, so that's kind of the way that server CAL licensing works in a VM. Fairly straightforward. Counting CALs is a little difficult. Managing the enterprise versus standard becomes difficult. But you know, you can, you can do that. Now in a virtual environment. There's really two ways that you can license a virtual environment. Okay. And this is different than Windows and it causes confusion for people a lot of the times. Okay, so in a virtual environment, I can license the virtual cores or I can license the physical cores. And I'm going to come to that in a second. Okay, so again, what I'm going to do from a sort of real simple perspective is I'm going to take a look at my inventory. I'm going to see that I got a virtual operating system environment that has SQL. I'm going to look to see if it's standard or Enterprise. I'm going to look at the number of virtual cores that it's utilizing or have been assigned to it. And then I'm going to buy that number of core licenses of either standard or enterprise. And so I can look at all my VMs and look at all of them that are standard. Look at all of them Enterprise, look at the number of virtual cores are using. Again, remember that we have a four core minimum. So even if it's only using one virtual core, I have to actually license four core, four cores of that. But I'm just going to go and look and do, you know, add that all up. Okay. So I can look at VMs and license basically the VMs themselves. Okay. The other way that you can license for virtual machines is you can actually license all the virtual cores or sorry, not virtual physical cores on the box with SQL Enterprise with sa. So as long as I have software assurance on that, I get unlimited virtualization. Okay, so again, this is a math exercise. We don't see a lot of people licensing SQL for unlimited virtualization because it's very tough to get enough density unless you've created dedicated SQL clusters to justify the cost of licensing all the physical cores with SQL Enterprise. But it definitely is a way that you can save money if you can actually create clusters and go through that, then if you can create clusters that are dedicated to SQL, you can potentially get them dense enough that it makes sense when you do the math. But I would say that we probably only see unlimited VM writes in SQL with the essay at the physical box and just put as many on probably only about 10, 20% of the SQL instances that we see across all the customers that we work with. So it is something that you have to be thinking through from a which a costing perspective and your architecture there. Okay, So in a, there's a question that that was asked on in the case of licensing through virtual cor. If it's using Hyper threading, do we need to worry about counting threads? Basically it's a one to one relationship. So it's either vcores or virtual threads that you're counting, depending on how it's architected. That one gets a little bit technical and I'm happy to have probably a conversation offline on how you look at that in inventory data. But usually it's a one to one relationship where you either count the threads or the cores. But sometimes depending on your tools and the way that they report, things can be done differently in each of those tools. So if you reach out to me, my email will be up at the end. I can maybe give you a little bit more specifics to help with that. Okay, so this slide I think I can skip because this is the one where I just talked about the unlimited virtualization that you get if you, if you use SQL Enterprise on all the cores. The big thing that catches people in VM environments. Most people know it now, but it's what they call license mobility. Again, this slide's got a lot of words on it. You can read it while I talk. I'm just going to talk about how this is relevant and why it's relevant and the challenges that we see people get themselves into when it comes to licensing SQL. Here at the root of it is Microsoft has this rule that they call it the 90 day rule where basically you can only reassign a license from Microsoft once every 90 days. If we take a simple example where I have two host servers and one SQL VM and that VM can go from either Host one to Host two, basically what Microsoft's rules state is that the license can move from host one to host two, but now it's tied to host two for 90 days. So you can't move if the VM moves back to Host one, you can't move the license with it and then you get non, you get into this non compliant state. So now what Microsoft did, which was very generous of them, was in 2008 you were allowed to move them. Didn't matter. The licensing rules for SQL allowed for this, but in 2012 they came out and said, well, we're going to make this great essay benefit and we're going to make it free for you to move those unlimited number of times without violating the 90 day rule if you have software assurance on your SQL licenses. So if I go back to that scenario, Host 1, Host 2, 1 VM, if I have license only, you know, technology like VM, VMotion is turned on. Once it moves to Host 2, it's tied there for 90 days. If it moves back to Host 1, the license is stuck. If I have software assurance, move it a million times a day, they don't care between Host one and Host two. Okay, so one of the things to note here is that a lot of people, the only reason they're buying software assurance on SQL, I shouldn't say the only. But the primary reason they're buying software assurance on SQL, this right here, right? Server mobility, because, you know, their VMs are moving right now. They don't move as much as Microsoft likes to think they do. Right. Microsoft, I think, believes that these VMs move around all day long. And in some architectures they do, but a lot of the times they rarely move. Okay. So if you think about software assurance and the cost of it, you know, when you're looking at, I think when we did an analysis recently, I think we believe about 50% of our customers are still running 2008 R2. Like 50% of the databases are still 2008 R2 or older. Right. So you're not getting any benefit out of the upgrade rights of software assurance. You're paying for it for this. And so, you know, in your physical environments. One of the things you may want to be considering, because I don't have VMotion, right, if I own 2019 SQL Server, I'm running 2012 or 2014 or 2017 or have the rights to upgrade to 2019 and run it for till 2029 and be supported. Do you really need SA on those physical environments? I mean, we challenge our clients all the time on that because they're not upgrading. They just don't upgrade quick enough to justify SA there. But when you get into license mobility in virtual environments, you need it now. There are ways to even limit this. Like we had a client recently where when we were looking at their, their server environment and what they were doing, they had to have a lot of essay to cover server mobility. And so we sort of worked with them to look at their clusters and sort of things like that and decrease the number of SA by actually certain servers just saying, let's lock these things down with affinity rules because they didn't need to move. And so, you know, they could drop SA and stuff like that. So those are the sorts of assessments that you can actually do is start to look at your environment and say, does it really need to be architected, you know, in that manner? Because if it doesn't, you know, it's costing us a lot of money for, for this essay. But that is where they really catch it, right? Is this, this essay, that's why you have to buy it, is this license mobility. One of the things that I will say is in an audit, they're automatically going to assume that if it's virtualized, it's moving, so it needs essay. And so you need to be able to document to. If you're not buying sa, you need to be able to document that it doesn't move. So you need to be able to show that with infinity rules within vMotion, the only place that you can see whether things are, how often things move are in that I know of, are in VMware logs. And a lot of people don't keep 90 days worth of logs just because of the volume of them and things like that. So, you know, even if you want to say it doesn't move, they would say, okay, show us the logs that doesn't move and give us 90 days worth, which a lot of people don't have. So, you know, the best way to protect yourself is with affinity rules and lock, lock them down if you don't want to buy essay for license mobility. Okay, so the next concept is license mobility to shared servers. Okay. And so shared servers. I'm actually going to talk about this for a couple of minutes because this is another area that we're seeing Microsoft and their auditors dig in on are what they determine the shared servers. So one of the terms in your agreements with Microsoft state that you cannot share physical hardware and use your commercial licenses from EAs and you know, MPSAs and slacks or open agreements, you can't use shared, what they call shared hardware. So shared hardware is when two unaffiliated third parties are using the same piece of physical hardware, whether it's virtualized or not. Right. So when you move, when you move to the cloud, you're on shared servers. When I move to Azure aws, I'm sharing hardware with multiple people. I don't know who that's Shared servers with SQL, with sa, they allow you to move to shared servers. If I have sa, I can move my SQL servers to shared servers. Cloud, just in cloud aws. Now this is different than Windows. Windows does not have this, right? They don't have license mobility with Windows. That's why you can't move your Windows servers to aws, but you can move your SQL servers to aws. And I put the link in here because I knew I would get asked it. But you can move with SA to AWS currently until Microsoft changes this. But it's through license mobility that you're able, able to do that. Okay, now there's a bit of a process that you have to run in order to do that. You got to make sure that they are a, what Microsoft calls a license mobility partner. And then you got to fill out some forms. You got to submit those forms to Microsoft in order to be able to do it. But it is possible. Okay. Now, one of the areas that people are getting in trouble with shared servers are internally. Okay? So a good example of where this happens is you divest yourself of an organization, you put a transition agreement in place where you're going to support that organization that you divested out for a period of time. And they're accessing your servers, you no longer own them. They're an unaffiliated third party. Now I'm actually running shared servers internally that I can't use my EA and Select agreement for or MPSA agreement. If you have scenarios where you have unaffiliated third parties sharing those servers with you internally, you could be in violation of the product terms. And they're starting to look for this in audit. And it happens quite frequently. Mergers and divestitures is one example. Now there are things like where you are allowed to let customers come in and things like that. So it's not where you're letting them come in to access your application. It's where you're supporting them on that sort of stuff. So some clients, depending on your industry, you may actually have an application that you sell to clients. So you know, you've created an application, you're selling that to clients. You got multiple clients on the same servers that are coming in. That's shared infrastructure. There's a different licensing model. I'm not going to go into that today. But you want to be watching for those shared server scenarios internally because if in an audit they get sniffed out, that's definitely one area that they're, they're starting to, to come after because they call that commercial hosting, which is in violation of their license rights. The next thing I want to talk about is licensing SQL Server for big data clusters. I'm not going to spend a ton of time on this because it's a newer license model that they have. It's just come out. Like I said, I do have a couple of clients that are already heading down this road. But I just want to plant the seed for you guys so that if you start hearing about Big Data with SQL being used in your environment, at least you can go, hold on. Mike said something about that. Come back to the deck and kind of figure out what happens. Okay, so basically in Big Data you've got a server, what they call a SQL Server Master Instance. Now the one thing is, this doesn't have to run on Windows anymore. It could be on Linux. So one of the things here is that is licensed with either SQL Standard or Enterprise and under the same Rules, right? So the number of cores, you buy those core licenses and off you go. But then you get these data nodes, these big data nodes, big SQL Server big data nodes that go under it. I'm going to show a slide on the architecture here next that are licensed with a SQL Server big data node. And then there's some software assurance benefits that come with this as well that I'm going to talk to. Just think that when I get into big data clustering and those sorts of things with Microsoft, I potentially need these big data node licenses now that I didn't need in the past. Right? That's the key thing is the main instance is licensed the same way as it has been today. The big data nodes have a new license type. Okay? And so sort of what ends up happening, as I said, is you just count the number of cores. The rules kind of apply the same way, except for when you get to the big data nodes, except for if you're an unlimited virtualization. So if I've got a SQL Enterprise where unlimited licensing, I don't have to worry about the big data nodes. But like I said, that tends to be rarer in terms of people licensing that way. So what's the essay benefit here? Okay, so basically, if I have. Here we go. To make things confusing the way Microsoft always does, if I have software assurance on SQL Enterprise, I get eight times the number of cores that are on the master in big data nodes for free. So let's just say it's four cores because that's the minimum. I get 32 big data nodes for free. The 33rd I have to buy this new big data node license for. Okay? So depending on how many big data nodes I have and how many I get for free, determines whether I need to buy the big data nodes. I need software assurance in this scenario, by the way, I can't do this without essay. So it's another one where they're making forcing you down that path of needing essay. Now, with SQL, it's one to one. So if I got four cores of SQL standard at the master, I get four big data nodes, okay? But if I need 32, then I gotta go up and buy 28. Okay? So if you sort of look here, here's a SQL Enterprise scenario. So each one of these are just identified as four cores. So the master is four cores, and I got what, 8 12, so 48 cores in the big data nodes. So with a SQL Enterprise, I buy four SQL Enterprise cores, I get 32 big nodes for free, which means I got to buy 16 big data node licenses. This is where it gets confusing is now we got to track from an inventory perspective not just what is the master instance, but how many big data nodes there are. That's going to create all net new inventory challenges, I'm sure. Same scenario, but it's SQL standard. I buy SQL standard, four cores, I get four big data nodes for free. And so I got to go and buy 44 big data nodes to get to the 48 that we have in that scenario there. That's about all I'm going to touch on on big data today. Just because it is new, not a lot of people are doing it yet. But just planting that seed that if you do start to hear of it, that there is this big data node thing. So I'm going to have to think through two things. One, what's my inventory and how do I inventory a master versus big data nodes? And two, that there's a big data node license. Now before I go into some of the other considerations here, the other one to think about is containers contain. So Microsoft did something in this month's product use rights that is new. In the past they just sort of said they just sort of contain containers within the standard SQL licensing. They pulled it out as a separate part of the product terms this month. That said, you know, here's how container licensing works for SQL and container licensing basically is the same as core based licensing. The number of vcores that are assigned to the containers or the number of threads which would then be a core license in the containers is how you license and it follows all the SQL rules today. It's basically if you're doing containers for SQL, it's the same licensing rules as applied today for the cores, but I think they pulled it out. My guess is as container becomes more popular, I think we're gonna probably see some different licensing methodologies for for containers. But today it works the same as cores. Just think of the number of cores assigned to the container or hyper threads assigned to the container. Equally a core that, that needs to be licensed. Okay, so a couple other things to note. They've changed some of their failover rules. Okay. So this is one that a lot of people were taking advantage of. So basically we kind of think of this as the active passive thing, right? So in the past, if I had again, I love Microsoft, right, because they always do things that they try and make seem like a benefit that truly isn't. So prior to 2012, Active Passive was free, right? Basically if I had an active server, I didn't have to license the passive side. 2012 comes along and say, well, we're going to give you this great new essay benefit. You have to have essay in order not to pay for the passive side. So it used to be I didn't have to have essay 2012. They made it, you know, you need essay again. It's because essay is kind of, I said, people don't upgrade SQL. It's not worth it to buy for the upgrade piece on SQL Server. And so they're just trying to throw stuff in to force you to continue to pay essay here. Okay, so how does it, how does it work if it's a passive node? I don't have to license it if I have essay. Okay. And so passive, you know, basically means that it's, it's sitting there, it's not running, it can fail over. But you know, you can do some maintenance related things like do consistency checks and log backups and full backups and you know, you can monitor it for resource usage and you can turn it up for brief periods of disaster recovery testing every 90 days. That they don't define what brief periods are. You know, is it a couple hours? A couple of days is a week. They just say brief. Right. So again, it's a little vague in how, in how they do that. If you are turning them up on a regular basis to do doctor testing, I always suggest getting it added as a clause to your contract, how often you can do that. But you know, these things are both supposed to be sitting there. Now one of the areas that we see people get caught in all the time, and I'm going to talk about this in a couple of minutes as well, but is that on the active side they've got the database. On the passive side they put reporting services. As soon as you separate reporting services from the database, it becomes licensable. So in an audit, a lot of times people be like, well I got an active passive configuration. And then we go and look and go, well, you got reporting services and there's a list of individual components of SQL that if they're not on the main database, are licensable. And it's like, no, these are licensable because you've separated them out, right? And especially their enterprise, that gets really expensive. So I'll talk about that in a little bit more detail there. But that's definitely one thing, you can't split those things out. So when I talk about SQL components, we'll talk about which those are. But that's one of the areas that we see People get hit at all the time in these audits. Okay. So the other thing that they did was they actually. It used to be sort of like a one to one relationship. Now you can actually have up to four. I've only got three in the diagram here because the fourth one is fairly simple. Right. So I can have my primary or my active side. I can have my passive side for high availability and I can actually have a passive side for Dr. Right. So I can have my, my primary database. I can do a passive side for high availability. I do a passive side for doctor. The fourth is I can actually put up a second doctor in a public cloud. Okay. And do that for free as well. So if I'm looking at this scenario, you know, we've got 12 cores here. How many licenses do I need? I need 12 core licenses, like so six licenses because divided by two. But I need to license 12 cores because I don't have to pay for the passive side if I have it. I gotta have essay, but I don't have to pay for the passive side. I don't have to pay for my doctor and I don't have to pay for doctor and doctor in the cloud if I'm doing that. So again, this is one of these areas that when we're doing audit work, when we're talking about passive active, we're actually now doing a lot of discussions around Dr. And how you're managing Dr. And what do those Dr. Sites look like and do they need to be architected the way that you guys are architecting them? Because a lot of the times I would say they're warm doctor which isn't cold. AKA does not fall into just doing these sorts of things. You may be doing data replication over to them live those sorts of things. Right. So again, there's a lot that goes into looking at these things. But I've put in this document, when you this PowerPoint deck, the things that you want to look at to see is Dr. Do I have to pay for it? Don't I have to pay for it? If I'm doing something outside of these sorts of things, I can't do it. I would suggest grabbing the SQL licensing brief and reading that if you're looking at these things and then the product terms as well to go into depth. But most of what you need to look at that is in here. Okay, so the next one I wanted to talk about is the SQL Server Azure Hybrid benefit. This is different than license mobility. License mobility allows me to move it to a cloud provider on premise Whatnot, the Azure hybrid benefit allows me to assign my SQL licenses to Azure. For the most part, moving to Azure works the same way, SQL licensing works the same way as it does on premise. Basically one core of SQL database is equal to one core in Azure for Managed Instance Elastic Pool or Single Database Business Critical or SQL Server Integration Services, or a single core SQL Enterprise Virtual Machine. So those are things in Azure not going to go into those in depth today. I think I've covered that off on last month when we did Azure. We talked about this in a little bit more depth. But for the most part you're allowed to do this one to one transition of licenses over to Azure. Now there is a slight benefit if you're doing the managed instance general purpose licenses because you actually get for each core you get four cores in Azure. So that's where the benefit is. If you're doing doing the managed instance stuff that they give you four cores for SQL Enterprise standards still one to one. Okay, and so what does hybrid mean? That's the real question, right? Because with SQL it's different than Windows, right? With Windows Data center, for instance, I can use my license both in my on prem to cover my VMware environment and I get those hybrid rights to use in Azure. With SQL, the hybrid write is a temporary write. I'm allowed to use my license to cover a database both on premise and in Azure, but only for 180 days as I do the migration. If I get to over 180 days and I still have it on premise and in the cloud, I got to buy an extra set of licenses now. So the hybrid feature of SQL is not use it on premise in the cloud. So I believe that's a misnomer of naming here. It's really just a migration, right, that allows you to use it on premise for up to 120 day 80. Sorry, up to 180 days as you migrate to Azure. Like I said, definitely not the same as Windows where you can use it in both ongoing, it's a temporary write. We are seeing people that had SQL BI licenses in 2016. Microsoft had a Business Intelligence model that was licensed as a SQL Server CAL model. They discontinued that and now if you have it, it actually turns into Enterprise SQL Enterprise Server licenses, not CORS Server licenses. And one BI I believe goes up to five enterprise servers. So if you did have the BI Server license, just know that it migrates to SQL Enterprise Server cal. And so if you still want to use that model, you can get some SQL Enterprise licenses in the server CAL model. If not, you're going to have to move to the core based licensing model for BI Server as they discontinued that license model. Okay, I talked about this, that you can maintain those legacy deployments of SQL Enterprise Server cal. I'm not going to go into any more detail on it because we talked about this already where you get the four VMs that cover up to 20 cores if you still have those. But you got the challenges of counting SQL Server cals. So here's the list products that I was talking about that are licensable components. I just pulled this out of the product terms. The left part is off of SQL and TechNet. On one of their pages it says here's the licensable components. So if I have SQL and I move the database engine away from analysis service reporting services integration services, Master Data Services or the new machine learning Services, the instance that component of SQL is licensable. When we're looking at inventory, we're going to be looking to see if we see enterprise services or anything like that in inventory on a server separate from the database. If it is, it becomes licensable. Now there are other things that are free like the. I'm drawing a blank. The management toolkits and things like that. There are components that are still free, but these ones are licensable. Okay, this is one too. By the way, there was a question here about ServiceNow and SQL licensing. This is one of the reasons you actually can't get a position in ServiceNow, Sam. Because I think they're only doing two of the eight today. Right. And so they only consider two of these to be licensable. For some reason over there you can actually do a SQL license position inside of ServiceNow SAM. Because they don't look for these all as being licensable. Won't go into this. We've talked about most of these throughout, but there's just a list of the SQL essay benefits there. The last thing I want to touch on is non production servers. This is where we spend a lot of time as well on SQL is around non production servers and how to license them. There's really two ways that you can license non production without paying production licenses. One that we highly recommend, if at all possible, is to just deploy the SQL Developer Edition. Now there are some technical limitations. Some organizations can use it, others can't. It is a fully functional SQL enterprise database. It gives you all the same functions. I don't understand the technical challenges on why why the the teams don't want to deploy the Developer Edition. But Developer Edition is free. If it's SQL Developers, the title, it's free, right? And it gives you the full functionality of SQL in test and dev environments. I would highly recommend, if possible, to use SQL Developer. Basically a production environment is one that does not connect to a production database. It's not there for doctor purposes. It's used. It can be used a little bit for production where you're copying over data, but it's not, you know, constantly being connected. And there's some things we go through in separate detail on what makes production or non production the other way. Sorry, excuse me, sorry about that. The other way that you can license non production is with Visual Studio and MSDN subscriptions. Really, it's the MSDN subscriptions. There's different types of MSDN subscriptions. You can buy Visual Studio Pro or Enterprise to come with msdn. It's also MSDN platforms. Again, when you're getting into how many visual studios, that's a separate exercise and a separate topic there. But you just need to make sure you have Visual Studio for anybody that touches the servers that is in, I would say it. UAT testers do not need to have an MSDN license. Man, I can't tell you how many times I've heard people say I can't do it because I gotta have all my UAT testers. Not true. If you extinct that, ping me separately. I'll send you the wording where you don't need to. But where people get caught on MSDN subscriptions sometimes is around operations teams, right? So think about, you know, the Windows teams that's patching these, these dev servers and testing, staging and things like that. They require MSDN licenses too. It's not just the SQL DBAs that require it. Okay? So that's, that's one thing to be careful of. One of the things that we see a lot of the times are people don't do a good job of actually keeping track of their dev environment. So we'll hear a lot of like, hey, we got a standard naming convention that if it's this, that means it's, you know, non production. But we don't always follow it, right? So a lot of the times, you know, we go in and one of the things that they would say on SQL, you want to be looking at your SQL environment and seeing if somewhere between 40 and 60% is declared as dev, because that's what the average is. If it's lower than that. When we do these, if we go and say Give us all your dev environment. We see it's at 20%. One of the first things we're doing is we're going in, going, what are we missing? That's dev, because it should be higher than that. Those are the topics that I wanted to cover off today. There's my email address. If, if I didn't get to your question, I think I've answered most of them that I've seen. But if I didn't get to your question, please feel free to email me and I know the one question on hyper threading. Email me and we can talk about that offline in a little bit more detail. I did want to show real quickly before, before we part, let me just make sure I am doing this correctly. What am I sharing right now? I think we should see our portal. This is our portal where we do licensing. So we take your inventory and we throw it in. We've built licensing logic so that we can quickly create license positions. And so literally once we get your inventory, we're going to throw it in and we're going to put it in and in a few minutes later we'll throw in your licenses and we come back with a report that sort of looks like what we see on the screen here, which is really a really a report that shows where you're over or under license or whatnot and a bunch of different things, right? So in this case, this customer here short a couple hundred thousand dollars in licenses and we corrected that by going in and investigating a bunch of things. But there's a bunch of things that you want to be looking for, right? So like for instance, we call them orphaned VMs. So those are VMS where we don't have guests to host relationships because those could be consuming licenses unnecessarily, right? Where we don't have the additions, right? So unknown additions is about 38%, right. So if you have an unknown edition. So basically your management tools don't tell you whether it's SQL standard or enterprise. Those unknown additions the auditors are going to assume are enterprise, right? Very expensive assumption because a lot of times it could be like express or standard. That's what we see most often. Some of them are enterprise. But you know, even if you look if your environment's 5050 standard, they're going to assume 100% of the unknowns are enterprise, right? So you want to go in and start looking at those things. So that's where I was talking about getting sort of the requirements. But we use this visualization real quickly to look at things, right? So again, I'm looking and going, okay, there's 58% depth, probably about right, because we're usually looking for 40 to 60. If it was less than 40, I'm going to go in and start having conversations with them about identifying tagging, dev systems and things like that. That's definitely one of the things. But you got to be able to visualize your data in a manner where you can look at clusters and hosts and the number of processors and cores in that, and then the guests that are on them and then the versions and additions. And when you start to see blanks or unknowns in this data, that's where you got to go and do your work in order to get a good inventory from. And so I've tried to talk about some of these challenges on the data side throughout today, but, you know, that's what I was talking about. But really why I wanted to bring this up is you can see in here like we're looking for analysis services and integration services and reporting services, because depending on where those set, those become licensable. And so that's one of the things, that's a big area that people get hit up on quite often. I don't have an exact stat, but my gut. My gut tells me probably 10 to 20% of SQL licenses are being consumed by these services or components that are licenseable, that don't sit on the main servers. That's where I wanted to end today. Thank you everybody for taking the time. I know I went a couple of minutes over, but if you've got any questions, feel free to reach out. I'm happy to answer those. Thanks, everybody.