Top 4 Microsoft Licensing Pitfalls for Software Developers

Microsoft Visual Studio and Microsoft Development Network (MSDN) licensing is a critical element in the Microsoft development landscape. It's not uncommon for developers to assume that these licenses are a free ticket to a wide range of Microsoft software. But, as with anything in the tech world, things are not as simple as they might seem at first glance.

MSDN Licensing: An Essential Tool

The MSDN license shipped with some Visual Studio subscriptions or sold separately as "MSDN Platforms" allows developers to create what we might call 'sandpits' or 'playgrounds' — special environments where they can deploy and test almost all Microsoft software, depending on the level of their subscription. This is true whether the software is being developed for internal use or sale and redistribution.

Licenses can cover every developer on your team, whether through Visual Studio subscriptions with MSDN or MSDN Platforms. In these environments, developers can deploy as much Microsoft software as they want, again, depending on their subscription level.

Even if your internal IT wants to test a Microsoft solution, they can do so under MSDN licenses, deploying various Microsoft products and running different configurations and scripts.

While this all sounds fantastic, it's crucial to be aware of some common pitfalls and misconceptions. The first is the idea that MSDN is a free lunch. It's not.

Misconception 1: Only Visual Studio Developers Need Licenses

A common misconception is that only developers who use Visual Studio require a license. For instance, let's say a company has a hundred developers requiring Visual Studio. The company buys Visual Studio subscriptions for those users and creates a development environment.

The company also has a hundred developers who don't require Visual Studio but still use this 'sandpit'. Many companies believe that, because they've licensed all the Visual Studio developers, they can also allow the other developers to use the environment. This is a costly mistake.

These developers also require an MSDN subscription of sorts. If they're using a Microsoft development environment or they are deploying Microsoft products, or using databases, they require some sort of Visual Studio subscription. If they're using the Windows Server infrastructure to deploy their applications, even if it's just on one server, all of them that access this environment require a Visual Studio license.

Misconception 2: Admins Don't Need Licenses

But it doesn't stop there. If you have IT admins supporting and managing the development-only infrastructure, they, too, require MSDN licenses. This is because any form of interaction with the infrastructure, whether management or installation, counts as usage. This means that no one, not even the highest-level system administrator, is allowed into this sandbox without some level of Visual Studio subscription.

The Exception

There is an exception, however. End users who are occasionally invited to try something new, such as a new version of an internal SAP application, don't require MSDN or Visual Studio licenses. However, professional testers would still need appropriate licensing.

Azure DevOps Server is Production Use

Certain elements can complicate MSDN licensing. For instance, deploying Azure DevOps Server in your sandbox can lead to various complexities. Azure DevOps Server usage is considered productive use, which effectively means that all your Azure DevOps Servers are production servers.

It's important to remember that using Azure DevOps Server in a virtual machine in the non-production environment does not change the status of your non-production VMs, but it does affect the licensing of the hypervisor if you're running Windows Server. The hypervisor then requires production licenses. The solution is to keep your Azure DevOps Server separate from your development cluster.

Remember that there's a good chance you might encounter some dodgy salespeople who'll insist you need to license everything as production in your development cluster. To avoid such potentially costly situations, it's better to keep your Azure DevOps servers deployed elsewhere.

System Center is Production Use

Another key area is System Center monitoring and management. While you may use System Center Virtual Machine Manager under MSDN licenses in your development sandbox, any System Center product that manages and monitors your development environment is considered production use and thus requires production licenses.

Remember that it does not affect the other MSDN software in the non-production environment. You may continue using it under developer subscriptions assuming that you licensed it correctly.

Now That You Know the Risks

In conclusion, when it comes to MSDN licensing, it's not just about covering everyone with Visual Studio licenses. It's also about understanding the nuances of the environment and ensuring all aspects, including the System Center, are appropriately licensed. Failing to do so can result in significant unexpected costs.

Do you have any challenges with Microsoft licensing for your software developers? We would be glad to help. Please message us with your queries, and we'll do our best to assist.