Schedule Files (.nds)

FlexNet Manager Suite 2024 R1 (On-Premises)

Files with the .nds extension contain data about schedules for use by the FlexNet Inventory Agent (in both the Adopted case and the Agent third-party deployment case).

A single schedule file is generated by inventory beacons each time changed schedule information is downloaded from the central application server. The file is cached against future requests, and a package file (.osd) is created at each update that references the new schedule. (The package file is referenced in the policy file downloaded by each FlexNet Inventory Agent, for which see Policy Files (.npl).) A single schedule file is used in common by all FlexNet Inventory Agents.

You should not edit schedule files, but viewing them can help you to determine that the schedule information distributed to managed devices is as you expect.

Details for schedule (.nds) files created during schedule changes

Server location

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

Folder

On inventory beacon: %CommonAppData%\Flexera Software\Staging\Common\Schedules

On Windows devices after download: %CommonAppData% \ManageSoft Corp\ManageSoft\Schedule Agent\Schedules

On UNIX-like devices after download: /var/opt/managesoft/scheduler/schedules

Updated

Automatically each time that inventory beacon policy downloaded from the central application server includes a change to the schedule for installed FlexNet Inventory Agents.

File name format

Default Machine Schedule.npl

Format

XML (text).

Sample file

In the following sample, line numbers have been added for reference only; some lines have been wrapped for reproduction; and others have been elided when they repeat similar content.

(1) <?xml version="1.0" encoding="utf-8"?>
(2) <!DOCTYPE Schedule PUBLIC "ManageSoft Schedule" 
         "http://www.managesoft.com/schedule.dtd">
(3)
(4) <Schedule SCHEDSCHEMA="60" NAME="Default Machine Schedule" 
          TIMEDATESTAMP="20160204T151801Z">
(5)	<Event NETWORK="false" NAME="Generate Inventory" 
            ID="{de9cddcd-53ac-4796-b02c-f00764f00a1f}" 
            CATCHUP="Never" IDLEDURATION="60">
(6)		<LogicalCommand PARAM=" -o UserInteractionLevel=Quiet" 
                   COMPONENT="Tracker" ACTION="Report" />
(7)		<Trigger TIMESTART="080030" TYPE="Daily" TYPE_PARAM="1" 
                   TIMEWINDOW="28800" DATESTART="20100101" />
(8)	</Event>
(9)	<Event NETWORK="false" NAME="Update Machine Policy" 
            ID="{30c8899c-9eab-4f07-9160-d8610b27f67f}" 
            CATCHUP="Never" IDLEDURATION="0">
(10)     	<LogicalCommand PARAM="-t Machine -o UserInteractionLevel=Quiet" 
                   COMPONENT="PolicyClient" ACTION="Apply" />
(11)     	<Trigger TIMESTART="000500" REPEAT="43200" DURATION="86400" 
                   TYPE="Daily" TYPE_PARAM="1" TIMEWINDOW="3600" DATESTART="20160204" />
(12)     	<Trigger TYPE="Logon" ... />
(13)     	<Trigger TYPE="OnConnect" ... />
(14)     	<Trigger TYPE="Now" ... />
(15)	</Event>
(16)	<Event NETWORK="false" NAME="Update Client Settings" ... >
(17-21)	...
(22)	</Event>
(23)	<Event NETWORK="false" NAME="Upload Client Files" ... >
(24-26)      ...
(27)	</Event>
(28) </Schedule>

The components in the schedule file, line by line, are:

• (1) and (2): The XML header. The FlexNet Inventory Agent has built-in knowledge of the schedule file structure, and does not use the DTD reference.
• (4) and (28): Schedule start and end tags, with attributes for the time and date of last change, and schema version (the schema is internal to the ndschedag component).
• (5) 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.