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

General Licensing Forums

74 posts

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.


Compliance exclusions

Posted by ana.marquez Employee Apr 29, 2019

This is one of four blog posts related to features in SLM 9.2.0 release.

A capability for all SAM programs is being able to provide an accurate license position and financial risk exposure to the organisation for key software manufacturers. This is complicated in general, however a crucial challenge is being able to account for the exceptions and exclusions that many manufactures have within their licensing rules. This results in the need to manually adjust compliance figures each time the organisation needs to know what their license position is, and the risk associated. This quickly becomes almost unmanageable in large organisations. Even just documenting and calculating which computers are being excluded and why is a huge task.


The SAM development team at Snow have been investigating how we can help resolve this, engaging with SAM specialists from around the globe, coming to a solution that allows our users to manage these scenarios with ease. The new feature, compliance exclusions, allows a SAM manager to document these license scenarios and tell the Snow platform which applications should be excluded, from what computers. This allows Snow to remove the license requirement from computers with those applications, impacting compliance and therefore the risk and cost reported.

This is done through the creation of exclusion rules, where a SAM manager can either manually or dynamically select which applications and computers should be included in the rule, as well as a name and description of which licensing rule this is related to. They can also see which platform user created the rule, when and who last updated it, and detailed reporting on the results of all of the rules that have been added.


To give you a taste, below is a detailed example of how this feature can be used to help solve Microsoft MSDN licensing. As always, get in touch or comment on this post with questions.


In many organisations purchasing Microsoft software, a number of employees and their devices are licensed for non-production use through MSDN licensing. In some cases, the SAM team might not need to track the spend on MSDN licensing, however they do need to remove the license requirements created by computers and servers dedicated to non-production use from the rest of their Microsoft licensing.

To account for this scenario in our compliance calculation, see the example below using the exclusions feature:


Navigate to the Administration section and then select Compliance Exclusions

Select "Add exclusion":

Enter a name and description - in this example we enter in some information related to how we are using this rule to help with MSDN licensing:

Select applications to be included in this exclusion rule either manually or by adding a dynamic criteria - in this case we add all of the applications that are created by Microsoft and filtered out any Office 365 applications to keep the example simple - however you could target specific application families, or specific apps, or even exclude some applications. With this criteria it means that any new Microsoft application that gets released will be included automatically:

Select computers to be included in this exclusion rule either manually or by adding a dynamic criteria - in this case we target all computer whose hostname contains the naming convention "dev", allowing us to automatically apply this to new hosts that are added with that convention. Whilst this is a simple example, the complexity of the criteria can match the complexity of your environment:

View a summary of all the computers and applications that will now have their license requirement removed when the rule is active is shown:

When hitting save we are prompted to active the rule if we are ready for it to impact compliance:

Now the rule is active, you can see how it is impacting compliance on the computer details page of computer with excluded applications:

And see its impact on the overall compliance of one of the excluded applications on the applications detail page:


As always, if you have any questions feel free to post in the comments section or reach out to me directly.

I've had recently a couple of requests about Security information in Snow.

After providing the specific user guides and getting a good feedback about their content (no doubts about it! ), I thought they could be useful for the SnowGlobe community too.

Below you can find the direct permalinks, so you can reach the documents easily without searching in the full Knowledge Base.


Technical Description: Security Considerations in Snow License Manager 9


Technical Description: Security Considerations for Snow Analytics


Technical Description: Security in Snow Inventory for Snow Inventory 5


Technical Description: Security Considerations for Snow Inventory 6


User Guide: Federated authentication with SAML for Snow License Manager 9


User Guide: Federated Authentication with SAML - Update revision 8.3


I hope you find them useful!


Snow Agent Monitoring

Posted by aaron.fryer Employee Apr 6, 2019

Snow Agent Monitoring


DOCUMENT DATE            21/03/2019
AUTHOR                              AARON FRYER


This document will provide some best practice processes and tips to monitor the behaviour of the Snow Agent.



- Snow Inventory 5.x / 6.x

- Procdump tool
Download here -

- Windows Debugging tool


Using the procdump tool


- Download and install the procdump program
- Extract the contents to C:\Temp
- Run command prompt as an administrator
- Browse to the directory C:\Temp via command prompt

Collect a memory dump file based on high CPU usage

The "-c [%value]" argument specifies the CPU usage threshold after which a memory dump file should be collected.

The "-c" argument is usually combined with the following ones:

"-s [secs]" – specifies how long the CPU usage should remain at a specified level for a memory dump file to be collected. The default value is 10 seconds.

"-u" – specifies the CPU usage of any particular processor core to be tracked, comparing the average CPU usage of all the cores.




Collect a memory dump file based on high memory usage

The "-m [MBs]" argument can be used to specify memory usage threshold after which a memory dump file should be collected.

Example. Collect a memory dump file if the process memory usage is larger than 500 MB.

Once there is a successful dump of the application that’s being monitored, you’ll find a .dmp file placed in the directory.

To view the dump file, you’ll require the Windows Debugging tool


Snow Agent Logging

The snow agent logs can be viewed remotely from the Snow Inventory console using the below method in the SMACC.

- Browse to device
- Double click the device to open the settings
- Browse to log file in the navigation pane



It can be useful to change the log level of the agent to give you more visibility on the errors you may be facing when troubleshooting the snow agent.

To do this, you’ll need to browse to the directory C:\Program Files\Snow Software\Inventory\Agent and open the snowagent.config file

It’s recommended to use notepad++ when opening this file to make editing easier and more clear.

On line 72 change the log level to verbose and on line 73 the MaxSize setting to 10000. Below is an example of what you should see in the snowagent.config file once these changes have been made. Once done, save and close the file and stop and start the Snow Inventory Agent service.





Snow Active Directory Discovery

DOCUMENT DATE            14/03/2019
AUTHOR                              AARON FRYER

This document will walk you through how to enable Active Directory Discovery for Snow Inventory.



- Snow Inventory 5.x / 6.x

- An Active Directory user account which is a member of the domain users group.



Login to the Snow Inventory Server and open the SMACC Console. Browse to Inventory Servers and click the show details option to be directed to the next page.


On this page, you’ll need to click edit

You’ll now be presented with this menu, tick the box to enable Active Directory Discovery, this setting will start searching for machines in your domain once enabled and saved.


Click the Add option and you’ll see a list of options as below. Fill out the options below and click add and then save.


To enable User Discovery options, complete the same process and hit save once done.

Hello SnowGlobe,

we often receive requests about or minimum requirements to build a well structured and sized Snow environment, such as operating system, database, disk space, memory, etc.

We have created a System Requirements document that is constantly kept updated by our R&D team.


This is the permalink, so R&D will always post here the most recent version: 

Snow System Requirements - System requirements for all Snow products


Add it to your bookmarks!

Hej alla,

Det finns ett fåtal platser kvar på våra utbildningar nu i april på vårat huvudkontor i Solna Business Park,
se till att säkra din plats i dag!

Utbildningarna är:


Är ni intresserade av andra kursdatum eller kurser i Norden kolla in denna länk: Kurser i Norden 2019

För andra tillgängliga platser i världen kolla in denna länk: All Snow utbildning


Vid frågor kontakta oss på



Hej hej, SnowGlobe!

I'm glad to inform you that we still have some few places available in our courses in April 2019 held in our HQ in Solna Business Park (Sweden).

The courses are:


If you are interested in other courses available in the Nordics region, please check this link: Courses in Nordics area 
For other available locations all around the world, please check this link All Snow Training


If you have any questions, reach us at


You're wecolme!

Background: you want to exclude specific software installations on specific computers from the compliance calculation in your Snow License Manager. This could have multiple reasons and has been solved in different ways in the past and/or still for some special cases.


Previous challenges and solution:
MSDN: licensing of multiple test systems, where only specific Microsoft products could be covered.
OEM licenses connected to the relevant hardware.
Terminal servers: some software manufacturers, including Microsoft, allow their software to be installed on terminal servers, but these are not counted towards a compliance, rather the devices under TS- applications.
Training environments: some software manufacturers, including Microsoft, give the right to use a limited number of computers with their software for free under certain agreements.
All other software products that might cover more than two installations where there might be no direct technical linkages to secondary use rights or other use rights.
The main solution is implemented by moving the relevant computers to a dummy organizational unit, and then adding dummy site licenses to these to cover all of the relevant software installations.


The following example will show how one software application will be removed from the compliance calculation in Snow License Manager.

Step 1: find the application that needs to be adjusted and check the current compliance. 


Step 2: if you have administrative rights in Snow, go to the “Administration” page and click on “Compliance exclusions”.

Step 3: click on “Add exclusion” to start defining the compliance exclusions.


Step 4: enter the rule name and reason. The “Active” checkbox can only be used later or set in the last step.

Step 5: search for the identified application as in Step 1 and mark the checkbox to fill the right-side column. In this right-side column you can delete wrong applications by clicking on the small cross or “Clear list”.

Step 6: search for the computers or use the “Filter with installations” functionality. Mark the required computers in the results list and you can delete computers from the right-side column by clicking on the small cross or remove all with “Clear list”.

Step 7: after these steps please click “Save” at the bottom right side of the window.


Step 8: as mentioned in Step 4, you are asked if your settings should be activated. If your settings are correct, please click on “Yes” to activate the rule.

Step 9: your rule will then be added to the list of all rules and can be edited from here in future or deleted by clicking the small cross on the right side of each rule. More rules can be added here by clicking on “Add exclusion”.

Step 10: after adding/editing any rule, please ensure that you start a compliance recalculation before looking for any changes. This menu item can be found under your user name in the top right hand corner.


Step 11: open the application(s) that you are working on and see how many computers have been manually excluded from the compliance calculation.

Please note that this is a new feature and might change over time.

This article relates to a real-world case – the customer’s name has been omitted.

The issues raised were all relate to the UNIX Snow Agent. The customer needed Oracle scanning, so the SIOS.jar process was running with the standard snowagent.jar scan. Before we begin, we must remember that:


  • We strongly recommend Java Runtime Environment (JRE) version 1.8 is used. 1.6 is the oldest version supported, but performance is best on 1.8 or above.
  • NFS (Network File System) mounts are rather common place on UNIX boxes – essentially, these are remote directories, much like network drives on Windows.


Mounting Issues and Troublesome Runtimes

The customer came to us reporting that the UNIX agent was taking too long to complete the scan and the Oracle scan. Why was this?

Two main reasons – the UNIX boxes in question were using JRE 1.6 and there was also a large amount of NFS mounts that the agent was trying to scan every time. This could have resulted in many, many more GBs of data being scanned, across the network, unintentionally.

The issue with the NFS mounts was easily resolved by looking at the snowagent.config file and adding exclusions for those mounts:



Next came the issue of the Java runtime – the system JRE was version 1.6, which is supported, but it is recommended to use 1.8 – which is precisely what we did.

The problem is, it was not desirable to upgrade the system JRE on all the UNIX boxes. The solution, therefore, was to specify our own JRE that the agent can use.

First, the version 1.8 JRE was placed in the agent directory - /opt/snow.



Next, the snowagent.config file is modified:



The value highlighted here can be modified to point to a specific Java Runtime.

Problem solved – almost. The crontab also needs to be changed. The crontab is how UNIX\Linux devices schedule processes. Crontab, by default, looks like this:



The crontab line as shown above was changed:




This troubleshooting and resolution method provided a fix for this customer’s particular “pain points” without the need for any down time for major changes to their platform.


Developing Ideas

Posted by ester.memoli Employee Mar 22, 2019

May 2019 Update: many of the Ideas mentioned in this article have been developed. Please consider the list as outdated. Anyway the Ideas page, the Search method and the hints are still valid.

Our tireless R&D team works every day to develop improvements, updates, fixes and new features for all Snow applications. Did you know they also evaluate and take in consideration the ideas coming from customers, partners and even Snow employees from all departments?

This is done throught the Ideas Portal, available here in the community at the following link: Snow Ideas Board


An example of all the Ideas currently (March 2019) in development:



Bulk delete computers from the Inventory SMACC
New MS chassis types to Inventory
Excluding autofs filessystems/ NFS mounts from agent scanning

Disable Auto/Dynamic Search Feature
Open/Known Problem Database

Change Snow Products main Icon



Show install path in reports
Additional Columns for report Applications per computer
License ID Field Needed in All Licenses Report
Add "Installed" to "Applications per computer" report

Color uninstalled applications in report same as on Desktop
Add the period to the report "All licenses"

Enhanced Reporting Feature Request for Applications by Computer Report (Historic Metering)

Add hypervisor detection to report "Computers that are not inventoried"

Report Showing All Computers Per User

Add Processors & Total cores to the column selector in All Computers report

Add the ability to add (custom) fields to the compliance summary report



List of available detection scripts

Publish release details for detection scripts


Version and Edition Index in Licence compliance per organisation

Add Custom Compare Value name in license compliancy summary

Import functionality for Oracle Orders and Agreements
Add Processors & Total cores to the column selector in All Computers report



Add custom fields to Oracle orders

PowerVM connector for AIX LPAR info

Improve connector access to AWS by using Cross Account Access Roles

Adobe Creative Cloud Connection into SLM


and many more!

NOTE: To be sure to look at the most up to date list, please go to the Ideas Board main page, click on "See all Ideas", then select "In development" from the drop-down list.


The intention of this blog is to prepare you for a smooth Snow License Manager 9 Upgrade, with some useful hints to raise the awareness and the knowledge about the process.

Please note that we strongly recommend to run the upgrade guided by either professional services or a qualified Snow partner. Please contact your account manager or your local Snow partner for further information and assistance. If you are unsure who your account manager is, please submit a ticket to support.

Please be advised that any resulting issues during the upgrade from uncertified resources is not covered by the Support Agreement and therefore needs to be remedied by Snow Professional Services or certified Snow Partners.


  1. Prerequisites

    1. License Key

      To get your Snow License Manager 9 Key, please contact your account manager or your local Snow partner. In some cases you may contact the Backoffice directly.

      Please be aware that the company (organization) name should not exceed 35 characters as described in KB0017826.

    2. System Requirements

      Verify that the servers meet the system requirements for this product. System requirements and
      information on dependencies on other Snow products are gathered in the document System
      Requirements for all Snow products, which is available for download on this Knowledge Base Article.
    3. Software preparations

      Use Microsoft SQL Server 2012 Standard or later (recommended version 11.0.7469.6 - SP4).

      Use Microsoft Windows Server 2012 or later.

      Install ASP.NET 4.5 with all features enabled as a role on your server.

      Install .NET Framework 4.7.2 or later on your Snow License Manager application server.

      Have Snow Inventory version 6.0.3 which is the minimum database version supported by SLM 9.0.0.

      If you are using the IIS (Internet Information Services) to host other web applications, make
      sure you have a web hostname or a specific port assigned to the Snow License Manager

      SQL Server Database compatibility level: The minimum version is 100 (corresponding to SQL Server 2012). This setting is configured per database in SQL Server and must be manually checked if the database has been migrated from SQL Server 2008.
  2. Readiness Upgrade Checks

    1. Checking minimum DB Size and Growing Policy

      By default, our setup packages create the databases not specifying a minimum size or a growing policy. The growing policy impacts performance because Microsoft keeps 1MB as default. Please, add the following content to check these settings:


      SLM Data File: Growing 4096MB, (Recommended maximum: Unlimited)
      SLM Log File: Initial size 4096, Growing 1024MB, (Recommended maximum: Unlimited)

      Please, respect the values for Log file. SQL Server creates something called “virtual disks” in that file. The formula applied by mixing 4096MB + 1024MB keeps those virtual files in a reasonable number (300-600 hundreds) for large DBs what improves performance. The partner will need to shrink log files using the SQL Server Management Studio tool to reduce any existing Log file to 4096 if the current size is higher.

      The growing policy is one of the most common problems while talking about performance in our customer base.
    2. Administrative accounts for in-scope Snow application server and SQL server

      Please verify that the used accounts do have enough permissions; Ensure the SQL user account with database  does have administration privileges (sa or equivalent account with sysadmin rights).

      Verify that the LicenseManagerUser SQL account belongs to the db_ower role in SnowLicenseManager and SnowInventory databases. This account is used to perform the upgrade process.

      This role could be lost due to security restrictions, after a migration from SQL Server 2008 or while recovering a database in a Test Environment.

      LicenseManagerUser should also have SQLAgentOperatorRole, SQLAgentReaderRole and SQLAgentUserRole.

      This is default applied settings when upgrading to SLM8.


      SQL version, If SQL 2016 by default, Microsoft does not apply optimized code unless and Administrator allows that. Please, check that:

      Database (SnowInventory and SnowLicenseManager) > Properties > Options > Query Optimized Fixes = 0N
    3. Additional Information for Inventory Sources in the SMACC settings
      All Inventory databases configured in SMACC with "Enable data update job" to active must be on Inventory 6.0.3.
      The data update job in SLM 9 requires that no configured Sites in any Inventory Source in any CID for the same Inventory database overlap. Example of an overlap:

      Inventory Source 1, site: Company%
      Inventory Source 2, site: CompanyUK

      Snow Management and Configuration Center checks for Site overlap when adding a new Inventory Source but existing overlaps must be fixed before upgrading to SLM 9.0.0.

    4. Backup

      Verify in scope backup/restore procedures for SQL DB's and application server(s) request full backups to be completed in line with the planned upgrade.

      Microsoft SQL Server
      Full backup of SnowInventory and SnowLicenseManager database

      Also request full application settings backups of the following locations on the SLM8 server:

      Snow License Manager Compliance Settings
      ..\Snow Software\Snow License Manager\Services\Licensing\SnowSoftware.LicenseManager.Licensing.Service.exe


      Event Store


      Import Settings
      ..\Snow Software\Snow License Manager\Services\ImportTool\DataImport\Import\*.*

    5. Calculating space requirements

      Snow Inventory Server
      The database will grow a 20% and must have enough space in the transaction log before starting the upgrade. Use the following formula to estimate its size (temporarily, it can be reverted to the original size after upgrade):

      (Total SnowInventory DB size) * 0.5 +
      (SnowInventory.inv.DataMetering size + SnowInventory.inv.DataMeteringConcurrency size) * 2.85

      Snow License Manager
      Total size of the SLM database will grow up to 30-40% after upgrade and first initial DUJ run.

    6. Checking custom procedures and reports

      Several database changes may or will impact custom procedures and reports. All existing customizations must be analyzed to check compatibility by professional services.

      How to identify existing custom procedures:
      USE SnowLicenseManager
      select * from tblSystemCustomProcedures

      How to identify existing custom reports:
      USE SnowLicenseManager
      select * from tblReport where IsCustomReport = 1
    7. Checking the current logs to identify any existing errors

      In order to facilitate troubleshooting if an error appears after the upgrade, all existing logs should be checked looking for any existing issue before upgrading the products


      Snow Inventory Server Checks:



      Snow License Manager Server Checks:

      %PROGAMFILES%\Snow Software\Logs


      %PROGAMFILES%\Snow Software\Snow License Manager\Web\Logs


      %PROGAMFILES%\ Snow Software\Snow LicenseManager\Services\ImportTool\DataImport\ErrorRows


      Snow License Manager Database Server:
      USE SnowLicenseManager
      select * from tblErrorLog order by LogDate desc

  3. New features which have been implemented with SLM 9

    – Tracking of licensing model changes

    – Manual exclude computers during the Compliance calculation

    – Hypervisor Technology and high availability of datacenter and cluster

    – Reports for cost estimation of Microsoft Windows Server

    – Inkremental Data Update Job (DUJ 2.0) – Performance optimization

    – Direct access to the UserGuides

    – Discovery of Google Cloud Computer Engine

    – Different Oracle optimisations (needs the latest version of the Snow Inventory Oracle Scanner)
    Processing of Oracle Datenbase Data
    License determination of Oracle Databases
    Detailed lifetime support information about Oracle Datenbases
    Oracle WebLogic Server investigation and inventory
    Tracking of Oracle Database inventory

    When you have upgraded to Snow License Manager 9, be aware that the first run of Data Update
    Job will take a considerable amount of time to run; subsequent runs of Data Update Job will take
    considerably less time.

    We recommend to always use the latest version of Snow License Manager in order to stay updated
    with the latest features and corrections. Please read the Release Notes for details.

  4. FAQ

Are Snow Inventory Clients (3.x) compatible with Snow License Manager 9?

Yes, however it is highly recommended to update them to the latest version of the Snow Inventory Agents 6 as there have been lots of improvements.

Note that the macOS 6.x Agents requires Inventory Server 6.0.0 or higher.

If you want to check which Agents are compatible with which OS checkout this blog:

Using earlier Snow Inventory agents to scan older operating systems


Can I upgrade to Snow Inventory 6 and continue running Snow License Manager 8?

Yes, INV 6 and SLM 8 are compatible. However, this compatibility is by design, as Inventory 6 is a prerequisite for SLM 9. We do not recommend this configuration to persist longer than it takes the customer to carry out the SLM 8/9 upgrade. 

Can I run Snow License Manager 9 with Snow Inventory 5?

No, SLM 9 and INV 5 are not compatible.

Can I upgrade from Inventory 3 to Inventory 6 directly?

Yes. We recommend doing this for users who plan to update to SLM 9.

Why are we rolling out INV6 & SLM9 in two phases?

The 6/9 update involves changes to the Snow Inventory and Snow License Manager databases, with new tables, and new structures for data processing.


This blog may be continuously updated.

[Updated on 12/04/2019]

As you may know, in our Knowledge Base we collect all the most up to date documents and guides about our software. You can filter the data by topic or by category and even order for the "last update" field, but why not having here a quick list of the most up to date documents about SLM 9.0.x? 


So, here they are:


      User Guide for Snow Management and Configuration Center for the administration of License Manager.

      US English version of the User Guide: Web User Interface Snow License Manager version 9. 



      This Technical Description describes how the Snow License Manager web user interface allows users to sign in       while Data Update Job runs and what areas are made unavailable when which stored procedures are executed.




I hope you find them helpful. In case you need more information about our SnowGlobe Community, our tools, forums and trainings, please check this link: Welcome to Snow – Where to start and things to know 


For various reasons (described at the end of this post), compatibility with older operating systems is sometimes broken when we release a new inventory agent version. In these cases, we will still support the older operating system, but you  would need to use an older version of our agent in order to inventory the system.


The most recent example is our macOS agent version 6.0.0, which does not support macOS 10.7, so to scan computers with macOS 10.7, you need to use the prior agent version which is 5.1.0.


Our colleagues in R&D created the following list of all older operating systems that we still support as of today, by using an earlier version of our Snow agents:


Operating system

Agent version

Microsoft Windows 2000 (x86)

Windows Agent version 3.7 (EoS July 2019)

Microsoft Windows XP (x86, x64)

Windows Agent version 5.2.4

Microsoft Windows Server 2003 R2 (x86, x64)

Windows Agent version 5.2.4

Microsoft Windows Server 2003 (x86, x64)

Windows Agent version 5.2.4

10.6 - Snow Leopard

macOS Agent version 2.3 (EoS July 2019)

10.7 - Lion

macOS Agent version 5.1.0

Debian 5.x

Linux Agent version 5.2.0

Debian 6.0.00-6.0.10

Linux Agent version 5.2.0

Debian 7.0-7.6

Linux Agent version 5.2.0

Oracle Enterprise Linux 4.x

Linux Agent version 5.2.0

Red Hat Enterprise Linux 4.x

Linux Agent version 5.2.0

Red Hat Enterprise Linux 5.0-5.11

Linux Agent version 5.2.0


Linux Agent version 5.2.0

Ubuntu/Kubuntu 10.x

Linux Agent version 5.2.0

Ubuntu/Kubuntu 11.x

Linux Agent version 5.2.0


Unix Agent version 5.0.4


Unix Agent version 5.0.4

Solaris 8

Unix Agent version 5.0.4

Solaris 9

Unix Agent version 5.0.4

All this information can be derived from the System Requirements, but as this has been requested a few times, R&D created this summary for a better overview.


So why do we even break compatibility at all?

The main reason is that we need to keep the agents up-to-date with the latest libraries, and these libraries in-turn may lack support for an older OS. The benefit of these newer libraries is often improved security and/or bug fixes.