RSS

Tag Archives: Service Provider Use Rights

Yikes…how to move from one cloud to the next.

The latest buzz word in this crazy IT world in which we live is not “Cloud” it’s “Hybrid Cloud”.   Even the definition of hybrid cloud has evolved throughout its short existence. Having a mix of on premise workloads and cloud workloads has transformed into having workloads spread throughout different cloud vendors as well.  “Cloud Sprawl” is born and guessing is here to stay.

In this article, we will review how the licensing works to move a customer’s workload from one cloud to another; customer’s owned licenses back to on premise; and customers on premise licenses back to your cloud.  As the title of this article states..Yikes!

Moving away from your cloud to another cloud

So, your sales rep “accidentally” promised the world to your customer that he/she could not deliver.  Unfortunately, they now want to move to another provider.  First thing to do is fire the sales rep.  Second thing to do is read your SPLA agreement.

When you sign a SPLA agreement (or any Microsoft agreement) your license keys are your license keys.   The data is not yours, but the keys are (at least while you have an active agreement – remember, SPLA is non-perpetual license). License keys are not to be transferred, resold, etc. over to another datacenter provider.   Where does it say that?

In section 6C, page 5, of the 2017 SPLA Indirect Agreement “Copying and distribution of Products and Software documentation” states: “customer may distribute original media or software contains products only to outsourcing company and affiliates.”  Another cloud provider is not your affiliate or outsourcing company, they are your competitor.  The section continues: “Customer may distribute original media or software containing client software and/or redistribution software to its end users.”

What that statement is saying is the service provider can provide the image to their client but not to another service provider.  If they do this, Microsoft requires the license keys to be removed first.  Remember, your keys are your keys, not theirs. As mentioned, the data is not yours either.  An end customer has the right to transfer their data from your datacenter to another provider.  You can also transfer the media to your customer, but not to another service provider as the statement suggests.

Over the years, the transfer of data, transferring images, and using outsourcing companies has made it difficult to track which media/keys belong to which company.  My recommendation is to have language in your agreement that is like the one in your SPLA to protect you.  Is this a gray area?  Absolutely.  My other recommendation is that no matter which keys belong to which organization – be sure to license the environment correctly; in the end, that’s the most important part.

Customer’s owned licenses back to on premise 

The same sales rep screwed up again.  They promised the customer that by moving to your cloud environment they would never be audited again.  Guess what?   They got audited.  Now they are upset and want to move back to on premise.  How does the licensing work?

In this situation, let’s assume the customer is moving workloads that have software assurance (SA) and are using license mobility. (even if they didn’t, same rules would apply.  I just like using license mobility because it’s more common).   Whenever an end customer transfers their own licenses (not SPLA) it’s important to read the Product Terms, not just the SPUR.  The Product Terms is for volume licensing, which applies to customer owned licenses.  The SPUR, as we all know is for SPLA.  Two different programs, two different use rights.

Page 84 (good Lord this is a massive document) of the 2017 Product Terms states “Customer (your end customer) may move its licensed software from shared servers (license mobility) back to its Licensed Servers or to another party’s shared servers, but not on a short-term basis (not within 90 days of the last assignment).

When you buy a license through volume licensing (VL), you assign that license to a server.  That’s one of the reasons you cannot mix SPLA and VL on the same server (different use rights).  When you assign that server to a different server farm (another datacenter provider) that server license cannot move within 90 days of assignment.  If your end customer gets upset and demands you transfer their licenses back to their premise, you can pull out this little blurb in the Product Terms.  I would recommend having language in your agreement that states the same.

You might be wondering – “isn’t the benefit of Software Assurance the ability to move workloads freely without worrying about the 90-day rule?”  That’s true and I’m glad you brought that up.  If it’s within the same server farm, workloads can move freely.  Pay attention to page 84 of the Product Terms as well as the definition of a server farm.

One of the best lines in the Product Terms happens to be on the same page (84).  “Customer (again, customer in this example is your end customer) agrees that it will be responsible for third-parties’ actions about software deployed and managed on its behalf” I would definitely include that statement with your customers.

Moving back to your cloud

You gave your sales rep an ultimatum, win the customer back or lose your job!  Your sales rep won the customer back.  Now your customer can move back to your cloud, but make sure you follow the license mobility use rights as mentioned above.  Remember the 90 day rule.  Once a customer assigns a license back to their premise, they have to wait 90 days to move it back.  Secondly, if they do not have SA, you must dedicate the entire infrastructure for your customer.  Dedicated means the hardware used to support the solution.

The moral of this story?  Make sure you have a good sales rep!  Secondly, read the SPUR, Product Terms, SPLALicensing.com, and have language written in your agreement to protect yourself.  Lots of talk about moving to the cloud, moving away from it is just as important.

Thanks for reading,

SPLA Man

 

 

 

 

Advertisements
 
Leave a comment

Posted by on August 3, 2017 in Compliance

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , ,

IaaS Gotchas…

In this post I will highlight new (and not so new) compliance gotchas as it pertains to providing infrastructure as a service.

Let’s start with a common example and go from there.  You provide the infrastructure such as Windows/SQL, your customer provides the applications.  Sound familiar?  You license Windows Datacenter, SQL Enterprise in a shared (aka public cloud) environment under SPLA. You have no idea or really care what applications your customer’s are installing right?  You just provide the support of the infrastructure.  That’s not your concern.  It’s their application, why should you care?  Ahhh…but maybe you should.

Have you ever wondered how they’re accessing the applications?  Are all applications web-based?  I will answer that question for you…no.  So how are they accessing the applications?  Do they use Citrix?  Do they remote into the application somehow?  There’s that word…remote.

If you enable the Remote Desktop Services role within Windows Server – you guessed it…you need to report RDS licenses.  The number of IaaS providers who just report Windows and SQL is astronomical. The number of IaaS providers now reporting RDS is also rapidly growing.  Did they wake up one day and decide they should start reporting RDS?  Unfortunately no.  They were audited.  Shoot me over an email and I will forward the guide that explains RDS and when it applies. Remember when you license RDS, you need to license each user that HAS access to RDS – not who does access.

Let me provide an example of how easily you could be underreporting RDS.   Let’s say your customer has an application from another vendor (outside Microsoft) that’s hosted in your datacenter.  That same vendor provides support to the application.  You are not hosting the application for the vendor but for your customer, you just provide the vendor access to support the application via remote connection.  SPLA allows 20 users to provide support and administration per datacenter.  If you exceed that limit, you are going to have to report those additional users.  Yes, even if you are not charging them.

Other IaaS Gotchas –

While we’re on the topic of customer owned applications, do you have it written in your agreement with the customer that you are not responsible for the applications they install?  What would happen if they install applications that you are not aware of and they don’t have the appropriate licenses…who’s responsible you or the end customer?  Kind of a trick question, it’s both.  You will get audited, it’s installed in your datacenter, you are ultimately responsible.  You need to ensure you have it written in your agreement that you’re not responsible so you can have a nice chat with your customer.  All the big boys do it…you should too.

What about SQL?  Are you virtualizing?  Why aren’t you reporting SQL Enterprise?  Are you utilizing all the use rights that come with SQL Enterprise – unlimited virtualization, DR, mobility within server farms, etc?  What about smaller environments?  Have you considered licensing by user instead of by core for SQL Standard edition?

SQL Web is tempting isn’t it?  Less expensive option but no one really understands what it is.   Here’s a quick synopsis – if you do not host public facing websites, SQL Web is not an option.

How are you managing your datacenter? Do you have System Center installed?  You should report the Core Infrastructure Suite.  Running Hyper V with few VM’s, license CPS. Both products include Windows.  You need Windows to run System Center, so you kill two birds with one stone so to speak.

Ask your customers if they have Software Assurance.  It’s no longer about latest version rights and annual payments.  It’s about moving to the cloud.  Let’s make sure it’s your cloud and not someone else’s.

Conclusion –

I’ve been around this game of SPLA for a long time.  The best advice I can give is to listen to your customers and don’t be afraid to change.  Cloud is evolving, you should evolve too.  Don’t report out of convenience, look into ways you can optimize what you are reporting.  It’s competitive out there, let’s make sure you are getting the most value out of your agreement.

Thanks for reading,

SPLA Man

 

 

 
11 Comments

Posted by on January 31, 2015 in IaaS

 

Tags: , , , , , , , , , , , , , , , , , ,

SPLA Compliance Audit- How Not to be the Chosen One!

If you recently went through an audit or just nervous about being notified, I outlined ten steps that service providers can take to arm themselves more efficiently and be compliant.

  1. If you are running Microsoft software, you must license Windows.  All Microsoft software runs on a Windows OS.
  2. If you are licensing SharePoint- SharePoint requires SQL and Windows.
  3. Reporting SharePoint Enterprise you must license SharePoint Standard
  4. Installing Office on a server requires Remote Desktop (RDS) licenses.  Office and RDS licenses should match (cannot have more Office licenses than RDS licenses)
  5. If you have customers bringing licenses into your hosted environment you need to host it in a physical and dedicated environment.  (nothing shared among other customers)
  6. If you are reporting user licenses (SAL- Subscriber Access License) you need a license for each user that has access.  For example, if you have 10 totals users in the month of May and only 4 actually use or access that software, you must license all 10.  SPLA user licenses are similar to your cable bill; your cable provider is going to charge you regardless if you turn your TV on or not.
  7. If you have customer owned licenses in your environment, you must keep all relevant documentation.  This includes enrollment information, start date, end date, and who they bought the licenses from.
  8. Renting out a PC make sure the PC has an OEM license preinstalled.
  9. No virtualizing/streaming Windows desktop OS from a datacenter.
  10. You can install your server on a customer premise, but do not install SPLA software on your customer’s server!

This is not bulletproof by any means.  Use this as a guide when looking at your own environment.  Look at it from the auditors eyes.  What information would they need to verify that I am compliant? The SPUR (Service Provider Use Rights) is the best reference when it comes to Microsoft SPLA.  You can download a copy here.  If you have trouble sleeping at night; this is a must read.

Thanks for reading,

SPLA Man

 
1 Comment

Posted by on March 5, 2013 in Compliance

 

Tags: , , , , , , , , , , , , , , , , , , , ,

 
%d bloggers like this: