RSS

Tag Archives: SPLA Audits

Steps to take to limit SPLA audit exposure

It’s the fourth quarter at Microsoft, this means audits are in full swing.  One of the easiest ways to collect large upfront payments are through SPLA audits.  Knowing this, what steps can you take to limit your audit exposure?

  1. Inventory – Although you submit a SPLA usage report each month, licenses are missed inadvertently.  When collecting inventory of what you should and should not report, be sure to include customer owned licenses.  If ANY customers are bringing licenses into your datacenter, they must have software assurance if it’s a shared environment.  Secondly, make sure to take a hard look at SQL.  To no one’s surprise, SQL is very expensive.  If you miss license SQL, it can add up really quickly.
  2. Agreements – Which MBSA agreement did you sign?  Don’t know what a MBSA agreement is?  Please ask your reseller for a copy.  Every SPLA customer has a signed Master Agreement.  This is the umbrella that ties all your Microsoft agreements together including SPLA.  There’s specific language in the agreement that goes over audits and the timeframe in which they are able to audit historically. Look closely at your agreements with your customer.  Did you mention they are responsible for licenses they bring into your datacenter?  Did you send them a license verification form for license mobility?  Do you have language that states they are responsible for anything under their Microsoft agreement but you are only responsible for yours?  Do you make the end user license terms (part of your signed SPLA) available to all customers?  Don’t know what an end user license terms agreement is?  Ask your reseller.
  3. Check AD closely.  Do you have administrative accounts that you are reporting?  What about test accounts?  Read your Microsoft SPLA agreement around testing, developing, and administrative access.
  4. Label server names appropriately – Label if a server is “passive” and label a server if it’s “development”.  This can save you time with the auditors.
  5. Check server install dates – If a server was active June, 2013 but nothing was reported on that server until June, 2015; Microsoft is going to ask A) what that server is doing and B) Why haven’t you reported it.  If it’s doing nothing, than shut it down before the audit.
  6. Check SAL licenses –  Do all users who potentially HAVE access are being reported?
  7. Check Office licenses – Do all users need access to Office Pro Plus?  Can they get away with Standard?  Did your engineers inadvertently publish Visio to every user when it only needs to go to a handful of end users?
  8. Double check server versions – Did your engineers accidentally install SQL Enterprise when it should be Standard?
  9. Are you taking advantage of all the use rights available?  As a SPLA, are you aware you can provide demonstrations to your customers at no charge?  Are you aware of the admin rights?  Are you aware you can run 50% of what you are hosting externally – internally?  (must actually report it all under SPLA – they are not free).
  10. Virtualization rights – Are you reporting SQL Enterprise to run unlimited VM’s? Are you running Windows Datacenter?  Remember, you do not license the individual VMs for Windows Server.  (You count physical cores which allows 1 VM for Standard or unlimited for Datacenter).
  11. MSDN, VDI, and other restrictions – No, you cannot host VDI and MSDN in a shared environment.  If you are, dedicate the servers immediately.  If you are hosting from the same hardware you are running internally, this also must be separated.
  12. Hiring Experts – Are they really experts or just advertise as such?

Hope this helps.  Any questions email info@splalicensing.com

Thanks for reading,

SPLA Man

 

 
Leave a comment

Posted by on April 25, 2017 in Compliance

 

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

 
%d bloggers like this: