SQL Server Licensing Myths

SQL Server Licensing Myths

Which would you rather do, wade through the nuances of SQL Server licensing or a typical tax form?  Some days, I think the latter would be a welcome respite. Let’s just put it this way, I bet Brent Ozar (BrentO on twitter) is happy that licensing wasn’t the biggest part of the MCM grade. (I don’t know this, I just presume it because people actually pass the MCM every once in a while).

Common SQL Server Licensing Myths

People Lost in Corn Maze
The people in this maze might be better off than us.

I am going to talk about some of the more common myths I’ve encountered with licensing throughout my career and consulting. Microsoft has some decent SQL Server licensing resources including some PDFs (some short and some nearing legislation size with flowcharts abound). This quick guide is a good start to look at. This longer guide includes many more details here.Which brings me to a disclaimer:

This blog post does not replace your own research and understanding of licensing guidelines from Microsoft.  The thoughts presented here are my own and represent my views of Microsoft licensing guidelines and my interpretations thereof. My perspective has the potential to be wrong (I’m a husband, so I’m likely wrong, come to think of it 😉 ) and could become outdated with future changes. Check with Microsoft and your licensing representative to make any final decisions.

On to the myths I encounter…

You Need Enterprise

Look at the edition feature matrix for your version (2008, 2008 R2, 2005) and see what you need and anticipate needing – it can save you around $15k + per CPU to go with Standard over Enterprise. I have commonly bumped into people believing that they need enterprise licenses when they don’t when it comes to things like:

  • Log Shipping (Standard is fine)
  • Clustering (You can have a single instance two node cluster on Standard)
  • Mirroring (Some types are allowed in Standard)

In fact, this post was inspired recently when I was able to see a project at a company to roll out Enterprise Edition simply because of Log Shipping. No other enterprise features needed. This company had great pricing on Standard and I was able to save them almost $60,000 in Enterprise licenses they didn’t need. Wait. There’s more! Act now and you can save even more because another myth sounds like this:

You Need To License Your Mirrored Copy Also

In most situations (yours may be different, double check), a DR standby (For mirroring or log shipping) doesn’t need to be licensed by default. Now there are certain triggers (pardon me) that will hit you with a license cost (Being failed over to it for more than 30 days or reporting off of a snapshot of the mirror, for a couple examples) but by default, many simple options don’t. This same company had an Enterprise License purchase (single CPU) for the fail over site. Another $19,000 saved with no standard license even needed because that instance can sit there “unlicensed”.

I Can Put SSAS, SSRS and the DB Engine anywhere…

You can. And, as a best practice in busier environments I’d say you should. But you can’t do it for nothing. You can put them all on the same box and they will be licensed as though you just had one (under most circumstances). The moment you split them out (again, generally a best practice for performance) you must license each component separately. While I’ve saved some companies money, here I’ve cost some money… Sorry. I don’t like it either but it is what it is.

Multiple Instances Still Means Multiple Licenses

I hate typing this because just as soon as I do, I am sure some pointy headed boss someplace will say, let’s consolidate every instance onto one machine! Don’t do that. But this myth isn’t true – you pay by the CPU by the machine. If you have two instances on one machine each using 2 CPUs, you only need one 2 CPU license. Add another instance to it? Same thing, no new license, you pay by the machine not the instance. This is great and can really help save some license expenses at smaller shops but just do so carefully as I wrote when I first drafted this SQLServerPedia wiki article on multiple instance decision making.

SQL Server Licenses Are By Core, Like Oracle

Or at least like Oracle was last time I checked… SQL Server (today.. I don’t know of anything changing, but you never know) licenses by the socket. By the actual die that goes into the socket. Not by the core or thread. So you can have a Quad core proc with hyperthreading that looks like 8 CPUs in perfmon but you are paying for a single CPU license. This is good to know. Might make that hardware upgrade more worthwhile. Who knows how long this will last and, for all I know, maybe it is gone by the time you read this, so double check yourself.

Virtual Server Licensing Works Just Like Physical

I’m not going to say anything except to say this isn’t necessarily true. There are all sorts of scenarios and differences depending on if you are using standard or enterprise. The IRS has a hotline (800-829-1040). So does Microsoft, if you aren’t sure it may be worth a call or e-mail.

Developer Edition Works for All Developers

Well that may be true most of the time. Your developers could probably use developer edition but keep a few things in mind: 1.) Did you pay for it? Or is it just a download everyone shares? If you are covered by MSDN (For each developer who touches the instance) or some sort of enterprise agreement then you may be fine. If you paid for the product and a proper license you are fine for the intended use in the agreement. If not, you aren’t. But also – consider this: What is production going to be? If your production environment is standard, do you necessarily want the product developed and tested on developer edition, which is Enterprise Edition by features, Developer edition only be price tag and EULA?? There may be a reason (especially if you have MSDN licenses for each developer, a good investment typically) to make sure an app is developed and tested in something other than Enterprise. Consider the end goal and end edition. It would stink to see Dev and QA using Developer and relying on some enterprise feature that never failed a test only to find a deploy gone wild.

Licensing, Just Like SQL Server, Is Set-It-And-Forget-It

No. No to both. Depending on your agreement with Microsoft the day may come when they come to do a true up of your environment. They will discover your SQL instances with you and verify you are using what you purchased. If you haven’t you’ll be buying more licenses and you are in violation of laws and software agreements. You could face fines as a company or a individual, potentially. An answer? Do your own True Ups. Awhile ago I blogged about using the Microsoft Assessment and Planning Toolkit (MAP) to discover your SQL instances. The report it spits out shows you all sorts of great details (server name, edition, version, CPU count, etc). Do your own true up, no reason you can’t. Are you in line? If not fix it by adding licenses or consolidating and saving the company hard earned cash (“Hey, boss, I just want 1%…”)

Summing It Up

A simple look at a few of the more common myths I bump into around licensing. They can all be summed up with the same advice, do your homework, understand the license agreements with factual information (not someones recollection or interpretation) and always double check. Even if the information comes from a trusted vendor (you know how I feel about that), you could be breaking the law or throwing away company money. Neither are great career advancement moves.

What about you? Do you have a licensing horror story? A tip for someone else out here. Leave it in the comments or blog about it and let us know when your post goes up, I’ll be more than happy to link to any tips to help folks avoid making a mistake up front.

Subscribe for Updates

Name

21 thoughts on “SQL Server Licensing Myths”

  1. Nice post here about licensing. Having run this gauntlet several times myself, I would add that many LARs (Large Account Resellers) I deal with are ill equipped by Microsoft to answer licensing questions without doing some research themselves. I often find myself correcting our LAR on licensing restrictions. Recently while truing up our SQL licensing, our LAR tried to convince me that I needed a SQL Server license for each developer/admin interested in using SSMS (SQL Server Management Studio). While not mentioned above in your post, the client tools themselves can be installed on an unlimited number of client workstations, including SSMS, SSBIDS, and the VS tools. Also helpful to mention that you should only by Software Assurance (available with a license under Select and Enterprise agreements) if you plan to USE the coverage to upgrade that SQL server to a new version during the term of the SA coverage. Before I took over managing my companies licensing, they wasted hundreds of thousands of dollars on SA coverage for software they never had any plans to keep current with more recent versions when available. Finally it is worth considering CAL (CLient Access Licensing) as an alternative to CPU/socket based licensing for SQL products. If the SQL server is for internal use only, or if you have several SQL servers all being used by a limited number of users, CAL licensing can be more affordable. Each CAL covers access to any of those SQL servers, who themselves are licensed under a pricing model that is more affordable than the CPU/Socket model. CPU/socket licensing definitely makes sense for SQL servers being accessed by a large user base, either internally or publicly. .

    Reply
    • Thanks John! All great points. Especially about Client Tools not needing licenses and only buy SA if you know (or it is very likely) that you will use it. The way most folks stick with SQL Server versions, SA almost seems to be a money maker for Microsoft more than a money saver for customers in a lot of situations. (That isn’t to say folks wouldn’t benefit from upgrading, it’s just that their own testing/release cycles may not allow them to keep up with SQL Server’s release cycles..) All you have to do is ask at any presentation is, “how many people still run SQL Server 2000” and you’ll see the issue with SA on SQL 🙂

      Reply
  2. Pingback: John
  3. @Mike, I do have this nice Developer Edition / Standard Edition twist with a small customer. They have a single production server (Standard Edition) and two admin/dev guys who use two computers for development and testing. The licensing situation is 2 processor licenses Std. Ed. for the production server (fitted with 2 quad-core processors) and two Developer Editions (one for each admin/dev guy). The installed situation on the admin/dev systems is Standard Edition however, because they don’t want to get caught in features they can’t use in production. I tried to get this setup confirmed with MS people here in the Netherlands, but they couldn’t tell me if it was okay or not.

    @John, I believe there is a little catch with the Admin and Developer tools. Yes, they can be installed on numerous systems, if you have a matching server license. As far as I know in the theoretical case of only having Express Editions, you are not allowed to use any other Management Studio, but the Express version.

    Reply
    • Hi Stan –

      I have never checked with MS specifically on the license myself for using Standard in development. That would be worth further investigation, now that you mention it. I had rationalized in my head that because it is being used for development and the developer has an MSDN license that they would be fine and I am 98% sure that I am correct there but not sure in the situation where you don’t have MSDN but buy specific individual licenses for your developers. I think, again, we would probably be fine because it is being used for development purposes (and has less features than Developer edition) but that may be something to ask further with Microsoft licensing.

      Reply
      • Pretty certain that Stan is not license compliant, if the single Std edition license was obtained as a retail copy or as part of a volume license agreement. He would definitely need to have an MSDN subscription if he wanted to run a copy of SQL std for development purposes, and he would need an MSDN subscription for each developer using that system for development purposes. MSDN based software licenses cannot be shared among developers.( http://msdn.microsoft.com/en-us/subscriptions/cc150618.aspx )

        Reply
        • John – If you re-read his note I believe we are interpreting differently 🙂

          “The licensing situation is 2 processor licenses Std. Ed. for the production server (fitted with 2 quad-core processors) and two Developer Editions (one for each admin/dev guy). ”

          When I read that, I had presumed they own 2 CPU licenses for Standard (for prod) and two individual Developer Edition licenses for two separate developers. The only difference is that those two developers are using Standard edition under their developer licenses and they are using it for development purposes.

          No MSDN but individual dev license purchases. If they had two MSDNs it would be a clear and cut “no problem” but with them being dev edition licenses, I don’t know what the official policy would be but I wouldn’t be surprised if there was enough grey area to cover their development use of Standard edition by the Developer edition licenses.

          I would definitely check further at MSFT though on that one, Stan.

          Reply
          • Hi John, Mike,

            The development undertaken is Office (Access and Excel) and just SQL Server based (T-SQL, SSAS, SSRS and SSIS). The reason this customer “downgraded” the developer edition to standard edition has to do with the fact that a couple of reports had been developed based on a database snapshot take a snapshot at 0:00 and compare that with the current database to get the current day changes. However, since standard edition doesn’t offer database snapshot abilities…. to cut it short, they didn’t want to get fooled by such an edition difference again and decided to play it safe (from the technical perspective) from there. From the license perspective, MS NL couldn’t provide an answer (yeah, we could open a CSS call). If you have some entry-points at MS that can provide a conclusive answer, I’d be obliged.

            There happens to be a connect-item on the technical aspect of this;
            http://connect.microsoft.com/SQLServer/feedback/details/496380/enable-sql-developer-edition-to-target-specific-sql-version

          • Stan – The rationale makes perfect sense and it is what I was referring to when I mentioned the “use standard” edition rather than dev point in the original blog entry.

            Rather than CSS – have you reached out to the Microsoft licensing folks? I provided a link to the main US site for licensing and they have contact information there.

            Every situation can be different and licensing regulations can be different in different countries so I don’t want to give you are more definitive answer than that and to mention that I have done just what you propose here and it was legitimate, the developers were covered by a SQL Server Developer Edition license each we just had them develop on standard and we were alright. Your situation may be different, however.

    • @Stan, since none of those bundled admin/developer client tools are available as free downloads, you need to have a copy of full SQL server (not Express) in order to install them. There is little chance in ‘accidentally’ installing those tools when you do not have the server portions already paid for and deployed, unless you are already violating the license agreement by using an illegal copy of SQl server. The tools themselves are identical across all the full SQL editions 9Dev, Std, and Ent)

      Reply
  4. Hi, just thought I’d add something…. the only reason I’d want to purchase Enterprise Edition for my company is because it allows table partitioning. Unfortunately, Standard doesn’t allow that option. Since this is something not completely obvious and it took some Googling to arrive at the conclusion, thought I’d mention it here.
    Cheers and thanks for the article

    Reply
  5. Pingback: Mark Blakey
  6. Pingback: Turgut Terlemez
  7. Pingback: Erin Stellato
  8. Pingback: Mark Stacey
  9. Hi

    Great blog!! ,It helped me a lot.
    I have a queshtion about licensing high availability cluster.
    I am using high availabity with windows cluster (active/pasive)

    I am looking for the micrsoft documate that said that the pasive node can be active max 30 days, before you need to pay for it.
    (you wrote “Being failed over to it for more than 30 days”)

    Can you plesae point me to it?
    Thanks a lot,
    Guy

    Reply
    • Hi Guy –

      First off the documents are linked above. Secondly – apologies for the long delay here, I apparently lost your comment as spam. If you are still out there wondering or anyone else is – clustring is different. The 30 day deal applies to mirroring or log shipping – a separate server. When you are in a cluster – it doesn’t matter which node is active and for how long. So you can start out with the instance on Node A, have a failure and end up with it on Node B for 2 years and that is fine.

      Disclaimer – I’m just a person with my own understanding and interpretation of Microsoft licensing guidelines. You should verify advice like this with your reseller or Microsoft- but I have always worked with clusters in that method.

      Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Share This