Skip navigation
All Places > Snow Product Hub > General Licensing Forums > Blog > Author: mark.lillywhite

Snow has always had two places to store the cost of an application and they are traditionally used for different reasons. The behaviour of this functionality recently changed – this article explains the current functionality and the recent change.


  1. Application Cost

    This is the cost to be used in any Risk, or Cost saving reports and the financial info tab for a computer (used in cost per business area / TCO type reports). It is entered by editing the application, and is easy to bulk upload prices for many applications as desired.

  2. License Cost

    This will be the Purchase price of the license divided by the number of actual licenses – in the example below the cost is £10 per installation.

  3. Financial Info

    This tab shows the cost of the Hardware and the application costs of any software on that hardware (see below)

    These values can be reported in the 'Potential Cost Savings' report, and also the 'Cost of Unused Applications per Computer' report.

    It is important to note that in versions of SLM between 8 and 9.1, if there was a license cost AND an Application cost for an application, the license cost would always win. This had one unfortunate side effect: If the license cost was Zero, it would override any application cost – showing risks as zero, and savings as Zero (if you had a license entered).

    As of SLM 9.2 there has been a change:

    If the license cost is zero, Snow uses the application cost. If the license cost has a value, Snow will use that value an ignore Application cost. In the screenshot below Application cost is £140, license cost is zero.

    In the screenshot below license cost per install is £10 and application cost is still £140

This means in the Family View Risk is shown at the license value - £10

Where as without a license cost, the Risk is shown using the application cost ONLY

Note: Snow will average the license cost per installation if there are many licenses but with different prices.
In the example below we have two licenses at different prices (£300 & £500)

meaning the License average is £400 per install in this case.

Since the beginning of time, Windows operating systems have had a major version and edition, and then various updates. Originally Service Packs, but since Windows 10/2016 its been version numbers.

Now Snow always used to report on Service Packs, but since version numbers have been used, Snow Inventory would pick these up, but there was no report in Snow License Manager. This is now fixed - you can access version numbers in the Operating Systems Report:

And also in the computers tab within the OS Application

So why is this interesting? Older Windows 10 and 2016 builds are going End of Service, and as such need to be updated - 1607 and earlier are already End of Service.

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

Snow gathers its deployed software information in the following ways:



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

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

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



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

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


Raw Inventory Data

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


Pre-Recognised Data

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

A screenshot of ‘IsRecognised’ data is shown below:




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




For raw data the SRS must receive as a minimum:


Executable name

Publisher name

Executable version

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



For Pre-recognised data SRS requires:


Software Name

Publisher Name

Software version



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






Unofficial Snow data sources vary enormously. For example, Tanium out of the box does not provide Software Publisher, which puts the recognition at about 10%. Using the Tanium Asset module (which provides .exe information instead of add/remove programs) and the recognition jumps to around 75%. Likewise, Splunk can provide good recognised data for a good level of recognition, if it queries the right registry keys.


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



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


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



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

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

Change agent settings

Start a command prompt as admin (windows – type ‘cmd’ and then right click and select ‘run as administrator’)

To change settings:

  1. Type notepad
  2. Open the following file – C:\Program Files\Snow Software\Inventory\Agent\snowagent.config
  3. Edit the entry e.g. ‘<Address> so it reads:
  4. <Address></Address>
  5. Save snowagent.config



Stop and start the snow agent for it to pick up the new settings by:


  1. Change directory in the CMD prompt to ‘C:\Program Files\Snow Software\Inventory\Agent’
  2. snowagent stop
  3. snowagent start
  4. Manually initiate a scan with ‘snowagent scan’
  5. Transmit the scan file to the snow server using ‘Snowagent send’


Check the C:\Program Files\Snow Software\Inventory\Agent\data  folder for any .snowpack files - if the scan and send were successful no .snowpack files should be present.

In the event that .snowpack files remain, check the snowagent.log in the same folder for details of any error.


Increase Logging


edit the following snowagent.config  setting:





Set it to






Don’t forget to stop and start the agent. You could also set verbose

 With the latest 3.1 Snow for ServiceNow connector certain items have changed.

There is no longer a manual XML update Set needed – the transform maps are created automatically.


As Per the Snow for ServiceNow documentation (User Guide – Installation and configuration v3.1)

  1. You must request the Snow for ServiceNow connector through the ServiceNow Store.
  2. Snow will receive your request, and check your entitlement and approve.
  3. The Snow Software Catalogue and CMDB Integrations are then available WITHIN ServiceNow after this approval.

Important Note: This is not available in the free developer instance – only in Sandbox, Test or Prod instances of ServiceNow - Jakarta and above.

As per the documentation, you will need to set up the Snow SIM 5.8 or higher to talk to the SLM API

For detailed information, search in ServiceNow for

Snow Software Catalog Integration

Snow Software CMDB Integration


For details of the Transform Map used, see ‘Transform Map’ under the relevant integration



And then click on the relevant Table Transform Map to understand the detailed field mappings



License Balance Lookup

In order to enable the License Balance lookup, you will need to configure your Software Request to call into Snow in Realtime via the API, to check the balance of that Software Title.


Building Software Requests in ServiceNow is beyond the scope of this document (its covered in the Snow for ServiceNow Installation and Configuration Guide v3.1), but the License balance lookup is included as part of the Snow Software Catalog Integration.

To locate it: Search for ‘script includes’ – scroll down to ‘System Definition’ and select ‘Script Includes’


Search and Select ‘SnowLicenseManagerAjax’ – the Snow API lookup code is shown.

This should be integrated into the Software Approval Step

SCCM Data - a good start:

Using the SCCM agent as an inventory source has merit, since the data it has gathered can be imported into Snow very quickly to gain visibility of much of the deployed, licensed software and hardware in the estate.

To accelerate SCCM and Snow working together, Snow has developed an automated import system that uses a pre-defined schedule to collect the source data from SCCM, which is then automatically processed through the Software Recognition Service (SRS) with no need for manual intervention. Snows Software Recognition service cleanses the millions of executables into a straightforward list of software titles, and whether they require a license or not.

There are advantages to this approach:

  1. Getting a ‘quick and dirty’ view on deployed software in the estate is sometimes necessary, especially if deadlines are tight. It is possible to get a snapshot of deployed licensed software within 24 hours (assuming the SCCM agents are comprehensively deployed and functioning). This then gives the benefit of Snows’ Software Recognition Service, and its easy to use Reporting, to gain visibility.
  2. The change control process in the datacentre to add the snow agent can often take weeks – and if SCCM is already deployed, a feed from SCCM is far better than no data at all.
  3. Because the SCCM agent provides the data, there is no need to deploy a further agent – useful if other teams (or outsouced teams) outside the control of the SAM sponsor need to be engaged.

However there are also problems. The main issues with SCCM data are:


Detailed Usage Information:

Whilst it is possible to configure SCCM to track windows application usage, it has to be configured by an SCCM admin for individual applications, with expert technical knowledge of what executable is relevant for what application. In practise this introduces a large administrative overhead on the SCCM team, meaning it is seldom kept up to date. Also SCCM metering for MACs does not exist.

Correct identification of Suites

The Snow agent uses proprietary techniques to correctly identify certain suites, bundles and editions of software. In particular SQL Editions, Quest products (e.g. Toad), Adobe and Autodesk products all have basic or incorrect identification if the primary inventory source is SCCM. Snow is able to accurately identify these products, as well as ISO 19770-2 software tags (as used by Adobe, Symantec and certain other vendors), to produce the most accurate inventory available.

Remote Desktop (Citrix) and VDI recognition

When software is accessed via Remote Desktop Services (or similar technologies like Terminal Services or Citrix) it causes different licensing rules to apply. The SCCM agent is simply unable to identify which users, and from which devices a remote application was accessed from. This means no secondary use rights can be assigned and indeed the calculated position will be grossly overestimated or underestimated – meaning significant financial risk or overspend.

Operating Systems other than Windows

Whilst SCCM 2012 now has MAC & LINUX agents, they are rarely deployed, and provide extremely limited information. In addition, there is NO UNIX or Thin Client information (essential for compliance around ORACLE, Citrix (or Remote Desktop Services) and VDI.

SAAS and Web Application Tracking

Many applications are web based (e.g. Salesforce, ServiceNow) that require tracking for compliance or optimisation purposes – even Sharepoint comes with different CAL’s (Enterprise and Standard) driving a need to understand which Sharepoint Servers are servicing users with the wrong CAL. SCCM is unable to track this, whilst the Snow agent uses its constantly updated Software recognition service to define and report on the top 500 SAAS applications.


SCCM agent performance

The SCCM agent in standard configuration consumes a reasonable amount of bandwidth. When configured for full Software Scans, it can severely impact the device being scanned for several minutes, and generate upwards of 800 Kb of data. Across a large estate, with a weekly scan this can be a worrying burden – most SCCM implementation’s therefore do not use the software scan and instead rely on the hardware scan (which contains add/remove program information). Contrast this to the Snow agent which uses proprietary techniques to scan a desktop or server in around 30 seconds, producing around 50Kb of data. The Snow agent and the SCCM agent together will consume less resources then the SCCM agent alone configured for Software Scans.


App-V, ThinApp, App-J recognition

App-V is commonly deployed to both physical desktops, as well as virtual desktops & published desktops. SCCM cannot identify which users have accessed App-V based applications in a virtual environment, meaning an all or nothing approach must be adopted when performing license calculations. The Snow agent has specifically had technology added to identify both what a user accesses, as well as the app-v packages that user has access to.



SCCM as an inventory source is basic, but readily available. It can be used together with the Software Recognition Service for a quick view of most deployed, licensed software on the desktop estate. There will be gaps (e.g. certain suites) but being able to see something quickly may outweigh other considerations.

 When using SCCM to Supply Server information, there are more severe limitations, especially when a virtualised Server estate is in question, but again something is better than nothing.

 Remotely accessed Applications, Mobile Device Software and comprehensive & complete usage information is simply not possible with SCCM.

Blacklisting software is one of the 'bonus' features that comes courtesy of Snow's extensive recognition database. Even the best IT Security teams often dont have the time to figure out which .exe's are good and which are harmful. 

The question though is what to define in your blacklist. The obvious ones are which snow constantly keeps up to date are:

'Games%' Games are mostly bad - especially as users need admin rights to install
'Malware -%'notice the hyphen - otherwise Malware Bytes shows up which is good!
'Filesharing%'As Filesharing apps keep morphing, this is a really good one since ongoing SRS research keeps it up to date
'Poker%'Nuff sed - Games and Gambling together???


Recently we've started finding other applications - I've included a link so you can research at your leisure


Reason its bad 
'Tor Browser' For surfing the Dark Web - If you dont know read the following
'TunnelBear'Its a free VPN product that hides your IP Address - typically used so you can stream video from other countries...
'CCleaner 5'Recently proved as hacked -
'Mic Tray Icon 1'

This has the capability to be a key logger -

In the Application Types Categorisation in Snow, there is a 'Keylogger' category - Good to know 


These are applications typically launched from a USB key. This means Admin rights are not needed - could be legitimate or not legitimate use - if its a game it probably not legitamate. If you see Wireshark (Packet sniffer) being used via PortableApps, check the user - are they a Network admin (legitimate) or an ordinary user (in which case why are they being sniffed?)


Moves the mouse every few seconds if you are not at your desk. Stops screensavers activating, and as a colleague pointed out, makes your Skype status look active when you are actually having a kip

Zenmap (Nmap)

A network scanning tool that has several password cracking add-ons. Great if you are IT security making sure things are secure - not so good if its being used by others....


If you've any more that you look for, comment below - We're constantly researching more and happy to hear of new bad things.

Looking at the Snow usage for Google Chrome below, it seems impossible that after only a few days you could have run Chrome so many times.

The reason is Chrome itself runs several processes - one for each tab as well as plugins - read this if you're interested. Thus Snow will count every process, every day as a ‘run’ - hence why the count is much higher than than other applications.