Novell ZENworks : Distribution Rules for Application Objects
On this webpage, we want to take a look at the attributes which are used to configure the Distribution Rules of ZENworks application objects:
 |
zenAppInventory |
|
zenAppInventoryTree |
|
zenAppInventoryApplication |
Distribution Rules are very important when you are dealing with software deployment in a Novell ZENWorks environment. You can specify with these rules that an application is installed or available on a machine only if certain prerequisites are met. You can configure several criteria for each application which can be combined in a complex logical AND/OR structure.
Unfortunately, the content of these LDAP attributes and their relation to each other is not intuitively clear. And because you cannot find any documentation to the ZEN distribution rule internals on the manufacturer's (Novell) website, this article is aimed at showing how to read or even set the ZEN distribution rules with LDAP scripts.
Objects and Attributes for Distribution Rules
Generally, the Distribution Rules are properties of Novell ZENWorks application objects (LDAP object class appApplication)
The older Legacy Distribution Rules (<ZEN 6.5) are stored in the following LDAP attributes:
OS Version: Criterion block in attribute zen2appInventory
FileExists: Criterion block in attribute zen2appInventory
FileVersion: Criterion block in attribute zen2appInventory
FileDate: Criterion block in attribute zen2appInventory
FileSize: Criterion block in attribute zen2appInventory
Application: String array member in attribute zen2appInventoryApplications
Die modernen Distribution Rules (>= ZEN 6.5) are stored in the following LDAP attributes:
OS Version: Criterion block in attribute zenappInventory
FileExists: Criterion block in attribute zenappInventory
FileVersion: Criterion block in attribute zenappInventory
FileDate: Criterion block in attribute zenappInventory
FileSize: Criterion block in attribute zenappInventory
Application: String array member in attribute zenappInventoryApplications
The logical AND/OR relationships and the regarding criteria grouping are stored in the attribute zenappInventoryTree.
List of the criteria types/sub types
| Criteria | Type | SubType |
| Header | 2D | 02 |
| OS Version | 1E | 01 |
| FileExists | 22 | 01 |
| FileVersion | 22 | 02 |
| Registry – Key Exists | 24 | 01 |
| Registry – Value Exists | 24 | 02 |
| Registry – Other | 24 | 03 |
Legacy Rule: Basic structure or the zen2appInventory bit field
It is an LDAP attribute of type octetstring: Binary data with a maximum length of 2^32 bit.Overview:
Fields:
| Field | Length (Byte) | Content |
| Header | 8 | Always 0x41 4F 54 20 46 49 4C 45 'AOT FILE' |
| Criteria 1 – x | Variable length, each criterion block stores it's own length in the 3. DWORD | Blocks with criteria data, there could be no criterion at all as well |
After the leading header block, there are several blocks with criteria data following. In the first DWORD of these blocks, there s a marker which identifies the type of criterion. The most important of these types are discussed in the other paragraphs in this article.
Note: The structure of almost all data fields in the inventory is based on DWORDs with Big Endian byte order (like in almost every Novell network data structures). The DWORD 0x11AA22BB for example is stored as byte array 'BB 22 AA 11'.
Modern Rule: Basic structure or the zenappInventory bit field
It is an LDAP attribute of type octetstring: Binary data with a maximum length of 2^32 bit.
Overview:
Fields:
| Field | Length (Byte) | Content |
| Header | 8 | Always 0x41 4F 54 20 46 49 4C 45 'AOT FILE' |
| Header Criteria | 16 | 4 Big Endian DWORDs 0x2D 00 00 00 0x02 00 00 00 0x10 00 00 00 (Length of the header criteria) <Number of the remaining criteria blocks> as Big Endian DWORD |
| Criteria 1 – x | Variable length, each criterion block stores it's own length in the 3. DWORD | Blocks with criteria data, there could be no criterion at all as well |
After the leading header block, there are several blocks with criteria data following. In the first DWORD of these blocks, there s a marker which identifies the type of criterion. The most important of these types are discussed in the other paragraphs in this article.
Note: The structure of almost all data fields in the inventory is based on DWORDs with Big Endian byte order (like in almost every Novell network data structures). The DWORD 0x11AA22BB for example is stored as byte array 'BB 22 AA 11'.
Criterion block for condition 'OS Version'
This condition can occur as the only criterion block or as one of several blocks, stored in the LDAP attribute zenappInventory (resp. zen2appInventory for legacy rules).
Overview of the criterion block:
Fields:
| Field | Length (Byte) | Content | |
| CriteriaType | 4 | Value 0x1E 00 00 00 | |
| SubType | 4 | Value 0x01 00 00 00 | |
| TotalLen | 4 | 0x24 Length of the entire criterion block, Big Endian DWORD |
|
| Flag | 4 | 1. Byte: Operator | 0x04 for OSVersion = ValueData 0x08 for OSVersion != ValueData 0x10 for OSVersion < ValueData 0x20 for OSVersion =< ValueData 0x40 for OSVersion > ValueData 0x80 for OSVersion >= ValueData |
| 2. Byte: Reserved | 0x00 |
||
| 3. Byte: Reserved | 0x00 |
||
| 4. Byte: Show Icon | 0x00 for Show=FALSE 0x10 for Show=TRUE |
||
| Minor Version | 4 | DWORD: The minor version. An example: If we would have 4 version parts, for a version 5.1.2.3 the value would be 0x03 00 00 00 You can use wildcards here: 0xFF FF FF FF |
|
| OS Marker | 4 | 0x02 00 00 00 for Windows 98 0x03 00 00 00 for Windows NT/2000/XP |
|
| Major Version | 12 | 3 DWORDs with the version parts of the major version. An example: If we would have 4 version parts, for a version 5.1.2.3 the value would be 0x05 00 00 00 01 00 00 00 02 00 00 00 |
|
Criterion block for condition 'File Exists'
This condition can occur as the only criterion block or as one of several blocks, stored in the LDAP attribute zenappInventory (resp. zen2appInventory for legacy rules).
Overview of the criterion block:
Fields:
| Field | Length (Byte) | Content | |
| CriteriaType | 4 | Value 0x22 00 00 00 | |
| SubType | 4 | Value 0x01 00 00 00 | |
| TotalLen | 4 | Length of the entire criterion block, Big Endian DWORD | |
| Flag | 4 | 1. Byte: Operator | 0x01 for 'File exists' 0x02 for 'File don't exists' |
| 2. Byte: Reserved | 0x00 | ||
| 3. Byte: Reserved | 0x00 | ||
| 4. Byte: Show Icon | Always 0x00 for Show=FALSE | ||
| Reserved | 28 | All 0x00 | |
| SubjectLen | 4 | Length of the fie path, Big Endian DWORD | |
| Subject | store in SubjectLen | Path name of the file | |
Criterion block for condition 'File Version'
This condition can occur as the only criterion block or as one of several blocks, stored in the LDAP attribute zenappInventory (resp. zen2appInventory for legacy rules).
Overview of the criterion block:
Fields:
| Field | Length (Byte) | Content | |
| CriteriaType | 4 | Value 0x22 00 00 00 | |
| SubType | 4 | Value 0x02 00 00 00 | |
| TotalLen | 4 | Length of the entire criterion block, Big Endian DWORD | |
| Flag | 4 | 1. Byte: Operator | 0x04 for FileVersion = ValueData 0x08 for FileVersion != ValueData 0x10 for FileVersion < ValueData 0x20 for FileVersion =< ValueData 0x40 for FileVersion > ValueData 0x80 for FileVersion >= ValueData |
| 2. Byte: Reserved | 0x00 | ||
| 3. Byte: Reserved | 0x00 | ||
| 4. Byte: Show Icon | 0x00 for Show=FALSE 0x10 for Show=TRUE |
||
| Reserved | 1 | 0x00 00 00 00 | |
| Version | 28 | 4 Big Endian DWORDS with a version hierarchy each. An example: Version 1.2.3.4: 0x01 00 00 00 02 00 00 00 03 00 00 00 04 00 00 00 |
|
| Reserved | 8 | All 0x00 | |
| SubjectLen | 4 | Length of the fie path, Big Endian DWORD | |
| Subject | is in SubjectLen | Path name of the file | |
Criterion block for condition 'Environment'
This condition can occur as the only criterion block or as one of several blocks, stored in the LDAP attribute zenappInventory (resp. zen2appInventory for legacy rules).
Overview of the criterion block:
Fields:
| Field | Length (Byte) | Content | |
| CriteriaType | 4 | Value 0x23 00 00 00 | |
| BlockCount | 4 | Number of info blocks contained in this criterion, |
|
| TotalLen | 4 | Length of the entire criterion block, Big Endian DWORD | |
| Flag | 4 | 1. Byte: Operator | 0x01 for 'Value/Key exists', (BlockCount is 1 or 2, info block for ValueData not present) 0x02 for 'Value/Key dont exists', (BlockCount is 1 or 2, info block for ValueData not present) 0x04 for Value = ValueData (BlockCount = 3) 0x08 for Value != ValueData (BlockCount = 3) 0x10 for Value < ValueData (BlockCount = 3) 0x20 for Value =< ValueData (BlockCount = 3) 0x40 for Value > ValueData (BlockCount = 3) 0x80 for Value >= ValueData (BlockCount = 3) |
| 2. Byte: Reserved | 0x00 | ||
| 3. Byte: Reserved | 0x00 | ||
| 4. Byte: Show Icon | 0x00 for Show=FALSE 0x10 for Show=TRUE |
||
| Reserved | 4 | 0x00 00 00 00 | |
| VarNameLen | 4 | Length of the VarName string, Big Endian DWORD | |
| VarName | is in VarNameLen | Name of the environment var | |
| ValueLen | 4 | Length of the Value string, Big Endian DWORD | |
| Value | is in ValueLen |
Value of the environment var | |
Criterion block for condition 'Registry'
This condition can occur as the only criterion block or as one of several blocks, stored in the LDAP attribute zenappInventory (resp. zen2appInventory for legacy rules).
Overview of the criterion block:
Fields:
| Field | Length (Byte) | Content | |
| CriteriaType | 4 | Value 0x24 00 00 00 | |
| BlockCount | 4 | Number of info blocks contained in this criterion, 0x01 00 00 00: Only for Key-(Dont)Exists operator, Value and ValueData not present. 0x02 00 00 00: Only for Value-Exists operator,ValueData not present. 0x03 00 00 00: For all other operators: Subject, Value and ValueData are present. |
|
| TotalLen | 4 | Length of the entire criterion block, Big Endian DWORD | |
| Flag | 4 | 1. Byte: Operator | 0x01 for 'Value/Key exists', (BlockCount is 1 or 2, |
| 2. Byte: Reserved | 0x00 | ||
| 3. Byte: Reserved | 0x00 | ||
| 4. Byte: Show Icon | 0x00 for Show=FALSE 0x10 for Show=TRUE |
||
| Reserved | 4 | 0x00 00 00 00 | |
| SubjectLen | 4 | Length of RegKey strings, Big Endian DWORD | |
| Subject | is in SubjectLen |
Path name of the RegKey | |
| ValueLen | 4 | Length of RegValue name strings, Big Endian DWORD | |
| Value | is in ValueLen |
Name of the RegValue | |
| ValueDataLen | 4 | Length of the registry value, Big Endian DWORD Always 0x04 00 00 00 for REG_DWORDs, otherwise length of the string |
|
| ValueData | is in Value-DataLen |
Registry value for the value comparison, either a string or a DWORD | |
Criterion block for condition 'Application'
This criterion is not stored in the LDAP attribute zenappInventory (resp. zen2appInventory) like the other distribution rules before, but in the attribute
zenappInventoryApplications (resp. zen2appInventoryApplications for Legacy Rules)
These are LDAP attributes of type 'Provider Specific'. That means, it could be any kind of data type and ADSI is not able to identify the structure automatically. The maximum size of such an attribute is unknown.
But obviously there are string values stored here: It is an multivalued (array) string attribute, which can be read accordingly. Each line of this string array contains an application criterion with the following syntax:
Fields:
| Field | Content |
| App-DN | DN of the application object |
| Flag | A decimal number, written as a numeric string, which is derived from a DWORD: 0x10 00 00 01 for 'show=True application installed' (decimal 268435457) 0x10 00 00 02 for 'show=True application not installed' (decimal 268435458) 0x00 00 00 01 for 'show=False application installed' (decimal 1) 0x00 00 00 02 for 'show=False application not installed' (decimal 2) |
Logical connections between the conditions
You can group and combine the criteria of a software distribution rule with any combination of logical operators (AND / OR):
The crucial factor for the structure of this logic is the attribute zenappInventoryTree. In this attribute is the AND/OR combination tree of the criteria stored. But: You cannot use complex logical combinations in the older legacy distribution rules, the attribute zenappInventoryTree doesn't exist neither there.
Structure of the zenappInventoryTree attribute (again, it is an LDAP attribute of type octet string):
Fields:
| Field | Length (Byte) | Content |
| Header | 8 | Always 0x41 4F 54 20 46 49 4C 45 'AOT FILE' |
| FieldType | 4 | Value 0x2D 00 00 00, this is the same as the criterion type of the first criterion in zenappInventory |
| SubType | 4 | Value 0x01 00 00 00 |
| TotalLength | 4 | 0x14 00 00 00 Length of the header criterion |
| LogicCount | 4 | Number of the following 4 byte logical blocks (see below) |
| Reserved | 4 | 0x00 00 00 00 |
After that a variable number of logic blocks follows, each block is 4 DWORDs long (16 bytes). The 4 DWORDS in each block represent a line in the structure of the condition logic (see the screenshot picture above). This is the structure of the blocks:
Fields:
| Field | Length (Byte) | Content |
| Block Type | 4 | 0x00 00 00 00: A normal condition like 'OS Version', 'File Exists', 'File Version', 'Environment' or 'Registry'. The actual data for the condition are stored in the attribute zenappInventory. |
| Operator | 4 | 0x00 00 00 00: AND combination 0x01 00 00 00: OR combination |
| Sibling | 4 | Number of the logic block (counted from 0) which is the second operand for the current combination. If there is no additional operand, the value is -1.
|
| Criteria Number | 4 | For normal conditions like 'OS Version', 'File Exists', 'File Version', 'Environment' or 'Registry', this is the number of the criterion block in the attribute zenappInventory (counted from 0). |
The following examples list the logic blocks for different combinations and groupings. Each logic block contains (like described above) a type, an operator, a sibling number and a criterion number.
