Close this search box.

MSDN and TFS Licensing Gotchas

As most of you know it’s probably easier to understand Rocket Science than it is Microsoft Licensing.  Unfortunately, I’ve had to deal with it enough over my career that I have a pretty good grasp of at least how MSDN, Visual Studio and TFS Licensing works.  The best resource for attempting to decipher how it works is the MSDN Licensing White Paper.

However, there are several gotchas with the way licensing works.  These are things that most people don’t even realize, and they run afoul of the rules without knowing it.  There are also some good parts of the licensing rules that lots of people don’t know about.  Lets start with the good ones:

The Good

TFS is Free

For most teams TFS is actually “free”.  MSDN includes a production license for TFS, meaning so long as you have more MSDN Licenses (VS Pro and up) than you have TFS Servers you don’t need to buy any additional licenses (of course you still need to make sure you have CAL’s for everybody, but your MSDN users will all have CAL’s as part of their MSDN). 

SQL and SCVMM Exception

TFS requires a SQL Server and if you’re using TFS Lab you need an SCVMM Server.  MSDN includes a “limited use” license that allows you to install SQL Server Standard and SCVMM without needing to purchase licenses for them, on the condition that they are *only* used for TFS (the SQL Server can be used for the TFS Data Tier and the SCVMM Data Tier and the SharePoint Data Tier, so long as the SCVMM/SharePoint instances are used only for TFS).  Note: If you wish to use SQL Server Enterprise you have to purchase a license for that. 

TFS Lab Software

If you use TFS Lab functionality, the virtual machines you setup do not require you to purchase any licenses for Windows/SQL/BizTalk/etc (or for the Hyper-V Host and Library servers) – so long as everybody accessing TFS Lab environments has an MSDN license.  This effectively means that TFS Lab is “free” on the condition that only MSDN licensed users access it.

The Bad

Cannot Deploy Development VM’s to Same Hosts as Production VM’s

This is really the most shocking one to me.  Any VM that uses MSDN licensed software cannot reside on the same physical host server as any production VM’s.  This would effectively require companies to have separate virtualization infrastructure for the production and non-production VM’s.  Almost nobody actually does this (in my experience), and as a result is violating the MSDN licensing rules.  Here is the specific quote from the MSDN Licensing White Paper that specifies this limitation:

“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. The same holds true for other software used on the system—for example, Microsoft SQL Server obtained as MSDN software can only be used to design, develop, test, and demonstrate your programs.”

When I first read that I thought I must be misunderstanding what that means because it just sounded so outrageous.  However, I received confirmation from Microsoft (on the ALM MVP mailing list) that this does in fact mean you must have separate hosts for Production vs. MSDN-Licensed VM’s.

Software Installation Requires MSDN

Most teams I work with have several Dev/Test/UAT/etc environments that they use.  These are often provisioned by some central IT Ops group, then the Dev team takes over and installs the necessary software.  These environments should not require any purchase of licenses for Windows/SQL/etc because they will be using MSDN licensed software (this is exactly what MSDN licensing was invented for).  However, typically when the IT Ops group provisions the machines, that usually involves installing Windows and Windows Updates, and joining it to the domain.  What most people don’t realize, is that anybody that accesses that machine requires MSDN, even if they are just accessing it to install the OS, or join it to the domain.  So unless your IT Ops group has MSDN licenses for their staff (which they usually don’t), then they are violating MSDN licensing rules.

Multiple TFS CAL’s Required for Consultants/Contractors 

If you are somebody that accesses the TFS Servers belonging to multiple different companies, you might not realize that you actually need to acquire a separate TFS CAL for each company.  For example, I work for Imaginet and Imaginet pays for my MSDN subscription.  The TFS CAL that comes with that MSDN is only valid for connecting to Imaginet TFS Servers.  Each client I visit, I would need a separate CAL to access their TFS Servers in theory acquired by that Client.

UAT Exception and Using MTM 

There is a specific exception in MSDN that says you can use MSDN Licensed environments (your Dev/Test/UAT environments) for performing UAT even by people that do not hold MSDN Licenses.  In this case, my understanding is UAT is specifically limited to end-users of the application (does not apply to QA staff, who will require MSDN licenses).  The question came up recently whether those end-users performing UAT are allowed to use MTM to facilitate that UAT process (run Manual Test Cases from MTM and use MTM to record the results). The answer is that UAT testers can in fact use MTM without an MSDN license (just like any other MSDN software), *however* they are not allowed to access TFS without a CAL, even when doing UAT.  Since MTM is totally useless without accessing TFS, this effectively means that they cannot use MTM to perform UAT.

The silver lining here, is that if you do wish the UAT testers to use MTM, you don’t need to buy them an expensive MSDN license, you just have to buy them a somewhat cheaper TFS CAL.

This article is part of the GWB Archives. Original Author: Dylan Smith

Related Posts