Skip navigation
All Places > Snow Product Hub > General Licensing Forums > Blog
1 2 3 4 Previous Next

General Licensing Forums

57 posts

Microsoft SQL Server is a relational database management system developed by Microsoft.

As a database server, it is a software product with the primary function of storing and retrieving data as requested by other software applications—which may run either on the same computer or on another computer across a network (including the Internet).


There are various editions of SQL server:

               SQL Server Enterprise

   SQL Server Standard

   SQL Server Business Intelligence

The number of editions and their names and capabilities varies by version, Enterprise and Standard are available at a minimum. Depending on the version, there may also be some of the editions below available.

SQL Server Datacentre

SQL Server Web

SQL Server Business Intelligence

SQL Server Express

SQL Server Developer

                         NOTE:         Developer edition is functionally equivalent to Enterprise Edition

         It is FREE to use for Test & Development under the existing licensing for your SQL licensing, but          you are NOT allowed to use it for production work or for disaster recovery (DR)


Can I use SQL Server Express for Snow installation?

To answer this question, read below for the pros and cons of SQL Server Express.


SQL Server Express is a free version of Microsoft’s SQL Server.

SQL Server Express is the most basic offering available. It is a full database engine you can deploy to a server or embed into an application. Express is free and comes with many of the same features as the enterprise edition. SQL Server Express is probably most suited to supporting production applications for smaller to midsize businesses. A typical SQL Server Express use case would be a deployment by developers who do not want to create applications with a database hosted on a server. Using Express, they would be able to develop apps with their SQL Server database.


SQL Server Express Benefits

Some benefits come with an SQL Server Express deployment.

  • Cost: One huge advantage of SQL Server Express is that it is free. Your only outlay is the time investment you make downloading and setting up the system. If you only want to learn how to use SQL Server, then Express is for you.
  • Scalability: SQL Server Express is an ideal starting point for smaller independent software vendors since it can be used with any smaller application. The licensing allows Express to be included as part of an app or product.
  • Security: Within SQL Server Express there is the option of free online backup that will help to protect your valuable business data if anything goes wrong.
  • Features: While Express is the “lite” version of SQL Server, there is still an impressive range of features that you would have to pay for with other systems. Express supports native XML, and the SQL Common Language Runtime.



SQL Server Express Limitations

  • 1GB maximum memory used by the SQL Server Database Engine

  • The maximum size of each relational database is 10GB

  • SQL Agent is not included in Express. The SQL Agent is a background tool which enables administrators to automate tasks like backing up data, database replication setup, job scheduling, user permissions, and database monitoring.

  • The limit on the buffer cache for each instance is 1MB of RAM.

  • The relational database engine is restricted to the lesser of 1 socket or 4 cores.


The answer to this question is no, Express cannot be used. Snow products require the SQL Server Agent to run the overnight Data Update Job.

Additionally, the 10GB database limitation is far too restrictive for the size of database most customers. An example of this database size would be under 1000 units the estimated size of the Snow License Manager database would be in the region of 15GB.


For guidance on which edition to use, please refer to the Snow System Requirements document which can be found here 


Further edition functionality comparisons can be found at the following links:

Editions and supported features of SQL Server 2017

Editions and supported features of SQL Server 2016

Editions and supported features of SQL Server 2014

This article will deal with how to use Snow reporting and License Assignment for Direct License Allocation. Datacenter allocation will be covered in Part 2. This method can be used to assign licenses to a large number of hosts - speeding up the initial allocations when implementing Snow. Its also a good housekeeping task to check regularly that new unlicensed servers arent appearing in the estate. 

First report on the unlicensed servers:

1. Run the ‘License tracking per Computer’ report. Filter on ‘Windows Server’
2. Add columns for ‘Datacenter Name’ as well as ‘Compliance’ and ‘License Requirement’.
3. Filter on ‘Coverage reason’ = None. Your report should look similar to the screenshot below.

4. Save this report and schedule if desired – recommend weekly.
Now prepare the import spreadsheet:
5. Now export this report to XLS – it’s the list of all unlicensed Windows Servers we will work with in the next steps.
6. Remove any servers you don’t want to cover at this time – e.g. other Physical hosts requiring DC licenses
7. Add a column for the ‘Allocation’
8. Add a column for ‘ExternalID’ – this needs to match the ‘ExternalID’ field in the information tab of the license you want to assign (Note ExternalID is normally blank unless you have added a value when you added the license)
You can also use the ‘License ID’ value, which is the unique ID Snow assigns to each license – both fields are visible in the column selector of the ‘List All Licenses’ view from the Licenses Tab

9. In the XLS add the correct number of processors or processor cores to the allocation field, to match the License Requirement field, and the License or External ID of the license where they are to be taken from.

Now import the allocation:
10. From the ‘Home’ menu select a ‘License Assignment Import’ – select the XLSX above

11. Map 'Assign to' – ComputerName and ‘Assigned Quantity’ -Alocation – ‘Type’ is only necessary if datacenter licenses to be allocated. LicenseID or ExternalID is automatically assigned if it matches.

Click next and the preview screen shows the allocations that will be assigned

12. Proceed if no errors and perform a ‘License Recalculation’ to see the results in Snow License Manager

Caught in The Web

Tracking and metering software usage is one thing – but what about tracking web applications? This article will serve as an introduction to the world of Snow Web/Cloud App Metering. We will take a look at the two methods Snow provides – and their limitations, pros and cons.


Web App Metering Method

The “traditional” method of web app metering is fairly basic and still fully supported by Snow – set a web pattern in SLM:



A web.config file is then created in the Snow Agent install folder on the client machine. This method works by referencing the client machine’s DNS cache. You can view this on your own machine from a command prompt using the command ipconfig /displaydns.

Unfortunately, whilst this technique is largely robust enough to show who had accessed what, this method will not show the where and the how long. For example, it will show that a user had accessed the site, but not what features and not the length of time.

Furthermore, the DNS cache is not readable in all corporate environments – proxies can block this, for example.


Cloud App Metering With Inventory 6

Cloud App Metering incorporates DIS (Data Intelligence Service) rules. Within the DIS, patterns and rules are stored which can recognise which features, pages, tools, etc of a particular web app was used.

This is useful as many web apps offer different subscriptions levels which make certain parts available. With Cloud App Metering, it is possible to view which features are actually being used and which aren’t.



The task of adding web patterns into Snow License Manager is not necessary here, as the DIS rules are uploaded to the Software Recognition Service. Each web app is then assigned a unique ID and the rules are stored within the Snow Inventory database.

The Cloud App Metering rules are then downloaded by the Snow Inventory Agent and stored on the local machine.


Browser Extensions



The above is facilitated by the use of a browser extension – currently we support Chrome, Firefox and Internet Explorer 11. Browser extensions are installed via the agent, once Cloud App Metering has been activated within the Snow Inventory admin console.

The browser extension will capture all URLs accessed by the browser and stores the information in a \cloudmetering\extension-output directory within the %ProgramData% hidden folder in Windows – this data is obfuscated, meaning it cannot be read and interpreted in plain text. The agent will compare the contents of these results with the web app patterns received by the DIS rules and, when a match is found, will store them and delete all results from the extension.

This data is then sent with the .SNOWPACK file when the scheduled scan and send occurs. Once the Data Update Job runs, it is visible in Snow License Manager.

Cloud App Metering does not store data centrally for all web traffic – only websites that have DIS rules attached!




Setting It Up

Here’s how to setup the Snow Inventory to start using Cloud App Metering:

  1.       Agent .config file – the snowagent.config file must contain the following lines within the <SystemSettings> section:

    <Setting key="saas.firefox.enabled" value="true" />

    <Setting key="saas.ie11.enabled" value="true" />

    <Setting key="" value="true" />

  1.       Activate Cloud App Metering within Snow Inventory console:

  2.       Select the configuration you are rolling the change out to:

  3.       Once the agents receive the instruction, the browser extension will appear on the client machines:

Sluggish Snow License Manager tables, reports taking too long to load? This article aims to provide a starting point when diagnosing possible performance issues, particularly for larger environments.


If you have the following issues, you may need to look at your SQL Server platform:


  • Snow License Manager IIS web app usage generally slow and sluggish
  • Reports taking too long to generate
  • SLM website hangs
  • .SNOWPACK agent scan files in \Incoming\Data\Error folder with SQL timeout errors


Performance Anxiety

This article aims to provide advice on where to improve performance in the following areas:


  •  Speed of Inventory Agent .SNOWPACK file processing
  • Accessibility and usability of the Snow License Manager web application
  • Speed in which the over-night Data Update Job takes to run
  • Other general performance issues


Snow Software do not have any best practice guidelines for monitoring performance and usage. This task must be carried out by the customer. The advice offered in this document is largely based on previous engagements with similarly sized customers as well as the application of widely recognised industry best practices.



Dressed to Compress

SQL Server 2008-2014 Enterprise, or SQL Server 2016 Standard SP1 is recommended to allow Data Compression – this will reduce database size. This may increase the CPU usage as data is decompressed, but will not affect the IOs, so performance should not be affected overall and the decrease in database side should off-set this overhead.



A recommended disk configuration for large environments (over 100k seats) suggestion is as follows:

C: OS Drive

D: SnowInventory Database Data File, High-Speed Disk

E: SnowLicenseManager Database Data File, High-Speed Disk

F: TempDB Data File, High-Speed Disk

G: Log Files, High-Speed Disk

A configuration such as the above has been shown to give good performance for such large environments. The drives above should be separate physical disks and not separately partitioned volumes.


Monitoring - What's Going On?

To aid in identifying where the performance issue may lie, customers should investigate the SQL server. As a start, the monitoring counters common to all Windows Servers can be used.




Third-party monitoring tools may also be used to get further analytical information. Some suggestions on areas to monitor could be:

  • Processor(Total)\% Processor Time – This is a basic indicator that should demonstrate that the server is running within the accepted parameters. The counter being in the 20-40% range would be considered acceptable, but spikes of over 80% could be a concern.
  • Memory\Available MBs – tracking the available MB of memory can highlight if the amount of memory installed on the server is the issue. It can also help establish if other processes are using memory that could be used by SQL Server.
  • Paging File (Total)\% Usage – If a lack of memory is causing issues, it could be that the Page File is being used. Reading and writing to and from disk instead of memory will cause noticeable performance decreases.
  • PhysicalDisk(Total)\Avg. Disk Sec (Read & Write) – Two counters displaying this metric for both read and write can show how fast the I/O subsystem can respond to data requests. Latency values of more than 20ms may be an issue and should not be expected is SSDs are used.
  • System\Processor Queue Length – If this counter reports on the number of threads that are queued for processor. If this is above 0 then there are too many requests per core than the processor can handle, which will have an impact on performance.





Many of our customers now have large environments of 80-150k seats. For this amount of data and users, they would see improved performance by carrying out some or all of the following:

  • Ensure a 16 core processor is used
  • Ensure RAM size is 128GB
  • Ensure storage volumes are split across enough physical disks and that the disks are high performance SSDs
  • Migrate to SQL Server 2014 Enterprise or SQL Server 2016 Standard SP1 in order to enable SQL Data Compression
  • Monitor SQL server performance for an extended length of time to ascertain the times and extent of the performance issues

Oracle Java

Posted by hans.andreasson Employee Oct 15, 2018

Licensreglerna kring java ändras. Att få veta hur det ser ut i er miljö är enkelt: rätt filter och rapporten är klar. Det som gör detta möjligt är Snow´s programvaruigenkänning på Java och 6 miljarder andra executables (SRS / DIS) för knappt 100 000 tillverkare.


Kontakta din snowkontakt eller om du behöver hjälp eller har frågor.Oracle Sun Java fitler report


Enemy: Unknown

Your organisation has Snow Inventory and Snow License Manager up and running. Agents are rolled out to all devices on your estate and you are starting to make use of all the data. One fact remains: your network is huge. Multiple VLANs, multiple regions connected by MPLS, secured networks and more – how can you be sure that you can see every network device? After all, SAM is only as effective as the data you put in. In this article, we will discuss an all-to-often overlooked functionality that Snow Inventory provides – Discovery.


The Gateway Drug

Snow Inventory offers scalability through the use of Snow Inventory Gateways. We can install as many Inventory Gateways as is required – this is included within your Snow Inventory license. These Gateway Service instances can then be used to feed back discovery data on a network back to the Inventory Master Server.



Gateway Server instances can then be managed from within the Inventory SMaCC console on the Master Server:


Double-clicking into a Gateway will allow you to configure Network Discovery:



Discovery Methods

Now it’s time to look at the different types of discovery we can use…


Active Directory

Using an LDAP, we can identify machines across any number of domains. The data gathered can then be cross-referenced by Snow License Manager to identify any computers that are in the domain or domains and give an output of the machines that are not inventoried (i.e. there is no Snow Inventory Agent installed on the machine).

Any domains that do not have a Trust Relationship to the domain where the Master Server resides will require a Gateway Server within that domain.


SNMP (Simple Network Management Protocol)

Not all network devices can be fully inventoried, but you can still discover them. Who knows what devices you may have out there sitting in frame rooms? SNMP, or Simple Network Management Protocol is usually used for remote management of simple devices – uninterruptable power supplies (UPS), routers, switches, printers and other such devices may not even be running a full operating system but still have network connectivity so that they can report back basic information to your IT team – IP address, MAC address, serial number, firmware version etc. Snow Inventory can use this to discover and report on such devices.


DNS Lookup

Domain Name System lookup – DNS assigns a name to an IP address. Inventory can use this to attach hostnames to IP addresses to further identify devices.


TCP/IP Fingerprinting

TCP/IP Fingerprinting is used to try and determine what OS is behind the IP address that has been discovered. This can particularly help identify elusive Linux and Unix machines, as well as Windows, if WinRPC is unable to.



This protocol is used solely for Windows remote management and is another tool that Inventory could use to potentially identify a Windows machine on the network. Port 135 must be open on the target machine to be able to be scanned via WinRPC.


SSH (Secure Socket Shell)

SSH protocol is most often used to remotely manage Unix devices, for example, when using a tool like PuTTY to SSH protocol is used (usually via port 22) to secure copy (SCP) files to a Unix-based machine. Using this protocol, Inventory can identify Unix machines on the network.


Making Use of Discovery Data

Once Inventory has discovered two of the following – an IP address, a MAC address and a hostname, then this device is discovered and will show up on Discovered Devices reports within Snow Inventory.


Within Discovery, there are a number of default views:



AD and SIM Computers – All computers that have been found by the Active Directory discovery or any SIM Connectors.


Reachable Network Devices – Any devices picked up by the SNMP protocol, i.e. switches, printers etc.


Reachable Unknown Devices – These devices have been discovered but there is not enough information to determine much more than the IP address and MAC.


Reachable Computers – These devices have been discovered by either the WinRPC/WMI, TCP/IP Fingerprinting or Active Directory protocols to determine the operating system.


Reachable Computers with Snow Inventory Client 3.x for Windows – This is useful for identifying any Windows machines that are still using the old Inventory Client. These machines can then be targeted for Inventory Agent deployment.


Dear reader,


This time around, I’ve decided to write a blog post about managing a Virtual Desktop Infrastructure (VDI) within the Snow License Manager. I’ll try to explain and show ways to determine how to draw up an overview of all VDI’s and their relation with the actual physical hardware clients and users. Besides this, we’ll also have a closer look into ways you will be able to create license requirements for the Windows Desktop Operating Systems being used from within the VDI and of course what the impact of a VDI has on you overall application landscape.


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


  • understand what a Virtual Desktop Infrastructure is and how this data is represented in Snow License Manager.
  • analyze your own VDI environment and the virtual applications being used.
  • analyze the business consumption with regards to which device and / or user is accessing a VDI.
  • add Microsoft Windows Operating System & VDA licenses in Snow License Manager to cover the use of VDI’s.
  • create and save easy-to-use reports specifically for your VDI estate, including compliance information.




First lets get the facts and figures out of the way, so to speak…. What exactly is a Virtual Desktop Infrastructure?


Virtual desktop infrastructure (VDI) is virtualization technology that hosts a desktop operating system on a centralized server in a data center. VDI is a variation on the client-server computing model, sometimes referred to as server-based computing. VDI is a good and solid alternative to the server-based computing model used by Citrix and Microsoft Terminal Services. There are two main approaches to VDI: persistent and nonpersistent.


  • Persistent VDI provides each user with his or her own desktop image, which can be customized and saved for future use, much like a traditional physical desktop.


  • Nonpersistent VDI provides a pool of uniform desktops that users can access when needed. Nonpersistent desktops revert to their original state each time the user logs out.


Picture 1


In the screenshot above (picture 1) we can see a common example of different kinds of devices using virtual desktops, which are being streamed / pushed to the devices from the server back-end. In this particular case the virtual desktop has a Windows Operating System installed. The last thing I would like to add, which is very important and is a vital difference between a virtualized applications, is that a virtual desktop infrastructure contains:


  1. a virtualized operating system
  2. installations of virtualized applications
  3. and its own data


Hence, the reason it is called a “virtual desktop”. Instead of streaming a virtual application to the device, a whole desktop with pre-installed apps and data will be streamed to the device.




With the use of the Snow Inventory Client installed in the virtual VDI environment, all of the necessary data will be visible and manageable in Snow License Manager. Together with the integration between the Snow Software platform and the hypervisor technology used to host the virtual VDI pool(s), you will be able to establish a clear overview of the physical datacenter and all of the VDI’s available to be consumed by the business. This also includes, information about what is actually installed in each VDI, and the usage of each application made available in the VDI. You will be able to see which specific kind of device and which user has been using a VDI and the installed applications.


List all VDI’s

Lets first focus on generating a total overview of all VDI’s being inventoried in the IT-estate. With the use of the Snow Inventory Client installed in every single VDI (template), we’ll end-up with similar information of each individual VDI, just as we would when inventorying a physical computer. Once this data is available in Snow License Manager, we can have a look at the total number of VDI’s available in the system. If we navigate to the “Computer” category, from the drop-down menu we need to select the List all computer option, as shown in picture 2 below.


Picture 2


This will present the “List of” all computers that are currently being inventoried in your total IT-estate – either with the use of the Snow Inventory Clients and / or an integration with a third party inventory tool -. The list might also include possible hyper-visor servers. By using the available filters and the appropriate columns we are able to create an overview of all VDI’s. In the example (picture 3) we can see that the column selector needs to be opened first to add the VDI column.


Picture 3


After adding that particular column we can set the filter to Yes, which will create the list we are looking for, as shown in picture 4.


Picture 4


Form this list, I’ll select a VDI to have closer look at the detailed overview. Especially, when  using the Snow Inventory Client you may expect to see the following in-depth details (picture 5).


Picture 5


The User Interface is basically the same as when also looking at the detailed overview page of an individual laptop, server or computer, to name just a few other types of assets that might end-up in your personal Snow License Manager portal. The type of assets will always be display to the left of the computer name:


If we zoom in on a couple of interesting tabs available in the detailed overview, we'll see that in the screenshot above (picture 5) we get a nice list of all applications used from within this particular VDI. What is important to point out, is that this will either be an application that is actually installed in the VDI bubble or it will be an application that is streamed separately to the device that is running the VDI at that particular moment. In Snow License Manager, both will also be a part of the total application list. Later on in this blog I’ll highlight some interesting reports, in which you’ll be able to distinguish between these applications.


Looking ahead at the data we might need for compliance calculations, we can see a tab that displays the number of unique user that have been using this particular VDI (picture 6). If the appropriate license metric for one of the virtualized applications in this VDI session would be based on the number of unique user, the calculation would be based on these two users - after adjusting the license metric of the application first -.


Picture 6


We can also see a tab that will give information about each unique machines that has accessed (run) this VDI (picture 7). You may expect to see different kinds of machines in this tab, which will be based on the company assets used to run VDI’s and weather you’ll be able to also approach a VDI from your privately owned assets, like mobile phones, tablets or a laptop. The Snow technology will be able to create easy-to-use list of data and reports so you know exactly which user has used which machine to run which VDI or VDI’s.


Picture 7


Another very interesting tab to have a closer look at is the “Information” tab. In this tab we’ll see lots of different details ranging from the bit-rate of the Windows Operating system to specific details about the Snow Inventory client. What you’ll also find in this tab, is the link to the physical server that is hosting the VDI, including the information about which hypervisor technology is used. This is highlighter in the screenshot below (picture 8).


Picture 8


If I would click on the specific host server (ESX18057), I’ll end up on the detailed overview page of that machine, including the information about the cluster it belongs to, as shown in picture 9.


Picture 9




When it comes to using the reporting section specifically for a VDI environment, it is possible to use three available reports straight from the start. Out-of-the box, Snow License Manager contains a separate group that houses 3 unique reports for VDI usage and management. Below you'll find a screenshots (picture 10) of the section I’m referring to. The group is called “VDI (3)” and contains the following 3 reports:


  1. All devices that have accessed a VDI
  2. All user that have accessed a VDI
  3. Applications per VDI computer


Picture 10


In the "all devices" report, you can view exactly which specific company owned machine or any other possible privately owned machines has been using a VDI from the total available VDI pool(s). If you have implemented an organisation structure in the Snow platform, you’ll also be able to see the distinguish between business units. This information is important for those software vendors out there, that need to know the total number of physical devices that have been using application from within a VDI!


The "user related" report shows information about each unique user that have accessed one or more VDI’s, including first and last used information. Also in this case, an available organisation structure will distinguish between business units. With regards to specific user related license metrics this is very important information.


The third and last report, will show all applications that have been used from within each VDI. This means all applications installed or either used per VDI computer. All installed applications will be the default available applications in the VDI (template), just like the installed Operating System. Once a user is running a VDI locally on his or her device, other applications could also be used during that session, based on company protocols and user privileges. These other applications are streamed seperately to the VDI one by one and will also show up in this report. If you wish to switch between views, there is a criteria you can easily add to this report as shown in picture 11.


Picture 11


If you set this criteria to “No” it will only display the default installed applications of the VDI’s accessed per computer, and if you set the criteria to “Yes” it will display all virtual applications that have been streamed separately to all VDI sessions. Of course, you could add additional criteria and filters to analyze a specific vendor or application etc.


Besides these out-of-the-box available reports in the specific VDI group, I would like also like to point your attention to the following two reports available from the same "Reports" category, but located in different groups. The first report is available from within the Standard reports group and is called “Applications per device” (by default).

In the screenshot below (picture 12) I have create a specific detailed overview by applying the following columns:


  • Device/Computer – which is the physical machine used to run the VDI
  • Remote Server name – which is the actual VDI
  • Application manufacturer
  • Application
  • No license required – by applying the Yes/No filter you can easily switch and manage all applications that have a financial commitment, thus need a license!
  • Last user on device
  • Last used
  • and 3 columns with usage information….


Picture 12


The other report can be found in the group called “Datacenter”. The default name of the report is called “Physical and virtual servers per datacenter” as shown in the screenshot below (picture 13). By applying the necessary criteria (like; Virtual set to Yes and Operating system set to Not Like + words like Server, Linux etc.) you could end-up with this decent reports. The report will display the relation between the physical hosting layer and all the VDI’s running on top, including relevant information like the inventory column. It is important to know if a VDI is not being inventoried by the Snow Inventory Client.


Picture 13




By using VDI technology in your own IT-estate and being able to report on relevant data with the help of the Snow platform, you will be able to investigate the usage of VDI sessions from different angles. Up until now I’ve tried to explain how the collected data is presented in Snow License Manager and which specific reports will also assist you to get a better understanding of the consumption. A part from all this relevant information, you would also like to establish useful compliance information to determine particular license risks or possible optimization possibilities.


In order to create the correct compliance information, you’ll need to first determine the appropriate license metric that must be applied to each individual applications that is being used from within a VDI session. Vendors likes Microsoft and Adobe might approach the calculation of the required licenses, as to be based on the number of unique physical devices or the number of actual users that have access to a VDI. A vendor like VMware, might approach the calculation as the total number of unique VDI’s that have been accessed during a particular period in time.


Another very important matter might also be the virtual Operating System that is used inside your VDI bubble (environment). Most likely, this will be a Microsoft desktop operating system like Windows 10 or Windows 8. In order to actually run & access a VDI with a Microsoft desktop operating system on your local physical machine, you need to have the right license to do so. I would like this blog to be about the management of VDI environments in Snow License Management, and not spend too much about all the possible and mandatory license rules and available products in the market today. I will however, like to mention that Microsoft basically offers two vital option in order to be compliant on “the right to run & access a VDI that has a Microsoft desktop operating system installed”:


Windows Desktop OS with active Software Assurance (option 1) and Windows Virtual Desktop Access (option 2) are the licensing options required when accessing a Microsoft desktop operating system in a Virtual Machine (like a VDI). Windows SA and Windows VDA are device based licenses, and under select Volume Licensing agreements available in a Per User license option. Essentially the Windows VDA license is for devices or users that do not qualify or do not have Windows SA; such as thin clients, 3rd party owned devices and any device without Windows SA.


To determine and know for sure which license solution would be most suited for your personal situation, I kindly advise you to contact your trusted software advisor, the software vendor or your reseller (LSP) to assist and advice you on this specific topic, both with regards to the Microsoft VDI Operating System license options as well as to the individual applications used in your personal VDI environment!


At the moment, the Snow platform is only able to manage “device based licenses” with regards to the Windows Desktop OS Software Assurance and Windows Virtual Desktop Access licenses.


In the screenshot below (picture 14) I’ve selected the Microsoft Windows 10 Enterprise desktop operating system, and clicked on the compliance tab to hightlight the following.


Picture 14


Having the correct Snow Inventory Client installed on physical machines and in virtual computers like a VDI (Snow Inventory Client 3.7 or higher and for VDI the client must be configured with IsVDI=Yes), the Snow platform will be able to make a very important distinguish. As you can see in picture 14, the total number of unique installations of Windows 10 Enterprise is 842. The total number of Windows 10 Enterprise installed in VDI’s is 23, and is not taken into account.


It is important to understand that although the 23 installation of Windows 10 Enterprise are installed in the VDI environment. The installations must still be licensed with active software assurance (option 1) or VDA licenses (option 2). 

Also when looking at the application list of a single VDI, you’ll see the following remark in the “Remark column” (picture 15). The remark means that the operating system is installed on a virtual computer and of course will need to be licenses accordingly.


Picture 15


In the case that you have machines in your environment that are not being inventoried by the Snow Inventory Client, but do use your VDI’s, the following will take place in Snow License Manager. A couple of examples of machines that are not being inventoried could be a thin-client or a zero-client, but I could also be any third party device. In this case, when the Snow platform detects these types of machines it will automatically add the need for a Microsoft VDA license. Also when the Snow platform sees any inventoried machines that is covered with a Windows Desktop OS without active Software Assurance, it will automatically add the need for a Microsoft VDA license.


Using the report “All devices that have accessed a VDI” I will not only know exactly which physical machines has used a VDI, but I’ll also know which of these devices are not being inventoried, as you can see in picture 16. In this particular example, the report contain 10 unique machines that have run & accessed a VDI and that 1 of those 10 machines is not being inventoried.


Picture 16


With the use of picture 17 I can visualize what I meant to say, that the Snow platform will automatically add the need for a Microsoft VDA license. It is not actually an applications that is installed on any device, but it is added to the list of applications to highlight the necessity of the license right! In this way it will also show up in your Microsoft compliance summary.


Picture 17


Before, I actually start adding the necessary quantity of licenses, I would also want to analyse the installation of the actual Microsoft desktop operating system(s) we are using on our physical machines. In this example, I’ve gather information – which I would like to keep very keen and simple – that looks like this (picture 18).


Picture 18


I’ve been able to determine the total amount of unique Windows desktop operating systems that is installed in the VDI environment, but also on physical machines. As already mentioned and determined using the correct report, I know that 10 of these “so-called” installations are from VDI’s. These 10 installations still need to covered with licenses.


The next logical step would be to add the correct license entitlements owed by the company, which in the end should alter & update the Compliance Summary report with the correct facts and figures. From there, you should be able make the best next business decision.


The example in the screenshot (picture 19) below, shows that my company owns a total of 50 Microsoft VDA license based on devices. Hence, that you don’t forget to add the license subscription period.


Picture 19


The other licenses the company owns are Windows Desktop OS licenses with active Software Assurance. In this example shown in picture 20, these are Microsoft Windows 10 Enterprise Plan E3 licenses with active Software Assurance, that you need to activate in the second tab as demonstrated in picture 21. You can either add the actual period of the Software Assurance purchase or use the period of the agreement the license purchase itself is linked to!


Picture 20


Picture 21


Before I end this blog, there is still one vital remark and matter I wish to address. For the applications used from within each VDI session, you need to set the correct license setting in Snow License Manager. Of course, you’ll only need to do this for those applications that actually need a license. The correct metric that might apply, will depend on your personal business choice during the procurement of the licenses. Therefore, you’ll need to look-up the correct metric in your own purchase records, if not already stored in Snow License Manager. I would recon that the most common used metrics will be either per device or per user. In the screenshot (picture 22) below you can see how to alter the license metric for an application.


Picture 22


You first need to select the application that you want to edit. By clicking on “Edit application” you can select the second tab (picture 22) and then apply the correct metric; user or device!


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)


My other blog about creating a digital contract management system in SLM


  • Define the high-level process and the steps required to carry out bulk computer archiving in Snow License Manager.
  • Provide an additional mechanism of control in respect to complying with internal company asset life cycle management policies.
  • Help save a significant amount of time ordinarily required to carry out this task manually on a machine by machine basis where there is a requirement to archive many machines in Snow on a periodic basis.

What is Archiving

Snow license manager provides two separate means of removing computer records from the Snow database using the Web UI.


Using the “Delete” option will permanently remove the computer record from the Snow database and there will be no further access to that computer inventory record in Snow.

Note: Choosing to delete instead of archiving will depend entirely on the needs of your business and should be detailed in your data retention policy so please ensure you refer to this prior to taking this action.


The Archive option will also perform the “Delete” function however, prior to the deletion it will take a point in time (POT) Snapshot of the machine records which it retains in the License Manager database as an archive record in case you need to refer to it in the future using the standard archived computer report available in Snow License Manager.

Note: Choosing to archive instead of deleting will depend entirely on the needs of your business and should be detailed in your data retention policy so please ensure you refer to this prior to taking this action.

Why Archive?

In short, computer assets will at some point of their lifecycle be permanently removed from the corporate network and disposed of for several reasons i.e. No longer supported, damaged, lost, replaced etc. If the computer records remain in Snow license manager and software applications are reported as installed and or in use on the respective computers, then they are consuming licenses not only for Snow but for those applications identified on the machines.

If you do not archive or delete these entries from Snow it will have a direct impact on the overall software license compliance position and in turn will have financial and potentially legal implications.

Refer to your organisations data retention policy as this will govern what records are kept and for how long.

Your company’s requirement to reference these archived computer records would typically arise either for audit, legal, security, transformation related activity or simply for historical reference purposes.

The high-level Process

Step 1 - Create a custom Field in Snow

You should only have to do this once, after that the field will always exist in the Snow custom field list unless it is removed as part of a manual clean-up process.

See screenshots below:

  • Click on Home --> Administration-->Custom fields

  • Click Add

  • Select the category -- ‘Computer/Mobile device’

  • Select the Type field – choose ‘Yes/No’
  • Type ‘Archive’ in the Name field – This will be the custom field name.
  • In the description field, you can add whatever test you feel appropriate here to help you identify why you have created this custom field. For this one a suggestion would be to add ‘Created to support bulk archiving of computers in Snow process. This adds a field against each computer in Snow with the ‘Archive’ yes or no option which can be updated manually one PC at a time or via a bulk import’.
  • Next add a check to the Mandatory field to enable it to be a mandatory item against each computer.
  • The last field provides you the option of choosing ‘Yes’ or ‘No’ for the default. In this case, it will be ‘No’ by default as the option. As we only want to add ‘Yes’ to the machines we want to archive.

Step 2 -Create Import Template

Create the excel import template – this is a simple two columns excel file using machine name and the custom field [Archive].

See sample below:

Step 3 – Create list of machines

Add the list of machines to the template – Insert all the machine names in the Computer name column and add the word Yes to the ‘[Archive]’ column.

See sample below:

Save this file with a unique name for audit purposes in the Archived computers folder with a date relevant to the date you are archiving the machines.

Don’t over write the template!

Step 4 – Start the Import

Start the import process.

  • go to [Home]--> [Import Data] and choose ‘Update Existing Computers’ option.

  • Then browse for the saved Archived computers list in the Archived computers folder you saved earlier as per step 3

  • Click Next

Since we are importing an update to existing computers, in Step 2 of 5 of the import process ensure that for the ‘New Organisation Action’ selection is set to ‘Do Nothing’ and that the ‘Obsolete computer action’ is also set to ‘Do nothing’

In the next stage, you will be asked to confirm the Field mappings and as there are only 2 fields that we are importing against i.e. ‘Computer Name’ and ‘[Archive]’ Snow will want to ensure that it maps correctly for the import so this stage will allow you to correct any Mapping errors.

In the screenshot below you will see what should happen at this stage of the process and how the fields should look.

The options – ‘Trim leading or trailing white space’ is for ensuring that you are not importing any whitespace as this will affect the way Snow locates the relevant computers you are trying to update so if you have copied the data into excel and there are potentially white spaces in the text then select this option to ensure better results and avoid repeating the process.

The option ‘Map by Index’ can be ignored but ensure there is no check in the box then click next

  • Click Next.

The 4th stage of this import process will provide you a chance to preview and validate that the data you are importing and updating against will work and if any errors are identified i.e. if the computer name you are trying to update in Snow through this import is not found in the Snow computers list, then it will show up as an error at this point.

See example below:

If errors do exist, then you can take a note of these now and complete the import process and deal with the errors separately or cancel the import and correct the problems then start the import process again.

To do this you will need to export the exceptions/errors – click on the export invalid rows option and save the resultant excel file in the same location as the archive computers list so that you can deal with them as a separate task if required.

Example below

Once you have exported any exceptions, clicking next will provide a warning screen asking if you would like to continue excluding the exceptions. If not, then click cancel and go back to the beginning of the import process once you have resolved the exceptions.

Sometimes the machines with the errors are not identified in Snow as they may have been archived already or they just don’t exist in Snow at all. Check these exceptions and if you are happy to proceed then continue with the import process.

  • Click next and complete the import –

In this example, we have only imported against 1 machine so the completed import will show you in this case ‘1 row imported successfully’.

If in your import, you have multiple lines to import and there are errors then it will show you this along with the number of rows that encountered errors.

See screenshot below:

  • Click Finish.

Step 5 - Validate

To validate the list of computers to be archive and that your import/update was a success:

  • Click on ‘Computers’ --> ‘List all computers’.

  • Next use column selector to add the custom field you created called ‘Archive’.

  • Drag the ‘Archive’ field so that it slots in next to the ‘computer name’ field.
  • Next - use the drop down in the ‘Archive’ field column and choose ‘Yes’, this will then list all the machines you have updated with the custom field option to ‘Yes’ – The result will list only the machines you have chosen to archive.

At this point you can validate that the list of machines you have updated through your import matches that of the original import list. Once you are confident that they match you can move to step 6 which is where you can go ahead and archive the computers.

Step 6 - Archive

Now you need to perform the bulk archive – so select all the computers in this list, ensuring that you ONLY select the machines that have a ‘Yes’ against them in the Archive column.

  • Then choose the option next to the column selector and select ‘Edit computers’

Then you can add notes to the notes section

It is important now that you choose Archive and not delete the reason being is that Archiving takes a Snapshot of the machines prior to deletion and deletion does not. This enables an audit trail to exist and allows you to track the life-cycle of the machines, its users and the applications installed etc.

Once you select Archive, Snow will ask you to confirm. At this point if there is any doubt you can back out and check off any doubt or simply go ahead and confirm the Archiving of the selected machines. Once a machine is Archived it cannot be un-archived you should simply wait until the computer is reconnected to the network and scanned again with a Snow inventory agent and that would then add that same machine name back into the Snow DB and then just repeat the process if necessary to archive it again if that were the requirement.

This will now be the end of the Bulk archiving process steps.

You can check in the ‘Archived Computers Report’ located in the ‘Standard Reports’ section of Snow License Manager to confirm that your computers have been successfully archived.



Snow Integration Connectors (SIC) can automatically consolidate audit data from multiple inventory tools into a single view of all software and hardware assets from across the network and beyond.  


All audit data imported through a Snow Connector is automatically processed through the Snow Software Recognition Service to ensure the accuracy of software titles, versions and more.  


In some cases, there are limited requirements, or customers are using a 3rd party tool / ITSM / Helpdesk, where Snow does not have a standard connector to date. In this scenario Snow offers a generic file and database inventory connector or bespoke integration options.


One scenario I am often asked by customers is, that they have a 3rd party tool in place and are looking into capabilities of visualising normalised data that’s been gathered by Snow in a tool they have already heavily invested in.


From a tool perspective, Snow has a few options available to customer using the tool.

  • Calling the Snow API to return specific data;
  • Utilising the Stock Reports within Snow License Manager and exporting these on a schedule for import into a 3rd party tool;
  • For those on-premise customers, from within the Snow Inventory console, exporting reports containing un-sanitised / ”raw” data

Where there is a need for specific data to be exported in a set format or data from more than one report this is where the above measures become redundant.



Why implement a 3rd party connector?

Snow can provide ITSM solutions and 3rd party tool integrations, with the valuable SAM intelligence required to both maximize the efficiency of a service desk function and ensure high user productivity.  

In a service desk function, clean and accurate data from Snow License Manager can be used to help: 

  • Accelerate problem resolution by providing accurate and normalised software data, including vendor name, title, version number and patch level
  • Facilitate new software deployments by confirming if the organisation holds appropriate licenses to fulfil requests;
  • Support change management processes by identifying software and hardware that does not comply with standards, or requires upgrading


Combining the power of Snow’s SAM platform with service management solutions provides organisations with a complete and integrated solution for managing software and hardware use across the network.  




FOCUS: Snow License Manager / Snow inventory data visible in 3rd party tool


Business requirement

IT Support Desk receives calls from users detailing an issue. The IT Support Desk analyst needs to know further information about that users machine such as RAM, what processor they are using.


Despite providing instructions for the end user to provide this information, this is either “lost in translation” and the end user is unable to supply this OR they take so long to gather the requested information the ticket site unresolved for weeks.



The customer alongside Snow Services individuals undertake conversations that identify what information should be displayed in the 3rd party tool from Snow combined with any other sources.


This is translated into a project with a solution design being created detailing the data flow and requirements.


Currently the 3rd party tool is an unknown tool and no official Snow connector exists. In this case, Snow would create a series of scripts and configuration to collate the data reports into an export(s) ready for the customer to configure their tool to import in this data.


Pre-deployment, there will be several development and rigorous test cycles undertaken on local Snow environments that are similar in size / complexity to the customers to ensure the solution stands up within the end customer environment.


During the deployment into the customer environment, subject to the specifics of the project, scripts and configuration are deployed and the end to end solution is tested.


Detailed technical documentation is provided to cover the specific integration project.

Project is handed over to the customer for any outstanding actions and signed off.


A further example of some of the project that have been scoped is where information from an external source is imported into Snow License Manager.


FOCUS: 3rd party tool outputs enrich Snow License Manager content


Business requirement

HR system contains information relating to individual’s department service desk queue owners

This information needs to be cross referenced to a static list of teams to service desk queue owners held locally which is looked up based on a code held within an existing custom field ‘Desk Queue’ along with other information.



               Example of ‘Desk Queue’ contents



            Example of customer supplied spreadsheet with team number to match to ‘Desk Queue’



This information cannot be extracted via API calls but can be exported manually from the system once a month as a .csv file.


Information cannot be pulled out the system as a list detailing which user belongs to which service desk queue owners, but a field associated to each user that contains desk queue code + department name can be cross referenced against a team list.


The team will utilise Snow License Manager Web Configurator functionality to import a spreadsheet detailing each user and the Team number which populates into a custom field called


The first two/three characters of the custom field ‘Desk Queue’ is to be used to join to the customer supplied spreadsheet on the “Team Number” field with the service desk queue owners being populated from the lookup below.


This queue owner is updated within a custom field ‘Queue Owner’ as seen below.




In summary, the below flow diagrams highlight what is considered as part of any scoping when importing or exporting from Snow or a 3rd party tool


  3rd party tool export for import into Snow


Snow export for import into 3rd party tool




To ensure a successful integration, the scenario is fully scoped out with each customer so all elements of the solution are considered and tested before implementation into a live environment. 


Please contact your local Account Manager for further information regarding custom integrations.

Hi comminuty,


This days have appeared new ideas in the Snow Ideas Board .


I've seen one that demand the functionality to share Snow boards in the same way we can do for Reports (see Sharing Snowboards)


I received this request from one customers, so I temporally applied the following workaroud:


Go to the SnowLicenseManager.dbo.tblSnowboard table and execute the following sentence:


FROM [SnowLicenseManager].[dbo].[tblSnowboard]

Where CID = <CustomerCID>



Document the original UserID assigned for the SnowBoard you want to share (in the example 1. This will required to restore the previos state if you need to modify the Snowboard again), and take the SnowboardD that identify you Snowboard from the result list, and execute the following sentence:


Update [SnowLicenseManager].[dbo].[tblSnowboard]
set UserID=0
Where SnowboardID ='6ED76EA3-7875-4238-963F-0E4F40096F30'


The UserID=0 means that the SnowBoard will be shown for all users.

NOTE: The known limitation after apply this workaround is that you'll need to assign the UserID to the previous UserID if you want to edit it again. 


Hope this help meanwhile.




Hi community,


Some of our partners and customers are suffering the consequences of their IT governance policies that allow final users having administrative privileges.


This is a regular practice at consulting companies. For example: the consultants roles, especially IT Consultants, need extra privileges to install additional applications when they're assigned in a customer case, service or project.


Ok, we've got two problems here:

  • The first one, is that some people from our company have applications from the customer side, and some times this means a compliance risk.
  • And the other one is directly related with a security risk: the users can install applications on demand, non approved by IT department, or even uninstall applications.


Yes, I know you know that SLM offers differents ways to report this risks, like Black Listed Applications or Compliance summary report.


But, what happen when a user uninstall the Snow Agent?

Or what happen when a user delete some support scripts from the Snow Agent folder?

How can I identify users with admin privileges?


For the Snow Agent uninstallation issue, you can use ootb reports to list the status of the reported computers.
If a computer that you know that is alive is moved to quarentine pool, you must start to investigate. Some computer might have connectivity issues (ports, firewall blocking, etc), but this uses to affect massively to your computers (VLANs, Sites, etc)

NOTE: You can take a look of this post, discussing about how to hide the Snow Inventory Agent application from the Control Panel - Add / remove programs section

Windows agent 5.x.x - hide from add/remove programms


To identify if a user has deleted support files or not, we've been working with a customer to create a custom report to show exceuted PS scritps during the agent scan. This could be usefull to determine is some of those scripts are failing or ara missing from the agent side.
This is the result:


In same way, we've defined also a report and a signed PS script to collect local users and groups info from the computer.
This is the result:


So, if you find yourself suffering this issues, don't hesitate to contact your local Snow representative to support you with this.



Hi community,


Continuing the "How to" series (started with the How to: Using Snow Inventory Agent to collect registry values post), it's time to show you how to consume the collected info.


First, let see the result from SLM UI

Ok, lets see the report definition:


DECLARE @NAME NVARCHAR(MAX) = 'Customer Custom Registry Info'

DECLARE @uid uniqueidentifier = (SELECT NEWID())

DECLARE @Description NVARCHAR(MAX) = 'Report on Custom Registry Info'

DECLARE @ColumnList NVARCHAR(MAX) = 'ComputerID,HostName,Domain,Hierarchy,LastScanDate,LastModified,Contact,InstallDate,RegistryKey,Name,LastModifiedBy,Version'

DECLARE @ColVis NVARCHAR(MAX) = '-1,1,1,1,1,1,1,1,1,1,1,1'

DECLARE @KeyFieldName NVARCHAR(MAX) = 'ComputerID'

DECLARE @RowTargetLink NVARCHAR(MAX) = 'Computer.aspx?id='



DISTINCT tc.ComputerID as [ComputerID],

tc.HostName as [HostName],

tc.Domain as [Domain],

tco.Hierarchy as [Hierarchy],

tc.LastScanDate as [LastScanDate],

LastModified as [LastModified],

Contact as [Contact],

InstallDate as [InstallDate],

piv.KeyName as [RegistryKey],

Name as [Name],

LastModifiedBy as [LastModifiedBy],

Version as [Version]









tblComputerRegistry tcr


tcr.KeyName = ''HKEY_LOCAL_MACHINE\SOFTWARE\CustomerCustomInfo\MasterImage''

and tcr.CID = {0}

) src




for [VaHope lueName] in ([Contact],[InstallDate],[LastModified],[Name],[LastModifiedBy],[Version])

) piv

INNER JOIN tblComputer tc

ON tc.ComputerID = piv.ComputerId

LEFT JOIN tblComputerInfo tci

ON tci.ComputerID = tc.ComputerID

INNER JOIN tblsystemuserorgdefinition def

ON def.cid = tc.cid

AND def.userid = {1}

AND def.orgchecksum = tci.orgchecksum

LEFT JOIN tblOrganization tco

ON tco.OrgChecksum = tci.OrgChecksum

WHERE tc.cid = {0}

ORDER BY Hostname, RegistryKey desc'


DELETE from tblReport

Where Name like @NAME


INSERT INTO tblReport (ReportID, StockReport, IsCustomReport, ReportType, ViewName,

Name, Description, SQLQuery, ColumnList, ColumnVisibility, KeyFieldName, RowTargetLink)

VALUES (@uid, 0, 1, 1 , 'QUERYBUILDER', @NAME, @Description, @SQL, @ColumnList, @ColVis, @KeyFieldName, @RowTargetLink)


According to the the structure of the registry info:

we need to get the registry values for the registry path HKEY_LOCAL_MACHINE\SOFTWARE\CustomerCustomInfo\MasterImage.


This is done with the filtering in conjunction with pivot statement:


tcr.KeyName = ''HKEY_LOCAL_MACHINE\SOFTWARE\CustomerCustomInfo\MasterImage''

and tcr.CID = {0}

) src




for [ValueName] in ([Contact],[InstallDate],[LastModified],[Name],[LastModifiedBy],[Version])

) piv


NOTE: You can see a detailed how to create SQL Reports in SLM in this post Adding custom SQL reports in Snow License Manager from my colleague mark.potts.


Done! You just created a custom report to show collected registry values during the Snow Inventory scan!


Hope you'll find this usefull. See you on the next "How to" post!




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.