RSS

Tag Archives: Software Assurance

Answers to Your Cloud Licensing Questions

Will Azure be part of the SPLA program?

I wouldn’t think so and wouldn’t know how they could incorporate the two.  Azure is Microsoft hosted and SPLA is partnered.   Microsoft will want to keep SPLA and Azure separate.

Is Azure Stack part of SPLA?

Azure Stack by itself is not part of SPLA.  What’s part of SPLA is the Windows licenses.  As a service provider, you could deploy Azure Stack, pay the base consumption rate, and use Windows licensing with SPLA.  In fact, I think it’s less expensive to do it this way.

If my customer wants to use their own Windows license on Azure Stack, do they also require CAL’s?

Yes.  You need to pay attention to the Product Terms to ensure compliance.  As an example, volume licensing prohibits hosting.  You cannot install your own Windows licenses through volume licensing and host using Azure Stack.

Does Office 365 qualify for the SAL for SA product in SPLA?

The only Office 365 product that is eligible for SAL for SA is Skype.

Is SPLA pricing going up?

Yes and will not be decreasing anytime soon.

Since AWS offers dedicated hardware, could I transfer my customer’s license to their datacenter without Software Assurance?

Yes.  If its dedicated hardware Software Assurance is not required.

What about Azure?

No, you would need Software Assurance.

Will Microsoft finally allow MSDN to be licensed in my datacenter?

Probably not.  Although if you use Azure, MSDN is eligible to be transferred.

If I sell CSP through 2-Tier distributor, can I sign the QMTH addendum?

No.  You must be CSP 1 – Tier to qualify for QMTH.

Can I outsource support for certain software through CSP?

Yes.  You an resell the solutions you can support and leverage another partner for support for other products.

Thanks for reading,

SPLA Man

 

 

 

 

 

 
2 Comments

Posted by on November 7, 2017 in Top 5 Licensing Questions

 

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

Why Windows 10 in CSP stinks now but could be GREAT later

Microsoft made a pretty big announcement around Windows 10 and CSP.  Here’s a breakdown for those that are interested:

  1. Software Assurance is not included
  2. Windows 10 is available E3 and in CSP only
  3. Customers need a qualified OS license.  In other words, this is an upgrade license only.
  4. Not available under SPLA
  5. Not available in the shared computer activation model.
  6. Per user licensing with the ability to license on up to 5 devices per license.
  7. No minimum and surprise…no maximum either.
  8. Subscription is 1 year
  9. Pricing varies
  10. New use rights highlighted in the Product Terms

So why does this stink now but could be great later?  Pay attention to number 1, 4, and 5 in the list above.  That’s what stinks.   Think this will allow VDI?  Think again.

So why not?  Why the mystery around VDI and SPLA?  If I was Microsoft, I would go ahead and allow it but for only a select few SPLA providers.  Those providers are:

  1. Report on time.  Not one late payment/report during their agreement no matter what the excuse – “My reseller sucks” is not an excuse.  It’s a good reason to work with me though 🙂
  2. Deployed Hyper V (they must have some incentive to do this)
  3. Joined CSP program.

There you have it.  Microsoft wins big time – all that missed revenue from non reporters will get reported. Now you, the compliant service provider, will be allowed VDI in SPLA.

The likelihood of this happening is slim to none.  I do think Microsoft is missing out with the Windows 10/VDI restriction.  Ever since I started in SPLA, I’ve been asked about VDI (or the lack thereof).  That was 11 years ago.

Thanks for reading,

SPLA Man

 

 

 

 
Leave a comment

Posted by on September 29, 2016 in VDI

 

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

Hybrid Use Benefit – HUB

Our friend Azure is at it again.  He’s offering Windows license mobility without calling it license mobility.  It’s called HUB – Hybrid Use Benefit.  And yes, it’s only available in Azure.

What is it exactly?  Well let’s say an organization purchased Windows Datacenter with Software Assurance.  Because they purchased the server with Software Assurance, Microsoft will allow them to run a separate instance in Azure and only pay the Linux VM rate.

This same customer can now deploy an image in Azure, pay a non Windows rate (in Azure), and still run an on premise server in their own datacenter to make a true hybrid scenario.  They can do this with Datacenter edition only, since Datacenter allows unlimited virtual instances.  They cannot run a true hybrid with Standard.  They must either run on premise or in Azure with Standard edition.  If you are on the fence about which version to purchase, Datacenter might just win out.

A couple of things to consider.  1) You have to pay attention to the number of licenses you purchased for your on premise servers.  If you purchased Datacenter that has two processor licenses, this will all you to run two instances up to 8 cores or 1 instance up to 16 cores in Azure.  In other words, you cannot exceed the number of licenses you purchased. 2) If you do decide to run Datacenter on premise as well as in Azure, you must maintain CALs for your on premise solution.  Azure does not require CALs, but that doesn’t mean your on premise CAL requirement goes away.

So there you have it.  Confused yet?  If not, wait until I write more about Office 365!  Questions?  Email me at info@splalicensing.com

Thanks for reading

SPLA Man

 

 
3 Comments

Posted by on April 6, 2016 in Azure

 

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

Disaster Recovery Rights and License Mobility

 April 2015 PUR

Fail-over server rights do not apply in the case of software moved to shared third party servers under License Mobility through Software Assurance.

Example

Let’s say an end customer purchased a license with software assurance that qualifies for license mobility.  Since SA allows failover rights, most service providers (if not all) are under the impression they would get the same benefit in their datacenter as they would on premise.  In this example, the end customer transfers a SQL license over to the hoster, the hoster spins up a secondary SQL fail-over server.  Given the statement above from the PUR, If they are enabling SQL fail-over they would need a second license under SPLA.

 Why is this important?

For starters, compliance.  If that secondary server is not properly licensed or your under the assumption that if it exists on premise it must also exist in the cloud you are mistaken.

What about Cold DR?

Doesn’t exist anymore.

What about SQL Failover for SPLA specifically?

SQL SPLA licenses have fail-over rights.  Read the SPUR

What about other products for disaster recovery?

The SPUR has specific language around DR, how long the server can be active (non-production), when Windows would need to be reported, etc.

Any workarounds?

SAL for SA – I think this would fit well for DR.  Customer can still run the software on premise and spin up a second server in the cloud.

Normal SALs- 1 user SAL license can access multiple servers.  Could be another option if the customer is against license mobility.

In the words of a famous hoster “it’s not how you license…it’s how long can you get away with not licensing that really matters”  He was audited immediately following that statement.

Thanks for reading,

SPLA Man

 
Leave a comment

Posted by on April 30, 2015 in Disaster Recovery

 

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 Audit start to finish

Your business is doing great, your sellers and customers are happy, you are making money instead of spending money, when out of the blue….BAM…you receive an audit letter.  Sound familiar?

So what do you do?  Your first reaction is panic.  Your second reaction is to call a lawyer.  Your third reaction is to blame your reseller.  I think that about sums it up.  If you disagree, I’m not 100% sure you are being truthful with yourself.  If you do agree, I also think you are making a HUGE mistake.  Sounds a little odd doesn’t it?

First thing you need to understand is it’s not your fault.  It’s not as if you are purposely trying to be out of compliant.  Microsoft knows this as well.  SPLA is a difficult program and very hard to understand. As I pointed out in the “About” section of this blog, there is little information written about the SPLA program leaving service providers vulnerable.  The SPUR?  Forget about it. That’s why I created this blog in the first place.

I think that is why SPLA customers call a lawyer to help guide them.  This may help you sleep at night, but is it REALLY helping?  I will let you determine that after the dust settles.

What does happen during an audit? I don’t care if this is the first step or fourth step but at some point you will have to collect data.  Data that PROVES the reason you reported the way you did.  One of the biggest mistakes a SPLA provider can make is not reporting indirect access.  Again, not your fault.  Who has any idea of what “indirect” really means?  Think of indirect as Microsoft software that is used to run your other applications that you market to your customers.  You have an application that you developed that reports back to SQL using Excel.  Users have no idea they are using SQL, all they know is the application they use.  But since SQL is part of your hosted solution…it must be reported.  Make sense?  That’s also why Windows will always need to be reported.  Try running Exchange without a Windows OS.  Not going to happen.

Data can also mean the licenses that your customers own that they bring over to your environment.  How do you know who owns what?  Are there enough CAL’s?  One of the arguments service providers make is they can go after their customers if being audited.  There’s an easy conversation right?  Remember, you want to keep customers not lose them.

Some service providers have learned that their end customers install software on VM’s without informing them.  How do you know what is actually being installed?  So take a look at your datacenter; are your customers installing software you don’t know about?  Collecting this information after the fact is a difficult process.  This leaves auditors with no choice but to make a best guess.  Best guesses can cost you significantly.

So after all this data is analyzed by the audit team, it is then delivered to Microsoft.  That’s when you present your case.  They will take things into consideration, but understand that if you are missing information, it makes your argument that much more difficult.  Don’t blame your reseller, that doesn’t work.  Don’t rely on a lawyer, that doesn’t always work either.  Educate yourself.  That’s the best advice I can provide.  Just by taking the time to read this I think you are on the right path.

Happy to walk you through the process in greater detail.  I am one of the few that actually gets it. My email is at the top righthand side of this page.

Thanks,

SPLA Man

 

 
Leave a comment

Posted by on September 18, 2014 in Compliance

 

Tags: , , , , , , , ,

Hybrid, Dedicated, and Shared Scenarios…

There are three deployment options for service providers – Hybrid (mix of on premise and cloud) Dedicated, and Shared.  In this article, we will break each one down to explain how they work and the options available.

Dedicated Scenario – (3 options available)

Option 1
Your customer decides to bring their own software (such as Exchange) and infrastructure (Windows) via their own volume licensing agreement. They do not have software assurance on the software. Can they do this?

Yes. Why? Everything is dedicated. Server, virtual machine all dedicated to one single organization. Software Assurance is NOT required.

Option 2
Your customer decides to bring the software but the hoster will provide the infrastructure in a dedicated environment. Again, customer does not need Software Assurance if it’s a dedicated environment. In this scenario, the hoster (you) will provide the Windows license via SPLA and not report the other applications the customer brings over since it is already covered via their own volume licensing agreement. This is applicable, it’s dedicated (VM and physical servers)

Option 3
Your customer is a healthcare company that needs a dedicated environment due to regulatory compliance. They do not own any software; they would need the hoster to supply the software licenses. Can they (the hoster) do this? Yes, the hoster would report everything under SPLA. The hoster (you) CANNOT use your own volume licensing agreement to provide the solution but you can certainly provide SPLA. Please be aware that if you own a volume licensing agreement, you cannot use the same hardware your volume licensing agreement resides as your hosted solution.

Also keep in mind that SPLA is non perpetual, when the customer leaves, they can no longer use the software they were accessing.

Summary of Dedicated –
Dedicated is applicable for both SPLA and end customer owned volume licensing. Dedicated also means dedicated hardware and dedicated VM’s. In dedicated environments, the end customer DOES NOT need software assurance. From a compliance perspective, it is defined as the following:

“Any hardware running an instance of Microsoft software (OS or application) must be dedicated to a single customer. For example, a SAN device that is not running any Microsoft software may be shared by more than one customer; since, a server or SAN device that runs Microsoft software may only be used by one customer.” (source: Microsoft VDA FAQ)

Hybrid Scenarios – 3 options available

Option 1
You decide to offer your customer a shared infrastructure but they want the same applications to run on premise. A good option would be to have the customer purchase the server applications (think Exchange, SharePoint, Lync) with software assurance (SA) and run them on premise. You (the service provider) would run the same applications in your shared environment BUT report the SAL for SA SKU. Much cheaper option than standard SPLA prices. I wrote about this here This also works well for Disaster Recovery options.

Option 2 (not really a hybrid but just go with it)
You can use license mobility. Microsoft likes to define this as a “hybrid option” but to me, hybrid insinuates the ability to run on premise and in your cloud. License mobility is a SA benefit for certain applications (SQL, CRM, SharePoint, Exchange, Lync) that allows customers to leverage their investment in SA and transfer those licenses into a hosters shared infrastructure. Reason why I don’t think this is truly a hybrid is the customer is TRANSFERRING licenses into your datacenter. This means that if a customer wants to move back to their own datacenter, they have to wait 90 days. (transfer license rule). With SAL for SA, nothing is being transferred. Windows does not have mobility rights, this will need to be reported under your own SPLA. I wrote about license mobility many times – here’s an article for your review – here You can also check out the Microsoft site for more of a definitive definition http://www.microsoft.com/licensing/software-assurance/license-mobility.aspx

Option 3
Good Ole’ SPLA. Customer can run their own servers on premise, you just report SPLA licensing in your shared environment. The new SPLA agreement even allows you to run SPLA software on customer owned hardware as long as you still manage it.

Shared Scenarios – 2 options

Option 1
License Mobility – see above

Option 2
SPLA. We all know what that is.

Summary

I hope this brings a bit more clarity. Sorry if some things are redundant but at the same time, some things are simply worth repeating. Here’s the takeaway – customer’s can always bring licenses into your datacenter. There is no law of the land that prohibits this. What is prohibited is the way you deploy the technology. There is only one option to install customer owned licenses in a shared environment and that is license mobility. Again, (here I go being repetitive) if Microsoft allowed customer owned licenses to be installed in shared environments than why would they create license mobility?

If you still have trouble comprehending all this, shoot me an email located at the top right of this page. One general rule of thumb – if it’s shared – 90% of the time SPLA is required.

Thanks for reading

SPLA Man

 
15 Comments

Posted by on August 27, 2014 in Compliance, License Mobility

 

Tags: , , , , , , , ,

It’s a bird…it’s a plane…it’s VDI and SPLA!!!

We have all been there. You see an email come across in the subject line that you’ve seen before. You release a loud sigh, because you already know the response to the email before you even open it. How? Well you’ve been asked the same question before on numerous occcassions and give the same response. For me in particular, the subject in the email is “SPLA and VDI”  It’s not frustrating, it’s just I hate saying “no”  (just ask my son – a bit spoiled I admit)

I try to write about different topics, but I also like to give updates and understanding to various topics that really hit home; VDI is one of them. You can read my previous article here  In this post, I will break VDI into two parts: defining VDI and moving forward.

Definition

What is a virtual desktop in the licensing world? You should think about virtual desktop as a software assurance benefit. Like license mobility, software assurance is required. Unlike license mobility, there is no option to install in shared infrastructure. Let me repeat – no option to install in shared infrastructure. One more time…no option to install in shared infrastructure. What are the options?

Since VDI/VDA is a software assurance benefit, your customer must purchase their desktop OS with software assurance to have VDI rights. That means if they did not purchase with software assurance, there is no option for them to use virtual desktops from a true licensing perspective. What if the machine is a dummy terminal with no software assurance option available? The end-user would be required to purchase a VDA license for each device. VDA license is kind of like a device CAL, it just provides the user access to a virtual instance. If your customer has not purchased VDA or software assurance on the OS, they need to reconsider if they want a virtual desktop.

Some service providers are under the impression that they can sell a desktop OS perpetually to the customer and host it for them in a dedicated environment. They have the dedicated environment part right, but an OS sold to an end-user does not grant that end-user access to a virtual desktop without software assurance (SA). Secondly, you have to be an authorized reseller to sell perpetual licenses (non SPLA) to consumers. Third, you cannot buy a Windows desktop license yourself and host it to third parties. Anything you buy outside of SPLA is for your internal employees only. Last, not only should you not buy licenses and host, but do not install on servers that is also used for your internal use. That is a big compliance headache.  Where is it written that you cannot host on servers internal employees are also accessing?  It’s not.  That’s what makes it a headache.  Just don’t shoot the messenger!

So why can’t the end-user just go to Best Buy or some other retailer, purchase a retail copy, have you (the service provider) host it for them? That not only is a compliance risk, it is also not very economical. Download the FAQ guide here

Moving Forward

What are your options?  The good news is Azure, AWS, and all the others have the same rules.  They cannot offer desktop OS in the public cloud.  This is probably the best FAQ guide I’ve read around Azure and it applies really to all IaaS providers.  Check it out here

What you can do is offer Windows Server to emulate a desktop using RDS.  I get it, not the same thing but I think it is a more of a compelling solution from a cost perspective (and be compliant).  Dedicating a physical server and virtual server is not always the most profitable solution.  I’ve said this before, I think the bigger issue is Office.  RDS now has mobility rights, I think Office should too.

My Opinion

If I was a service provider, I would work with someone who is an expert in SPLA based licensing and an expert in software assurance benefits.  As you can see from my previous posts and with VDI, software assurance is a requirement for most cloud based licensing solutions.  In years past, SA (Software Assurance) was only leveraged for organizations that wanted the latest version on software and pay annually for the licenses under their agreement.  The “cloud” has changed that.  Fast forward to today and customers want to move to the cloud but leverage their existing licenses.  Have you been asked that before?  How do they accomplish that?  The answer is Software Assurance.  They need SA to use license mobility, they need SA for VDI, they need SA for hybrid scenarios such as the SAL for SA SKU’s, and they still  need SA for latest version rights and pay annually.  If I was a Microsoft shareholder, I would applaud that move.  It’s a way to add additional revenue on top of the licenses they purchased all the while giving customers the benefits they are after.

So if you ask, “why does Microsoft not allow VDI in a shared environment?”  My answer is “why would they?”

Thanks for reading,

SPLA Man

 
2 Comments

Posted by on August 13, 2014 in VDI

 

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

License Mobility With Software Assurance – the facts

Here’s another post on license mobility.  I am not purposely trying to be redundant, but majority of compliance issues come from customer owned licenses.  It’s important that you, your sellers, and more importantly your customers understand this program in its entirety. So here we go!

License Mobility, in its simplest terms, is a software assurance benefit that allows customers to migrate their existing licenses to a third-party data center.  Third party data center is a service provider.  (Amazon, Azure, Joe’s Hosting, etc).  Primarily this applies to application servers – Lync, Exchange, SharePoint, and CRM.  It also will include products such as System Center, SQL, and Remote Desktop Services.  I encourage you to check out the Microsoft website http://www.microsoft.com/licensing/software-assurance/license-mobility.aspx for more information.  Since this website is dedicated to the service provider community, I thought I would put together some common mistakes service providers make when deploying license mobility.  Fasten your seat belt, there might be a few surprises in this list.

Fact #1

License Mobility is an addendum to your SPLA.  This is NOT automatically granted.  If your company is not on this list, make sure you sign the addendum!  Download the list here  At a hosting summit several years ago, Microsoft announced this program to a room full of service providers.  You should have seen the look on everyone’s face as they made the announcement; almost hear the thoughts running through their minds “Wait a minute, this wasn’t legal before this announcement!!, We were doing this for years!”  That’s right, if you are hosting customer owned licenses in a shared hardware infrastructure/dedicated VM, make sure the products are license mobility eligible (see the SPUR) and make sure you sign the addendum!  I said this before, if Microsoft allowed all products to be installed on a shared hardware infrastructure, why would they have license mobility?  If you have customers that are bringing licenses into your data center and are not mobility eligible, make sure it’s dedicated.  (VM and hardware)

Fact #2

You need to make sure your end customer submits the verification form.  Why?  It’s a requirement by Microsoft.   Essentially there are three times your end customer should complete and submit a License Verification form:  (This is from the verification form guide).

1. “When you deploy eligible licenses with an Authorized Mobility Partner. A new form is required each time you deploy additional licenses.”

2.” When you renew your Software Assurance.”

3.” When you renew your Volume Licensing Agreement.”

“The form can include multiple enrollments or license numbers under a single agreement, provided that they are supported by the same channel partner. However, you should complete a License Verification form for each agreement under which you are using License Mobility (for example, an Enterprise Agreement and a Select Plus agreement).”

How many verification’s forms have been completed?  Very few if any.  Since this is not completed, you (the service provider) can be on the hook.  If anything else, please make sure you make this mobility guide available to your customer to review.  Check it out here

Fact #3

When end customer use license mobility, they are transferring the licenses into your data center.  When you transfer licenses, they can only transfer the licenses away from your data center once every 90 days.  Good news – you keep the customer for a minimum of 90 days!  So let’s say they decide to go back to their own data center; same story – once every 90 days.  From the License Mobility FAQ Guide.

“Customers must assign licenses for a minimum of 90 days, after which they may move their licensed software from a service provider’s shared servers back to their local servers or to another service provider’s shared servers.  Instances run under a particular license must be run in a single server farm and can be moved to another server farm, but not on a short-term basis (90 days or less). A server farm includes up to two data centers each physically located either in a time zone that is within four hours of the local time zone of the other [Coordinated Universal Time (UTC) and not Daylight Savings Time (DST)], and/or within the European Union (EU) and/or European Free Trade Association (EFTA).”

Fact #4

You need to include educational materials to your customers during the purchasing process.  I did not make this up, it’s part of the addendum you need to sign to take part in the program.  Azure does this via their website http://azure.microsoft.com/en-us/pricing/license-mobility.  Amazon does this as well http://aws.amazon.com/windows/mslicensemobility/ Very few on the partner list makes this readily available on their website.  In fact, out of 10 random selected partners on the list, none have a written statement on mobility.  Perhaps you make this as part of your agreement with your customer; but not sure why you wouldn’t make this as part of your marketing strategy.  If you look up “authorized mobility partners” why wouldn’t you want them directed to your site? To prove my point  I looked up “authorized mobility partners” and only a handful of actual hosters show up in the top searches.  Make it your company.

Fact #5

I’ll make this one short; Windows does not have mobility rights.  You need to report Windows server via SPLA.

I know I am beating a dead horse with license mobility.  I just feel this is a big miss by providers and customers.  The bigger miss is SAL for SA  – check out my old post here

I hope you find these articles helpful.  Have any concerns, questions, or just want a second opinion – feel free to email me at blaforge@splalicensing.com

 

 

 
Leave a comment

Posted by on June 24, 2014 in License Mobility

 

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

Disaster Recovery Rights for SPLA

Spring.  The time of year in which flowers bloom but storms loom. (I will not quit my day job by the way).  Those reading this article that live in the middle of the United States, you would probably agree with that statement.  Sometimes it may take a storm for organizations to start thinking about their own disaster recovery plans.  Maybe it’s time to get ahead of the storm; that’s why I thought I would spend time reviewing DR, industry best practices, and licensing scenarios.

In previous editions of the SPUR, you were allowed to temporarily run a backup instance on a server dedicated for DR with the following exceptions:  The server must be turned off except for limited testing and DR, may not be in the same cluster, and you may only run the backup instances and production instances at the same time only while recovering from a disaster.

I never understood the rule “the server must be turned off.”  If it’s turned off, how is backing up anything?  Secondly, what is meant by “limited testing?” How much time does it allow you test? Two days…a week…a month?

In the new SPUR, it brings clarity to some of those questions.  From the April SPUR:

“The disaster recovery server can run only during the following exception periods:

  • For brief periods of disaster recovery testing within one week every 90 days
  • During a disaster, while the production server being recovered is down
  • Around the time of a disaster, for a brief period, to assist in the transfer between the primary production server and the disaster recovery server

In order to use the software under disaster recovery rights, you must comply with the following terms:

  • The disaster recovery server must not be running at any other times except as above.
  • The disaster recovery server may not be in the same cluster as the production server.
  • Windows Server licenses are not required for the disaster recovery server if the following conditions are met:
  • The Hyper-V role within Windows Server is used to replicate virtual OSEs from the production server at a primary site to a disaster recovery server.
  • The disaster recovery server may be used only to
  • run hardware virtualization software, such as Hyper-V,
  • provide hardware virtualization services,
  • run software agents to manage the hardware virtualization software,
  • serve as a destination for replication,
  • receive replicated virtual OSEs, test failover, and
  • Await failover of the virtual OSEs.
  • run disaster recovery workloads as described above
  • The disaster recovery server may not be used as a production server.
  • Use of the software on the disaster recovery server should comply with the license terms for the software.
  • Once the disaster recovery process is complete and the production server is recovered, the disaster recovery server must not be running at any other times except those times allowed here.”

If I had a hosting company that specializes in DR solutions, I would have my customers purchase their licenses outright with Software Assurance from their reseller (like SoftwareONE).  I would make sure they deploy it on premise and I would set up a secondary server in my datacenter. Now comes the fun part – how to license the solution!

Let me provide an example.   Let’s say your customer is a law firm and email is extremely important to their business.  They cannot lose email for one minute, let a lone a day.    The customer would like the greatest discount long term but very concerned that if a disaster does happen, they won’t be prepared.  (this is when you come to the rescue).  You have a solution that will allow them to run their Exchange on premise by purchasing Exchange with Software Assurance from volume licensing (greater discount over SPLA long term), and you as the service provider can run Exchange in your datacenter using the SAL for SA SKU.  Never heard of the SAL for SA SKU?  You’re not alone.  This SKU is available for certain applications (Lync, SharePoint, Exchange – check SPUR for availability) and allows the service provider to host the application in a shared (virtual & physical) environment.  More importantly, the cost is extremely attractive AND your customer can still run it on premise.  This is NOT license mobility.  License mobility allows you to run it in a shared hardware but dedicated VM.  It also requires the customer to transfer those licenses out of your datacenter only (not on premise).

Here’s the criteria for reporting SAL for SA for those home gamers.

SALs for SA

“SALs for SA may be acquired and assigned to users who have also been assigned a qualifying Client Access License (“CAL”) with active Software Assurance (“SA”) acquired under a Microsoft Volume Licensing Program or who uses a device to which a qualifying Device CAL with active Software Assurance coverage has been assigned. You may not acquire SALs for SA for more than one user for any given qualifying CAL. Use rights for SALs for SA are identical to their corresponding SALs, as defined in this document. The right to assign a SAL for SA to a user or device expires when the Software Assurance coverage for the qualifying CAL expires.”

Be careful if you decide to go down this route. You have to ensure when reporting SAL for SA that the customer has active SA for the licenses you are reporting.  If they don’t, both you and your customer are out of compliant.  This comes up all the time during audits.  “I swear they own these licenses Mr. Auditor!”  Secondly, make sure the products are SAL for SA eligible when discussing with your client.

In summary, pay attention to the new DR rights mentioned above; consider SAL for SA as an alternative; and last but certainly not least, maybe reconsider your vacation to the Midwest until the Fall – flowers bloom, storms loom.  Hit me up at blaforge@splalicensing.com  if you want to learn more about SAL for SA or anything hosting related.

Thanks for reading,

SPLA Man

 
4 Comments

Posted by on April 30, 2014 in Disaster Recovery

 

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

 
%d bloggers like this: