Daryl: It's a pleasure having you back at SAMexpert's weekly Q&A.
Today we are going to be talking about service provider audits. And some fascinating questions that we received from our audience.
I'm Daryl Ullman, a partner and Chief Negotiation Officer at SAMexpert. With me is Alexander, or as everybody knows him, Alex Golev, our CEO and Chief Licensing Expert, for everything to do with Microsoft.
We've got quite a few interesting questions that have come in from our audience.
We want to talk mainly about audits because, for some reason, that's become a hot topic over the last few months. And I would say the majority of the questions that we have for the SPLA slash hosting, ISVs, and SaaS community are around audits. So something's happening there.
We see a massive increase, at least in Europe, around Microsoft SPLA audits, and it's becoming an issue for many providers.
I want to start with the first question that always comes to mind. I get an audit letter. Do I need to initiate the audit immediately? Do I need to set a call within a few days and then, in a week or two, start providing information to the auditor? Or do I have some leeway there?
Alexander: You have 30 days from the reception of the letter. The way it's worded, it's pretty interesting. So all it says is Microsoft is required to send you a notice 30 days before the initiation of the audit. Usually, in 99.9% of cases, you will not be able to push back and say, "No. You can't audit us." Unless you have exceptional circumstances, this is how it works. They send you a letter and try to set up a meeting in a week or ten days. You have 30 days.
There's a 30-day window to breathe out. Maybe find a partner to help you with an audit, discuss it internally, look at your risks, and then engage with the auditor. And then you also need to understand that even when you had a kickoff call, there are no calendar stipulations, so you don't have to immediately submit the date so that you can take your time.
You don't have to provide any additional responses to the questionnaires immediately. Take your time. Microsoft must notify you about the audit 30 days before the audit begins. So yeah, there you go. You have 30 days.
Daryl: If I understand you correctly, I got the letter. I now have a month to get my team in place because I need to put in the required resources.
I need to identify the key team members that may be historically also part of the team because a lot of data and information needs to be provided. And I need to update my stakeholders. Is that something that you would recommend?
Alexander: Of course, you need to update all your stakeholders.
Daryl: There is a severe risk if the audit goes in the wrong direction and you are found non-compliant. And non-compliance could sometimes be in the millions. How many years can they go back, Alex, when they audit? 3, 5, 10?
Alexander: As long as they want. The longest I've seen was six years.
Daryl: So, six years. So the risk is that they find a discrepancy and then multiply it by five or six years. And that's a considerable risk. You can't take the risk individually on your shoulders. That risk needs to be part of the executive team's responsibility.
Let's move on to another question that I have. I'm going to read it out to you. We accidentally submitted a non-hosting cluster, and the auditor counted it as an SPLA debt. Now they don't want to de-scope it.
Alexander: Of course they did. Firstly, push back. If the auditor is stubborn and says, "No, it must be in SPLA scope", what is the evidence that it must be in SPLA scope? Suppose you are sure that:
It's an internal use environment that you licensed with your enterprise licenses,
It's not a part of the internal use of SPLA or a hosting platform, your cloud platform,
It's not in the provider's scope,
In that case, continue pushing back.
The giant mistake you made was submitting the not-in-scope data to the auditor. And we see this all the time. Companies often overshare if there is no internal exercise to clarify the scope to be precisely just the services that are supposed to be licensed via either SPLA or Bring Your Own License. They often tell too much. If you put a technical person as your only point of contact, which we've seen as well, sometimes, rarely, fortunately, they can provide all the data the auditors ask for, and often they ask more than they should.
In your circumstances, continue pushing back. Involve Microsoft. If you are entirely sure that's not in scope, push back. The SPLA audit scope, as outlined in Microsoft's Audit Notice Letter, is only the SPLA services. That's it. Nothing extra should be included.
Daryl: If I have a cluster, Alex, and that cluster is used both for my hosting business and for my internal infrastructure, my internal IT, do I have to give all that data? That's my first question. And the second question is, can I also use our SPLA licenses for internal use?
Alexander: Yes. I should answer these as one. SPLA allows using licenses for internal use. The formula is a bit vague, though, because it says, "as long as your internal use is not more than 50% of all your end customers combined." From the worst-case point of view, I read it like your internal use should not be more than one-third — 50% of what your other customers use.
Going back to the first part of the question, if you mix internal use and hosting in one cluster, that cluster becomes a "shared-use" cluster. Therefore, you must use either SPLA or Bring Your Own License. It's a bit perverted in this case, but please understand it. You're bringing your own enterprise licenses to your own cloud platform. So you treat yourself almost as an external customer. And by the way, you must also pay for all these licenses. They are not free to use. You must report them. You are essentially hosting yourselves on that platform.
Daryl: What's the best practice?
Alexander: The best practice is, if you deploy your resources on hosting clusters, make sure you understand why you're doing that. Is it your best licensing strategy to license those virtual machines via SPLA?
Why wouldn't you deploy the same virtual machines on your regular internal use clusters where you use your commercial licenses? It may make sense when you need elasticity. When you don't know how many virtual machines you will need at some point, maybe some short-term projects where you don't want to overload your existing enterprise clusters. But one thing you should avoid, as that's not a good use case, is "dev-test" because there's no development and testing in shared environments. That would be a horrible mistake.
We see good cases of companies using SPLA for internal purposes. Still, we also see unreasonable cases where they would probably be much better with CSP subscription licenses instead of paying monthly for SPLA because the costs are comparable.
Daryl: A follow-up question we got from the same person was that they also have an extension of the hosting platform on AWS. Part of the licenses they receive directly from AWS as a part of the infrastructure and the overall EC2 costs. But there are other licenses that they should be paying for, like RDP SAL and SQL SAL. Can they use their SPLA licenses, purchase them from AWS, or even use the bring your own license option? Again, this is an extension of their hosting service on AWS.
Alexander: Most simply, providers are allowed to use other providers as Data Center Providers. That probably did not answer your question so let me explain. In SPLA, there's a definition of a Data Center Provider (DCP). It's another SPLA provider, which you, as a provider, may use to host your end client workloads.
Here's the problem. When you use another provider as a DCP, you are only allowed to bring your own SALs – Subscriber Access Licenses. Core licenses for SQL, Windows Server, and all the other products that are licensed per core or processor must be reported by AWS.
Daryl: So it's their responsibility.
Alexander: Yeah.
Daryl: The server side: Windows Server, SQL Server, is the DCP's responsibility, but you must bring the user licenses.
Alexander: Exactly. You, actually, have to. You can do that in general, but with AWS, Google and Azure, you must bring SALs via your own SPLA.
Why? Because these providers don't sell SALs.
Daryl: It's 100% your responsibility. There's no other way to purchase those licenses.
Alexander: Exactly.
By the way, we have a pretty good question in the chat. It's not an easy one. When you have E3/E5 subscriptions, do you get the right to install System Center on servers as part of your bundle rights?
Let me answer it.
E3/E5 subscriptions have a limited subset of System Center functionality to manage Windows 11, Windows client operating systems. So if we talk about on-premises, it's easy. System Center server components do not require licenses themselves. So you are allowed to deploy System Center binaries, the server itself, the management console and the components that manage other devices as a part of the E3/E5 subscription, of course.
But, there's a second part to that question. Can you use System Center via E3/E5 to license your products on hosted servers in an outsourcer's environment?
Yes. Why not? I would write an internal business case for that in case there are any compliance questions.
As some of you may probably know, starting from the 1st of October last year, it's much easier to deploy your Windows 11 VDIs on basically any IT outsourcer. I mean it. No authorisation is required, SPLA or QMTH. And E3/E5 licenses are eligible for that right as well.
So yes, you may go to another IT company or a provider and ask, "Would you accept that? Would you host it for us?" And you will probably want to manage those VDIs with your System Center. Why not? Because those are subscription licenses. System Center server components do not require licenses themselves. Therefore, I don't see a problem here at all.
If you have any pushback from your provider or any doubts, don't hesitate to get in touch with us via [email protected] or send us a message through our websites. And let's talk. I'd like to see the other side's arguments.
Daryl: Going on to our next question, Alex. It's about SPLA licenses that you resell to an end-customer with their own hosting environment that purchases SPLA licenses from you. So the scenario here is as follows. We have a customer that hosts their own service for their customers, but they're not an SPLA provider. They purchase SPLA licenses from their SPLA provider. And then the question is, who has the licensing compliance responsibility – the customer that purchased the licenses and is hosting the environment or the party that sold the licenses to the hoster?
Alexander: Anybody wanting to provide hosting services needs to become an SPLA provider. What you described right now is, potentially, a workable solution. It's possible but highly complicated. This company contractually becomes, at the same time, an outsourcing company for that SPLA provider to be able to bring those licenses to their estate. Then also, they must become a "Services Reseller" for the same company. So, it's possible but almost nonsensical from the contractual point of view.
The other scenario we see is when an end client does not want to buy licenses or is looking for ways to be more flexible. They can go to a provider and say, "We want to use SPLA for our internal purposes on-premises as a commercial company – like a doctor's office, a bank, or a retail company." They want to use flexible licenses, but on their premises. That is also possible.
But here's the problem. As an end client, you can't buy pure SPLA licenses. Strictly speaking, providers are not allowed to sell SPLA licenses. What you are legally allowed to purchase from a provider with SPLA is a service with licenses included. They don't even have to disclose the number and type of licenses.
The best example would be when you procure Windows Server virtual machines. You don't buy even a share of a Microsoft license because you procure a machine, and the provider pays for the host with unlimited machines.
A regular company, a business that is not a provider, may ask a provider to provide them with SPLA licenses only as a part of the service they get from the same provider. That's the only possible scenario. The provider can't simply give those licenses to you. You must buy a service from them.
Moreover, they must be the sole admins of those servers. Shared admin responsibility is possible. But if you read the language of SPLA carefully, you will see that the end client is not allowed to manage those servers. Think of it as an equivalent of "edge computing".
Daryl: So the bottom line is this. If I understand what you're saying, a provider company is providing SPLA licenses to a customer of theirs. The customer is using the licenses for internal use. The provider must have admin rights because, ultimately, the provider is responsible for compliance if there's an audit.
So if their customer is abusing, or overusing licenses, ultimately, they'll be responsible because they provided the licenses, and they should be managing the infrastructure and the licenses.
Alexander: Correct. I would probably even say that it's a riskier scenario than hosting everything in your data centres.
Daryl: So you're taking on a more significant risk because it's external, and you might not have full management rights.
Alexander: You must outline all the rules with your end client before even engaging in such a relationship. So they must understand they're not buying licenses from you. They're getting a service, and because they're getting a service from you, you are responsible for those servers, although the hardware may be theirs.
Daryl: Would you recommend getting your end customer to sign off on some document, use rights, or something like that?
Alexander: As the absolute minimum, SPLA requires end clients to sign End User License Terms and agree to use the software in a certain way, in a specific manner. There are limitations to what you can do with the software. Providers that provide licenses to be used on premises should extend that EULT to include on-premises specific terms. For example, you may include a provision saying, "You are not allowed to revoke administrative rights. You are not allowed to make changes to Active Directory groups", or something like that.
Daryl: We've got another question here regarding what's defined here as SPLA tools. Can we build our own SPLA tool with scripts, or do you suggest buying a product like Snow or Flexera to manage our SPLA environment?
Alexander: I'll start with a negative. I love Snow and Flexera and USU and all those tools when we talk about enterprise environments. None of these tools is capable of properly calculating SPLA. For SPLA, there are dedicated tools.
So firstly, yes, you can build your own scripted solution. Why not? Some providers do, and I was part of a few projects when providers built their own in-house scripted solutions. And the less complex your services are, the easier it is to implement. If you provide all kinds of licenses, especially user licenses, there are a few specialised SPLA tools in the market. If you're interested in which tools we recommend, please reach out to us privately via our websites, and we'll connect you to the companies that provide dedicated SPLA tools.
I would certainly recommend having a tool because it will make your life easier.
Daryl: And what about the Microsoft MAP tool? Could that be sufficient?
Alexander: No. Firstly, even collecting inventory will be a nightmare because the MAP tool works well in a single domain. If you have a hundred clients, you may have a hundred domains, and you need access to each. So specialised SPLA tools with agents installed in every virtual machine with a provision in your agreement that they must not stop the agent and the agent that reports license consumption and obfuscated data to a centralised server, that's the ideal scenario.
There was time, unfortunately not anymore, when Microsoft even postponed audits and completely detracted them if a provider proved to them that they had a tool with a hundred per cent coverage.
Daryl: That's ideal. That would be an ideal situation. There aren't many providers that have that coverage and can prove that kind of compliance.
Alex, I want to thank you for your time and the knowledge sharing for our community.
I'm sure there are many additional questions and topics around the audits, not even talking about the true SPLA potential of using SPLA licenses and the CSP hosting program.
Alexander: Some people are hesitant to ask specific questions in the chat, not to give away what's happening in their companies. Please send us an anonymous question through our website using any made-up name, but clearly outline your question and say we want you to answer that question at the next provider live stream. We will. Where do you think we took all these questions that we discussed today?
Thanks, everybody. Bye-bye.
Daryl: Thank you.
