Microsoft Licensing – The Mindf**k Part 1: Visualising

Let’s be honest when anyone considers the word ‘Licensing’, it can be daunting, not just because of the financial impact, but the fact that it is often portrayed that only those holding a PHD in splitting atoms can advise on a licensing model.

In some circles I have even heard this Microsoft Licensing model referred to as nothing short of Mindf**king!

To be fair Microsoft has really bucked up their ideas and they are working hard to ensure that online resources and partner training provides the information that we need to help convey model clearly to our clients.  See http://www.microsoft.com/licensing/

licensing-head

Our Experience

Having spent a serious amount of time reviewing licensing, with clients on solutions, LARS (License Agreement Reseller) and SPLARS (Service Provider License Agreement Reseller) I felt compelled to break it down.

Starting from the top then, you have a problem and you decide on a solution (hopefully from a reputable supplier) and then you are pondering how you license the Microsoft technology for your solution needs. Break it all down into 3 main areas:  visualisation, licensing models and licensing programs.

licensing-diagram

When visualising:

1. Start with the physical servers and hardware; just draw boxes, as these are going to get filled up with MS technology.

2. Move onto breaking down those virtualised environments, so if you have a hyper v set up, break down the nodes, as we need to visualise it all.

3. We aren’t specifically talking cloud licensing here, so let’s concentrate on your:

  • POSE – Physical Operating System Environments
  • VOSE – Virtual Operating System Environments

4. Break each server down with its server software and think (and version):

  • Operating System (Windows 2008 R2, Web Server)
  • Server Software (Sharepoint, Exchange, Lync, Project Server, etc.)

5. Show all devices (be explicit, laptop, desktops, mobiles, etc.) connecting to the solution both:

  • Internally
  • Externally (outside of your domain)

6. Show where security will be needed, for example certain external users or subset of teams internally.

7. Then start explicitly listing all of the features that w you will need for the server products, and where appropriate, by whom. For example, external users need to see exactly what internal users’ needs to see.

Points for Consideration – External Users and in particular the External Connector License can be a costly purchase, so when thinking external users: consider if you need anonymous access? who will require authentication? how many users will you have? how quickly could this grow?