Unlike most software applications, the Intel ASF solution requires configuration data before they can become functional. The IP address of the management console, alerting status enabled and the name of the SNMP community string that the management console is monitoring are some of the configuration items that are needed before the Intel alerting solution is functional. There are a myriad of ways that can be used to configure ASF; this section outlines some of the tools that can be used to configure. Ultimately, administrators must decide how to best configure ASF within their own environment.
Since the Intel ASF install model is MSI based, users can use a database table editor such as Microsoft ORCA, a tool provided with the Windows Installer SDK, to manipulate the install itself. Users can modify items such as the install name, support information, reboot requirements and the default install configuration. Through the use of tools such as ORCA, administrators can create installs that are customized for their organization.
In the case where an organization already has an MSI-based installation that they have created, it is worth considering using the Intel ASF merge modules that are provided. So what is a merge module? First, let’s provide some background on MSI. MSI supports the notion of features and components. Features represent what the end user sees when they install the product. Components represent the binaries and settings that are required to provide the functionality of a feature. Features need to be associated with one or more components. Merge modules represent a container of binaries and associated files and settings for a given component. Next, consider the case of an organization that has an in-house application that uses an MSI-based install. By adding an alerting feature to this pre-existing MSI-based install and associating all of the merge modules – the agent, aprov (agent provider) and custom merge modules in the case of the Intel ASF Agent software stack – you can integrate the full Intel ASF stack with minimal effort. More importantly, leveraging the merge modules enables the IT organization to provide the desired ASF functionality without the associated overhead of tracking yet another application. It is worth noting that the current Intel ASF installs follow the aforementioned model – it is essentially a wrapper around the merge modules provided as part of the Intel ASF solution.
Users should be cautioned that modifications to the base install or making use of the merge modules requires a degree of understanding of MSI and its tables. Please consult the MSI SDK for additional support.
Consider the case of the base Intel ASF install. The configuration settings of the base install will typically need to be modified for any given organization. MSI provides a mechanism called a transform that allows for modifications of a base installation at install time. Technically, a transform represents a template of the differences between two MSI databases.4 To generate a transform, administrators can install the Intel ASF solution to a given machine and configure it with their desired settings. Once this is complete, the administrator can use a tool such as Wise’s Package Studio* or InstallShield’s AdminStudio* to generate a transform. The administrator can then create a package – a package that would include the Intel ASF installation as well as the transform. The package can be deployed throughout the organization. The net result is that organization’s client systems would have the Intel ASF solution installed and configured based on the settings of the prototype system.
Scripts represent another option available to assist configuration of the Intel ASF stack. The Intel ASF solution includes two sample scripts – a VB script and a login script. The scripts should be modified such that the key values suit the needs of the given organization.
A VB script can be deployed in a number of ways. The script can be run locally or remote. It can incorporated into a software deployment package in much the same fashion as a transform – the Intel ASF base install and the VB script would comprise a complete package. Alternatively, the VB script can be an addendum in the user’s login script. Ultimately, the script is used to modify the default base configuration so that the settings conform to the organization’s desires.
The login script leverages the mechanisms of the users pre-existing login environment. The script may be used in conjunction with the user’s base login script or it may use some of the login mechanisms supported in tools such as Microsoft SMS. In the end, it is similar to any of the other mechanism previously mentioned – it modifies the default base settings so that they reflect the settings dictated by the organization.
Group Policy allows the administrator to configure groups of users or systems using Active Directory. Through Group policy, Intellimirror centralizes and simplifies change and configuration management.1 So how does Group Policy work and why is it easier?
The first step in using any Group Policy is to define the group. A group may be a site, a domain or an organization unit. As an example, let’s assume that a group has been created that represented all systems within your network that are Intel ASF capable. Next, consider the fact that group policies can be applied on a user or a system basis. Since ASF is solely focused on monitoring a given system and who is actually using the machine is irrelevant, system policies are the only group policies that need to be created for ASF.
Group policy features that support deployment and configuration are then leveraged for the “ASF Group”. An installation package is pushed to group members and an administrative template is used to configure the systems. Equally as important, Group Policy allows an administrator to lock down the client system so end users cannot modify configuration settings.
Copyright © 2002 Intel Corporation
*Legal Information
Last modified on 6/25/03 4:46p
Revision 2