RSS

Tag Archives: SPLALicensing.com

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

 

 

 

 

 
Leave a comment

Posted by on August 3, 2017 in Compliance

 

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

CAL’s, SAL’s and Multiplexing. 101 Licensing for on premise and cloud environments

 

In this article, we will take a closer look at CAL’s and SAL’s…what they are and how to license them.  We will also look at the User Subscription License (USL) for Microsoft Online Services.

Client Access License 

A Client Access License (CAL) provides the right to access a server.  Depending on the environment and product licensed, a CAL can either be a user or a device.   Many resellers, consultants, and even Microsoft, make it a lot more complicated than it needs to be.  The biggest trick to CAL licensing is remembering it is just a “right” not a technical requirement to access the server.  In other words, you can spin up a server, users can access it (in most cases with or without a CAL) and away they go.  Sounds great, but it’s not compliant, and I would argue that is the #1 reason customer’s fall victim to compliance.

SQL is a great example of this.  When I go to my SharePoint site, I pull reports, store information, share information, and perform many other tasks.  What I don’t know is SQL is used in the background to provide access to this information.  Did I log into a SQL Server?  No.  Did I “use” SQL?  Yes.  This is where multiplexing come into play. Multiplexing uses hardware and/or software to pool connections.  The best way to know if a user needs a license (and I’ve said this before) is to ask yourself “If I remove this from my hosted solution would it still work the same as it did prior?” If you answer “no” you need a license.  If your SQL Server is licensed in the Server/CAL model, you’re required to have CALs for any User or Device that accesses that application directly or indirectly. Very few users in an organization have credentials to a SQL Server.  One way to eliminate some of the risk with SQL is to license by core.  Cores allow unlimited number of users to access the server.  If they use the server or not, they are covered.

SAL Licensing

Under SPLA there is a Subscriber Access License (SAL).  SAL’s are licensed by user only (there are very few exceptions such as desktop applications and System Center).  Like a client access license, a SAL license is not concurrent.  This is important, since other vendors are based on concurrent licensing.  SAL is like your cable bill, your provider is going to charge you regardless if you turn your TV on or not, SAL licensing works the same way.  I’ve written about this before but it’s worth repeating – SAL is for any person that HAS access not who does access.  Unlike CAL’s, there is no need to purchase a server license in SPLA.

Online Services

To add a bit more complexity, let’s review Microsoft Online Services.  If you license Exchange Online or an Office 365 Suite, you will purchase a User Subscription License (USL).  A USL provides a user access to the online solution.  Unlike a CAL and like a SAL (that’s a mouthful) you do not need a server license to access the solution if it’s online.  If you want to run anything on premise or in another third-party datacenter, you would require a server license.  In other words, if you have SharePoint Online, the USL license will provide on-premises rights (essentially CALs) in addition to their online rights. This allows for the ability to migrate over time and have hybrid environments without incurring additional cost.  Keep in mind, when you run hybrid, you do require a server license on premise.

Additionally, if you to purchase an online suite (Exchange Online, SharePoint Online, Skype) you can run pieces of the suite on premise. For example, maybe you want to keep SharePoint on-premises but move Exchange to the cloud. An Office 365 Suite includes both online and on-premises rights for each product in the suite, which means you don’t have to pay for the E Suite and then buy Exchange CALs separately.   Just remember the server license!

Summary

It is very important to understand the licensing rules before purchasing any software.  There has and always will be a difference in the way in which technology can be deployed and the way it must be licensed.  Don’t waste money, time, and effort planning a cloud solution without considering the license impact.  I was on a call recently where a customer wanted to leverage their Windows Server with Software Assurance in a shared public cloud.  Unfortunately, Windows is not license mobility eligible.  They worked with a consultant or “expert” who told them one thing, but the rules state otherwise.  Yes, maybe they can take advantage of Windows HUB, but Azure unfortunately was not the right fit.  Pay attention to the license rules, it can save you.  Question?  Email info@splalicensing.com

Thanks for reading,

SPLA Man

 

 

 
6 Comments

Posted by on June 30, 2017 in Office 365, SPLA General

 

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

 
%d bloggers like this: