Catalog files (.osd)

FlexNet Manager Suite 2020 R2 (On-Premises)

A catalog file is small, usually around 1KB, and thus provides a fast way for the FlexNet inventory agent to check whether downloads of larger files are required (that is, whether the file that the catalog points to has changed). In this description, that larger file is called the "target file" to distinguish it from the catalog file. The catalog and its target file are together called a 'package'.

The catalog file includes:
  • A pointer to the target file
  • An MD5 checksum for the target file
  • The software version
  • Optionally, licensing details
  • The names and versions of any dependent packages.
The format of the catalog file was derived from the W3C's Open Software Description (OSD) format, described at http://www.w3corg/TR/NOTE-OSD.html. However, the catalog file format ignores some elements of the OSD proposal, and adds others (through a namespace declaration with a related DTD file).

Details for package (.osd) files

Server location

Generated on demand by (and saved on) inventory beacons.

Folder
On inventory beacon: In the appropriate subdirectories under %CommonAppData%\Flexera Software\Staging\Common\. Relevant subdirectories for catalogs include:
  • ClientConfiguration
  • ClientSettings
  • InventorySettingsConfiguration
  • Packages
  • Schedules.
Tip: Catalog files exist only after an installed FlexNet inventory agent has requested the relevant download. For example, the Default Machine Schedule.osd catalog is created only after a managed device has requested a schedule update.

On Windows devices after download:

On UNIX-like devices after download:

Updated

The catalog files are initially generated (and cached) when requested by a managed device, using the latest inventory beacon policy downloaded from the central application server. Thereafter each catalog is checked on demand for changes to the target file requested by the installed FlexNet inventory agents.

File name format

packageType.osd

Example: Default Machine Schedule.osd

Format

XML (text).

Sample file

In the following sample (which is a catalog for a schedule), line numbers have been added for reference only; some lines have been elided to shorten them for presentation.
(1) <?xml version="1.0" encoding="UTF-8"?>
(2) <!DOCTYPE SOFTPKG SYSTEM "http://www.managesoft.com/softpkg.dtd">
(3) <?XML::NAMESPACE HREF="http://www.managesoft.com/managesoft.dtd" AS="NETDEPLOY"?>
(4) <SOFTPKG NAME="Default Machine Schedule" TYPE="Schedule" VERSION="1,0,0,0" FORMAT="1.5">
(5) 	<TITLE>Default Machine Schedule</TITLE>
(6) 	<ABSTRACT>.
(7) </ABSTRACT>
(8) 	<NETDEPLOY::PROPERTY NAME="PackageTransferSize">0</NETDEPLOY::PROPERTY>
(9) 	<NETDEPLOY::USERDOMAIN DEFAULT="public" USERSELECT="True" INHERIT="True"/>
(10)	<IMPLEMENTATION>
(11)		<NETDEPLOY::DIGEST ALGORITHM="MD5" VALUE="e61e527...3033"/>
(12)		<NETDEPLOY::SYMBOL NAME="SelfHeal" VALUE="True"/>
(13)		<CODEBASE HREF="Default%20Machine%20Schedule.nds"/>
(14)	</IMPLEMENTATION>
(15) </SOFTPKG>
The components in the catalog file, line by line, are:
  • (1) and (2): The XML header. The FlexNet inventory agent has built-in knowledge of the catalog file structure, and does not use the DTD reference.
  • (3): A namespace definition that allows the use of additional elements through the second DTD file. Once again, knowledge of this structure is built into the FlexNet inventory agent, and the DTD reference is not used.
  • (4) and (15): Catalog (SOFTPKG) start and end tags, with attributes for the name, type, version, and format.
  • (5): A display title for the catalog.
  • (6): An abstract that may be used to summarize the purpose of the package.
  • and (8), (9) and (15), (16) and (22), and (23) and (27): Event start and end tags, with the most helpful attribute being the NAME.
  • (6), (10), and similarly in later events: The action to execute when any of the following triggers fires. The relevant component of the FlexNet inventory agent is identified, along with any command line parameters to inject.
  • (7), (11)-(14), and similarly in later events: Details of the trigger (or schedule pattern) when the above action should be executed. The parameters include typical scheduling details, such as:
    • The start of the time window within which the trigger should fire, along with the length of the time window in seconds (this time window allows for randomization across different devices, so that they do not all impact the network at the same time)
    • Whether the event should repeat during the day (with the delay in seconds, so that for example the policy update repeats every 12 hours)
    • Optionally, additional triggers to fire the same event when a new user logs on, when the device reconnects to the network, or immediately on machine reboot.

FlexNet Manager Suite (On-Premises)

2020 R2