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
SPLA Licensing 