dcsimg

Windows Patch Management, BigFix

By Marcin Policht (Send Email)
Posted Sep 29, 2004


The previous article in our Windows Patch Management series began a discussion of third-party patch management products. We continue in this vein, this time concentrating on a versatile and scalable solution that fits equally well in centrally administered, locked-down SMBs; large, distributed enterprises; and unmanaged, Internet-based environments.

One of the main differences between the BigFix products and the Shavlik solution previously looked at is the use of agent-based client operations.
We continue our discussion of third-party patch management products, this time taking a look at BigFix's server-based BigFix Enterprise Suite and its agent-based client software, the Fixlet messaging component.

The solution comes from California-based BigFix in the form of its agent-based client software — the Fixlet messaging component — and the all-encompassing BigFix Enterprise Suite (BES). BigFix provides multiplatform support for all versions of Windows, Red Hat and SUSE Linux, Solaris, and HP-UX, and it will soon support AIX. It goes beyond simple product updates to help with system misconfiguration issues and provides detailed reporting capabilities.

One of the main differences between the BigFix products and the Shavlik solution previously looked at is the use of agent-based client operations. The debate over the benefits of agent-based vs. agentless architecture among patch management products has been going on since their inception.

On the one hand, a lack of agents speeds up and simplifies deployment and reduces the number of components necessary to manage and troubleshoot. On the other hand, remote agents running on each system are typically efficient and sophisticated; they can operate independently, collecting detailed information without significant performance impact and detecting periods when a local processor is idling or hovering at low utilization levels. Additional intelligence built into agents enables them to filter redundant or irrelevant data, which can significantly benefit available network bandwidth and spare resources on the central system during inventory collection.

BigFix Enterprise Suite

BigFix Enterprise Suite's (BES') architecture consists of an Internet-based central patch manager library (maintained by BigFix); the company's central BES Server; one or more BES Relay servers; lightweight, agent-based BES clients that exchange data via proprietary network packets called Fixlets (which serve an important role in software distribution); and BES Administrative Consoles, which provide a central management point.

BES Server constitutes the focal point of the software distribution, inventory collection, and management: According to BigFix, it can manage up to 75,000 targets. The server communicates with the BigFix Internet-based central patch library, maintaining up-to-date knowledge about all available software updates (these can be updates released by BigFix or third-party vendors). Corporate administrative teams then decide which of these patches to deploy within the enterprise.

Once the decision is made, appropriate binaries can be downloaded locally to the server and distributed across all BES clients (alternatively, clients can be instructed to obtain patches directly). However, in large, distributed environments with multiple remote offices separated by slow WAN links, direct communication between clients and one central server can consume significant amounts of bandwidth.

To address this issue, BigFix users can fan out communication paths by implementing BES Relay servers (described in more detail at http://support.bigfix.com/bes/misc/besrelays.html), which can be deployed at multiple locations, as the primary interface to local clients and the bi-directional communication forwarder between them and the BES central server (or intermediary BES Relay servers). Its caching ability, useful for inventory collection and package deployment, reduces bandwidth utilization and remediates problems resulting from lost intersite connectivity. BES Relay servers can form a multilayer hierarchy, forwarding packages in one direction and inventorying or reporting data in the other. BES clients are capable of detecting the closest (in terms of network distance) BES Relay server. In addition to having a lowered impact on network bandwidth, this capability provides a level of fault tolerance, since a client can locate a new server if the one used previously becomes unavailable.

Deployment and configuration of BES Relay servers, as well as other administrative tasks, is performed on the BES Administrative Console. Its fairly intuitive interface allows access to each computer within a given environment running the BES client agent software. It reports WMI-based properties reflecting its status. The information retrievable in this fashion is not limited to vulnerabilities or patch levels but also includes a wide variety of other system characteristics, such as: location (defined using subnet ranges), applications and services (installed and running, with name, version, and vendor data), virus scanning products (software revision and its virus definition file dates), network properties (MAC and IP configuration, IP address assignment method, and dial-up settings), operating system data (version and service pack level, uptime, regional settings, and domain/workgroup membership), hardware specifications (number and type of processors, drives, video, network, sound cards, and serial number), file system details (type, total, and free space), or user information (local users defined with last logon date/time and password settings). A comprehensive list of these properties is available at http://support.bigfix.com/bes/misc/retrievedproperties.html. In addition, Web Reports functionality can be used for generating reports listing computer hardware assets, application estate, or security status (via Web Reports).

A number of administrative tasks can be optimized to meet the requirements of larger environments with thousands of computers. For example, major operating system upgrades (such as service packs), which typically consume substantial amounts of bandwidth, can be performed in stages. To do this, BES server designates the total amount of time within which a particular task should be completed. BES server then uses this value to spread out a distribution across all managed systems. Similarly, distribution targets can be identified dynamically based on the list of property-based criteria defined by an administrator. BigFix agents assess values of properties in real time and, if the match is found, apply the installation to a local system. Otherwise, the package can be maintained in local cache and be rechecked periodically in case criteria have been modified.

>> Fixlets

Page 1 of 2


Comment and Contribute

Your name/nickname

Your email

(Maximum characters: 1200). You have characters left.