Master Steps steps

This following group of steps is executed on the master, but they can be launched from any other device.

Autodiscovered Device Verification

This step sends an email with the list of newly autodiscovered devices since the last verification. The email contains the complete list of devices with other information pertinent to the individual devices, such as the operating system, discovered date and agent version, that have been added since the last verification.nThis step is only applicable on the master.

Parameter	Description
From	Enter the email address of the sender. This does not have to be a personal email, this may be any address which exists in your systems, such as support@starfleet.com . Also the email address does not have to be defined for an administrator account within the Console.
Message Text	Specify the introductory text of the mail body.
Port Number	Enter into this field the port number of the mail server, as defined in the Mail tab in the System Variables of the Global Settings .
Server Name	Enter into this field the name of the mail server, as defined in the Mail tab in the System Variables of the Global Settings . The name may either be entered as the full or short network name such as mail or mail.enterprise.starfleet.com or as its IP address in dotted notation, for example, 213.2.146.1 or 2001:db8:85a3::8a2e:370:7334 .
Subject	Contains the subject line of the mail.
To	Enter the email address of the recipient. This does not have to be a personal email, this may be any address which exists in your systems, such as support@starfleet.com . Also the email address does not have to be defined for an administrator account within the Console. You may specify more than one target address by separating them with a comma (,).

CSV File Import

This step imports data into the custom inventory data from a CSV file. The values in the CSV file may be separated either by a comma (,) or a semi-colon (;).

Parameter	Description
Administrator Name	The name of the administrator which is to execute this step. Make sure this administrator has the required capabilities and access rights, otherwise the step execution fails. Click the Select button next to the field and select the desired administrator from the list.
CSV File Path	The complete or relative path to the csv file. If you enter the path as a relative path it is relative to the master installation directory, <InstallDir>/Master/ .
Custom Inventory Object Name	Enter the prefix for the instance name for the custom inventory item, for example, entering Instance here labels the columns Instance0, Instance1 , etc.
Erase CSV File after Import	Defines if the csv file is stored or deleted after the data import.

The format of the csv file must be as follows:

The first line is the header and contains the names of the attributes equalling the columns of the final table; the first attribute (column) must be Device Name , the following are the remaining attributes
The lines 2 to n are the data lines, containing the values of the devices, whereby the first value must be the device name followed by the other attributes matching their column title defined in the header line.
The separator can be either a comma (,) or a semi-colon (;).

Example:

DeviceName;Name;IPAddress
DEVICE1;Samuel;10.5.157.55
DEVICE2;John;10.5.157.56

Device Clean-up

This step allows you to delete direct and indirect members from selected device groups. Optionally, if the deprecate device option is selected, the devices are deprecated instead of deleted.

Parameter	Description
Device Group	Enter the name of the device group, of which you want to delete or deprecate all its members. To select the group click the Add button and select the group or groups in the appearing window.
Delete Subgroup Members	Check this box to also delete or deprecate all members of all subgroups of the selected group.
Deprecate Devices	Check this box to deprecate all member devices of this group instead of deleting them.
Delete Assigned Devices	Check this box to delete the devices even if they are assigned to objects.
Allow Partial Execution	If this box is checked, the step executes successfully, even if some of the devices cannot be deleted or deprecated. In this case, an error is displayed in the "Error Details" column of the assigned device view. If none of the devices can be deleted or deprecated, the rule fails.nTo find which devices were not successfully deleted or deprecated, you need to check the operational rules log (operationalrules.log).
Administrator Name	The name of the administrator which is to execute this step. Make sure this administrator has the required capabilities and access rights, otherwise the step execution fails. Click the Select button next to the field and select the desired administrator from the list.

Centralized Wake On LAN

This step allows you to wake up specific devices via a number of other devices. Depending on the agent configuration, wakener devices should try to wake up the target devices using one of the available mechanisms: local, remote via configured wakeners, remote via notified topology or fallback (Unicast or Subnet-Directed Broadcast).

Parameter	Description
Number of Retries	Defines the number of retries the step is to execute before abandoning if it fails.
Which devices or groups should be woken?	Add into this list field the devices or device groups which are to be woken up. To add select the Add button and select the desired objects from the Select Objects window.
Retry Interval (sec)	Defines the interval at which the step is to effect its retries in seconds.
Who should wake up the devices?	Allows the master to call the wake up action on another device for which it has the following possibilities: To Use Specific Wakener , that is, a wakener device can be defined to execute the wake up actions if all targets are located in one subnet, or the waking up actions can be executed by the targets' parent device, Wakeup via Target Parent . In this case the list of direct parents of the devices to wake up is retrieved from the database and the waking up is delegated to the parents of the respective devices to wake up.
Which device should wake up the targets?	Enter into this list the device to wake up the devices listed above. You may only specify one device in this field. If you are not sure that all targets are on the defined device's subnet select the option Wakeup via Target Parent above to make sure all targets are woken up.

Assignment Management via XML File

This step allows you to assign/unassign objects (operational rules, packages, patch groups and application lists) via an XML file to/from their targets (devices and device groups).

Parameter	Description
File Path	Enter the complete path to the storage location of the XML file. The path may contain wildcard characters, for example, c:tempbmcac*.xml_ .
Administrator Name	The name of the administrator which is to execute this step. Make sure this administrator has the required capabilities and access rights, otherwise the step execution fails. Click the Select button next to the field and select the desired administrator from the list.
File destination path if successful	Enter into this field the full destination path into which the XML file is copied if it has been treated with success, that is, all assignments listed on the listed objects could be effected in the BCM database, for example, c:tempok . This path must point to a different directory than that of the source path, it can however be the same as for failed assignments.
File destination path if failed	Enter into this field the full destination path into which the XML file is copied if an error occurred during its treatment, that is, at least one of the assignments could not be effected in the BCM database, for example, c:tempnok . This path must point to a different directory than that of the source path, it can however be the same as for successful assignments.
Activate Created Assignment	Check this box, if the assignments provided by the XML file are to become active right away. If the box is left unchecked, the assignments are all recorded in the database, however the assigments are not sent and the object is thus not executed.
Reassign if Assignment Already Exists	Check this box if in case of an existing assignment it is to be reactivated. If the box is not checked the modifications supplied by the XML file are made to the assignments, however they do not become active.

Example 1

The following example assigns and a patch group to an individual device and a device group on March 9, 2011 at 4pm and advertises an operational rule to the device and group as well. The assignment is done by the administrator admin.

<?xml version="1.0" encoding="UTF-8"?> 
<OBJECTASSOCIATIONS>     
  <!-- This section must contain the list of objects to assign -->     
  <OBJECTS>         
    <!-- type can be OperationalRule, Package, PatchGroup or ApplicationList -->         
    <!-- the object can be referenced with its database ID with attribute "id" -->         
    <!-- or through its name with attribute "name" -->         
    <OBJECT type="OperationalRule" id="1001"/>         
    <OBJECT type="PatchGroup" name="PG Test Rule"/>      
  </OBJECTS>     
  <DEVICES>         
    <!-- This section contains the list of devices to which the objects are to be assigned -->         
    <!-- Devices can be referenced with database ID (attribute "id") -->         
    <!-- or name (attribute "name") -->         
    <DEVICE id="1000"/>         
    <DEVICE name="Device X"/>      
  </DEVICES>     
  <DEVICEGROUPS>         
    <!-- This section contains the list of device groups to which the objects are to be assigned -->         
    <!-- Groups can be referenced with database ID (attribute "id") -->         
    <!-- or name (attribute "name") -->         
    <DEVICEGROUP id="1000"/>         
    <DEVICEGROUP name="My Group"/>      
  </DEVICEGROUPS>    
  <OPTIONS>         
    <!-- Which administrator profile will be used for the assignment -->         
    <ADMINISTRATOR name="admin"/>         
      <!-- When will the object assignment be sent to devices (number of hours, minutes, etc and 0 for immediate) -->         
      <!-- This only applies to OperationalRule, Package, PatchGroup object types -->         
      <SCHEDULE hour="16" minute="0" day="9" month="3" year="2011"/>         
        <!-- Add if type is OperationalRule and only advertizemnt is needed -->         
      <ADVERTIZE/>     
  </OPTIONS> 
</OBJECTASSOCIATIONS>

Example 2

This example unassigns an operational rule and a patch group from an individual device and a device group with the default schedule, that is, immediately.

 
<?xml version="1.0" encoding="UTF-8"?> 
<OBJECTUNASSIGN>     
  <!-- This section must contain the list of objects to unassign -->     
  <OBJECTS>         
    <!-- type can be OperationalRule, Package, PatchGroup or ApplicationList -->         
    <!-- the object can be referenced with its database ID with attribute "id" -->         
    <!-- or through its name with attribute "name" -->         
    <OBJECT type="OperationalRule" id="1001"/>         
    <OBJECT type="PatchGroup" name="PG Test Rule"/>      
  </OBJECTS>     
  <DEVICES>        
    <!-- This section contains the list of devices from which the objects are to be unassigned -->         
    <!-- Devices can be referenced with database ID (attribute "id") -->         
    <!-- or name (attribute "name") -->         
    <DEVICE id="1000"/>         
    <DEVICE name="Device X"/>      
  </DEVICES>     
  <DEVICEGROUPS>         
    <!-- This section contains the list of device groups from which the objects are to be unassigned -->         
    <!-- Groups can be referenced with database ID (attribute "id") -->         
    <!-- or name (attribute "name") -->         
    <DEVICEGROUP id="1000"/>         
    <DEVICEGROUP name="My Group"/>      
  </DEVICEGROUPS> 
</OBJECTUNASSIGN>

Operational Rule Assignment via XML File

This step is designed to automate the assignment process of operational rules. The assignment itself is defined in the XML file. The schedule is defined via the administrator with which the assignment is created. It is therefore recommended to create an administrator group with a number of administrator members for each of which a specific schedule is to be defined. When listing an administrator in the respective field, its activation/execution schedule combination is used as the schedule for the operational rule/device assignment.

This step allows you to assign operational rules via an XML file to their target devices with a predefined schedule.

Parameter	Description
Administrator Name	The name of the administrator which is to execute this step. Make sure this administrator has the required capabilities and access rights, otherwise the step execution fails. Click the Select button next to the field and select the desired administrator from the list.
XML File Path	Enter the complete path to the storage location of the XML file.

Example

The following example assigns an operational rule to an individual device on March 9, 2011 at 4 pm as the administrator admin.

<?xml version="1.0" encoding="UTF-8"?>
<RULEASSOCIATIONS>
    <!-- This section must contain the list of operational rules to assign -->
    <RULES>
        <RULE id="1001"/>         // The Rule ID/Name must be the exact value that the rule is
        <RULE name="Test Rule"/>      known in Precision Database.
    </RULES>
 
    <DEVICES>
    <!-- This section must contain the list of devices to which the rules are to be assigned -->
        <DEVICE id="1000"/>        // The Device ID/name must be the exact value that the device is
        <DEVICE name="Device X"/>     known in Precision Database.
    </DEVICES>
 
    <OPTIONS>
        <!-- When will the rule be activated (number of hours, minutes, etc and 0 for immediate) -->
        <ADMINISTRATOR name="admin"/>
        <SCHEDULE hour="16" minute="0" day="9" month="10" year="2006"/>
        <!-- What type of installation should be used: "normal", "administrative" or "network"-->
        <NETWORKINSTALL mode="normal" />
    </OPTIONS>

</RULEASSOCIATIONS>

Package Assignment via XML File

This step is designed to automate the assignment process of packages. The assignment itself is defined in the XML file. The activation schedule may also be defined in this XML file. If a bad date is specified the assignment will be planned for the current day.

This step allows to assign packages via an XML file to their target devices with a predefined schedule.

Parameter	Description
Administrator Name	The name of the administrator which is to execute this step. Make sure this administrator has the required capabilities and access rights, otherwise the step execution fails. Click the Select button next to the field and select the desired administrator from the list.
XML File Path	Enter the complete path to the storage location of the XML file.

Example

The following example assigns a package to two devices on March 9, 2011 at 4 pm as the administrator admin.

<?xml version="1.0" encoding="UTF-8"?>
<PACKAGEASSOCIATIONS>
    <!-- This section must contain the list of packages to assign -->
    <PACKAGES>
        <PACKAGE id="1001"/>  // The Package ID must be the value that the package is
                                  known in Precision Database.
    </PACKAGES>
 
    <DEVICES>
    <!-- This section must contain the list of devices to which the packages are
         assigned to-->
        <DEVICE id="1000"/>  // The Device ID must be the value that the device is
        <DEVICE id="1002"/>      known in Precision Database.
    </DEVICES>
 
    <OPTIONS>
        <!-- This section contains the optional parameters, such as the administrator
              under which the packages are assigned and the schedule. -->
        <ADMINISTRATOR name="admin"/>
        <SCHEDULE hour="16" minute="0" day="9" month="10" year="2006"/>
    </OPTIONS>
</PACKAGEASSOCIATIONS>

Master Steps steps

Autodiscovered Device Verification

CSV File Import

Device Clean-up

Centralized Wake On LAN

Assignment Management via XML File

Example 1

Example 2

Operational Rule Assignment via XML File

Example

Package Assignment via XML File

Example

Comments