MSDN and Production Environment (again)

Question

I started this on another forum before I found this one, but this seems a more suitable place.
The definition of "production environment" seems rather odd. In some responses on this forum it appears to refer to "soft" systems whereas the latest MSDN licence refers to environment and physical kit.
Below is a conversation I had over email with someone from MSDN and I find the whole thing utterly bizarre. I cannot for the life of me see how this helps anyone apart from MS being able to charge for non-production software. It renders having a powerful desktop
for local lab experimentation pointless as you're not allowed to install anything and effectively doubles the hardware cost to small companies if they have to buy a separate server for any testing work (yes, best practice and all that, but budgets...) or pay
out for a Windows Datacenter licence.
Question:
“If a physical machine running one or more virtual machines is used entirely for development and test, then the operating system used on the physical host system can be MSDN software. However, if the physical machine or any of the VMs hosted on that physical
system are used for other purposes, then both the operating system within the VM and the operating system for the physical host must be licensed separately.”
Is this actually saying that if I have a physical server licenced with a purchased (not MSDN) Server 2012 R2, running Hyper-V with, say, a production file server VM on it,  that ALL Windows VMs on that machine must have purchased licences even if they
are only for development & testing purposes?
Is this saying that all production and development Windows VMs must be only completely separate hardware, cluster, SAN, etc otherwise you must pay for full licences for the VMs?
Or does it just mean that the bare metal licence (plus any additional ones required for running further production VMs) must be purchased if the VMs are a mix of production and development?
Answer:
We kindly inform that any products licensed under the developer tools model (e.g. SQL/BizTalk developer and/or MSDN) must be installed on their own separate physical hardware.
You are not allowed to run test or development products on a server where production workloads are running at the same time.  Kindly run your developer software on a device/host that is dedicated to testing and development.
Explanation:
The Product Use Rights (PUR) say that the developer software is not licensed for use in a production environment. Even if the PUR does not have a separate definition of production environment, a production environment is a set of resources for network, physically
dedicated hardware and software to provide "live" service.  If the intent was to say that the same physical server could be used for both development and production - it would say "not licensed for use in a production OSE," instead
it says environment.
See current PUR, page  51:
Developer Tools (User License)
You have the rights below for each license you acquire.
#      You must assign each license to a single user.
#      Each Licensed User may run an unlimited number of copies of the Developer Tools software and any prior version on any device.
#      The Licensed User may use the software for evaluation and to design, develop, test, and demonstrate your programs. These rights include the use of the software to simulate an end user environment to diagnose issues related to your programs.
#      The software is not licensed for use in a production environment. #      Additional rights provided in license terms included with the software are additive to these product use rights, provided that there is no conflict
with these product use rights, except for superseding use terms outlined below.
Question:
Classifying an entire physical infrastructure as "production" in these days of virtualisation and shared storage really does not make any sense at all. Not using the software for production purposes makes perfect sense, but not being able to locate
it alongside production OS installs is mad. Does this only apply to the server running the VM (CPU and RAM)? If the VHDX is hosted on shared SAN storage does the SAN have to be dedicated to non-production storage?
Answer:
We kindly inform that after double-checking the case we would like to confirm the development software cannot be run on the same hardware with production software.
We have also received a feedback from the responsible team regarding your request about a dedicated SAN (Storage Area Network) for MSDN software.
They have confirmed that the SAN has to be dedicated to the development and testing environment if it is used to run the software acquired through MSDN.
Question:
OK, so if I have my desktop (which is a production environment as I use it for email and other day to day office tasks), can I turn on Hyper-V and install an MSDN Windows Server 2012 instance for development purposes?
Answer:
We kindly inform it is not allowed to install and run software from MSDN subscriptions in production environments. Please do not install MSDN software on a desktop in a production environment:
"[.] The customer will need to run the developer software on a device/host that is dedicated to testing and development.
Explanation:
The Product Use Rights (PUR) say that the developer software is not licensed for use in a production environment. Even if the PUR does not have a separate definition of production environment, a production environment is a set of resources for network, physically
dedicated hardware and software to provide "live" service.  If the intent was to say that the same physical server could be used for both development and production - it would say "not licensed for use in a production OSE," instead
it says environment.
See current PUR, page  51:
Developer Tools (User License)
You have the rights below for each license you acquire.
-      You must assign each license to a single user.
-      Each Licensed User may run an unlimited number of copies of the Developer Tools software and any prior version on any device.
-      The Licensed User may use the software for evaluation and to design, develop, test, and demonstrate your programs. These rights include the use of the software to simulate an end user environment to diagnose issues related to your programs.
-  The software is not licensed for use in a production environment.
-      Additional rights provided in license terms included with the software are additive to these product use rights, provided that there is no conflict with these product use rights, except for superseding use terms outlined below.

Answer 1

Hi Mike,
It sucks that MSDN software can't be run in a production environment, that means you have to have two entirely separate hardware environments, which are costly, and it seems unnecessary.  
That's essentially it. I'm not saying for one second that it should be used for production purposes, just that it's physical location shouldn't be relevant. Also, the word "environment" is a very bad choice in the documentation simply because it's very open
to interpretation.
A production environment is defined as an environment that is accessed by end users of an application (such as an Internet Web site) and that is used for more than
Acceptance Testing of that application
or Feedback. Some scenarios that constitute production
environments include:
Environments that connect to a production database.
Environments that support disaster-recovery or backup for a production environment.
Environments that are used for production at least some of the time, such a server that is rotated into production during peak periods of activity.
So I dont think (here's that inconclusive language) but am not sure that your desktop machines count as production environments, based on that, unless end users are connecting to them. (I dearly hope they are not!)
My reading is based on the "Other Guidance" section:
"If a physical machine running one or more virtual machines is used entirely for development and test, then the operating system used on the physical host system can be MSDN software. However, if the physical machine or any of the VMs
hosted on that physical system are used for other purposes, then both the operating system within the VM and the operating system for the physical host must be licensed separately."
<o:p>This is the crux of the matter and the interpretation of "licensed separately". A (to my mind) sensible reading of that would be "if you're running any production purpose VMs on a server then the physical host OS must be a full licence
[presuming it's Server 2012 and not, say, VMWare or Hyper-V 2012] as must all production purpose VMs on that server". This has been getting interpreted by others (I'm not the first) and backed up by MS as meaning that if you want to run any dev/test VMs on
a server that also runs production VMs then you can't use MSDN for those dev/test VMs.</o:p>
Also, there is a section
here, on the MSDN Licensing help page that says (with my added emphasis):
Many
MSDN subscribers use a computer for mixed use—both design, development, testing, and demonstration of your programs (the use allowed under the MSDN subscription license) and some other use.  Using the software in any other way, such as for doing email,
playing games, or editing a document is another use and is not covered by the MSDN subscription license. 
When this happens, the underlying operating system must also be licensed normally by purchasing a regular copy of Windows such as the one that came with a new OEM PC.
Now to me, it seems this might be saying that the underlying operating system on a work
machine cannot be licensed using MSDN if that work machine is going to be doing non-msdn things in addition to MSDN things.  It doesn't say "This can't happen" it just says "When this happens, the underlying
OS must be licensed normally..." 
So, based on what I'm reading it seems that this quote from you might not be true:
"We can't install a local MSDN instance of Server 2012 or 8.1 for dev and test under Hyper-V on desktops
because desktops used for email, writing documents, etc are production. "
I wouldn't have expected this to be true either, but this is the response I was given. It may well be
that my question was misunderstood. I hope this is the case otherwise one of the big reasons for turning on Hyper-V on  expensive, powerful desktops enabling the running of personal test environments goes out the window!
Thanks for your time on this.