Skip navigation
All Places > Snow Product Hub > General Licensing Forums > Blog > 2018 > June


Dear reader,


In this blog post I would like to address the best possible ways to create a digital contract management system in Snow License Manager. As you might already know, Snow License Manager contains separate sections for storing agreement and license information. The questions raised many times are:


  • How do I obtain all this information
  • Where should I start first in Snow License Manager
  • Which types of agreements can and should I store in Snow License Manager
  • What type of data is mandatory or just nice to have
  • What are interesting reports to use for management.....


From a software optimization perspective – that contain different key competencies – it’s recommended to have a repository that shows information about all of your software purchases, including agreement information with the appropriate terms and condition, plus possible amendments that have been agreed upon between your company and the software vendor.


The main question here is: “how complete and accurate are our license entitlement records and what percentage of the procured license entitlements are actually recorded in a license entitlement inventory”?


The most common risks and implications of not having an agreement and license repository are:


  1. Risk of non-compliance and meeting other regulatory standards due to non-availability of proof of licensing documentation.
  2. Locally acquired licenses are not maintained in a centrally available license database.
  3. Risk of over- or underlicensing situations due to lack of global view for all procured licenses.
  4. Loss of bundling effects with regard to license purchases due to missing global overview over licensing situation.


Especially, global companies that - to a certain extent - allow subsidiaries to acquire licenses locally could end-up not seeing the big picture. For those companies that already have a centralized purchasing department and large volume license agreements that apply to most or all of the subsidiaries,  you still wish to periodically review the license entitlement data capture process, either form an optimization or a retirement perspective.


Before I actually show the possibilities from within the Snow License Manager, I think it’s vital to first discuss ways to obtain agreement and license information, so we get a better understanding of the possible percentage that we eventually are able or want to store in our digital Snow License Manager repository. Which steps could we take to increase the maturity (completeness and accuracy) of our license entitlement repository? Important information can be gathered from within your company, but also from the market. Besides, your quest to gather this information, you might also want to have a look at the current processes and tasks that lead up to a license purchase and what happens next.


My recommendations to increase the maturity of your current license entitlement inventory and gather the information you need, would be to:


  • Try to reach out to third parties to collect software purchase information. Third parties like large account resellers or value added resellers. Purchase information like; date, quantity, description, part/sku number, metric information, agreement number, maintenance period and maintenance rights, restrictions and other license rights that might be of interest!


  • Try to reach out directly to your Tier 1 vendors to request license summaries. Microsoft is well-known to share a Microsoft License Statement with their customers.


  • If your company went through joint-ventures or acquisitions, it’s highly recommended to specify what software records you still own or don’t own any more. When you acquired software this way, you need to make sure that you store details like:
    • actual proof of purchases
    • the approval of the transfer from the software vendor
    • the quantity purchased
    • license description, including, metric, edition and/or version
    • license only and not maintenance (many software vendors don’t allow maintenance to be transferred)


  • See if you have made any software purchases that are not based on a volume license agreement, like OEM software that is associated with your hardware purchases and other box-like-purchases. These types of purchases are usually not part of the purchase records kept by vendors. Either you have stored this somewhere in the company or your preferred reseller might assist you with this.


  • Review your existing purchase orders so that you might identify (large) software entitlement purchases and know which other entitlement documents you need to locate to complete each record.


  • Classify your software estate into Tier 1,2 or 3 vendors based on spend and risk. Tier 1 vendor usually come with a high risk, because of possible audits and account for most of your software spend. Tier 2 vendors have a mid-to- high risk for audits and account for an average of 20% of your software spend, and Tier 3 vendors usually have a low risk for audits and account for a maximum of 5% of your software spend.


  • Institute a policy that controls software purchases which need to go through approved procedures, before actually being installed or procured.


  • See if you can automate this process by offering a centralized self-service portal from where the business can only select what you offer them, including the appropriate authorization layer(s). This minimizes exceptions and maximizes the creation of license entitlement records and at the same time will prevent entitlement data to exist that does not contain proof of license data.


  • Try to validate the existence of entitlement records for the software that is actually deployed throughout your organisation. This way you can ensure which records you need to collect, if available. Due to the facts that Snow License Manager will show you a very large list of normalized software installations, you might also wish to separate that list into Tier 1,2 and 3 vendors.


Of course, you could decide to do this one software vendor at a time, with regards to gathering as much entitlement data as you possible can. The moment that you think that you have sufficient data that you wish to store in Snow License Manager, I do recommend to first analyse your deployment and inventory situation on these vendors. Regardless, which vendor you want to add agreements and licenses into Snow License Manager, first have a look at the application list in Snow License Manager to see what is already installed and especially check is the correct metric is applied! In the screenshot (picture 1) below you can see that you have different filter and grouping options to change the view.


Picture 1


Let’s say, I start with a particular software vendor and I filter on that vendor. I might get a list, that could contain installations of different applications from that vendor and the list might not contain any installations of entitlements I did purchase.


Here’s the challenge and the important things you should take into consideration and might need to do before you actually add a license of this software vendor. First focus on those applications that are actually discovered and inventoried in your estate. A simple example can been see in the screenshot below (picture 2).


Picture 2


In this example, I end up with 9 different applications that according to Snow License Manager require a license. If the metric is already correct, then I can continue and add the licenses. If my entitlement records tell me, that a different metric applies to one or more of these applications, then I need to adjust that metric, so that Snow License Manager is able to calculate the correct compliance delta. The thing is, that in Snow License Manager there are two places where you can adjust or set the metric that should apply! You can either select the metric that you want on the “application” and also on the “license”.


At this moment we are looking at a selection of the application list, because I’ve filter on a particular vendor. So, let’s first have a look at the options that are available when adjusting/changing the metric on application level, as you can in picture 3 below.


Picture 3


To be able to change the metric of an application, you need to select the application and then click on “edit application”. In the next view, you need to select the second tab called “License settings”. Here you have to following options:


  • No license required: check this box if you think the application doesn’t need to be licensed.


  • Installation: this means that the number of unique installations inventoried are counted and represents the license requirement value.


  • Custom compare values: use this option to determine the license requirement value yourself manually or even automatically this by setting up an import/export in the back-end.


  • Number of processors: select this metric when the number of processors of each asset is the metric that applies, with the options to even determine a minimum number of processors.


  • Number of processor cores: select this metric when the number of cores of each asset is the metric that applies, with the options to even determine a minimum number of cores.


  • Users: this will count the number of unique application users for a particular period – which you can determine – and the total sum of users represents the license requirement value.


  • Devices: this will count the number of unique devices that are using the application, regardless of the number of installations for a particular period - which you can determine - and the total sum of devices represents the license requirement value. This metric is usually used for Terminal server or Citrix environments.


  • Concurrent users: this will count the number of unique simultaneous application users for a particular period – which you can determine – and the total sum of simultaneous users represents the license requirement value. This metric is also usually used for Terminal server or Citrix environments.


  • Concurrent devices: this will count the number of unique simultaneous devices utilizing the applications for a particular period – which you can determine – and the total sum of simultaneous devices represents the license requirement value. This metric is also usually used for Terminal server or Citrix environments.


  • PVU: This metric is based on IBM PVU (Processor Value Unit) values of computers and we recommend to integrate with ILMT or BigFix, so that this metric is automatically set within your Snow platform. Please contact a Snow representative for more information on this matter.


  • CAL (Client Access License): The CAL metric is only a registration of the number of licenses. Select this metric if the license you have purchase is clearly is CAL. No compliance is calculated based on this metric, except when you apply the “custom compare value”


In the current application list I need to adjust only one application. After saving the change, the application will be update immediately as you can see in picture 4 and in picture 5.


Picture 4


Picture 5


What about possible entitlements that I might have within my purchase records, but are not displayed in the application list in Snow License Manager. This basically means that I have purchased a license, but we aren’t yet utilizing the application (it’s not installed and therefore not inventoried). In case you also need to adjust the metric on these applications or you wish to make sure the metric is correct, you have the options to search on applications that are “not” installed.


To do  this, you need to go to the “Applications” category in the top main menu and select “Search for applications”. There you need to select the correct search criteria to get the desired overview. In the screenshot (picture 6) below you can see that I have used the following two criteria to create a list of all applications available in the Software Recognition library, regardless if it’s installed or not.


Picture 6


  1. Criteria 1 = Manufacturer. I have entered the manufacturer exactly the way it exist in Snow.
  2. Criteria 2 = Also include not installed/used. Just make sure you set this to “Yes”.


The red arrow indicated, where you can add additional search criteria. As you can see, the total result is 209 items. The list also contains the 9 applications that are installed. I should be able to find the other applications in this list and if needed adjust the metric.


Now, that I’ve been able to gather all relevant entitlement and agreement details of the vendor(s) I want to store in Snow License Manager and I’ve also made sure that – as far as possible – the correct metrics are in place, I can finally start to add my entitlement data into Snow License Manager.



If you actually have an agreement, I would also advise you to add them into Snow License Manager. If you don’t have an agreement or any details that you could use to create an agreement first in Snow License Manager, you could simple skip this step or decide to do add an agreement and use other details to store the agreement in Snow. Other details could be your invoice information, budget number details etc.


In Snow License Manager you can store the following agreement types straight out-of-the-box (picture 7):


Picture 7 – main category is “Agreements” & then select “Add agreement” -


The main difference between the type “Software agreement” and the rest of the agreements (except the Oracle agreement) is that you can attached computers/assets to those agreements, located in a specific business unit. An example of this is shown in the screenshot below (picture 8). If you wish to only select just a couple or specific computers/assets, you’ll first need to save the agreement (maintenance / support / purchase) and then go to the computer list, select those assets that you wish to attach and from the context menu select “edit computers”. In the next view you’ll be able to select the agreement that you wish to attach to those computer assets!


Picture 8


Regardless, which agreement type you select, you’ll always want to populate as many fields as possible located in the different tabs before you save your agreement.


  • Tab – General:
    • add the agreement number here (this number has to be unique in SLM)
    • add an appropriate name for your agreement; like “Microsoft Enterprise Agreement E351198”
    • subscription agreement = check this box if the agreement is a subscription
    • upgrade rights = check this box if all the entitlements in the agreement have upgrade rights
    • selectable after expiration = tick this box, if you wish to link licenses to the agreement, even if the agreement period is expired


  • Tab – Agreement periods: add the active period of the agreement here


  • Tab – Contact info: add contact details about the software vendor and your reseller here


  • Tab – Alerts: activate the alerts with three particular threshold so that you are notified in time when the agreement is about the expire. The amount of time you need to renew the agreement should be the minimum amount of time you wish to be notified in advance. I recommend to take more time then you might think you need. In the administration section of Snow License Manager (located under “Home”) you might always wish to active e-mail notification about agreements that will expire.


  • Tab – Description: add anything here that you might think be of  any interest to mentioned about the agreement


  • Tab – Documents: attached actual files here to the agreement or use a redirect link if you should have this available (a document management system like SharePoint)


  • Tab – Custom information: add additional fields created by your self here. To create a custom field you need to go to the administration section of Snow License Manager (located under “Home”).


  • Tab – Security: here can prevent other Snow user profiles or business units to see the agreement


Important note: The agreement type “Software agreement” is the only agreement that you can use to link software licenses to!


In the screenshot (picture 9) below you can see a possible final result of adding different agreements and types.


Picture 9




Once you have added the agreement(s) you want to be a part of the contract management repository in Snow License Manager, you’ll also need to add the most important part, which is the actual software entitlements. From the main top menu category “Licenses” you need to select “Add license”. This will bring you to the add license section where you’ll need to populate particular fields in different tabs. Let’s have a closer look at the most important ones (picture 10).


Picture 10


The first two tabs will require you to add most of the actual purchase details, like: the purchase date, purchase price, invoice reference and the maintenance period (picture 11).


Picture 11


You can decide to add a maintenance period or check the box if the period is exactly the same to the agreement the license is linked with.


What is rather important from a license rights perspective, is that you always add the correct version and edition of the application. Very recently purchased entitlement grant you the highest and latest version of the application, but always double check what applies each time you add a new license. You can use the application name or the SKU search to find the right applications (picture 10).


After selecting the correct application/license, in the drop-down box for Agreement you can link the license record to the agreement, you’ve created previously (picture 10).


The options available in the red rectangle (picture 10) all depend on the type of license you have purchased.


  • Downgrade rights: check this box if the license is purchased with downgrade rights
  • Upgrade license: check this box if the license is an upgrade license and then also make sure to establish the correct relation with the base license in the additional tab that will appear.
  • Cross edition rights: check this box if the license allows for coverage of applications within the family with the same or lower “edition” rights.
  • Cross platform rights: check this box if the license allows for coverage of applications within the family and the same edition, “regardless” of the operating system they are installed on.
  • License has a subscription period: check this box and enter the correct subscription period if the license is a subscription license.


Besides the settings and the information in the first two tabs, it is also vital that you determine if the correct metric is applied. As mentioned before, when you adjust a metric of an application, this will automatically be applied when you add the corresponding license for that application. For all other cases, you might wish to change the metric each time you add a new license record.


Picture 12


As you can see in the screenshot (picture 12) above, you do have some options to select from. Please note, that not all the metrics that you saw in an application are also available here. Some are not available and two new ones are available on the license. The first step is that you select the metric and then select the correct assignment type.


  • Example: if I wish to assign SQL core licenses to server, the metric should be “Number of processor cores” and the assignment type should be “Computer/datacenter”


  • Example: if I wish to assign a named user MSDN subscription license to an employee of my company, the metric should be “Installations” and the assignment type should be “User”


  • Example: if I wish to assign a Windows External Connector to a particular business unit, the metric should be “Installations” and the assignment type should be “Site”


  • Example: if I wish to assign a Windows Enterprise server 2008 to a server, the metric should be “Installations” and the assignment type should be “Computer/datacenter”



After you adjusted the metric and the assignment type or kept it default, you should always go to the third tab “Assignment” and based on the assignment type that you selected add the correct assets, e.g.; machine, user or business unit.


I recon the other tabs are self-explanatory, so I’ll skip them in this blog. I you should have any questions about one of the other tabs, just let me know in the comments below. In the following screenshot (picture 13) you can see how the end result can look like when you have many different kinds of licenses in Snow License Manager.


Picture 13




Now that we have added some  all or just one record and contract in Snow License Manager, it’s also nice to know that under the category “Reports” you can find some interesting out-of-the-box reports, you can use to create, store and share. If you select the two categories as shown in picture 14: Agreement- and License reports, you immediately get a list of all the reports available.


Picture 14


Especially, the reports available in the “Standard reports” group (picture 15) are very interesting to use to manage you whole software entitlement database.


Picture 15


Just to name a few, which I find very interesting and always discuss with my customers:


  • Incomplete licenses: If you have any incomplete licenses in the system, you definitely want to make sure these all become complete. Incomplete licenses are not taken into account when Snow License Manager calculates the compliance.


  • License compliance reports: it makes perfect sense, that you want to know what the impact is of adding all those licenses in Snow License Manager. With the compliance reports you can see the results straight away.


  • Maintenance and support overview: when you have active maintenance and support details with financial figures in Snow License Manager, this is the report to use and find out what your renewal cash flow is from year-to-year.


  • Potential software cost savings: this report is all based on software usage, and will inform you about application s that are unused in percentages, but it will also inform you about the compliance delta for those same applications. Imaging you are missing licenses for a particular applications and at the same the business is not consuming the application!


  • Unassigned licenses: use this report to see which licenses still need to be assigned to an asset (machine, user or business unit). Unassigned licenses are not taken into account when Snow License Manager calculates the compliance.


I hope this blog shines some light on the steps you need to take to fill your own contract and license repository in Snow License Manager. Don’t hesitate to comment on this blog post or reach out to me or any of your local Snow contacts for more assistance and guidance.


My other blog about Windows Server Management

My other blog about SQL Server Management

My other blog about importing and tailoring a Microsoft License Statement (MLS)





Dear reader,


Based on the previous questions from the community asked about how to efficiently manage the lifecycle of Microsoft Windows Servers, I’ve decided to write a blog post about this specific matter. In this blog , I’ll try to explain and show ways to determine how to draw up an overview of Windows servers currently being inventoried in your environment, how to assign different Windows server licenses and which reports you should apply to maintain and manage the lifecycle of your Microsoft Windows Server environment – quantity, version, edition, location and of course compliance –


So…after reading this blog post you should be able to:

  • determine and create different overviews of Windows Servers running in your own estate.
  • collect important information about these Windows Servers (version, edition, business allocation, resources used, if it’s a virtual server or not and more interesting information).
  • add Windows Server licenses in SLM and assign these licenses accordingly based on the correct metric and other important settings & findings.
  • create and save easy-to-use reports specifically for your Windows Server estate, including compliance information.




First I would like to focus on creating interesting views of Windows Servers running in your environment. Snow License Manager contains different kinds of ways to determine how many versions and editions are actually discovered and inventoried within your estate. Before you actually start assigning Windows Server license entitlements and create useful reports, you might first wish to have a total overview and understanding of every server that is actually running some kind of Windows Server operating system. My personal approach would be to:


  1. draw up a list that contains Windows Servers, which are all part of my production environment*.
  2. and separate that list into (1) clusters that contain information about the physical hosts and the virtual servers that have a Windows Server operating system installed vs (2) stand-alone physical servers that have a Windows Server operating system installed locally.


* In general, one might expect to see a commercial production environment and a separated test, development & acceptation environment. The latter would normally be licenses with MSDN subscriptions - instead of commercial licenses -. Because I wish to keep this blog post as general as possible, I will only focus on the production environment, that needs to be licensed with commercial Windows Server entitlements!


Let’s have a closer look at some views that shine some light on our Windows Server estate, starting with the application list.


Applications list

When you browse to the Applications category and select “List all application”, you should be able to create the overview shown below (picture 1). Please note that I’ve added three filters to generate this list of Windows Servers (red rectangle)


Picture 1


In my environment, this creates a list of different types of Windows Server operating systems and the total number of installations. As you can see in picture 1, the Snow Software Recognition Service populates the metric column with the correct metric. Although, this list is a nice overview of all the different types of Windows Servers discovered, it’s not quite good enough to know how I should allocate my entitlements based on most cost effective coverage.



Single Windows Server applications

Let us have a closer look at one of the applications in this list. For this example, I’ve deliberately selected the applications: Windows Server 2012 R2 Standard. The reason for this is the metric that applies to this particular application (the same applies for the cores metric by the way). I think it is important to understand how Snow License Manager creates the numbers mentioned under “Processors” [1073] and under “License requirement” [1292], when looking at the screenshot below (picture 2). If we first focus on the accumulated number of processors, this amount is the sum of every actual physical and virtual processor that is used in every server that has a Windows Server operating system installed.


Picture 2


An example of this can been seen in picture 3 below. Selecting a particular server – in this case a virtual server – will highlight the information of the hardware that is assigned to this virtual machine. As you can see, the number of v-processors is “3”. Snow License Manager will analyze every individual inventoried Windows Server and calculates the number of processors of each server and presents the sum as the total value for the metric that applies, which in this case is the total number of processors (it will do the same for the core metric).


Picture 3


The total sum that is presented as a “License requirement” value, is actually the total number of processers which is automatically updated with a minimum licenses requirement  adjustment. Microsoft states that Windows Server operating systems licensed with processor or cores licenses have a minimum requirement, regardless if the server actually has these hardware resources equipped.


Bottom line; this means that you always need to assign 2 processors or 16 cores as a minimum to each physical machine!


Each server that has less hardware resources, will be adjusted until the minimum is reached. In this case, each server that has only 1 processor installed, will be adjusted with +1. In the end, this results in 1073 + 219 = 1292.



Datacenters and clusters

When you browse to the Computers category and select “Datacenters and cluster”, you should see the result of the integration with your hypervisor layer(s). The initial list will contain all of your Datacenters/Clusters, and after selecting one of them you should end up with the installation overview shown below (picture 4).


Picture 4


As you can in that screenshot I have selected the second tab and added a filter on "windows server", so that I can see all of the virtual servers running a Windows Server operating System. Although, I’m only looking at my virtual Windows Server estate in this way, I should already be able to distinguish between applying a Windows Sever Datacenter or Standard entitlement (based on the number of virtual server use rights). This would mean, that I need to analyze all of my Datacenters/Clusters one by one, and look for a separate overview of my physical stand-alone servers.


Important: please make sure that all of the virtual servers running in each of your cluster is actually inventoried by the Snow Inventory Client. In the screenshot (picture 5) below you can see that in this particular cluster a total of 33 virtual server are hosted, but 1 virtual server is not inventoried. This server might also contain a Windows Server operating system.


Picture 5



Application Family for Windows Server

Picture 6


In Snow License Manger each application that requires a license is a part of an application family. This is a very powerful section within Snow License Manager, that I wish to share with you all before we continue to the next topics. In order to find the application family for Windows Server, all you need to do is select one of the Windows Server applications from the List of all applications in your own environment. Then click on “Windows Server” as shown above in picture 6 (red rectangle).


This will bring you to the Microsoft Windows Server application family, as its presented in Snow License Manager. On this page you’ll find interesting information about:


Picture 7


  • [picture 7] the different kinds of Windows Server editions and versions.
  • [picture 7] the overall compliance status of your Windows Server estate (inventoried by Snow).
  • [picture 7] the total financial investment made on Windows Server entitlement (requires you to add financial purchase data).


Picture 8


  • the available Windows Server licenses in Snow License Manager, including quantity and active maintenance (SA).
  • [picture 8] each individual machines that has a Windows operating system installed, including hardware resource data.


Although, I personally would still rather use a Snow report to determine the best assignment of my Windows Server entitlements, I have to address that the last tab shown here in picture 8 does contain almost every information detail I need to create a compliance  delta for my whole Windows Server estate. The only thing I might not have in this particular view, is the distinction between the production environment vs the test, development & acceptation environment.


Nevertheless, I can determine the number of clusters (1), the total physical hosts in each cluster (2), each virtual server running on a particular hosts (3) and the physical hardware recourses used by each physical layer – either each individual host or as a total within each cluster (4). If I would scroll down in this view, I would eventually end up with all the physical stand-alone servers, which also need to be license accordingly.




Up until now we have seen that we are able to gather lots of interesting information about our Windows Server estate looking at different applications views. However, my main goal is to assign my Windows Server licenses the best way possible, so that I’m able to create reports that will assist and guide me to easily spot compliance risks and possible optimization. Therefore, I would always use the reporting section in Snow License Manager as a starting point to create, store, export and share this information.


Focusing on Windows Server installations, the following reports (in the category "Reports" from the main top menu) are available to assist you with this -  please keep in mind, that many of these reports show information that you could use for creating a final compliance report for your Windows Server environment -:


  1. Physical and virtual servers per datacenter
  2. Applications installed on virtual machines in a datacenter
  3. Compliance summary (by application family)
  4. All applications
  5. All computers
  6. Applications per computer
  7. Hardware comparison for processor/core based applications
  8. Operating systems


The reports all mentioned above, might need some additional criteria or columns to present the information that you need. My advice would be to open each report and see for yourself, if it contains the information that you are looking for.


I’ve saved the best report for last, and I would like to specifically focus on this report with some examples. I’m talking about the report that is called “License tracking per computer”. This report is located in the group called Standard reports.


The beauty of this report is, that it will show you a compliance delta on machine level. I’ll try to explain and demonstrate this with two different examples. In the first example, I want to get a better picture of the large clusters that contain many virtual servers, so that I can license these areas with the Windows Datacenter licenses, because I want to capitalize on maximum virtualisation rights. Before I can analyse each cluster, I first need to add two report criteria to get the search results I need. Below you can which two criteria (picture 9) I have applied before I clicked the “show report” button.


Picture 9


I have decided to remove and add particular columns for a better overview of the Microsoft Windows Server installations on cluster level.


Removed columns:

  • Organisation (which you could consider to keep in the report, if you need to know the business unit the Microsoft Windows Server belongs to).
  • Manufacturer (because I already know that in this case I’m focused on Microsoft only)


Added columns:

  • Compliance
  • Datacenter name
  • Host computer name
  • License requirement
  • Requirement adjustment reasons


To start analysing each cluster, I can double click on the header called “Datacenter name” or add something in the field like I’ve decided to do, which you can see in picture 10. In my estate, each cluster has its own number, so I can easily add this as a filter to view them one by one.


Picture 10


Currently, there are no Windows Server entitlements in Snow License Manager, which means that I’m 100% incompliant on this application family. As you can see, the reports clearly tells me that cluster “VMware Datacenter 2” contains two physical host servers and a total of 16 virtual servers. The metric in this case is based on the information about the Windows Server edition that is installed in each individual virtual server. Because, I've not yet added any licenses in Snow License Manager and also did not assign any licenses, the "assignement type" column it totally empty.


As long as I apply the correct Windows Datacenter license edition and quantity, this cluster and every single virtual server will become compliant. I’ll pick this up, in the next topic. For now, I’ve saved this report in a new group and called it “Windows server Cluster License assignments and compliance report”.


For the second example, I wish to create an overview of all the stand-alone servers that have a Windows Server operating system installed. In the screenshot below (picture 11) you can see that I’ve used the same report as before (with the same criteria and column set-up). I want to focus on the columns that contains a server that is not a part of a large cluster / datacenter!


Picture 11


As you can see in picture 11, I’ve been able to drill this down into two separate kinds of stand-alone servers;

  • the physical server marked with “A” is a single host running 2 virtual Windows Servers, but is not a part of a cluster.
  • and the rest of the list marked with “B” are all single stand-alone servers running different versions and editions of a Windows Server operating system.


The compliance column informs me how many licenses I need based on the metric that applies to each installation, with a possible adjustment based on a minimum requirement. With this information, I can now assign the appropriate Windows Server licenses to each individual stand-alone server. I’ve saved this report in the same group as before and called it “Windows server Stand-alone License assignments and compliance report”.




With these two saved reports, I can now start assigning the Windows Server licenses our company owns. Going through numerous Microsoft Volume License Agreements, I’ve been able to gather the following list of Windows Server entitlements my company owns:


  • 2 Windows Server Standard 2016 licenses (8 core-pack = 16 cores in SLM)
  • 6 Windows Server Standard 2012 R2 licenses (2 processor-pack = 12 processors in SLM)
  • 8 Windows Server Datacenter 2012 R2 licenses (2 processor-pack = 16 processors in SLM)
  • 2 Windows Server Enterprise 2008 R2 licenses (metric = based on installations)


When I look at my current compliance summary for Microsoft Windows Server, I get the following list of Windows Server application and the compliance delta for each application (picture 12):


Picture 12 – taking from the report: Compliance summary with criteria set on Microsoft as manufacturer and Windows Server on application family -


I now need to add all my available Microsoft Windows Server licenses one-by-one and regardless of the license metric, assign each license to the correct machine. With this last remark, I mean that I advise you to also assign Windows Server licenses that might have the metric “based on installation”.


When you add a Windows Server license into Snow License Manager that has either a Processor or Core metric, it is mandatory that you assign them to a computer or datacenter. This is not the case, when the metric is set to “based on installation”. You’ll need to change the assignment type from “organisation” to “computer/datacenter”.  Before I demonstrate a couple of different examples of adding and assigning licenses, I need to address the following first:


“I strongly recommend that when it comes to adding and managing licenses in Snow License Manager, that this is carried out by persons with adequate knowledge and experience. Not only do you need to understand how Snow License Manager works from a compliance perspective, but that you also need to have some understanding how - in this case - Microsoft licensing works. You might wish to contact your Microsoft trusted advisor, reseller (LSP) or SAM partner to assist and advice you with this matter”


The first licenses that I want to add into Snow License Manager, will be my Windows Datacenter licenses. These types of licenses are meant to be assign to physical hosts that run lots of virtual machines. To maximize on my investment, I will assign the available Windows Datacenter licenses to “VMware Datacenter 2”. By clicking on “Add license”, I get the following view and fields I need to populate (picture 13):


Picture 13


When I search for the application – either by name or by SKU – and select the correct license, the metric will be defined automatically. I need to add the correct quantity, which basically means that I always need to double the quantity that I have actually purchased; I have bought 8 Windows Datacenter Licenses, which equals a total of 16 processors. I need to activate the downgrade rights and the cross edition rights. The reason behind this, is that I will eventually assign the licenses to a cluster that contains physical hosts running different kinds of virtualized Windows Server edition and versions.


The downgrade rights will cover older versions than 2012 R2 and cross edition will make sure that other edition are also covered! Editions like; Web, Standard or Enterprise that might be installed in your virtual servers.


I you have active maintenance (Software Assurance), be sure to add this accordingly in the second tab! Before I can save this license, I need to assign the right amount of processors first with the correct virtualization rights. To do this, I need to go to the assignment tab and:


Picture 14


  • A [picture 14] Click the add button, so that I can search for the correct asset
  • B [picture 14] Use the search options to find the asset (cluster) and select it
  • C [picture 14] Click the lower add button, to add the asset into the license


Picture 15


  • D [picture 15] Change the VM use rights, by clicking on the “Change button”
  • E [picture 15] In this case select the second option, because unlimited virtual machines rights applies


Picture 16


  • F [picture 16] Add the correct – even – number of processors. In my example the cluster contains two physical hosts, which combined have a total of 5 physical processors installed. This means, I need to assign 3 Windows Server Datacenter licenses, which is the equivalent of 6 processors.


I now also need to do the same for all of my stand-alone physical server. Lets first do this for the physical server (SERVER374) hosting two virtual Windows Servers. For the assignment, I could use any of the Windows licenses I have left, but I’ve decided to use one of the Windows Server Standard 2012 R2 licenses. For this example, I’m jumping straight to the assignment tab. The purchase tab is identical to the example already shown above, except that I’m now adding a Windows Server Standard license!


Picture 17


It is very important that I again change the VM use rights as shown in the screenshot above (picture 17). I need to set the quantity to “2” and also assign the correct number of processors, which in this case is also “2”. Now I can save the license, and continue doing the same for the rest of the stand-alone servers. I will use the same license to assign them to other servers. I can simple edit the licenses and add the servers in the assignment tab, as shown below (picture 18).


Picture 18


SERVER374 is the only server that is hosting two virtual servers, so in this case Snow License Manger will automatically cover these virtual installations. The rest of the servers all have local installations of Windows Server operating systems.


These are all stand-alone physical server without any virtual servers being hosted, as you can see in the column called “VMs (Inventoried)”. In this case the locally installed operating system will become complaint and the VM use rights are just there as a given. Please beware, that you need to assign the minimum number of processors for each server, which is 2 in my example.


All I have to do now is add the rest of my license entitlement to the rest of the servers, so I can see the end result and decide what to do next. With regards to the Windows Server Enterprise licenses, I do want address that you also assign them to the correct assets. This means, that you’ll need to adjust the “assignment type” as shown below in picture 19. Just change it into “Computer/datacenter” and then go to the assignment tab and add the servers accordingly.


Picture 19


For the latest Windows Server 2016 licenses with the core metric, I’ve added an example below (picture 20). With this screenshot I want to highlight the fact, that adding these types of licenses is exactly the same as before. Snow License Manager will automatically adjust the correct metric settings. You just have to make sure that you add the correct “core” quantity and activate downgrade rights. Also activate cross edition rights when assigning the licenses to a host.


Picture 20


What is important to point out is the assignment tab for these types of licenses. As you can see in the screenshot below (picture 21), Snow License Manager will automatically adjust the VM use rights and set it to “Fixed”. This basically means, that each license grant one virtual machine coverage rights. Because you need to assign a minimum of two licenses, you eventually end up with two virtual machine rights. One licenses represents a pack of 8 cores, which is the total sum of 16 cores.


Picture 21


Although, in the example shown above the server has only 1 physical core, I still need to assign 16 cores to the server. This is something that you need to do manually, as also done in the previous examples.


Now that I have finished assigning all my available licenses, I should be able to see the results:


  • in the compliance summary report (picture 22)
  • and also in my saved license tracking reports (picture 23 & 24)


I don’t have any more Windows Server entitlements left, so I could investigate if I have Windows Server installations running outside my production environment, that I might licenses by other means. If not, then I know I have a compliance issues I need to fix and keep managing 


Picture 22


Picture 23


The screenshot above (picture 23) is the result of assigning Windows Datacenter licenses to one cluster, in this case “VMware Datacenter 2”. In the last three columns you can see the reasons why each individual installations is considered to  be compliant. The very last column on the right even highlights the compliance for each asset. If for some reason my company would expand this cluster and add one more physical host server, I would see the results in this report! The assignment of the license to this cluster, also resulted in populating the "Assignment type" column,


Picture 24


I hope this blog post helps you out with getting a better grip on your Microsoft Windows Server landscape and the possible views you can create to analyze this. And also how to add your Microsoft Windows Server licenses the right way and create your own easy to use reports, so that you can track compliance on machine level or on company level.


Don’t hesitate to comment on this blog post or reach out to me or any of your local Snow contacts for more assistance and guidance.


My other blog about SQL Server Management

My other blog about importing and tailoring a Microsoft License Statement (MLS)


This document describes how to install and run the Snow Inventory Agent for Linux. For more detail, please refer to the full user guide - SIAL510_UserGuide_LinuxAgent.pdf

The Snow Inventory Agent for Linux is part of the Snow Inventory solution and is used for inventory of Linux computers. The agent scans the computer and saves the collected data to a compressed and encrypted file, which is sent to a Snow Inventory server (Master Server or Service Gateway).

For detailed information on the configuration of the agent, refer to the document Snow Inventory Agent Configuration Guide.


This version of the Snow Inventory Agent can only be used in a Snow Inventory Server 5.x environment. Supported operating systems are found in the document System Requirements for all Snow Products found at Java Runtime Environment To be able to inventory Oracle database products by using the Snow Inventory Oracle Scanner (SIOS), the target computer is required to have Java Runtime Environment 6.0 (1.6) or later installed. Due to an internal defect in Java, Java Runtime Environment 1.7.0_7 must not be used.


Please note that in the example terminal commands, anything in [brackets] is not part of the command - for example [return] means to hit the return or enter key.


The Snow Inventory Agent for Linux can be installed using prepared packages or using copies of the binary files.

Installation Packages

Installation packages are prepared by and ordered from Snow Support. The current configuration file needs to be provided before any RPM or DEB package can be prepared. If no configuration file exists, certain information is needed in order to create one.

Required information:

  • Address to the Snow Inventory Server, including port number
  • Site name



  • Name of the configuration file
  • Cron scan time (default is “daily”)
  • If the Snow Inventory Oracle Scanner should be included
  • If the previous versions of the Snow Inventory Client for Linux should be removed


The installation package can be copied to any folder, but preferably not the /root folder. The install command must be run from the folder where the package is located, while the uninstall command can be run from any folder.

During the installation of the agent, an application argument will be automatically added to the cron. This command looks like this: nice -n 10 /opt/snow/snowagent

Prepared RPM Package

This section describes how to install and uninstall an RPM package from a terminal session. Use sudo or run the commands as root.


 Execute the rpm command with the argument -i, for example: sudo rpm -i snowagent_5.1-1_i386.rpm


To uninstall, execute a rpm command with the -e argument – you do not have to run this from within any particular folder: sudo rpm -e snowagent

Prepared DEB Package

This section describes how to install and uninstall a DEB package from a terminal session. Use sudo or run the commands as root.


Execute the dpkg command with the argument -i, for example:

sudo dpkg -i snowagent_5.1-1_i386.deb


Execute the dpkg command with the argument -P, for example: sudo dpkg -P snowagent


This section describes how to manually run a scan and then check the logs. Some light knowledge of Unix commands is advantageous but not completely necessary. Once the steps above have been followed, according to the type of Linux OS you are working on (RedHat or Debian) you can follow the below steps to complete and verify the installation.

  1. Verify the contents of /opt/snow by using the following commands from the terminal. Anything in [solid brackets] is an instruction or information and is not part of a command: cd /opt/snow [Return] You should now be looking at the directory the agent is installed into. Verify this with: ls [Return] This should output the contents of /opt/snow and should look something like this: /data [this is a directory] snowagent snowagent.config snowcron
  2. The files of the Snow Inventory Agent are one executable file called snowagent and one configuration file called snowagent.config. These two files are, by default, located in the /opt/snow directory. To see a command line summary of the executable, use the following command from a terminal window: sudo [you need this if you are not running as superuser] /opt/snow/snowagent -?


  1. You will notice that the one of the commands is scan. Run snowagent with the scan argument: sudo /opt/snow/snowagent scan [Return]
  2. You can now verify that the scan took place by looking at the /opt/snow/data folder. If you are already on the /opt/snow folder, you can simply do: cd data [Return] Or you can point to the full path: cd /opt/snow/data [Return] Use ls to list the contents of /data: ls [Return] This should list something like the following: result-000001512674563-1153644345674295837.snowpack [this is the .snowpack scan file] snowagent.lock snowagent.log [this is the log file] You can read the snowagent.log file if you wish: more snowagent.log [Return] [A successful scan will have an Info log stating that the agent has finished building snowpack]
  3. Before sending the data to Snow Inventory, you might want to verify your snowagent.config file. To do this, navigate back to /opt/snow either by simply using cd .. if you are in /opt/snow/data or by using cd /opt/snow. To read the snowagent.config file: more snowagent.config [Return] This will display the .config file. User the return key to read the document. You want to verify the <SiteName> and <Address> under <Endpoint> entries are correct as well as any other configuration items you may have specified when creating the agent. When you are finished reading, press Q.


  1. To send your generated .snowpack file, follow the same steps as in step 3, except use the send argument: sudo /opt/snow/snowagent send You can now navigate back to /opt/snow/data and use ls to list contents. The .snowpack file generated should now be gone as it has been sent to the Inventory server. Again, you can use more snowagent.log to verify that this has been sent.



To configure the scheduling, crontab is used with the argument -e. Run this at root level. You may need to run this from /root: sudo crontab -e [Return} It may ask what tool you want to use to edit the file. Usually, Nano is used, so we will use that for this example. Once the crontab has opened, the install package will have inserted the default line: 0 21 * * * nice -n 10 /opt/snow/snowagent>/dev/null 2>&1 This translates to the scan running at 21:00 – 9pm according to a 24-hour clock. You will notice that the minutes are put ahead of the hours. You must use single digits where applicable, so 5 minutes should be 5 and not 05. For example, to set the scan time to 10am, you would modify the line to read like this: 0 10 * * * nice -n 10 /opt/snow/snowagent>/dev/null 2>&1

Once the changes have been made, press CTRL-X to exit and press Y to save changes. The scheduling has now been set.

This article serves to provide a high-level “cheat sheet” set of common questions frequently asked by Snow Software customers. The purpose is to provide a starting point for further understanding the new ServiceNow 3.1 connector and how it works.


This document should be used in conjunction with the most up to date ServiceNow Connector documentation.


It is important to remember that while Snow Software consultants do have a good level of ServiceNow understanding, we are not expected to provide ServiceNow administration-level guidance or expertise.


“What does it do?!”

Usually the person asking this will want a high-level answer – our ServiceNow Connector actually comprises of two separate connectors available to download from the ServiceNow Store – the Snow Software Catalog Integration which populate the ServiceNow Product Catalog hardware and software models and the Snow Software CMDB Integration which populates the ServiceNow CMDB with information on hardware and software assets as well as users. Additional information can be shown in real-time but this functionality requires a Mid Server (see below) or for Snow License Manager to be externally facing.


“How often will ServiceNow be populated with this data?”

This depends on how the SIM connector is configured and requires discussions with the customer’s technical infrastructure contact – typically, it is run outside of working hours on a nightly basis, ensuring it is not run when the SLM Data Update Job is running (21:00 by default).


“What information will ServiceNow receive from SLM? What are the field mappings etc?”

Refer to document SSN31_TechnicalReference_ReplicatedAssetInformation.pdf – the ServiceNow administrator should review this document.


“Who do we need to involve during the implementation process?”

A technical infrastructure resource to work with to install the SIM connector and to allow you to log onto the SLM SMaCC to create apiuser and their ServiceNow administrator, whether it be in-house or out-sourced, plus any other stakeholders for both ServiceNow and Snow should be involved in any engagements regarding the ServiceNow Connector.


“What connectivity is required from our end?”

Typically, we will use the SIM on the Inventory server – this server will need to be able to contact their Snow License Manager 8 webpage as well as the ServiceNow instance webpage.


“What should we have in place prior to the implementation?”

The Catalog Integration and CMDB Integration ServiceNow applications are both required for implementation – it is important to notify customers that these must be requested through the ServiceNow Store, but that we approve every request manually – they must allow up to two working days for this request to come through. This must be highlighted to customers to avoid nasty surprises on the day of implementation!


Additionally, we require at least SIM v5.8 to be installed, usually on their Inventory server – we can carry out this upgrade on the day of the implementation, but they must be notified in-case they have to raise a change control request on their side to approve this change to their environment.


Finally, SLM must be on the latest version.


“What credentials/user accounts will we need to provide?”

As per SSN31_UserGuide_InstallConfig.pdf page 3, we require a Snow License Manager API User account (which we can help them create from the SMaCC) and a ServiceNow account with the two roles detailed in the pre-requisites.


“Will integrating Snow and ServiceNow overwrite any of our existing data on either SLM or ServiceNow?”

The ServiceNow CMDB aggregation is a one-way flow of data from the SLM Rest API to ServiceNow. Any data from other data sources flowing into ServiceNow will not be overwritten and no data within Snow License Manager will be changed.


“Why do we need a Mid Server/What is a Mid Server?”

A ServiceNow Mid Server is an on-premise Linux or Windows service that ServiceNow provides. It facilitates connectivity between ServiceNow and a third-party source. The ServiceNow Connector has the optional ability to provide real-time compliance information from within ServiceNow and this can be used for real-time workflows between ServiceNow and SLM. Where a customer requires this functionality, they will need a Mid Server within their internal network only if their SLM webpage is not externally facing – if it is externally facing, then ServiceNow can interface with SLM itself, without the need of the Mid Server.


It is important to note that it is not Snow’s responsibility to configure or maintain the ServiceNow mid-server.


“What is the success criteria for the implementation – how can we verify the implementation is a success?”

During the implementation, the Implementation Consultant will ensure that the SIM is set to show all details within the logs – the Catalog Connector will be run first and the SIM log will be monitored at the same time as the Transform History log within ServiceNow. Once this is complete, the same will be carried out for the CMDB Connector which needs to run after the Catalog Connector. Once both are run, information from Snow License Manager should be populated within the Computer asset tables within ServiceNow and there should also be a review of the Software and Hardware Models.


“How can we keep the ServiceNow Connector up to date?”

From within ServiceNow, you can check the Catalog Integration and CMDB Integration applications are up to date from within the System Applications > Applications > Updates section of ServiceNow.


Snow Preference Center

Posted by alexander.cora2 Employee Jun 25, 2018

You can manage your communication and marketing preferences for topics of interest, product announcements, events, blogs and newsletters. Just setup your preferences at Snow Preference Center and also manage your email frequency.


In case you look for specific product updates, you should configure your SnowGlobe profile. Please also see Notification on product updates .

Snow gathers its deployed software information in the following ways:



The Snow agent will scan certain areas of the disk looking for installed software executables, RPMs etc. It will gather attributes about these files – Vendor name, exe name, version typically.

In addition, the Snow agent will gather certain registry keys, SWID tags, and also executes encrypted read-only PowerShell scripts to gather specific information about certain vendors – SQL edition, Autodesk Region, Toad edition etc.

All of this information is passed to Snow Inventory, where once per day the information is processed against the Snow Recognition Service, to produce real product and vendor names to view in Snow License Manager.



SnowXML is an open XML format created by Snow to enable processing of inventory data from any 3rd party inventory source. SnowXML converts the data from the inventory source into a format that the SRS (Software Recognition Service) can work with.

There are two ways to configure how the data will be formatted ready for the SRS. The first option is to flag the data as “raw inventoried data” - the other is to flag it as “Recognized”.


Raw Inventory Data

Raw inventoried data is actual software data, which should be equivalent to what the Snow inventory client picks up (executables, registry keys, ISO 19970-2 tags etc.). Below is a screenshot of some of the raw data populated:


Pre-Recognised Data

 Recognised data means there has already been some level of recognition carried out by the 3rd party Inventory tool, and thus the data supplied will include a standardized name, manufacturer, and version of the product. Inventory Tools such as BMC ADDM, IBM Bigfix, iQuate provide pre-recognised data.

A screenshot of ‘IsRecognised’ data is shown below:




If there isn’t an official Snow connector, it is possible to convert a CSV file to SnowXML using a PowerShell or SQL stored procedure. This has the advantage that as long as the inventory tool can provide EITHER Raw data, or pre-recognised data in a format that has already been created in our SRS, you will get recognised software shown in Snow License Manager.




For raw data the SRS must receive as a minimum:


Executable name

Publisher name

Executable version

Operating System (Windows, OSX, LINUX, UNIX, IOS, ANDROID)



For Pre-recognised data SRS requires:


Software Name

Publisher Name

Software version



A good example of recognised data is in Add/remove programs (see below) where Snow has already created a wealth of SRS rules






Unofficial Snow data sources vary enormously. For example, Splunk out of the box does not provide Software Publisher, which puts the recognition at about 10%. Configuring Splunk to add Software Publisher as well, and the recognition jumps to around 60%.


Unofficial Snow data sources are delivered as a project via a technical team, and as such are not supported. Also, they will require manual scheduling on the Snow server to convert CSV to SnowXML each day. Whilst this data can be sufficient, it is the least desirable option.



Official Snow Connectors have been validated by Snow, and potentially have additional recognition rules in the SRS specifically for that source. Certainly, they will provide decent application recognition. Depending on the source depends on the level of recognition – typically expect between 60-80% of the recognition that the snow agent would provide. For example, SCCM default data typically provides around 60% recognition, but with the addition of SCCM asset intelligence and a full SCCM Software Scan, the recognition rate increases to 85%. This is because ISO 19770-2 tags are now gathered, and exe’s are being scanned compared to the default add/remove programs normally gathered.


An official Snow connector is also fully automated, meaning the Snow Integration manager is installed and configured once, and then scheduled automatically.



The Snow Agent provides EXACTLY the right data for the SRS rules to match. Thus, it provides the best recognition. Its also light (8Mb) and quick (40 second scan daily) – providing around 50Kb of data per scan.

 In addition, the Snow agent monitors usage of all applications, detects Virtualised and remotely accessed applications, and is able to monitor SAAS usage via the user’s Browser – the most comprehensive data set available.

Snow Inventory 6 – How Secure Is My Data?


For as long as Information Technology has been around security has been a concern – and for good reason. Data security should be a top priority within your organisation. Have you ever considered how secure the data is as it is gathered by the Inventory Agent and shuttled to the Inventory server to be written to the database and, after the Data Update Job has run, presented in Snow License Manager?

In this article, we will take a brief look at the measures the Snow Inventory Agent and the Snow Inventory solution itself takes to ensure your data is secured.


The .SNOWPACK file; it’s not just a clever name – it actually is an archived file that contains the result of the scan. It will typically contain:

  • json – Unique per machine (ID TAG)
  • xml – This contains all inventory content
  • config – A copy of the Agent configuration file
  • log – log file
  • Swidtags

This file takes all of the above, compresses it and packs it into the .SNOWPACK file. It is then encrypted – even the file name is encrypted – with 128-bit AES encryption. This encryption applies to any credentials that the Agent may be configured to use within the snowagent.config file.

The encryption key for this is a hard-coded part of the Snow Inventory product itself. Where absolute top-level security is necessary, you can even request your own encryption key using an app we can provide.

For complete data security, Snow recommends having the Agent send via HTTPS, usually via port 443. This will require an appropriate SSL certificate to be installed on the Inventory server hosting the landing page. This way, you can apply as much additional encryption as you require.

Even if HTTPS is not used and the data is sent using standard HTTP protocol, the SNOWPACK file itself is always encrypted with 128-bit encryption, protecting the data from being intercepted and opened.

Your organisation may require data to be anonymised – in which case, the Snow Inventory 5 Agent can anonymise user details and IP addresses.


Protecting the Back-End

Access to the Snow Inventory Console is facilitated through the Snow Management and Configuration Centre (aptly named ‘SMACC’). The SMACC uses SQL authentication to establish a connection to the database and this goes for Snow License Manager too.

The configuration for this is buried within the file system in Windows Server – C:\ProgramData\SnowSoftware. Anybody opening this config XML file will find a string of ASCII. This string contains the SQL server (or alias) on which the database is hosted and the credentials for the SQL account used. This is, of course, contained within this ASCII, encrypted and unreadable.

For Snow Inventory 5, the snowserver.config found in C:\Program Files\Snow Software\Snow Inventory\Server on the Inventory Master Server contains an encrypted string also – this contains the credentials and SQL server information necessary to establish a connection to the SnowInventory database.


SIC of Security Concerns?

The Snow Integration Connectors, or SIC, use the Snow Integration Manager (or SIM) to facilitate connections. The data gathered by the SIM is sent via .INV files. These are protected slightly differently from .SNOWPACK files, with 256-bit Rijndael encryption. Again, the encryption key is baked into the SIM product, but unlike with Inventory 5, custom encryption keys are not supported.

In addition to the data files themselves, the credentials and details for necessary for each connector to work are also secured. Examples of these may be vSphere logon credentials for the Virtual Management Option, Office 365 Connector credentials or ServiceNow Connector credentials. Such details are stored in the registry in the form of encrypted keys.



Correct installation and configuration of Snow License Manager and Snow Inventory products carried out by a Certified Snow Implementation Consultant, ensuring they are kept up to date and following best practices with regards to SSL certificates will ensure that your Snow platform is robust and secure.

You might have seen that yesterdays (07.06.2018) release of SLM 8 brings some changes to the GUI of Snow's Oracle Management Option (OMO). As you can see in the release notes "All features and capabilities related to Oracle products have now been consolidated under the Oracle overview page accessible from the Enterprise menu item. Navigation to Oracle functionality has been moved, but the features and capabilities remain unchanged".


From the release notes I will also copy the table where functionality has been moved to:


In the past version you could simply add an order from the Licenses menu. Now you need to find the hyperlink in the top right corner of the Orders tab of the Database Edition. I had some difficulties finding it, so I will share some screenshots:


Since getting to "Add Oracle order" takes more steps now, I would appreciate to see a shortcut item in the Snowboard for "Adding Oracle Orders". Maybe a shift from the Orders tab of the Database Edition to the consolidated Oracle overview page would make sense too.

Dear reader,


Based on the previous questions asked about how to efficiently import a Microsoft License Statement (MLS) and also manage Microsoft volume license purchases after the import, I’ve decided to write a blog post about this specific matter. In this blog post, I’ll try to explain and show how you can import a MLS file and also make sure which steps you need to make to have quality and trustworthy  data.  


So…after reading this blog post you should be able to:

  • Understand what a MLS is and how to get hold of a MLS
  • Understand what sets of  data are imported form a MLS and at the same time know what data is not available in a MLS
  • How to import a MLS in Snow License Manager
  • And where you should do some quality assurance in Snow License Manager




Before we get started with importing a MLS, lets first have a look at what this document exactly is, why you might need it and how you can get your hands on a MLS. If you wish to create a complete view of your Microsoft license investments, you’ll need an inventory of all your Microsoft agreements and licenses. This is what Microsoft calls a MLS; this spreadsheet document is a comprehensive effort by Microsoft to basically inventory every license transaction made by your company. A MLS could contain transactions going back 10 to 15 years. The MLS is a good starting point for creating a digital contract management system in Snow License Manager for all of your Microsoft agreements and licenses, but be aware that a MLS can be overwhelming to digest and can come across as a confusing and difficult document.


It is recommended that the MLS import is done by persons with adequate knowledge and experience. For this reason, I strongly advise you to contact your Microsoft trusted advisor, reseller (LSP) or SAM partner to assist and advice you. The MLS follows a narrow interpretation of the Microsoft licensing rules, that might not fully cover the reality of your company’s license position. The MLS spreadsheet might contain errors or might not contain all of your purchase history - a mistake or wrong interpretation in one field of the spreadsheet can easily create a waterfall effect.


In order to get a MLS, I would recommend you to get in contact with your current Licensing Solutions Provider (LSP). They should be able to request a MLS spreadsheet for you and assist you with the correct interpretation.




Before I demonstrate the actual importing of a MLS spreadsheet, I would like to first explain the sets of data which will eventually be imported into Snow License Manager. Although, a MLS file contain many tabs with useful information, during the import in Snow License Manager only the License Agreements and Transaction Data is imported via the MLS import function. Below an example of both tabs:

  • Picture 1: the license agreements tab
  • Picture 2: the transaction data tab


Picture 1


Picture 2


All of the imported licenses – from the transaction data tab –  will be mapped to applications in Snow License Manager using the SKU numbers (in the MLS this column is usually called Part Number). The MLS import will eventually results in importing all of the active and expired volume license agreements and all of the licenses attached to those agreements.


It is Important to know, that a MLS file doesn't contain entitlement data about Original Equipment Manufacturer (OEM) purchases, Full Packaged Product (FPP) purchases and Independent Software Vendor (ISV) licenses. Although, the MLS file could contain a separate “MPSA” tab, please note that also these entitlement will not be a part of the import. MPSA related agreements and licenses will need to added or imported separately into Snow License Manager!




Now that we have a recent copy of the company’s MLS, we can import the file straight form within Snow License Manager or via the Snow Management and Configuration Center (SMACC). Please note, that doing an import of any document via the SMACC will bypass the web portal services (IIS) and would basically speed up your import. Loading will eventually take some what longer, when you do the import straight from Snow License Manger. For your convenience, I’ve uploaded two screenshots that show the import page from the SMACC (picture 3) and from Snow License Manager (picture 4)


Picture 3


Picture 4


In case you’re unable to either select the “import data” option from the drop-down menu or select the MLS import from within Snow License Manager, this means that your Snow account lacks the correct privileges and I would recommend to have the correct person update your Snow License Manager account (either your local Snow admin or your Snow partner in case you’re using the hosted solution)


By selecting the “MLS import”, you’ll enter the import wizard for importing the MLS file. The import itself takes a total of 5 steps and I will mainly focus on the most important parts. The first step is selecting the MLS file that you want to import. The second step is where you can change three import settings (picture 5), which are rather important:


(1) Use organisation alias for agreements and (2) use organisation alias for licenses will only work if your organisation structure – created in the SMACC – contains the alias as mentioned in the MLS file. This will usually not be the case! I personally recommend you to deselect them both. All agreements and licenses will be allocated to the ROOT organisation (the top company in your organisation structure). This means, that you need to assign the agreements and licenses from within Snow License Manager after the import. Alternatively, you could update the MLS with the organisation names as they are applied in Snow (SMACC => organisation structure). This will need to be updated in both tabs of the MLS, in the “Customer Name on Agreement” column.


The third import setting lets you select the option to (3) import incomplete licenses or not. I do recommend to import incomplete licenses for the completeness of you license legacy. If you would like to only have the latest active volume license agreement in Snow License Manager, it would not be a smart idea to do a MLS import, but rather just import that agreement(s) via the agreement import, and use the agreement import template to get started. The main idea behind importing a MLS file, is to get all of your volume license purchases into Snow License Manager, including Software Assurance licenses, Upgrade licenses and / or Step-up licenses. These are all good examples of an incomplete licenses, after the import is done.


Picture 5


During step 3 en step 4 you will be asked to verify the agreements and licenses that will be imported. Especially in step 4 (picture 6) – verification of the licenses – you might see different kinds of error messages. Regardless of these messages, you will always be able to import all the data into Snow License Manager, and during both steps you may also export different excel sheets for your quality assurance checks. These exports contain explanations  for each error messages.


Picture 6


The final step should show a positive result and how many rows have been imported. Now that the MLS has been imported, you might need to carry out some additional quality assurance.




Because not all MLS imports are the same for each one of you, it’s hard to determine which specific assets need your attention after the import is done. If you have imported an unaltered MLS, all the licenses and agreements will be allocated to the ROOT, as shown in picture 7. This means, that you might need to change and assign them to the correct organisations (business units).


Picture 7


For the licenses, you first need to focus on the set of incomplete licenses, if any. Luckily, you can easily filter on all incomplete licenses in Snow License Manager (picture 8). The reason for each incomplete license might differ for your specific situation, but will always be one of the following:


  1. The license imported is a Software Assurance only purchase
  2. The license imported is an Upgrade Advantage purchase
  3. The license imported is a Competitive Upgrade purchase
  4. The license imported is an Upgrade license
  5. The license imported is a Step-Up license
  6. The SKU of the license in the MLS did not match with the Snow SRS databases


Picture 8


“A to E” will basically require you to link the incomplete license with a base license – the initial purchase – in order to make it a complete license. For “E” the mismatch will result in the license missing many important details. The result of a license missing after a MLS import can also been seen in picture 8, looking at the red numbers 1 to 4. As you can see, the purchase / license record will be imported, but most of the license details are missing.


For creating the correct relation between an incomplete license and the corresponding base license, you will need to analyse each individual license or license product family, in order to establish the correct upgrade paths. The screenshot below (picture 9) shows an example of an incomplete license, because this license was a Software Assurance only purchase.


Picture 9


You should be able to link the correct licenses together straight from within Snow License Manager, but you might also wish to analyse the purchase legacy in the MLS itself. Below you can see an example of the license purchase of Exchange Server Enterprise (picture 10).


Picture 10


I’ve added some filters to get the overview as shown above. Selecting the appropriate metric that applies removes the CAL licenses and by searching for all “Microsoft Exchange servers” in the application column, I should be able to link all purchases together.


In this particular example “1a” is the initial purchase of the Microsoft Exchange Enterprise edition. Followed by a Software Assurance only purchase, which is “1b”. This would mean I need to link 1b to 1a. The most recent purchase in this case is “1c”, which again is a Software Assurance only purchase that I need to link to 1b. In the end this will result in three purchase records (three complete licenses) and one license entitlement  of Microsoft Exchange Enterprise Server 2007 with Software Assurance for a particular period. As mentioned before in this blog, you might wish to pick this up with your trusted advisor, either your Snow partner or via Snow Software.


The last thing I would like to mentioned, which is also very important to take into account, it the quantity of licenses that you need to adjust when it comes to the following metrics:

  • Processors
  • Cores


The reason for this is that the MLS import will copy the quantity for each license purchase straight form the “transaction quantity” column located in the transaction data tab. If you look closer to a license purchase that has a processor or core metric, you’ll see that these purchase come in packs of two. The initial result of the MLS import in Snow License Manager is that you’ll need to double each license quantity. Below you can see an example of how the license purchase looks like in the MLS (picture 11) and eventually how this looks like in Snow License Manager (picture 12).


Picture 11


Picture 12


From an entitlement perspective you own 4 SQL Server Standard 2014 licenses, that come in separate packs of two. This is the equivalent of 8 SQL Server Standard 2014 Cores. This also applies to the processor core pack for products like BizTalk Server or Windows Server, and of course also the Windows Server based on the core metric. Please keep this in mind, before you start assigning these expensive licenses to the correct assets, that you multiple the quantity by two.


I would like to close this blog post, by saying that I strongly advice you to conduct a MLS import only once! After you have imported your company’s MLS, you should have a solid Microsoft agreement and license base from which you can start to maintain and update additional purchases separately by either adding these manually or by using the other import options available for agreements and licenses.


I hope this blog post helps you out by explaining what it means to import a MLS, how not only to do the import, but especially what you need to do after the import.


Don’t hesitate to comment on this blog post or reach out to me or any of your local Snow contacts for more assistance.


My other blog about SQL Server Management