Support Files for Snow Inventory Agent

jharrison asked a question.

February 20, 2018 at 8:00 AM

Hi all, In Snow Inventory there is an option to deploy support files as part of the agent update feature. The documentation doesn't say a lot about what support files can be deployed here. We have many organizational units, and we would like our agents to scan different paths based on the organizational unit. So obviously you can create a configuration for each organizational unit. However, this creates an administration headache. What happens when you want to make a global configuration change? Now you need to go into every configuration and make the change. It would be kind of cool if you could deploy a global snowagent.config file, and then a support file alongside it that provides custom settings to the configuration. So it might look something like: In the above screenshot example, snowagent.config contains our global config settings for all agents. But the supporting snowagent-aus.config provides custom override settings specific to Australia (for example). XML allows you to reference other XML files in a very straight forward way, but I suspect the snowagent.config file does not support this. Does anyone know of another way this might be done? I'd be interested to hear how many other people would benefit from a feature such as this. For a company with many configurations, a feature such as this would really simplify administration of all our configurations. Kind regards Jordan

Oliver Berger (Flexera Software)
9 years ago
Hi Jordan, Supportfiles could be anything you want to add to the client, at first agent extension scripts. I'm not aware of such a function for, let's call them "nested configurations", inside Snow Inventory and the support files or update functions will not solve your wish. The updates are just a "one shot" and will not install the modified files, when you add new machines with an old configuration. And instead of having administrative headaches in the configuration, you would have them inside the updates. But Snow Inventory Server automatically deploy changes to the computers with the specific configuration, when changing them centrally. Whenever I'm around in bigger environments, I always reference on using the normal software deployment strategy and technology, already available at the customer, instead to introduce a second one to bypass the first. Due to the fact that the config file is xml, you could change it, using some installation scripts during the installation. But in bigger environments 100+ different configurations and Agents is okay, and our support would provide you the new msi packages with pleasure. With that said, feel free to open a feature request via snow support, if you want to change the behaviour of Snow Inventory Server. Hope that helps Oliver
Expand Post
SamuelBaughan
9 years ago
Hi Jordan, It makes much sense that in a large organization, you want to keep the data harvested to a minimum otherwise you easily loose control on your DB size and DUJ runtime. Localized configurations make sense. Have you tried any XML cross reference solutions? There are a few mentioned here: https://stackoverflow.com/questions/1065026/xml-referencing-other-xml-files but of course they depend on whether they are supported by the XML parser used by Snow. If supported, the main config file could reference a secondary local file. Now it has to be determined which option is best: Reference a single second config file that has the same name for all OUs and find a way to deploy so many versions of the secondary config file all bearing the same name Reference all secondary files, using the localized name (config-AUS.config, config-USA.config, config-FRA.config ...), in the main config file and hope that the parser still compiles despite most of the referenced files not being found ... I'm far from an XML specialist so that second option might not work at all Regards, Samuel
Expand Post
DavidH
9 years ago
This is an interesting idea, it would be similar to app.config files in the .Net world where you can split sections out into different files. I had a little play with an Agent, but was not able to get my snowagent.config file to reference a section in another file. So I also suspect that snowagent.config files don't support this... However , when I looked at the documentation here , I noticed that it says this: "Every system shall have a default settings.xml file that decides what value should be the default if none is given. The order the client should do this is to first read the default xml file and after that write over these values with the values in the users xml file." ...so I wonder if that feature could be used? It sounds like the "users xml file" mentioned above can overwrite settings from another file. So in your hypothetical example above, could the global configuration become the "default xml file" and the Australia specific settings be placed in the "users xml file"?
Expand Post
- Oliver Berger (Flexera Software)
  9 years ago
  Well spotted. But we use this already behind the scenes. It's the reason why we do not have to add the regkeys for SQL Server. And the reason why we have to add them all, when a different key is added... And it is hardcoded, so out of reach. Sorry.
  Expand Post
  - DavidH
    9 years ago
    Thanks for explaining that. Although on the positive side, you do already have one config file overriding another. So perhaps it would not be too difficult a feature request to extend this to one more layer. Perhaps in a future release there could be a third file which overrides the "users xml file" (which I am assuming is the snowagent.config file)? That would be a neat way to allow custom overrides in certain circumstances.
    Expand Post

Related Product Forums

→ Flexera One

→ Snow Atlas

→ FlexNet Manager

→ Snow License Manager

→ App Broker

Need help finding an answer?

Ask a Question →