The Microsoft Developer Network, better known as MSDN, is one of Microsoft’s most fascinating and misunderstood products. Over my 15 years at Microsoft, I experienced many new MSDN launches, and each brought new and exciting features. As the product has matured over the years, adoption has soared. Keep in mind that much of Microsoft’s early success was based on winning over developers, so it is no surprise the degree of effort Microsoft has put into MSDN over the years. In today’s world of cloud, modern MSDN is evolving rapidly around cloud services, and that will continue to accelerate.
When most of us hear someone say those four letters “MSDN,” we automatically picture a software developer in our mind, but how many of you would also picture a system administrator? My guess is not many! So, why would I ever assign an MSDN to my system administrator? To answer that question we need do some level setting.
We first need to separate Visual Studio and MSDN. The only way to acquire a new copy of Visual Studio is to purchase it with an MSDN Subscription, with one exception. The exception is that Visual Studio Professional can be purchased without an MSDN subscription. So when you look at the SKU level, Visual Studio Ultimate with MSDN is a single SKU from a license entitlement perspective.
Microsoft Visual Studio is a world class software development tool which provides robust application lifecycle management (ALM) capabilities. Yes, this is the toolset your developers will use to design and test your organizations custom software. I will also include Team Foundation Server (TFS) and Lab Manager with Visual Studio for simplification purposes. Today, there are multiple versions of Visual Studio available, and yes, as you add features, it adds to the cost. To give you an idea of cost differences, you could choose to buy 11 copies of Visual Studio Professional with MSDN, or for the same price one copy of Visual Studio Ultimate with MSDN. To be fair, Ultimate offers significantly more capabilities over Professional. This article is not going to dive into the features of Visual Studio since that would be a book unto itself. The most important take-away here is Visual Studio is one of the most expensive user based products you will buy, and selecting the correct edition each developer requires is critical to cost management.
So what else do I get with an MSDN besides Visual Studio? There has to be something since Microsoft offers two MSDN subscriptions that do not include any Visual Studio. Those would be MSDN Platforms and MSDN Operating Systems. And we have now arrived at the core of this article.
All of us are accustomed to purchasing software licenses for our Microsoft production systems. We can license our non-production systems with the same licenses, but there is a more affordable option. And, you guessed it, that option is MSDN. One of MSDN’s largest benefits is development/test use rights of Microsoft software. Properly licensing your Microsoft non-production environment is easy once you understand the rules, and I am going to help get you started in the right direction.
Before we go any further, you need to understand that MSDN is licensed by user only and not by any other means. Over the years, I have met customers who thought Microsoft offered an MSDN team license, and some actually thought they owned a team license! A licensed user can install MSDN software anywhere Microsoft authorizes, which is outlined in the “Visual Studio 2013 and MSDN Licensing White Paper,” which can be downloaded from Microsoft’s website. The current version of the white paper is dated July 2014.
It is critical to understand what systems can be licensed with MSDN. I always start with the current “Visual Studio 2013 and MSDN Licensing White Paper.” Page 13 of the current whitepaper outlines where MSDN software can be run. It also clarifies what Microsoft views as a production environment, and MSDN can never be run in a production environment.
Just remember, every user directly or indirectly accessing Microsoft non-production systems licensed via MSDN must have the proper MSDN edition. I want to emphasize indirect access (Microsoft refers to this as multiplexing), for which Microsoft has a complete licensing brief. An MSDN is not required for an end user performing user acceptance testing (UAT), as outlined in the white paper. If a person’s primary role is to design, develop, or test software, it would be unlikely that they would also qualify as an end user.
So, let’s think about who normally accesses your Microsoft non-productions systems. Well, we know our developers will need an MSDN. Our database administrators (DBA) will need one too. Then, there are our business system analysts who work with the end users and most likely access the non-production systems on a daily basis. And, our system administrators will need one since they build and manage the non-production systems. Yes, even just managing the systems requires proper licensing, and you now know why your system administrator needs an MSDN.
So how do I know what software I am allowed to run in my non-production environment based on the MSDN subscription level? The good news is this is easy to determine by looking at the current “Products_by_Benefit_Level.xlsx,” which can be downloaded from Microsoft’s website. You can Google or Bing for “Products_by_Benefit_Level.xlsx,” and it will be easy to find. This easy to read spreadsheet lists each Microsoft product in the first column, and then provides a column for each MSDN subscription level. You can quickly look down and see if a specific level of MSDN can use a given Microsoft product in a non-production environment. For example, a Visual Studio Professional with MSDN has access to Windows Server and SQL Server, but not SharePoint Server. If SharePoint Server was in your non-production environment your developers with Visual Studio Professional with MSDN would be out of compliance if they were accessing the SharePoint Server. Thus, when selecting the proper level of Visual Studio for your developers, you have to account for the Microsoft software they will access in your non-production environment.
The MSDN Platforms was released in the summer of 2014 and prior to its release; customers had to purchase the more expensive Visual Studio Premium with MSDN to gain access to all Microsoft servers. This was an expensive proposition for customers who needed to license non-production servers like Exchange Server or SharePoint Server for users who never used Visual Studio. The new MSDN Platforms is long overdue, and now allows customers a cost effective option to properly licensing their non-Visual Studio users. Please note that MSDN Platforms is only available via the Microsoft volume license program.
When you hear someone referring to an active MSDN, they are saying that the MSDN is still covered with active Software Assurance (SA). All new MSDN come with active Software Assurance. I would like to point out that some MSDN licensing options provide a perpetual license to Visual Studio and non-production software. Your Visual Studio would be frozen at the latest release version when your active Software Assurance expires. Your rights to run non-production software will be frozen at the point the active Software Assurance expires, based on the current version of “Products_by_Benefit_Level.xlsx”. For example, if your non-production rights to SQL Server were frozen at SQL Server 2012, then your MSDN would never be licensed for SQL Server 2014 or beyond. If your organization is in the habit of running expired MSDN, you can do it, but it requires a very solid software asset management program to steer clear of compliance problems.
The higher end editions of MSDN (Ultimate and Premium) offer the added benefit of running Office Professional Plus 2013 on one device for production use.
I would like to point out some gotchas, so you can avoid them. If you mix production and non-production virtual servers on the same physical host, you need to pay very close attention to the licensing of both environments. You may not license System Center with MSDN to manage non-production systems, you must purchase production server management licenses. Another gotcha is desktop applications like Visio and Project. If they are used to create business documents, they cannot be licensed via MSDN. And last, the developers Windows desktop requires a production license of Windows.
To sum it all up, MSDN provides rights to license non-production systems in a cost effective manner. MSDN is only licensed by user; there are no other licensing options. All new MSDN come with active Software Assurance, you cannot acquire an MSDN license only. Some MSDN licensing options provide perpetual rights to license your non-production systems, but be careful. Remember when selecting the proper edition of Visual Studio for your development team; always make sure it will also license them for all of the Microsoft software they will access in your non-production environment.
Thank you for taking the time to learn why a system administrator would ever need an MSDN. I will be presenting “Licensing the Microsoft Development Environment” at the IAITAM 2014 Fall ACE, which will build on this article.