4.1 Setting Up the Configuration Assessment

The first step in setting up a Configuration assessment is to create the rules file you want to use and save it to the Vivinet Assessor Console computer. Then, import the file so that Vivinet Assessor can validate and read it. Finally, identify any devices you do not want to include in the assessment.

To set up the configuration assessment:

Create a rules file. For more information, see Section 4.1.1, Creating a Rules File.
Expand the Assess Configuration view and click Set Up.
Import the rules file. For more information, see Section 4.1.2, Importing the Rules File.
If necessary, exclude selected devices from the Configuration assessment. All eligible devices from the Network Inventory are shown in the Network Inventory table. Deselect the boxes next to any devices whose configuration you do not want to check.

HINT:You can use the Set Up view to export a configuration rules file that you imported and used in a Configuration assessment. Click Export to export the rules to an XML file that will be saved in the Program Files\Micro Focus\Vivinet Assessor directory by default.

4.1.1 Creating a Rules File

Before you can assess device configuration, create a valid configuration rules file in XML format. Use the following information to create your rules file and then save it on the Vivinet Assessor Console computer.

When you import a rules file, it is immediately validated against the Vivinet Assessor rules file schema, PropertyRuleSchema.xsd, which is installed by default in the Program Files\Micro Focus\Vivinet Assessor directory. The schema is an XML definition file that defines the structure, content, and syntax of the XML rules files you can import. It is based on structures in the Vivinet Assessor SQL database so that the data you gather on network devices during the Network Inventory can be analyzed by the configuration rules you import.

If your rules file does not conform to the rule schema, or if it is not in the same directory as the schema, an error is reported when you import it. You will than have to make changes to your XML file or to its directory location and re-import it.

A valid rules file must have a header containing the XML version:

<?xml version="1.0" ?>

The header also indicates that the schema (.xsd) file must be in the same directory as the rules file:

xsi:noNamespaceSchemaLocation="PropertyRuleSchema.xsd"

A description tag is a recommended, but not a required, element. The text in your description tag appears in the Rules description field of the Run view when you run the Configuration assessment. The following is an example of a header containing the previously mentioned elements:

<BasicRulesElement xmlns:xsi="http://www.w3.org/2001/XMLSchema-
  instance" xsi:noNamespaceSchemaLocation="PropertyRuleSchema.xsd" 
  Name="SampleRules" Description="NetIQ Configuration Rules">

You can see a more specific example by looking at a rule from our SampleRules.xml file, located in the Program Files\Micro Focus\Vivinet Assessor\Samples directory. This particular rule looks for Cisco routers with an IOS greater than 12.0 and is a good example of how to create a rule in general. We reference it when discussing the various components of a rule. The SampleRules.xml is a good starting point for generating your own rules file.

<?xml version="1.0" encoding="utf-8" ?>
<BasicRulesElement xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PropertyRuleSchema.xsd" Name="SampleRules" Description="Sample Rules">
    <Rule Name="CiscoIOSRule" Description="Cisco IOS downlevel rule">
        <TopRule LogicalOperator="AND">
            <BasicRule ComparisonOperator="EqualTo">
                <!-- Look for all Cisco router devices-->
                <BasicPropertyItem FilterOn="true">
                    <Property>Vendor</Property>
                    <Type>String</Type>
                    <Unit>None</Unit>
                    <Value>Cisco</Value>    
                    <DeviceType>router</DeviceType>
                </BasicPropertyItem>
            </BasicRule>
            <BasicRule ComparisonOperator="GreaterThan">
                <BasicPropertyItem>
                    <!-- Check IOS level greater than 12.0-->
                    <!-- Using Type Integer for an alphanumeric field will typically yield better results than Type String for GreaterThan/LessThan Comparisons -->
                    <Property>OSRevision</Property>
                    <Type>Integer</Type>
                    <Unit>None</Unit>
                    <Value>12.0</Value>  
                    <DeviceType>router</DeviceType>
                </BasicPropertyItem>
            </BasicRule>
        </TopRule>
    </Rule>

Each element defined below is a component of the rule described above.

Element	Description
Rule Name and Description	Name and Description are attributes of the Rule element. You should supply names and descriptions indicating what the rule is evaluating as a kind of shorthand for what the XML is doing. These attributes are referenced in the Run view and in the Report.
TopRule and IntermediateRule	Used to introduce a logical operator. If you plan to evaluate multiple properties in one rule, you should use a logical operator. The example above presents a rule that evaluates devices based on the Vendor property AND the OSRevision property. An IntermediateRule (not shown in the above example) is similar, but allows some flexibility in further defining what a rule evaluates. Rules are generally more effective if multiple properties are evaluated together, as, for example, when you check for a particular vendor, operating system, and installed memory with a single rule.
BasicRule	The element where you can supply the comparison operator to be used on the property you are evaluating with the basic rule construct. The example above looks for two different properties: the property Vendor EqualTo Cisco AND the property OSRevision GreaterThan 12.0. A complex rule can have several BasicRule elements.
BasicPropertyItem	A complex element comprising the next five basic elements, which define characteristics of the property being evaluated. The following are all required elements.
Property	Several properties are stored for each network device discovered during the Network Inventory. The following are basic device properties you can use a rule to evaluate: Vendor, Model, OSRevision, InstalledModules, MemoryFlash, MemoryRAM
Type	A data type. Determines whether the rule should look for a string value or an integer value.
Unit	Determines the units that are applied to a metric. For example, if you want all your routers to have at least 64 MB of RAM, you would supply MegaBytes for the <Unit> rule parameter. The following units are valid: None, Bytes, Kilobytes, and MegaBytes
Value	Specifies what you are looking for in a given property.
DeviceType	Associates a rule with a particular kind of device to generate more effective rules; expected Basic property values are usually different for different device types. The following types are available: all, switch, router Use <DeviceType>all</DeviceType> if you want a rule to be applied to both switches and routers.
Operators	Logical operators are used to create expressions that evaluate multiple properties in the same rule. The following are available: AND, OR Comparison operators are used to compare a device’s basic property against a known value. The following are available: EqualTo, NotEqualTo, LessThan, LessThanEqualTo, GreaterThan, GreaterThanEqualTo, AND, OR, Find
Find operator	An operator that works similarly to EqualTo, GreaterThan, LessThan, and other operators. It locates a particular value within a property being analyzed by a rule. Useful in instances where an EqualTo is not really applicable. For more information, see Section 4.3.2, Example 2: Installed Modules.
FilterOn attribute	FilterOn is a special Property attribute of the BasicPropertyItem that can be used to query only devices with a certain value you are interested in and not create failure results when a device does not meet that criterion. Filtering out all devices except for those made by a particular vendor, for example, can focus the rule on the subset of devices you want to evaluate. For more information, see Section 4.3.3, Example 3: Filtering Rule Properties. The following values are available for the FilterOn attribute: true, false

4.1.2 Importing the Rules File

After creating the rules file, import it for use in the Configuration assessment.

To import the rules file:

In the Rules file field, type the full path to the rules file directory location. Or click the Browse button to navigate to the file.
Click Import.

Vivinet Assessor runs a quick check to ensure the file format is valid for the schema. Any problems are reported so that you can correct them and re-import the file.