RSS

Tag Archives: SharePoint

If you could change ONE thing in SPLA…What would it be?

If you were THE Microsoft SPLA MGR in charge of the entire program, what would you change to help grow the SPLA business? (more importantly, YOUR SPLA business)  If you have multiple that’s ok.

Here’s a list from a colleague to get you started:

  • Allow Windows Desktop OS to be included in the unlimited virtualization rights of Windows Server DC
  • Allow MSDN to have License Mobility Rights.
  • Remove the SharePoint Enterprise SALs additive requirement.  Just make Enterprise more expensive.
  • Create cores for Excel and Access for ISV’s.
  • Expand the Productivity Suite and have O365 equivalents to align with O365 pricing.
  • Bring back SQL Enterprise SALs.
  • Add Power BI as a product
  • Reduce Office SPLA pricing!
  • Have the resellers require an End Customer Enrollment for deploying customer owned hardware, and open it up to include Windows PC’s.
  • Bring better clarity to RDS licensing.
  • Create a better way for Microsoft field reps to get credit for SPLA consumption.

You can tweet me at @SPLA_man or send me an email info@splalicensing.com

Thanks for reading,

SPLA Man

 
Leave a comment

Posted by on March 2, 2017 in SPLA General

 

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: , , , , , , , , , ,

Hosting SharePoint 2013

The newest addition to the SharePoint family has features that are built off it’s younger sibling; SharePoint 2010, but offers cool/semi cool new features as well.   For a full list check out Microsoft.com/sharepoint.

Personally, we don’t care about the features, all we care about is how to license it!  SharePoint 2013 for Hosting Providers is not overly complicated, and if you knew how to license SharePoint 2010, chances are you will know how to license the 2013 version.

To license SharePoint 2013, you will either need to license by user (intranet sites) or by processor (extranet site).  If it’s for your customers employees or contractors, you have to license by user (SAL).  If you require Enterprise functionality, you will need to license SharePoint Standard and Enterprise together. (SharePoint Enterprise is an additive license to Standard).

Some things did change with the new edition.  For starters, I noticed the lnaguage in the SPUR has changed for the processor based license.  It now reads:

All content, information, and applications accessible by internal users must also be accessible to external users. Access to servers that provide content, information, and applications that are limited to internal users, must be licensed under SharePoint Server 2013 SALs. “External users” means users that are not either (i) your customer’s employees, or (ii) your customer’s onsite contractors or agents. All other users are “internal users.”

In other words, if you have users that are external and internal, you can license by processor for both scenarios.  The trick is this – the same information has to be accessible to both groups.  If it’s not, you would have to license internal users by SAL and external users by processor. If you are running this in a virtual environment – you will have to license the virtual processors.

To recap:

1. If you license SharePoint by user (internal employees only) you need to report SharePoint Standard Sals.  If you need SharePoint Enterprise, you need to report SharePoint Standard + SharePoint Enterprise

2. SharePoint requres SQL  (either Standard or Enterprise)

3. SharePoint Foundation is free.

4. Always report Windows

5. External users = processor.

6. Virtual environment? – Must license virtual procs (if external)

I wrote a new blog post that tells a fictitious story about a SPLA licensing SharePoint incorrectly. You can check it out
https://splalicensing.com/2014/03/02/dont-be-dave-hosting-sharepoint-2013/

Hope this helps!  Thanks for reading.

SPLA Man

 
13 Comments

Posted by on April 29, 2013 in SharePoint

 

Tags: , , ,

 
%d bloggers like this: