Unsupported content This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Component design

During the design phase, expert administrators use the Component Templates folder to model the requirements for component templates in a controlled test environment.

Component templates identify the server objects and configuration settings needed to make a component. For example, a component template might specify a collection of files, software, and registry settings needed for an application. Or, a component template might include a collection of configuration settings, such as password lengths and expiration requirements. A component template also includes decisions about how the component should be used and maintained.

When defining component templates, many configurations settings vary between environments. For example, settings may change between servers, networks, or departments. A component template lets you accommodate these differences by using parameters. A parameter can resolve to a different value on each server. For example, the path to a directory can include parameters such as ??TARGET.SYSTEMROOT??/rsc. In this example, ??TARGET.SYSTEMROOT?? can have different values on different target servers, such as /c or /d. Similarly, a path such as /usr/??TARGET.DEPLOYPATH?? could resolve to values like /usr/DEV, /usr/QA, or /usr/PROD. A deploy path like this allows a component to be discovered in different locations on servers used by different departments.

There are several stages to component template design. A wizard helps you initially create a basic component template, as described in Creating-a-component-template. You then refine the template's definition during an editing process, as described in Editing-a-component-template. When editing the template, you can specify any of the following:

  • Allowable Operations — Determines whether a component as a whole can be used for browsing, snapshots and audits, discovery, deployments, and compliance. If a component is subject to compliance, you must also determine whether its configuration can be remediated when compliance failures occur.
  • Template Parts — Defines the collection of configurations on which you can operate. For example, template parts can be collections of files, properties, and registry values or a group of security settings.
     A component template need not include only those parts used by an application. A part can be used for other purposes, such as component discovery and compliance. Some users include a part that should not exist and test for its presence when discovering the component. If the part is present, the component is not discovered.
     When defining component template parts you can choose the types of operations that each part is used for, such as compliance, browsing, snapshots, and audits.
  • Signature — Specifies the set of conditions that a server must satisfy for a component to be created. A signature can be a very simple test, such as verifying the existence of a single server part, or it can be much more sophisticated, specifying multiple mandatory conditions.
     Signatures must be based on template parts and properties. You can specify that a part must exist or that it must exist and satisfy a list of additional criteria in the form of part characteristics. When evaluating part characteristics, you can use many types of operators, such as equivalence, inequality, membership in a list, or inclusion in a range of values. Similarly, you can specify that a part cannot exist. You can also specify that either a part does not exist or, if it does, it must satisfy a list of conditions. If you want to add signature conditions in the form of property values, you can create lists of properties and evaluate those properties with an extensive list of operators, much like you can with parts.
     After you have defined a signature, you can test some representative servers to determine whether you can successfully associate this component template with servers. After a component template is complete, you can run a Component Discovery Job, which examines a server to determine whether it matches the conditions in the component signature. If it does match, a component is associated with the server.
  • Browse — Specifies the individual template parts that can be browsed after a component has been associated with a server.
  • Snapshot and Audit — Specifies the individual template parts that are used in Snapshot and Audit Jobs after a component has been associated with a server. You can use includes and excludes to refine this list of template parts. For example, you can include only DLLs, or exclude log files. You can also specify options that apply when using these template parts in snapshots and audits, such as whether the snapshots and audits should include MD5 checksums.
  • Compliance — Specifies a subset of the component template parts and defines compliance rules that these parts must satisfy. Each compliance rule can include a set of instructions explaining what actions to take if a rule is not satisfied. One possible action is the deployment of a BLPackage to correct the problematic configuration.
     After a component template is complete, you can run a Compliance Job to monitor the configuration of component. For each component, the Compliance Job examines the template parts specified in the compliance rules, comparing them to the rules that you have defined. When a component fails to satisfy the compliance rules and remediation is enabled, you can deploy a BLPackage to correct the issue. Remediation can occur automatically, as part of a Compliance Job, or you examine Compliance Job results and manually remediate compliance rule failures.
  • Local Properties — Specify properties you can assign directly to a component template. Local properties let you discover multiple instances of the same component on the same server. For example, on a single machine you may want to create two versions of the same component --- one for development and one for QA. In such a case, you can use two instances of a local property, with each instance defined to the values you need. A Component Discovery Job automatically discovers a component for each of those local property instances.
    One common usage of local properties is to create a Custom Property Class in the Property Dictionary with instances that contain the various possible values of your properties. The local property in the Component Template (or BLPackage) then links to the custom class. In this way you can re-use the same property structure and values across multiple objects.
  • Local Configuration Objects — Allow you to create configuration objects (that is, configuration files or extended objects) that apply only to this component template. When defining a local configuration object, you can specify a path to that object using local properties as parameters. By setting up properties in this way, you can create one definition of a configuration object that applies to multiple components on the same server.
  • Install/Uninstall — Allows you to install and uninstall components by associating Batch Jobs with component templates. The installer Batch Job runs a series of jobs that deploy all parts necessary to create a component. The uninstaller Batch Job can remove component parts and invalidate an existing component.

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*