IBM Bigfix

Version 9.5

Configuration Guide

IBM
IBM Bigfix
Version 9.5

Configuration Guide

IBM
 Note
Before using this information and the product it supports, read the information in “Notices” on page 135.

This edition applies to version 9, release 5, modification level 7 of IBM BigFix and to all subsequent releases and
modifications until otherwise indicated in new editions.
© Copyright IBM Corporation 2010, 2018.
US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract
with IBM Corp.
© HCL Technologies Limited 2018
Contents
Chapter 1. Introduction . . . . . . . . 1 Validating HTTPS certificates . . . . . . . . 43
What is new in V9.5 . . . . . . . . . . . . 1
Service Management Connect. . . . . . . . . 6 Chapter 7. Configuring secure
Terms used in this guide . . . . . . . . . . 6 communication . . . . . . . . . . . 45
Customizing HTTPS on Web Reports . . . . . . 45
Chapter 2. BigFix Site Administrator and Customizing HTTPS manually on Windows
Console Operators . . . . . . . . . . 7 systems. . . . . . . . . . . . . . . 47
The Site Administrator . . . . . . . . . . . 7 Customizing HTTPS manually on Linux systems 48
The Console Operators . . . . . . . . . . . 8 Customizing HTTPS on REST API . . . . . . . 49
Different ways to define a Console Operator. . . . 8 Customizing HTTPS manually on Windows
Adding Local Operators . . . . . . . . . . 9 systems. . . . . . . . . . . . . . . 50
Mapping authorized activities with permissions . . 11 Customizing HTTPS manually on Linux systems 50
Operators and analyses . . . . . . . . . . 12 Private key and certificate format . . . . . . . 51
Monitoring Operators . . . . . . . . . . . 13
Chapter 8. Downloading files in
Chapter 3. Integrating with LDAP . . . 15 air-gapped environments . . . . . . . 57
Integrating with a Generic LDAP . . . . . . . 15 Overview . . . . . . . . . . . . . . . 57
Integrating with Active Directory . . . . . . . 16 Non-extraction usage overview . . . . . . . 57
Integrating the Windows Server with Active Extraction usage overview . . . . . . . . 60
Directory . . . . . . . . . . . . . . 16 Requirements . . . . . . . . . . . . . . 62
Integrating the Linux Server with Active Using the Airgap tool . . . . . . . . . . . 63
Directory . . . . . . . . . . . . . . 18 Non-extraction usage . . . . . . . . . . 63
Adding LDAP Operators . . . . . . . . . . 23 Extraction usage . . . . . . . . . . . . 71
Associating an LDAP group . . . . . . . . . 26 Log files . . . . . . . . . . . . . . 76

Chapter 4. Enabling SAML V2.0 Chapter 9. Getting client information by

authentication for LDAP operators . . . 29 using BigFix Query . . . . . . . . . 77
What Is SAML 2.0 . . . . . . . . . . . . 29 BigFix Query requirements . . . . . . . . . 77
How SAML works . . . . . . . . . . . . 30 BigFix Query restrictions . . . . . . . . . . 77
Which BigFix user interfaces integrate with SAML Who can use BigFix Query . . . . . . . . . 78
V2.0 . . . . . . . . . . . . . . . . . 30 How to run BigFix Query from the WebUI . . . . 79
How BigFix integrates with SAML V2.0 . . . . . 30 How BigFix manages BigFix Query requests . . . 79
Assumptions and requirements . . . . . . . . 31
What changes from the BigFix user's perspective . . 32 Chapter 10. Archiving Client files on
How to configure BigFix to integrate with SAML 2.0 33 the BigFix Server . . . . . . . . . . 83
Editing the archive manager settings . . . . . . 83
Chapter 5. Using multiple servers Creating a Custom Action . . . . . . . . . 84
(DSA) . . . . . . . . . . . . . . . 37 Archive Manager . . . . . . . . . . . . 84
Disaster Server Architecture (DSA) . . . . . . 37 Archive Manager Settings . . . . . . . . 84
Configuring relay failover . . . . . . . . . 38 Archive Manager internal variables . . . . . 85
Message Level Encryption and DSA . . . . . . 39 Archive Manager Index File Format . . . . . 86
Managing Replication (DSA) on Windows systems 40 Upload Manager . . . . . . . . . . . . 86
Changing the replication interval on Windows Upload Manager Settings . . . . . . . . . 86
systems. . . . . . . . . . . . . . . 40 PostFile. . . . . . . . . . . . . . . . 89
Switching the master server on Windows systems 40 PostFile Settings . . . . . . . . . . . . 90
Managing Replication (DSA) on Linux systems . . 40 Resource Examples . . . . . . . . . . . . 90
Changing the replication interval on Linux
systems. . . . . . . . . . . . . . . 41 Chapter 11. Additional configuration
Switching the master server on Linux systems . . 41 steps . . . . . . . . . . . . . . . 93
Installing and configuring the email notification
Chapter 6. Customizing HTTPS for service . . . . . . . . . . . . . . . . 93
Gathering . . . . . . . . . . . . . 43 Sending email notifications . . . . . . . . 94
Enabling HTTPS . . . . . . . . . . . . . 43 Configuring FillDB . . . . . . . . . . . . 96

© Copyright IBM Corp. 2010, 2018 iii

 Configuring the FillDB database insertion level 96 Creating custom client dashboards . . . . . . 118
Increasing the size of the FillDB buffer directory 97 Geographically locating clients . . . . . . . 120
Enabling FillDB parallel processing . . . . . 98 Locking clients . . . . . . . . . . . . . 121
Configuring ODBC . . . . . . . . . . . . 99 Editing the Masthead on Windows systems . . . 121
Microsoft SQL Database Connection . . . . . 100 Editing the Masthead on Linux systems . . . . 124
DB2 Database Connection . . . . . . . . 101 Obfuscating server passwords . . . . . . . . 125
Configuring the number of Web Reports results 104 Modifying Global System Options . . . . . . 127
Managing Daylight Saving Time (DST) for Web Extending the IBM BigFix License . . . . . . 128
Reports . . . . . . . . . . . . . . . 105 Re-creating Site Credentials. . . . . . . . . 128
FIPS 140-2 cryptography in the BigFix environment 106
Configuring FIPS 140-2 on the BigFix Server . . 106 Chapter 12. Maintenance and
Managing Client Encryption . . . . . . . . 107 Troubleshooting . . . . . . . . . . 129
Generating a new encryption key. . . . . . 109
Monitoring relays health . . . . . . . . . 129
Creating top-level decrypting relays . . . . . 109
Relay and Server diagnostics . . . . . . . . 130
Message Level Encryption (MLE) Overview . . . 110
Virtualized environments and virtual machines . . 131
Changing the Client Icon . . . . . . . . . 111
Optimizing the servers . . . . . . . . . . 112
Optimizing the consoles . . . . . . . . . . 112 Appendix. Support . . . . . . . . . 133
Managing Bandwidth. . . . . . . . . . . 113
Dynamic Throttling . . . . . . . . . . . 113 Notices . . . . . . . . . . . . . . 135
Managing Downloads . . . . . . . . . . 115 Trademarks . . . . . . . . . . . . . . 137
Enabling data pre-cache . . . . . . . . . 116 Terms and conditions for product documentation 138
Dynamic download White-lists . . . . . . 117

iv IBM Bigfix: Configuration Guide

Chapter 1. Introduction
This guide explains additional configuration steps that you can run in your
environment after installation.

In this guide you find information about:

v Chapter 2, “BigFix Site Administrator and Console Operators,” on page 7
v Chapter 3, “Integrating with LDAP,” on page 15
v Chapter 4, “Enabling SAML V2.0 authentication for LDAP operators,” on page
29
v Chapter 5, “Using multiple servers (DSA),” on page 37
v Chapter 6, “Customizing HTTPS for Gathering,” on page 43
v Chapter 7, “Configuring secure communication,” on page 45
v Downloading files in air-gapped environments
v Chapter 9, “Getting client information by using BigFix Query,” on page 77
v Chapter 10, “Archiving Client files on the BigFix Server,” on page 83
v Chapter 11, “Additional configuration steps,” on page 93
v Chapter 12, “Maintenance and Troubleshooting,” on page 129

What is new in V9.5

IBM BigFix Platform Version 9.5 provides new features and enhancements.
Patch 9:
Added signature to the Red Hat installation packages
Starting from BigFix Version 9.5.9, the Red Hat RPM packages for
Server, Agent and Relay are signed with a PGP key. Also the
CentOS BigFix Agent and Relay use the same Red Hat binaries.
The same applies to the Oracle Linux BigFix Agent.
For more information, see Red Hat Installation Instructions .
Ability for endpoints to constrain the download action if the Agent is
not connected to the designated (preferred) Relay
BigFix 9.5.9 introduces the capability to prevent starting actions
requiring downloads when the BigFix Agent is not connected to a
preferred Relay. In such scenario, you can avoid that actions are
executed if the total size of the downloads associated to the action
exceeds a configurable value.
For more information, see Configuration Settings.
Ability for Web Reports to restrict access to some properties
BigFix 9.5.9 introduces a new client setting that allows to configure
a list of properties that will be blacklisted for Web Reports. In such
scenario, you can prevent reporting on large or privacy sensitive
data and you can limit the memory usage.
For more information, see the _WebReports_Properties_Blacklist
setting in the Configuration Settings.

© Copyright IBM Corp. 2010, 2018 1

 Improved Relay scalability by supporting 5000 endpoints per Relay
BigFix leaf relays for the Windows and Linux platforms can be
configured now to manage up to 5000 endpoints.
For the implementation guidelines, see the BigFix capacity
planning guide: Capacity Planning, Performance, and Management
Guide.
Added support for AIX 7.2 on Power 9
Added support for IBM BigFix Agent and Relay on AIX 7.2 on
Power 9.
Patch 7:
New database offered during the installation
When performing a fresh installation of BigFix Server Version 9.5
Patch 7, if no database engine is detected, you can choose whether
to install Microsoft SQL Server 2016 SP1 Evaluation or to manually
install another SQL Server version. The provided evaluation
version is valid for 180 days.
Slimmed down Windows installation files
When performing a fresh installation or an upgrade to Patch 7, the
SQL Server installer is provided as a separate file and is no longer
contained in the BigFix server installer which is now smaller.
Client Deploy Tool enhancements
v Added a new wizard to distribute the agents on all supported
platforms
v Added a new dashboard to view the results of the deployments
v Added the possibility to upload the target log files to the BigFix
server.
Names of files and folders using local encoding on UNIX and Linux
clients
You can specify the names of files and folders of UNIX and Linux
clients in their local encoding, even if it is different from the
encoding on the BigFix server. Depending on the actions to be
completed on the client, you can use a set of commands that are
documented on BigFix Developer site.
Read from and write to files, having different encoding
You can read from and write to files, having different encodings
using the encoding inspector. For additional information see
Reading and writing files in the specific encodings and BigFix
Developer site.
Enhanced Client identity matching when Clients are detected
You can use the new setting (clientIdentityMatch) to allow the
BigFix Server to use the existing computer information to try to
match the identity of a Client and reassign the same ComputerID to
computers that might have been rolled back or restored and avoid
having duplicate computer entries.
New options when running commands as a user local to the target
The override action script command has been improved with new
options to run commands on the target client as user different from

2 IBM Bigfix: Configuration Guide

 the logged on user. For more information, see the override
command on the BigFix Developer web site.
Improved SSL configuration documentation
The documentation of SSL configuration has been updated to
ensure a major consistency across the different BigFix applications.
See the overview of the SSL configuration containing certificate
requirements and links to the SSL configuration procedures for all
BigFix applications: HTTPS across BigFix applications.
Patch 6:
Security enforcement enhancements
v Two new masthead parameters, minimumSupportedClient and
minimumSupportedRelay are added to enforce a higher level of
security in the deployment. For more information, see
Additional administration commands for Windows servers, or
Running the BigFix Administration Tool for Linux servers.
v You can use a new advanced option (requireSignedRegistration
) to ensure that a client registration request is not accepted if
there is at least one relay in the registration chain that is not
upgraded to the same version of BigFix that is installed on the
Server.
New security check on Fixlet/task content
A new security check was added to parse the content of the
imported or generated Fixlet and tasks, and identify the existence
of possible script content. If such content is detected, a Warning
Panel is displayed to the Console Operator.
OpenSSL Initialization changes
Starting from 9.5.6, each BigFix component initializes OpenSSL in
FIPS Mode based on the existence of the client setting
_BESClient_Cryptography_FipsMode, and the client masthead.
Default status of Relay Diagnostic page changed
On both the Server and the Relay components, the Relay
Diagnostic page is now disabled by default. The Relay Diagnostic
page can be enabled again by setting
_BESRelay_Diagnostics_Enable = 1 on those components.
Additional changes
v Resigning of Mac Clients with new certificates
v Console Qualification for Windows 10 Creators Update
Patch 5:
Enablement for the BigFix Detect application
Client Deploy Tool enhancements
v Enabled the agents distribution on all supported platforms by
using a new Fixlet
v Enabled the distribution of the old agent versions, including
agent versions that are no longer supported in BigFix Version 9.5
Added capability to run Fixlet actions as a specific user and to specify
the context for the actions
Specified under which specific user context a specific action must
be run on the endpoint

Chapter 1. Introduction 3
 Airgap tool enhancements
v Added capability to gather information on external sites without
accessing a BigFix server in a secure deployment
v Added file download capability
Enhanced the FillDB component to process agent reports by using a
multi-thread approach
Improved BigFix Platform performance by leveraging multi-core
server resources
Added capability for a Non-Master Operator to stop other Non-Master
Operator actions
Enhanced the BigFix evaluation installation to avoid ripping and
replacing the BigFix deployment if transition to production license is
needed
Improved the user experience for "Try and Buy" scenarios and
promoted the evaluation environment to production environment
without installing again
Enhanced the REST API for Baseline support
Enabled REST API to perform major baseline functionality
available on the console
Enhanced the BigFix agent application usage summary inspector
Collected the process executable path
Enhanced the Mac OS version of BigFix agent and inspectors
v Detected applications installed into the /Library path
v Improved Wi-Fi inspectors
v Leveraged spotlight search when using inspectors for searching
Mac installed applications
v Enabled the process inspectors to report the process path name
Improved the BigFix database layer to enable direct access from Web UI
v Enabled the Web UI not to depend on ETL and ensured
backward compatibility with current Web UI versions still
leveraging ETL
v Improved the Web UI scalability and performance
Enhanced the Client UI end-user experience
v Made running message dialog optionally not dismissible
v Made running message dialog optionally topmost
Enhanced the Self Service application enablement
v Allowed REST API blocking "action-ui-metadata" mime field
included in the baseline and MAG definition
v Added timestamp information of when the offer was issued in
the Offer Available message
Security enhancements
v Changed non-FIPS OpenSSL Windows library to use ASLR
v Created native Red Hat Enterprise Linux (RHEL) Version 6
based agent and relay to allow the client installation when the
operating system is in FIPS mode
Patch 3:

4 IBM Bigfix: Configuration Guide

 Enablement for Remote Web UI deployment
You can deploy the Web UI on a remote endpoint rather than on
the BigFix Server.
Enablement for BigFix Query enhancements
You can target BigFix Query requests to dynamic groups.
Enablement for BigFix Software Distribution enhancements
You can use the Self-Service catalog from the Client UI when using
the SWD application.
Enablement for DB2 HADR
You can run the database backup without requiring the shutdown
of the BigFix Server.
Enablement for BigFix Patch enhancements
A new inspector is added to the set of Client inspectors to allow
the Patch application to discover broken filesets on AIX agents.
Added support for new platforms and database levels
v Microsoft SQL 2016 support
v Tiny core Linux support for relay.
v BigFix agent now supported on:
– SUSE Linux Enterprise 12 on Power 8 Little Endian
– Ubuntu 16.04 on Power 8 Little Endian
– Windows Server 2016 and System Center 2016
– Windows 10 Anniversary Update
– Mac OS 10.12 (Sierra)
Migrated BigFix Platform manuals to the new BigFix Developer site
The content of the following manuals was reworked, improved,
and migrated to the BigFix Developer website, the new repository
for the BigFix Platform development and customization
documentation:
v Relevance Guide
v Action Guide
v API Reference Guide
Earlier versions of these manuals in PDF format are still available
for download at ftp://public.dhe.ibm.com/software/tivoli/IEM/
9.5/Platform/.
Additional enhancements
v SHA-2 signing certificate for Windows binaries
v Capability to install and run the Web Reports as a
non-administrative user.
Patch 2:
BigFix Query
You can use this function to retrieve information and run relevance
queries on client workstations from the WebUI BigFix Query
Application or by using REST APIs. This function is available only
for BigFix Lifecycle or BigFix Compliance Version 9.5 Patch 2 or
later licenses. For more information, see Chapter 9, “Getting client
information by using BigFix Query,” on page 77.
Version 9.5

Chapter 1. Introduction 5
 Unicode support
BigFix Platform V9.5 gathers data from BigFix clients deployed
with different code pages and languages, encodes the data into
UTF-8 format, and reports it back to the BigFix server.
HTTPS gathering
You can gather license updates and external sites via the HTTPS
protocol on a BigFix server or in an airgapped environment.
SAML V2.0 integration
Single-sign-on and CAC/PIV authentication support for BigFix
LDAP operators connecting to the console.
Database cleanup tools
You can use the BESAdmin interface or the BESAdmin command
line to remove data about computers, custom Fixlets, properties,
analyses, and actions and to update the PropertyIDMap table with
changes.
FillDB log rotation
It is active by default with LogFileSizeLimit set to 100 MB.

For more information about the changes and the enhancements introduced with
V9.5, see the Release Notes.

Service Management Connect

Connect, learn, and share with Service Management professionals: product support
technical experts who provide their perspectives and expertise.

Access Service Management Connect at Endpoint Management. Use Service

Management Connect to:
v Become involved with transparent development, an ongoing, open engagement
between other users and IBM developers of Tivoli products. You can access early
designs, sprint demonstrations, product roadmaps, and prerelease code.
v Connect one-on-one with the experts to collaborate and network about Tivoli
and the (enter your community name here) community.
v Read blogs to benefit from the expertise and experience of others.
v Use wikis and forums to collaborate with the broader user community.

Terms used in this guide

BigFix terms are not always labelled with BigFix.

The following terms are all BigFix terms, but are used throughout the guide
without being labeled every time with BigFix:
Agent A computer on which the BigFix client is installed
Console
The BigFix console
Client The BigFix client
Server The BigFix server
Relay The BigFix relay

6 IBM Bigfix: Configuration Guide

Chapter 2. BigFix Site Administrator and Console Operators
In BigFix there are two basic classes of users:
The Site Administrator
The Site Administrator is responsible for installing and maintaining the
BigFix software, and to run administrative tasks that globally affects the
environment such as site-level signing keys management. There is only on
Site Administrator for a BigFix environment. For more information, see
“The Site Administrator.”
The Console Operators
They are the user of BigFix who access the BigFix Console and, if
authorized, the WebUI. They can be Master Operators (MO), the user with
Administrators of the BigFix Console, or Operators (NMO), the day-to-day
managers of their own domains. While, Master Operators can create other
operators and assign management rights, Operators can not. For more
information, see Introducing Operators.

Note: When defining an operator, ensure that the user name does not contain any
of the following characters: :, @, and \.

The Site Administrator

The site administrator has the following primary responsibilities:
Obtaining and securing the Action Site Credentials
To install IBM BigFix, the site administrator must generate a private key,
receive a license certificate from IBM, and create a masthead with the
digital signature and configuration information. This is a special key and
must be used only for site-level tasks such as:
v Setting global system options
v Editing Mastheads
v Administering Distributed Server Architecture (DSA)
Preparing the Server
The IBM BigFix Server must be correctly set up to communicate externally
with the Internet and internally with the Clients. The Server also needs to
be configured to host the IBM BigFix database (or another computer can be
used as the SQL Server database).
Installing the various components
The site administrator installs the IBM BigFix Client, Server, Relay, and
Console modules, and configures the credentials of the first master
operator who will connect to the console to define the license
subscriptions, gather content from subscribed sites, and define the BigFix
network, the roles and the other operators.
The site administrator sets up and administers multiple BigFix Servers in a
Disaster Server Architecture (DSA) for doing automatic BigFix server
failover and failback.
Maintaining the Server
The IBM BigFix server runs an SQL Server database and several specific
services, such as running the Diagnostic Tool and the Administration Tool.

© Copyright IBM Corp. 2010, 2018 7

 Standard maintenance tasks such as upgrades or fixes are managed using
Fixlet technology or can be performed manually by the site administrator.

For day-to-day console operations, the site administrator must create a master
operator key.

The Site Administrator cannot:

v Access the BigFix Console.
v Create operators in addition to the one created during installation.
v Access the BigFix WebUI.
v Run BigFix Queries.

The Console Operators

There are two types of Console operators:
Master Operators (MO)
They are the administrative users of the Console. They have access to all
the computers defined in the BigFix environment and the authority to
create and manage other console operators. Any master operator can
create, assign, and revoke management rights that allow operators to
deploy actions.
Operators or Non-Master Operators (NMO)
They manage the day-to-day BigFix operations, including Fixlet
management and action deployment, against a subset of computers they
are allowed to manage by the master operator. They cannot create other
operators and cannot assign management rights.

By default the Console operators cannot:

v Access the WebUI, unless the Can use WebUI permission is set to YES.
v Submit BigFix queries, unless both Can use WebUI and Can Submit Queries
permissions are set to YES.
These and other permissions can be set by a master operator in the Permissions
area of the Details tab of the operator’s description. For more information about
operators rights, see “Mapping authorized activities with permissions” on page 11.

Different ways to define a Console Operator

There are different ways to add console operators, assigning them roles or granting
permissions to view or manage specific computers and sites,
v You can add single operators at any time by selecting the Tools > Create
Operator item or by right clicking in the operators work area and selecting
Create Operator as described in “Adding Local Operators” on page 9.
v If you are using Active Directory or a generic LDAP, you can add previously
defined users by selecting the Tools > Add LDAP Operator item or by right
clicking in the operators work area and selecting Add LDAP Operator as
described in “Adding LDAP Operators” on page 23.
v You can also associate an LDAP group to an existing role, in this way, with just
one click, you add an operator for each user specified in the LDAP group and
you associate that operator to the role. For more information about this
capability, see “Associating an LDAP group” on page 26.

8 IBM Bigfix: Configuration Guide

 Note: For LDAP operator and LDAP Group an Active Directory or LDAP
directory must first be added to IBM BigFix.

Adding Local Operators

You can create accounts for operators that access the console using the local BigFix
account.

To add a local operator perform the following steps:

1. Click the Tools > Create Operator menu item or right click in the operators
work area and select Create Operator. The Add User dialog appears.

2. Enter the Username of the person you want to designate as a publisher or

operator.
3. Create a Password and retype it for confirmation. When you give the keys to
your operators, they can change their passwords if they want.
4. Click OK. The Console Operator window opens.
5. From the Details tab, assign operator permissions.

where:
Master Operator
Specifies if the operator is a Master operator or not.
Show Other Operator's Actions
Specifies if the operator can see the actions submitted by other
operators.

Chapter 2. BigFix Site Administrator and Console Operators 9

 Note: An operator with the Show Other Operators' Actions
permission can see the action only in the following cases:
v If he is the owner of the action.
v If another operator submitted the action on at least one of his
administered computers, and this computer is administered by both
operators. In this case, the information is available only when the
computer reports back the data to the BigFix server.
Stop Other Operator's Actions
Starting from IBM BigFix Platform V9.5 Patch 5, you can specify if the
operator can stop the actions submitted by other operators. To stop an
action, triggered but not expired yet, the roles or the computer
management rights assigned to the operator must be either identical
or a superset of the roles or the computer management rights assigned
to the operator who submitted the action. To use this capability, the
operator must have also the Show Other Operator's Actions
permission set to 'Yes'.
Can Create Actions
Specifies if the operator can create actions.
Can Lock
Specifies if the operator can lock targets. This is a way to prevent
other operators from running activities on those targets.
Can Send Refresh to Multiple Clients
Specifies if the operator can run a refresh on more than one target
concurrently by clicking the Refresh button on the BigFix console.
Can Submit Queries
Specifies if the operator can submit BigFix Query requests from the
WebUI user interface.
Custom Content:
Specifies if the operator can run activities that require the creation of
custom content.
Unmanaged Assets
Specifies if the operator can manage assets on which no BigFix
component is installed.
An Explicit Permission is a permission that you are assigning to the operator.
An Effective Permission is a permission that is inherited from the roles that
the operator is assigned to. If the values displayed in Explicit Permission and
Effective Permission for the same permission are different, the less restrictive
permission is applied.
You also decide to influence the ability of the operator to trigger restart and
shutdown as Post-Action or to include them in BigFix Action Scripts.

Depending on the configuration that you set for a specific operator for
shutdown and restart, the radio button in the Take action panel might be
disabled for that operator. This configuration has no effect on actions with
type other than BigFix Action Script.

10 IBM Bigfix: Configuration Guide

 You can also set permissions to access the BigFix user interfaces.

6. From the Administered Computers tab, you see the list of computers that this
operator can manage. This list is populated after the computers that satisfy
the criteria specified in the Computer Assignments tab report back their
information to the BigFix server.
7. From the Assigned Roles tab, select the roles to apply to this operator.
8. From the Sites tab, assign the sites you want this operator to have access to.
9. From the Computer Assignments tab, specify the properties that must be
matched by the computers that the operator can manage. For master
operators, all the computers are assigned.
10. From the WebUI Apps tab, specify the WebUI Applications that the operator
is allowed to access.
11. To save the changes click Save Changes.

At any time, you can also convert a local operator to an LDAP operator. To do so,
follow these steps:
1. From any list of local operators, right click on the operator you want to
convert.
2. From the context menu, select Convert to LDAP Operator.

Mapping authorized activities with permissions

The following table shows which activities you can, cannot or could, under specific
conditions, allow an operator to do by assigning permissions in the Details tab of
the Operator Definition. For more information about operator's specific
permissions, see “Adding Local Operators” on page 9.
Table 1. Mapping of authorized activities with operator permissions
Activities Operator
Initialize Action Site No
Manage Fixlet Sites No
Change Client heartbeats No
Create Fixlets If Custom Content is set to YES
Create Tasks If Custom Content is set to YES
Create Analyses If Custom Content is set to YES
Create Baselines If Custom Content is set to YES
Create Groups Manual Groups Only
Activate/Deactivate Analyses Administered
Take Fixlet/Task/Baseline Action Administered
Take Custom Action If Custom Content is set to YES

Chapter 2. BigFix Site Administrator and Console Operators 11

 Table 1. Mapping of authorized activities with operator permissions (continued)
Activities Operator
Stop/Start Actions Administered
Manage Administrative Rights No
Manage Global Retrieved Properties No
View Fixlets Administered
View Tasks Administered
View Analyses Administered
View Computers Administered
View Baselines Administered
View Computer Groups Administered
View Unmanaged Assets Administered
View Actions Administered
Make Comments Administered
View Comments Administered
Globally Hide/Unhide No
Locally Hide/Unhide Yes
Use Wizards If Custom Content is set to YES
Remove computer from database Administered
Create Manual Computer Groups Yes
Delete Manual Computer Groups No
Create Automatic Computer Groups If Custom Content is set to YES
Delete Automatic Computer Groups If Custom Content is set to YES and
Administered
Create Custom Site No
Modify Custom Site Owners No
Modify Custom Site Readers/Writers Site Owners
Create a Master Operator No
Use the WebUI If Can use WebUI is set to YES
Submit BigFix Query If both Can use WebUI and Can Submit
Queries are set to YES
Administered: The operator must own or have permissions.

Requires Custom Authoring: Granted by the site administrator through the console.

Operators and analyses

Operators have various rights and restrictions when activating and deactivating
analyses:
v Ordinary operators cannot deactivate an analysis activated by other operators on
computers they administer.
v Master Operators cannot directly activate custom analyses authored by ordinary
operators. They can, however, make a copy of an analysis and activate the copy.

12 IBM Bigfix: Configuration Guide

Monitoring Operators
If you are a master Operator (you must have a correctly authorized user name
created with the BigFix Administration Tool), you can monitor what other
operators are doing and what computers they are authorized to administer.

Each operator is represented by, among other attributes, a Name, User Type and
Login type. To view the list of Console Operators, select the All Content Domain
and then click the node labeled Operators from the Domain Panel. In the List
Panel on the right, all the current Operators are listed.

Click any operator from the List Panel to open the Operator work area.

There are several tabs to choose from:

v Details: Describes the operator by name and type and lets you select a login
type. This is also where you can view and alter operator permissions.
v Administered Computers: Presents a list of computers that are currently
assigned to the selected console operator.
v Issued Actions: Presents a list of actions that have been issued by the selected
console operator.
v Assigned Roles: Displays the currently assigned roles, and lets you reassign
them.
v Sites: Displays the sites currently assigned to this operator, and lets you reassign
them. If the site is a custom site, you can also set Read/Write/Owner
permissions.
v Computer Assignments: Lists the properties that must be matched by the
computers that the operator can manage. If you specify a property to be
matched, any time a computer is changed to match that property, it is added to
the list of computers assigned to the operator. On the other hand, if a computer
is changed not to match that property, that computer is removed from the list.
This tab is available only for not-master operators.

Chapter 2. BigFix Site Administrator and Console Operators 13

14 IBM Bigfix: Configuration Guide
Chapter 3. Integrating with LDAP
You can add Lightweight Directory Access Protocol (LDAP) associations to BigFix.
That allows you and other users to log in to the console using those credentials.
The same advantage applies also to Web Reports.

Follow the instructions provided in the next topics to learn how to integrate BigFix
with a Generic LDAP or with Active Directory.

After you completed the steps to integrate with one of these two types of LDAP,
you can associate LDAP users or groups to BigFix Console operators or roles as
described in “Adding LDAP Operators” on page 23 and “Associating an LDAP
group” on page 26.

Integrating with a Generic LDAP

Configure the integration with a Generic LDAP by adding an existing LDAP
domain to the console as follows:
1. From the Tool menu, select Add LDAP Directory or right click in the work
area and then select Add LDAP Directory. The Add LDAP Directory dialog
appears.

2. Provide a name and from the Type pull-down, make sure Generic LDAP
Server is selected. Note that no global catalog option is available on generic
LDAP servers.
3. Fill in the information pertaining to your LDAP installation. Under Server,
enter the host name or IP Address of the server.
4. Enter the port number, typically 636 if you are using Secure Sockets Layer
(SSL).
5. Enter the base distinguished name (Base DN), of the form dc=example,dc=com.
6. Click the button to connect anonymously or to use credentials. If you choose
to connect using credentials, enter your User DN and password.

© Copyright IBM Corp. 2010, 2018 15

 7. Click Test to ensure you have entered your information correctly and a
connection can be made to your LDAP.
8. If you want to include user or group filters, click the Show advanced settings
link. After specified, all further LDAP searches will be subject to the
appropriate filter.
9. Click Add to complete the LDAP setup.

Your LDAP Server is now configured and available for use in the console.

Integrating with Active Directory

You can use Microsoft Active Directory (AD) to handle authentication on BigFix.
That allows you and other users to log in to the console using your Active
Directory credentials, taking advantage of your existing authentication policies. The
same advantage applies also to Web Reports.

Note: On Windows platforms, the inspector that manages the calls to the Active
Directory causes an ephemeral port to be allocated on the User Datagram Protocol
(UDP), in addition to the 52311 port already required for the BESClient process.
This port is visible in the output of the netstat -an command.

Integrating the Windows Server with Active Directory

To add an existing Active Directory to the console, follow these steps:
1. From the Tool menu, select Add LDAP Directory. The Add LDAP Directory
dialog appears.

2. Provide a name for the Active Directory and from the Type pull-down, make
sure Microsoft Active Directory is selected.
3. Under Server, enter the host name, IP Address or fully qualified domain name
of the server.
4. To access an entire Active Directory forest, click This is a global catalog server.

16 IBM Bigfix: Configuration Guide

5. Click the button to connect as the root server service user or to use
credentials. If you choose to connect using credentials, enter your Active
Directory Username and Password.
6. Click Test to make sure you have entered your information correctly and a
connection can be made to your Active Directory server.
7. Click Add to complete the Active Directory setup.

Note: When you add an LDAP Server as Microsoft Active Directory, ensure that
on the LDAP server you have defined the UserPrincipalName attribute
corresponding to the User logon name of each user. This attribute value is used on
the BigFix Console for each user authentication.

To add an existing Active Directory running over SSL, you must perform the
following steps:
1. Select Generic LDAP Server as server type.

2. If the server is a global catalog server, specify as port number 3269.

3. Click the Show advanced settings link. The user filter and group filter options
are displayed:

Chapter 3. Integrating with LDAP 17

 4. Enter UserPrincipalName in Login attribute.

Note: The UserPrincipalName attribute cannot be one of the following formats:

domain/user, domain.com/user, or user.
5. Enter (objectClass=user) in User filter
6. Enter (objectClass=group) in Group filter.
7. Click Use the following credentials to connect to the directory server and
enter your Active Directory Username and Password.
8. Click Test to ensure you have entered your information correctly and a
connection can be made to your Active Directory server.
9. Click Add to complete the Active Directory setup.

Your Active Directory Server is now configured and available for use in the
console.

Integrating the Linux Server with Active Directory

To ensure a secure communication between Linux BigFix server and Active
Directory, use the Kerberos protocol.

To integrate the Linux BigFix server with the Windows Active Directory domain
using LDAP with Kerberos authentication, perform the following steps:
1. Ensure that the host names and the time service are set correctly in both the
Linux BigFix server and the Active Directory server
2. Install the NSS and PAM libraries
3. Configure the Kerberos LDAP security and authentication

18 IBM Bigfix: Configuration Guide

4. Modify the local LDAP name
5. Configure the NSS and PAM libraries

Preliminary Checks
Before running the integration between the BigFix server running on a Red Hat
Enterprise Linux 6 or Linux 7 system and the Active Directory server, ensure that:
v The DNS host names of both the Red Hat Enterprise Linux 6 or Linux 7 system
and the Active Directory server are resolved correctly, by performing the
following steps on the Red Hat Enterprise Linux 6 system:
1. Open the file /etc/host and ensure that both DNS host names are specified
as fully qualified domain names.
2. Open the file /etc/sysconfig/network and ensure that the host name of the
Red Hat Enterprise Linux 6 or Linux 7 system is specified as fully qualified
domain name.
v The time between the Active Directory and the Linux BigFix server is
synchronized. If needed, you can synchronize the time service on the Red Hat
Enterprise Linux 6 or Linux 7 system and the Active Directory server with the
time source server, by performing the following steps:
1. In the file /etc/ntp.conf on the Red Hat Enterprise Linux 6 or Linux 7
system, replace the following lines:
server hostname

with:
server time_source_server_name

where time_source_server_name is the server hostname or IP address of the

time source server used to synchronize the time.
2. When DNS lookups are not reliable, configure the Red Hat Enterprise Linux
systems to perform DNS lookups from the Active Directory server by editing
the /etc/resolv.conf file as follows:
domain my.domain.com
search my.domain.com
nameserver1 ipaddress1
nameserver2 ipaddress2
3. Activate the change on the Red Hat Enterprise Linux 6 or Linux 7 system by:
– Stopping the ntp daemon:
service ntpd stop
– Updating the time:
ntpdate Red_Hat_server_IP
– Starting the ntp daemon:
service ntpd start
4. Synchronize the Active Directory server with the time source server by
entering:
w32tm /config /manualpeerlist:"time_source_server_name"
/syncfromflags:manual /update

where time_source_server_name specifies the list of DNS names or IP addresses

for the NTP time source with which the Linux server synchronizes. For
example, you can specify time.windows.com as the NTP time server. When
you specify multiple peers, use a space as the delimiter and enclose the
names of the peers in quotation marks.

Chapter 3. Integrating with LDAP 19

 5. On the Active Directory server, run the following command to ensure that
the time is synchronized with the time source server
w32tm /query /status | find "Source"
w32tm /query /status | find "source"
6. On the Red Hat Enterprise Linux 6 system configure the ntpd daemon to
start at system boot:
chkconfig ntpd on

Installing the NSS and PAM libraries

Ensure that the following NSS and PAM packages are installed:
nss-pam-ldapd-0.7.5-18.2.el6_4.x86_64.rpm
pam_krb5-2.3.11-9.el6.x86_64.rpm

Note: If you have a valid RHN subscription, run yum as shown in the following
example:
yum install nss-pam-ldapd.x86_64 pam_krb5.x86_64

Configuring Authentication
To configure the Kerberos protocol, the LDAP security and the authentication files
for Active Directory integration, you can use one of the following methods:
v system-config-authentication graphical tool
v authconfig command-line tool

Using the system-config-authentication graphical tool:

To configure the authentication with the system-config-authentication tool, perform

the following steps:
1. Run the system-config-authentication graphical tool to define LDAP as the
user account database for user authentication.
2. In Identity & Authentication, from the User Account Database drop-down list,
select LDAP. Selecting the LDAP option allows the system to be configured to
connect to the Windows Active Directory domain using LDAP with Kerberos
authentication.

20 IBM Bigfix: Configuration Guide

3. In LDAP Search Base DN specify to retrieve the user information using the
listed Distinguished Name (DN), such as dc=tem,dc=test,dc=com.
4. In LDAP Server specify the address of the LDAP server such as
ldap://winserver.tem.test.com
5. In Authentication Method select Kerberos password.

Chapter 3. Integrating with LDAP 21

 6. Configures the realm for the Kerberos server in Realm, such as TEM.TEST.COM.
Ensure you enter the Realm name in uppercase.
7. Specify the Key Distribution Center (KDC) in KDCs for issuing Kerberos tickets,
for example, winserver.tem.test.com
8. Specify the administration servers running kadmind in the Admin Servers, such
as winserver.tem.test.com
9. Click Apply.

For more information about how to use this tool, see Launching the Authentication
Configuration Tool UI.

Using the authconfig command-line tool:

To update all of the configuration files and services required for system
authentication, you can run the authconfig command-line tool, as shown in the
following example:
authconfig --enableldap --ldapserver=ldap://winserver.tem.test.com:389
--ldapbasedn="dc=tem,dc=test,dc=com" --enablekrb5
--krb5realm TEM.TEST.COM --krb5kdc winserver.tem.test.com:88
--krb5adminserver winserver.tem.test.com:749 --update

where:
--enableldap
Specifies to configure to connect the system with the Windows Active
Directory domain using LDAP with Kerberos authentication.
--ldapserver
Specifies the address of the LDAP server such as ldap://
winserver.tem.test.com
--ldapbasedn
Specifies to retrieve the user information using the listed Distinguished
Name (DN), such as dc=tem,dc=test,dc=com
--enablekrb5
Enables the Kerberos password authentication method.
--krb5realm
Configures the realm for the Kerberos server, such as TEM.TEST.COM. Ensure
you specify the realm name in uppercase.
--krb5kdc
Specifies the Key Distribution Center (KDC) for issuing Kerberos tickets,
such as winserver.tem.test.com.
--krb5adminserver
Specifies the administration servers running kadmind, such as
winserver.tem.test.com.
--update
Applies all the configuration settings.

For more information about how to use this command, see Configuring
Authentication from the Command Line.

Modifying the local LDAP name

To modify the local LDAP name, perform the following steps:
1. Make a backup copy of the LDAP configuration file as follows:

22 IBM Bigfix: Configuration Guide

 cp -p /etc/nslcd.conf /etc/nslcd.conf.bk
2. Modify the value of the base and uri settings in the /etc/nslcd.conf file as in
the following example:
base dc=tem,dc=test,dc=com
uri ldap://winserver.tem.test.com
3. Restart the local LDAP name service daemon:
service nslcd restart
4. Ensure that the local LDAP name service daemon (nslcd) is set to start with the
server:
chkconfig nslcd on

Configuring the NSS and PAM libraries

To use the LDAP database to authenticate users on a Linux system edit the
/etc/nsswitch.conf and change passwd, shadow and group entries from the SSSD
daemon (sss) to LDAP:
passwd: files sss
shadow: files sss
group: files sss

to LDAP (ldap):
passwd: files ldap
shadow: files ldap
group: files ldap

To configure the PAM libraries, edit the /etc/pam.d/system-auth and

/etc/pam.d/password-auth files and add the pam_krb5.so library entries:
auth sufficient pam_krb5.so use_first_pass
...
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
...
password sufficient pam_krb5.so use_authtok
...
session optional pam_krb5.so

Note: Remove the entries for the SSSD libraries (pam_sss.so).

For additional information on RedHat integration see Integrating Red Hat

Enterprise Linux 6 with Active Directory.

Adding LDAP Operators

You can create accounts for operators to access the console by using an existing
Active Directory or LDAP account. When you select this option, an operator with
the same name as the one specified in the LDAP directory, is added to the
operators node in the Domain Panel on the BigFix console. These operators can
then log in as usual, using one of the following notations:

username
username@domain
domain\username

The permissions assigned to that user in the LDAP directory are not inherited by
the newly created operator. You must either assign the needed permissions to the
operator or assign the operator to an existing role.

Chapter 3. Integrating with LDAP 23

 Note: Starting from version 9.2.6 for accesses to Web UI and Web Reports, and
from version 9.5 for accesses to the Console, you can integrate BigFix with SAML
V2.0 to provide BigFix LDAP operators with:
v Two-factor authentication with Common Access Cards (CAC), Personal Identity
Verification (PIV) cards, or other factors, if required by the Identity Provider.
v Web-based Single Sign-On authentication method from the identity provider
login URL.
For more information, see Chapter 4, “Enabling SAML V2.0 authentication for
LDAP operators,” on page 29.

To add an LDAP operator, complete the following steps:

1. Ensure that the needed Active Directory or LDAP directory is added to the
BigFix environment.
2. Click the Tools > Add LDAP Operator menu item or right click in the work
area and then select Add LDAP Operator. The Add LDAP User dialog
appears.

3. You can query and filter the users defined on the specified LDAP server using
the Search field and the two radio buttons.
4. When you find the user to add as LDAP operator, select it and click Add. The
Console Operator panel opens.

24 IBM Bigfix: Configuration Guide

 5. From the Details tab assign operator permissions.
You can decide to give the operator the ability to trigger restart and shutdown
as Post-Action or to include them in BigFix Action Scripts. Depending on the
configuration that you set for a specific operator for shutdown and restart, the
radio button in the Post Action tab of the Take Action panel might be disabled
for that operator. This configuration has no effect on actions with action script
type other than BigFix Action Script.
You can also set permissions to access the BigFix Console and REST API.
6. The Administered Computers tab lists the computers managed by this
operator.
7. From the Assigned Role tab, select the roles that you want to assign or
unassign this operator to.
8. From the Sites tab, assign the sites that you want this operator to have access
to or unassign them.
9. From the Computer Assignments tab, specify the properties that must be
matched by the computers that the operator can manage.
10. To save the changes click Save Changes.

At any time, you can also convert a local operator to an LDAP operator. To do this,
follow these steps:
1. From any list of local operators, right click on the operator you want to
convert.
2. From the context menu, select Convert to LDAP Operator.

Chapter 3. Integrating with LDAP 25

Associating an LDAP group
You can associate LDAP users or groups, that have been defined in an existing
Active Directory or LDAP directory, to console operators or roles.

To add such a group perform the following steps:

1. Ensure that the needed Active Directory or LDAP directory is added to the
BigFix environment.
2. Create a role to accept your new group by selecting Tools > Create Role or
right click in the work area and then select Create Role.

Enter a name for your group and click OK.

3. The Role panel appears.

Click the LDAP Groups tab.

4. Select the LDAP group that you want to assign to this role and click Assign
LDAP Group.
5. To save the changes click Save Changes.

When you assign an LDAP group to a role, any user from that group can then log
in to the console. Only those users who actually log in will be provisioned with
accounts and thus end up in the list of operators. This avoids the creation of
unnecessary accounts. Operators are granted the highest privileges resulting from
the sum of all their roles and permissions. For instance, if a user has access to
26 IBM Bigfix: Configuration Guide
computer set A and sites X from role 1, and computer set B and sites Y from role 2,
they will have permissions for Sites X and Y across both computer sets A and B.

Chapter 3. Integrating with LDAP 27

28 IBM Bigfix: Configuration Guide
Chapter 4. Enabling SAML V2.0 authentication for LDAP
operators
Starting from version 9.2.6, BigFix supports SAML V2.0 authentication via
LDAP-backed SAML identity providers. After configuration, SAML V2.0 support
enables:
v Two-factor authentication for BigFix with Common Access Cards (CAC),
Personal Identity Verification (PIV) cards, or other factors, if required by the
Identity Provider.
v Web-based Single Sign-On authentication method from the identity provider
login URL. Logged in users are automatically redirected, upon request, to the
web-based components that support SAML V2.0 authentication without having
to log in again.

What Is SAML 2.0

The OASIS Security Assertion Markup Language (SAML) is a standard that uses
an XML-based framework to describe and exchange security information between
online entities.

SAML 2.0 supports:

Web-Based Single Sign-On
It provides a standard vendor-independent grammar and protocol for
transferring information about a user from one web server to another,
independent of the server DNS domains.
Identity federation
It allows partner services to agree on and establish a common name
identifier for the user to share information about themselves across
organizational boundaries.
This type of sharing helps to reduce identity management costs.
Federated identity implements FIPS 201 to define a US Government-wide
interoperable identification credential, known as the Personal Identity
Verification (PIV), for controlling physical access to federal facilities and
logical access to federal information systems.
The CAC PIV card is a multi-application smart card for PIV Cardholder
authentication that contains a linear barcode, two-dimensional barcode,
magnetic stripe, color digital photograph, and printed text. It serves as a
token for:
v Logical access to computer systems
v Personnel identification
v Physical access to buildings
v Public-Key Infrastructure (PKI) for signing, encryption, and
non-repudiation.
Web services and other industry standards
SAML allows its security assertion format to be used outside a “native”
SAML-based protocol context. This modularity has proved useful to other

© Copyright IBM Corp. 2010, 2018 29

 industry efforts addressing authorization services (IETF, OASIS), identity
frameworks, web services (OASIS, Liberty Alliance), and so on.

How SAML works

The SAML specification defines three parties:
v The principal, which is typically a user.
v The Identity provider (IdP), which is the LDAP-backed SAML identity provider.
v The service provider (SP), which in this case are the BigFix services.

The SAML standard controls how the identity assertions are exchanged among
these three parties. SAML does not specify the method of authentication at the
identity provider.

In SAML, one identity provider can provide SAML assertions to many service
providers.

For more information about SAML V2.0 use case scenarios, see SAML V2.0
Overview.

Which BigFix user interfaces integrate with SAML V2.0

The SAML authentication enhancement, when configured, affects all BigFix LDAP
managed users accessing the Web UI, the Web Reports and, starting from IBM
BigFix V9.5, the BigFix console.

How BigFix integrates with SAML V2.0

The integration with SAML V2.0 uses the passport-saml authentication provider to
allow both Identity provider (IdP) initiated and Service provider (SP) initiated
authentication.

The SAML use and requests are managed, for all the BigFix user interfaces that
support it, by a WebUI component.

The way you configure the integration with SAML depends on the use that you
plan to do:
v If you want to use the SAML authentication for Web Reports and for theBigFix
console only, and you do not need to use it with any WebUI application, you
can start the WebUI in SAML-only mode. This SAML configuration allows you
to minimize resource consumption. For more information about how to set up
this configuration, see Enabling the WebUI in SAML-Only Mode.
v If you want to use the SAML authentication for all the BigFix user interfaces,
including the full set of WebUI components, or the WebUI's ETL process, follow
the instructions provided in Enable the WebUI (Platform V9.2.6 – V9.5.2), if you
are using a version of IBM BigFix earlier than V9.5.3, or the instructions
provided in WebUI Installation Checklist if are using IBM BigFix V9.5.3 or later.

If the BigFix environment uses one LDAP server as a user repository, user
provisioning is not affected by this integration, and administrators continue to
define operators and roles to authorize them to use BigFix services. If your BigFix
environment operators are defined on more than one LDAP server, read carefully
the information provided in “Assumptions and requirements” on page 31.

30 IBM Bigfix: Configuration Guide

 Integration with SAML 2.0 maintains existing audit scenarios and includes
SAML-authenticated user entries in the server_audit.log file.

See the following sample use case:

1. The user requests a service from BigFix, for example, accesses a page or
attempts to log in, through the Web UI, the Web Reports or the BigFix console.
2. BigFix requests an identity assertion from the LDAP-backed SAML identity
provider.
3. Before delivering the identity assertion, the LDAP-backed SAML identity
provider might request some user authentication information, such as user
name and password, or another form of authentication, including multi-factor
authentication. A directory service such as LDAP or Active Directory is a
typical source of authentication token at an identity provider.
4. On the basis of the identity assertion provided by the identity provider, BigFix
decides whether to perform the service requested by that user.
5. The authentication information is retained and used to allow automatic access
for the user, according to the assigned permissions, to the services provided by
BigFix.

Assumptions and requirements

Before configuring BigFix to use SAML V2.0, carefully read the following list of
assumptions and requirements:
v BigFix supports SAML V2.0 authentication with an SAML V2.0-compliant
identity provider such as Active Directory Federation Services (ADFS).
v The SAML V2.0 authentication is restricted to:
– Only one SAML IdP backed by one or more LDAP directories. If you already
defined multiple LDAP servers as user repositories in your BigFix
environment, be aware that, after enabling SAML authentication, only the
users and the groups managed by the selected IdP will still be known to the
BigFix environment. In this case, ensure that your IdP environment is
correctly configured so that the SAML IdP (ADFS or ISAM) can authenticate
users from the different LDAP environments that you want to use as the user
repository.
– Identity providers using SHA256 as secure hash algorithm.
– Web Reports servers connecting to only one data source (Root server) and
configured with SSL.
v To configure and use SAML authentication, you must enable the use of the Web
UI by running, from the console, the task 2252 - Enable WebUI available under
BES Support. If you are using the Web UI solely for providing SAML
authentication for Web Reports and the BigFix console, you can start the Web UI
in SAML-only mode to reduce resource consumption. For information about
how to start the Web UI in SAML-only mode, see http://www.ibm.com/
support/knowledgecenter/SSTK87_9.5.0/com.ibm.bigfix.webui.doc/WebUI/
Admin_Guide/c_saml_2_0.html.
v In DSA architecture, the configuration is replicated to replica DSA servers.
However, the replica does not enable Web UI for SAML on non-primary DSA's,
which means that you must run the task 2252 - Enable WebUI from the console
on each secondary DSA server.
v When running Web Reports, if SAML is enabled, the check on the referrer is not
performed. You can use the setting _HTTPServer_Referrer_CheckEnabled to
enable or disable the referrer check. The referrer is an optional header of the

Chapter 4. Enabling SAML V2.0 authentication for LDAP operators 31

 HTTP protocol. It identifies the address of the web page (that is the URI or IRI)
that linked to the resource being requested. For information about how BigFix
manages the referrer check, see Configuration settings.

What changes from the BigFix user's perspective

From the BigFix user interfaces operator’s perspective, this enhancement affects
only authentication.

After enabling SAML authentication for LDAP users:

LDAP operators:
v Must authenticate to the Web UI and to the Web Reports from the SAML
identity provider only by accessing the following URLs:
https://<WebUI_server> (for the Web UI server, assuming that it uses
port 443)
https://<Web_Reports_server>:8080 (for each Web Reports server,
assuming that port 8080 is used)

Note: The buttons and links to log out from the Web UI and the Web
Reports redirect these users to a page where they can click a
Re-authenticate button to get back to Web UI and Web Reports pages
without having to log back on, unless the IdP login timeout has expired;
in this case they are brought back to the IdP login page.
v Must enable the Use SAML authentication check box in the Console
login panel, if the BigFix server was configured to integrate with SAML
V2.0.

The selection is automatically validated and retained by BigFix for future

login requests.
Local non-LDAP operators:
v Log in to the Web UI or to the Web Reports by accessing the usual login
URLs:
https://<WebUI_server>/login (assuming that the Web UI is set on port
443)
https://<Web_Reports_server>:8080/login (for each Web Reports server,
assuming that Web Reports is set on port 8080)

32 IBM Bigfix: Configuration Guide

 v Log in to the BigFix Console from the usual login panel ensuring that
the Use SAML authentication check box is not selected.

Note: If SAML is not enabled in the environment, the Use SAML

authentication check box is greyed out.

After SAML is configured and enabled only local non-LDAP users will be able to
log in using API; the 4-eyes authentication approvers must be local accounts.

How to configure BigFix to integrate with SAML 2.0

Before configuring the integration, ensure that:
v The BigFix server can resolve the hostname used in the URL for the identity
provider login page.
v The identity provider (ADFS server or another type of supported SAML
authentication providers) can resolve the BigFix root server hostname specified
in the redirect URLs used to communicate with the Web UI, Web Reports, and
BigFix console.
v The Web UI is enabled and active.

The overall configuration comprises two parts:

v The configuration of the SAML identity provider for explicit two-factor
authentication, which is under the responsibility of the identity provider
administrator. For what concerns this part, ensure that:
– The redirect URLs are added to the relying party trust indexed, with binding
HTTPS_POST, and in this format:
https://<WebUI_server>/saml (for the Web UI server, assuming that it listens
on port 443)
https://<Web_Reports_server>:8080/saml (for each Web Reports server,
assuming that they listen on port 8080)
https://<Bigfix_server>:52311/saml (for the BigFix Console)

Note: If the identity provider is ADFS, the redirect URLs must be added, as
SAML Assertion Consumer Endpoints, in the Endpoints tab inside the ADFS
Relying Party Trust properties.
– In the Identity Provider configuration, the login setting must be set for
FORMS login.
– If you plan to use the smart card authentication, ensure that the Identity
Provider is correctly configured to use multi factor authentication. For
example, if you use ADFS, ensure that at least one between Certificate
Authentication and Windows Authentication, if you want to use the Windows
Integrated Authentication, is enabled in the Global Authentication Policy
configuration.
– For Active Directory user authentication, set the identity provider Claim Rules
as follows:
Attribute store:
Active Directory
Mapping of LDAP attributes to outgoing claim types:
- LDAP Attribute: User-Principal-Name
- Outgoing Claim: Name ID

Chapter 4. Enabling SAML V2.0 authentication for LDAP operators 33

 v The configuration to allow the BigFix server to use SAML authentication, which
is a Master Operator (MO) and Web Reports administrator responsibility.
Complete these steps to accomplish this task:
1. Configure LDAP with Active Directory in the BigFix Console. For more
details, click here.
2. Define LDAP operators. For more details, click here.
3. Define Web Reports LDAP operators in the Web Reports user management
pages. For more details, click here.
4. Access the Administration page to configure the integration with SAML 2.0:
https://<WebUI_server>/administrator (if the Web UI listens on port 443)
https://<WebUI_server>:<webui_port_number>/administrator (if the Web
UI listens on a port different from 443).

5. In the Administration page, specify:

Entry Point:
The Identity Provider login URL. It is the URL from where the
operator can log in and be redirected back to Web UI or to the Web
Reports, for example https://<idp_fqdn>/adfs/ls.
Signing Certificate:
Browse for the certificate file or paste in this field the key from the
Identity Provider certificate in Privacy Enhanced Mail (PEM)
format.
Issuer: Enter the Identity Provider Identifier in a textual format, for
example "BigFix". If you are configuring ADFS configuration, this
value must match the ADFS Relying Party Identifier setting.
6. After filling in all the fields, click the Enable button.
7. If WebUI is installed on a separate remote server, set the
_WebUI_AppServer_Hostname key of the BigFix server computer to the
hostname of the computer where the WebUI is installed (the WebUI Server
computer).
8. If you want to enable the use of smart cards as SAML authentication
method, set on the WebUI Server computer the
_WebUIAppEnv_SAML_AUTHNCONTEXT setting to one of the following two values:
– urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient if the Identity
Provider is set to use the Transport Layer Security (TLS) cryptographic
protocol.
– urn:federation:authentication:windows if the Identity Provider is set to
use Integrated Windows Authentication (IWA).

34 IBM Bigfix: Configuration Guide

 Then restart the WebUI.
9. Restart the BES root server.
10. Restart the BES Web Reports services.
It might take a while for the Web UI to restart after you set up this configuration
and restarted the BES root server.

After these steps are successfully run, all LDAP operators from these services must
authenticate through the configured identity provider.

An administrator can use the Administration page also to update the existing
configuration.

Chapter 4. Enabling SAML V2.0 authentication for LDAP operators 35

36 IBM Bigfix: Configuration Guide
Chapter 5. Using multiple servers (DSA)
Here are some of the important elements of multiple server installations:
v Servers communicate on a regular schedule to replicate their data. To review the
current status and adjust the replication interval see “Managing Replication
(DSA) on Windows systems” on page 40 or “Managing Replication (DSA) on
Linux systems” on page 40.
v When each server is ready to replicate from the other servers in the deployment,
it calculates the shortest path to every other server in the deployment. Primary
links are assigned a length of 1, secondary links 100, and tertiary links 10,000.
Links that resulted in a connection failure the last time they were used are
considered to be non-connected.
v When an outage or other problem causes a network split, it is possible for a
custom Fixlet or a retrieved property to be modified independently on both
sides of the split. When the network is reconnected, precedence goes to the
version on the server with the lowest Server ID.
v If multiple copies of Web Reports are installed, they operate independently.
Each Web Report server can connect to the server that is most convenient,
because they all contain equivalent views of the database.
v By default, server 0 (zero) is the master server. The IBM BigFix Administration
Tool on Windows and the BESAdmin command on Linux only allow you to
perform certain administrative tasks (such as creating and deleting users) when
connected to the master server.
v Depending on the platform where you installed the server, you can switch the
master to another server as it is explained in “Managing Replication (DSA) on
Windows systems” on page 40 or “Managing Replication (DSA) on Linux
systems” on page 40.

Disaster Server Architecture (DSA)

The following diagram shows a typical DSA setup with two servers. Each Server is
behind a firewall, possibly in a separate office, although it is easy to set up
multiple servers in a single office as well. The servers must have high-speed
connections to replicate the IBM BigFix data (generally LAN speeds from 10 to
100Mbps are required). The IBM BigFix servers communicate over ODBC and
HTTP protocols.

In case of a failover, the specific configured relays automatically find the backup
server and reconnect the network. For more information about the relay
configuration see “Configuring relay failover” on page 38.

© Copyright IBM Corp. 2010, 2018 37

Configuring relay failover
If an BigFix server goes down, whether due to disaster or planned maintenance,
the DSA server might be used to find a new server connection. When the disabled
server comes back online, its data will automatically be merged with the data on
the healthy server.

In order for the failover process to successfully occur set the DSA server as the
secondary relay in client settings using __RelayServer2 for the top-level relays (or
via the console Computer right-click settings user interface). When a failure on the
primary IBM BigFix server occurs and lower level IBM BigFix relays are unable to
report, they use the secondary IBM BigFix relay value during normal relay
selection process to find and report to the secondary IBM BigFix server.

Note: The setting _BESClient_RelaySelect_ResistFailureIntervalSeconds

specified on the client system can have an impact on failover timing. Its value can
range from 0 seconds to 6 hours and it defines how many seconds the client
ignores reporting failures before attempting to find another parent relay. The
default value is 10 minutes. In case of a failover configuration, ensure that, if
defined, _BESClient_RelaySelect_ResistFailureIntervalSeconds is set to a low

38 IBM Bigfix: Configuration Guide

 value.

Message Level Encryption and DSA

If Message Level Encryption is enabled and clients are set using Task: BES Client
Setting: Encrypted Reports, move the BigFix server encryption key to the
secondary BigFix DSA server. This enables the BigFix DSA server to process reports
from encrypted BigFix clients during normal operations or in the event of an
outage on the primary BigFix server.

Copy the encryption key (.pvk) from the BigFix server directory:
v Windows server: %PROGRAM FILES%\BigFix Enterprise\BES Server\Encryption
Keys\
v Linux server: /var/opt/BESServer/Encryption Keys
to the DSA secondary server.

Chapter 5. Using multiple servers (DSA) 39

Managing Replication (DSA) on Windows systems
Replication servers are simple to set up and require minimal maintenance. You
might want to change the interval or allocate your servers differently. Most of
these changes are done through the IBM BigFix Administration Tool. Here you can
see the current settings for your servers and make the appropriate changes.

Changing the replication interval on Windows systems

On Windows systems if you have multiple servers in your deployment, you can
schedule when each one replicates. The default is five minutes, but you can
shorten the time for greater recoverability or increase it to limit network activity:
1. Start up the IBM BigFix Administration Tool.
2. Select the Replication tab.
3. Click the Refresh button to see the latest Replication Graph.
4. Select the server you want from the drop-down menu. Using longer replication
intervals means that the servers replicate data less often, but have more data to
transfer each time. Note that replication intervals can be different for
“replicating from” and “replicating to” a server.
5. Select the replication interval from the menu on the right.
6. Click OK.

Switching the master server on Windows systems

By default, server 0 (zero) is the master server. The Administration Tool allows you
to perform certain administrative tasks (such as creating and deleting users) only
when you are connected to the master server. If you want to switch the master to
another server, you must set the deployment option masterdatabaseServerID to
the other server ID. Here is how:
1. Start up the IBM BigFix Administration Tool.
2. Select the Advanced Options tab and click Add.
3. Type masterDatabaseServerID as the name, and then enter the other server ID
as the value.
4. Click OK.

After the value has successfully replicated to the new server, it become the master
server. If a server suffers a failure while it is the master, another server must be
made the master server by direct manipulation of the ADMINFIELDS table in the
database. The details of this are beyond the scope of this guide, but broadly
speaking, you might use a tool like SQL Enterprise Manager to view and alter the
ADMINFIELDS table. Set the variable name masterDatabaseServerID to the value
you want.

Managing Replication (DSA) on Linux systems

Replication servers are simple to set up and require minimal maintenance. You
might want to change the interval or allocate your servers differently. Most of
these changes are done through the iem command line. Here you can see the
current settings for your servers and make the appropriate changes.

40 IBM Bigfix: Configuration Guide

Changing the replication interval on Linux systems
On Linux systems if you have multiple servers in your deployment, you can
schedule when each one replicates. The default is five minutes, but you can
shorten the time for greater recoverability or increase it to limit network activity:

To change the replication interval, perform the following steps:

1. From the /opt/BESServer/bin command prompt, start the command line:
./iem login --server=servername:serverport --user=username
--password=password
2. From the /opt/BESServer/bin command prompt, run the following command:
./iem get replication/server/0 > /appo/replicationServer0.xml
3. In the /appo/replicationServer0.xml file, edit the following keyword:
<ReplicationIntervalSeconds>300</ReplicationIntervalSeconds>

to change the value in seconds of the replication interval. Using longer

replication intervals means that the servers replicate data less often, but have
more data to transfer each time.
<?xml version="1.0" encoding="UTF-8"?>
<BESAPI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="BESAPI.xsd">
<ReplicationServer Resource="http://9.87.126.68:52311/api/replication
/server/0">
<ServerID>0</ServerID>
<URL>http://nc926068.romelab.it.ibm.com:52311</URL>
<DNS>nc926068.romelab.it.ibm.com</DNS>
<ReplicationIntervalSeconds>300</ReplicationIntervalSeconds>
<ReplicationLink Resource="http://9.87.126.68:52311/api/replication
/server/0/link/3">
<SourceServerID>0</SourceServerID>
<DestinationServerID>3</DestinationServerID>
<Weight>1</Weight>
<IsConnected>0</IsConnected>
<LastReplication>Fri, 01 Mar 2013 11:17:12 +0000
</LastReplication>
<LastError>19NoMatchingRecipient - Fri, 01 Mar 2013 11:17:12 +0000
</LastError>
</ReplicationLink>
<ReplicationLink Resource="http://9.87.126.68:52311/api/replication/server/
3/link/0">
<SourceServerID>3</SourceServerID>
<DestinationServerID>0</DestinationServerID>
<Weight>1</Weight>
<IsConnected>1</IsConnected>
<LastReplication>Fri, 01 Mar 2013 11:17:18 +0000
</LastReplication>
</ReplicationLink>
</ReplicationServer>
</BESAPI>
4. Upload the modified file by running the following command:
./iem post /appo/replicationServer0.xml replication/server/0

Switching the master server on Linux systems

By default, server 0 (zero) is the master server. To switch the master to another
server, set the deployment option masterDatabaseServerID to the other server ID as
follows:
1. From the /opt/BESServer/bin command prompt, start the command line:

Chapter 5. Using multiple servers (DSA) 41

 ./iem login --server=servername:serverport --user=username --password=password
2. From the /opt/BESServer/bin command prompt, run the following command:
./iem get admin/fields > /appo/switchmaster.xml
3. In the /appo/switchmaster.xml file, add or edit the following keyword and its
value:
<Name>masterDatabaseServerID<Name>
<Value>0</Value>

to switch the master server to another master server:

<?xml version="1.0" encoding="UTF-8"?>
<BESAPI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="BESAPI.xsd">
<AdminField Resource="http://9.87.126.68:52311/api/admin/field
/masterDatabaseServerID">
<Name>masterDatabaseServerID</Name>
<Value>3</Value>
</AdminField>
</BESAPI>
4. Upload the modified file by running the following command:
./iem post /appo/switchmaster.xml admin/fields

After the value has successfully replicated to the new server, it become the master
server. If a server suffers a failure while it is the master, another server must be
made the master server by direct manipulation of the ADMINFIELDS table in the
database.

42 IBM Bigfix: Configuration Guide

Chapter 6. Customizing HTTPS for Gathering
You can gather license updates and external sites by using the HTTPS protocol on
a BigFix server or in an airgapped environment.

To enable the HTTPS protocol you must set a client keyword.

After enabling HTTPS, you can create or download (from the curl website) a
package of certificates that you want to trust. The curl website offers a prebuilt
package that contains the same certificates that are included with Mozilla.

The BigFix server starts the certificate verification during gathering, trusting the
provided certificates.

Enabling HTTPS
To gather the external sites by using the HTTPS protocol, complete the following
steps

On the BigFix Server:

Set the client property _BESGather_Use_Https to 0 or 1

When setting the property to 0, the server uses the protocol defined in the URL.

When setting the property to 1, the server tries to gather all sites using the HTTPS
protocol only.

In the airgapped environment:

Launch the Airgap command as follows:

Airgap -usehttps

The server tries to gather all sites using the HTTPS protocol only.

Validating HTTPS certificates

By default the HTTPS certificates used for enabling the HTTPS connection are
validated by using the certificate bundle included in the BigFix server installation.

The Windows default path is:

C:\Program Files (x86)\BigFix Enterprise\BES Server\Reference\ca-bundle.crt

The Linux default path is:

/opt/BESServer/Reference/ca-bundle.crt

To validate the HTTPS certificates with a custom bundle of trusted certificates

before the HTTPS gathering, complete the following steps:
1. Create or download a set of trusted certificates (for example,
http://curl.haxx.se/ca/cacert.pem). The certificates that you can use are:
v "VeriSign Universal Root Certification Authority" (to gather sites)
v "thawte Primary Root CA - G3" (to check license updates)

© Copyright IBM Corp. 2010, 2018 43

 2. On the Server:
Set the client property _BESGather_Use_Https to 1 for using the HTTPS protocol
and _BESGather_CACert keyword to the path of the downloaded set of trusted
certificates ( for example c:\TEM\certificates\custom-ca-bundle.crt on
Windows systems and /TEM/certificates/custom-ca-bundle.crt on Linux
systems).
In the airgapped environment:Launch the Airgap tool with the option -cacert
<path>:
Airgap -cacert <path>

where <path> is the path of the saved set of trusted certificates.

44 IBM Bigfix: Configuration Guide

Chapter 7. Configuring secure communication
BigFix automatically enables the Secure Socket Layer (SSL) protocol by using
self-signed certificates to ensure secure communication between your Web Reports
or Rest API server and all users that access it. If you don't want to use the
provided private key and the self-signed certificate complete the following steps:
1. Generate a private key and a certificate signing request (CSR) for a CA signed
certificate. For additional information on the private key and certificate format
see “Private key and certificate format” on page 51.
The advantage of using an external CA is that root certificates of known public
CAs are imported by default into modern web browsers.

Important: You can use the private key and the certificate generated for BigFix
Inventory or License Metric Tool also for Web Reports only if the private key is
not password protected.
For additional information on how to get these files see “Creating private keys
and certificates” on page 52 and “Signing certificates” on page 53.
2. Copy the files to a folder of your choice on the Web Reports or Rest API server.
3. Configure the Web Reports server or REST API server as described in
“Customizing HTTPS on Web Reports” and “Customizing HTTPS on REST
API” on page 49.

Note: You can also configure Web Reports or Rest API to work with Hyper
Text Transport Protocol Secure (HTTPS) manually without using the console.
For additional information, see Configuring HTTPS manually on Windows
systems and Configuring HTTPS manually on Linux systems for Web Reports,
and “Customizing HTTPS manually on Windows systems” on page 50 and
Configuring HTTPS manually on Linux systems for Rest API.
4. Depending on which component you are setting HTTPS, restart the
corresponding service, BESWebReports for Web Reports and BES Server for
Rest API:
Web Reports
v On Windows, open Services, select BESWebReports and on the Action
menu, click Restart.
v On Linux, run from the prompt: service beswebreports restart or
/etc/init.d/beswebreports restart.
Rest API
v On Windows, open Services, select BESServer and on the Action menu, click
Restart.
v On Linux run from the prompt: service besserver restart or
/etc/init.d/besserver restart.

Customizing HTTPS on Web Reports

If you have a trusted SSL security certificate and key from a certificate authority,
you can configure the BigFix Web Reports computer to use this certificate and key
to enable trusted connections.

Complete the steps to accomplish the following tasks:

© Copyright IBM Corp. 2010, 2018 45

 v Specify that you are using a secure communication.
v Specify where the SSL certificate and private key files are located.
v Define the HTTPS port number, listening for HTTPS connections and redirecting
the client to HTTPS on the SSL port.
1. From the BigFix console, select the Computers tab.
2. Select the computer on which Web Reports runs and Edit Computer Settings
from the Edit menu.
3. Look for the _WebReports_HTTPServer_UseSSLFlag setting. If it exists, do not
create a second one, but edit its value to 1 to enable HTTPS. If it does not exist,
add it.

Important: If you combined the private key file with the certificate file, skip
the following step and set only the
_WebReports_HTTPServer_SSLCertificateFilePath setting.
4. Look for the _WebReports_HTTPServer_SSLPrivateKeyFilePath setting. If it
exists, do not create a second one, but edit its value to the full path name of the
private key (.pvk file) which contains the private key for the server. The private
key must not have a password. If it does not exist, add it.
5. Look for the _WebReports_HTTPServer_SSLCertificateFilePath setting. If it
exists, do not create a second one, but edit its value to the full path name of the
.pem file which might contain both the certificate and private key for the server,
or only the certificate. If it does not exist, add it.

Ensure that the .pem file is in standard pem file format.

The certificate is supplied by the server to connecting clients (browsers) and
they present a dialog to the user containing information from the certificate. If
the certificate meets all of the trust requirements, then the browser connects
without any interventions by the user. If the certificate does not meet the trust
requirements of the browser, then the user is prompted with a dialog that asks
if it is OK to proceed with the connection, and giving them access to
information about the certificate. A trusted certificate is signed by a trusted
authority (such as Verisign), contains the correct host name, and is not expired.

46 IBM Bigfix: Configuration Guide

 Note: These settings are stored in the registry under the key
HKLM/Software/WoW6432Node/BigFix/EnterpriseClient/Settings/Client of the
Web Reports computer.
6. Look for the _WebReports_HTTPServer_PortNumber setting. If it exists, do
not create a second one, but edit its value to the port number you would like to
use. If it does not exist, add it:

7. When SSL is enabled define the forwarding port with the following settings:
v _WebReports_HTTPRedirect_Enabled to 1
v _WebReports_HTTPRedirect_PortNumber to the port listening for HTTP
connection and redirecting the client to HTTPS.
8. To require TLS12 for web browser requests, look for
_WebReports_HTTPServer_RequireTLS12. If it exists, do not create a second
one, but edit its value to 1. The Web Reports component always uses TLS 1.2
when communicating with the BigFix server, regardless of local settings or
settings of the masthead.

Important: Use of a TLS with a version earlier than 1.2 is deprecated.

9. Restart the BES Web Reports Server service:
v On Windows, open Services, select BESWebReports and on the Action
menu, click Restart.
v On Linux run from the prompt: service beswebreports restart or
/etc/init.d/beswebreports restart

You can also set the secure communication using a manual procedure as described
in “Customizing HTTPS manually on Linux systems” on page 48 and
“Customizing HTTPS manually on Windows systems.”

Customizing HTTPS manually on Windows systems

When you have a trusted SSL certificate (a .pem file), place it on the computer
running Web Reports (usually the server) and follow these steps:
1. Run regedit and locate HKEY_LOCAL_MACHINE\Software\BigFix\
EnterpriseClient\Settings\Client for x32 systems and HKEY_LOCAL_MACHINE\
Software\Wow6432Node\BigFix\EnterpriseClient\Settings\Client for x64
systems.
You need to add or modify subkeys for the HTTPS flag, for the location of the
SSL certificate, for the HTTPS port number, and for the redirection to HTTPS.
2. Create a subkey of Client called _WebReports_HTTPServer_UseSSLFlag (if it
does not yet exist).
3. Create a string value (reg_sz) for the key _WebReports_HTTPServer_UseSSLFlag
called value and set it to 1 to enable HTTPS.

Chapter 7. Configuring secure communication 47

 4. Create a subkey of Client called
_WebReports_HTTPServer_SSLCertificateFilePath (if it does not yet exist).
5. Create a string value (reg_sz) for the key
_WebReports_HTTPServer_SSLCertificateFilePath called value and set it to
the full path name of the SSL certificate (cert.pem).
6. Create a subkey of Client called _WebReports_HTTPServer_PortNumber (if it
does not yet exist).
7. Create a string value (reg_sz) for the key _WebReports_HTTPServer_PortNumber
called value and set it to the port number you want to use (typically 443).
8. Create a subkey of Client called _WebReports_HTTPRedirect_Enabled (if it does
not yet exist).
9. Create a string value (reg_sz) for the key _WebReports_HTTPRedirect_Enabled
called value and set it to 1 to enable the browser redirection to HTTPS.
10. Create a subkey of Client called _WebReports_HTTPRedirect_PortNumber (if it
does not yet exist).
11. Create a string value (reg_sz) for the key
_WebReports_HTTPRedirect_PortNumber called value and set it to the number
of the port listening for HTTP connection and redirecting the client to HTTPS.
12. Restart the BESWebReports service.

Customizing HTTPS manually on Linux systems

When you have a trusted SSL certificate (a .pem file), place it on the computer
running Web Reports and customize the keywords in the applicable file:
v besclient.config - if a client is installed together with Web Reports
v beswebreports.config - if only Web Reports is installed

To define the port number you want to use:

[Software\BigFix\EnterpriseClient\Settings\Client
\_WebReports_HTTPServer_PortNumber]
value = 443

To define the full path name of the SSL certificate (cert.pem):

[Software\BigFix\EnterpriseClient\Settings\Client
\_WebReports_HTTPServer_SSLCertificateFilePath]
value = /tmp/CERT/cert.pem

To enable HTTPS:
[Software\BigFix\EnterpriseClient\Settings\Client
\_WebReports_HTTPServer_UseSSLFlag]
value = 1

To enable client redirection from an HTTP connection to an HTTPS connection:

[Software\BigFix\EnterpriseClient\Settings\Client
\_WebReports_HTTPRedirect_Enabled]
value = 1

To define the number of the port listening for the HTTP connection and redirecting
the Client to HTTPS:
[Software\BigFix\EnterpriseClient\Settings\Client
\_WebReports_HTTPRedirect_PortNumber]
value = portnumber

48 IBM Bigfix: Configuration Guide

Customizing HTTPS on REST API
If you have a trusted SSL security certificate and key from a certificate authority,
you can configure the BigFix root server to use this certificate and key to enable
trusted connections. After you have completed the configuration, connections from
the REST API and console use this trusted certificate.

Complete the steps to accomplish the following tasks:

v Specify that you are using a secure communication.
v Specify where the SSL certificate and private key files are located.
1. From the BigFix console select the Computers tab.
2. Select the computer running Rest API (usually the server) and Edit Computer
Settings from the Edit menu.
3. Look for _BESRelay_HTTPServer_UseSSLFlag setting. If it exists, do not create
a second one, but edit its value to 1 to enable HTTPS. If it does not exist, add
it:

Important: If you combined the private key file with the certificate file, skip
the following step and set only the
_BESRelay_HTTPServer_SSLCertificateFilePath.
4. Look for _BESRelay_HTTPServer_SSLPrivateKeyFilePath setting. If it exists,
do not create a second one, but edit its value to the full path name of the
private key (.pvk file which contains the private key for the server. The private
key must not have a password. If it does not exist, add it.
5. Look for _BESRelay_HTTPServer_SSLCertificateFilePath setting. If it exists,
do not create a second one, but edit its value to the full path name of the .pem
file which might contain both the certificate and private key for the server, or
only the certificate. If it does not exist, add it:

Ensure that the .pem file is in standard OpenSSL PKCS7 .pem file format.

Chapter 7. Configuring secure communication 49

 The certificate is supplied by the server to connecting clients and they present a
dialog to the user containing information from the certificate. If the certificate
meets all of the trust requirements of the connecting client, then the client
connects without any interventions by the user. If the certificate does not meet
the trust requirements of the client, then the user will be prompted with a
dialog asking them if it is OK to proceed with the connection, and giving them
access to information about the certificate. A trusted certificate is signed by a
trusted authority (such as Verisign), contains the correct host name, and is not
expired.
6. To require TLS12, look for _BESRelay_HTTPServer_RequireTLS12. If it exists,
do not create a second one, but edit its value to 1 .

Note: The REST API component always uses TLS 1.2 when communicating
with the BigFix server, (regardless of local settings or settings of the masthead).
7. Restart the BES Root Server service:
v On Windows, open Services, select BES Root Server and on the Action
menu, click Restart.
v On Linux run from the prompt: service besserver restart or
/etc/init.d/besserver restart.

Note: These settings are stored in the registry under the key HKLM/Software/
WoW6432Node/BigFix/EnterpriseClient/Settings/Client.

Customizing HTTPS manually on Windows systems

If you have a trusted SSL security and a key from a certificate authority (.pem file),
you can configure the computer running REST API (usually the server) to
customize trusted connections. After you have completed the configuration,
connections from the Rest API and console use this trusted certificate. Complete
the following steps:
1. Run regedit and locate HKEY_LOCAL_MACHINE\Software\BigFix\
EnterpriseClient\Settings\Client for x32 systems and HKEY_LOCAL_MACHINE\
Software\Wow6432Node\BigFix\EnterpriseClient\Settings\Client x64 systems.
You need to add or modify subkeys for the HTTPS flag, and for the location of
the SSL certificate.
2. Create a subkey of Client called _BESRelay_HTTPServer_UseSSLFlag (it might
already exist).
3. Create a string value (reg_sz) for the key _BESRelay_HTTPServer_UseSSLFlag
called value and set it to 1 to enable HTTPS.
4. Create a subkey of Client called
_BESRelay_HTTPServer_SSLCertificateFilePath (it might already exist).
5. Create a string value (reg_sz) for the key
_BESRelay_HTTPServer_SSLCertificateFilePath called value and set it to the
full path name of the SSL certificate (cert.pem).
6. Restart the BES Root Server service.

Customizing HTTPS manually on Linux systems

If you have a trusted SSL security certificate and key from a certificate authority
(.pem file), you can configure the BigFix root server to use this certificate and key
to enable trusted connections. After you have completed the configuration,
connections from the REST API and console use this trusted certificate.

50 IBM Bigfix: Configuration Guide

 This procedure describes how you can configure the BigFix root server on Linux
systems to use a certificate to enable trusted connections through the REST API
and BigFix console.
1. Save the file em.pem, containing both the certificate and the private key, in a
protected area of the file system, where it can be accessed by the BigFix
besserver process, for example, /etc/opt/BESServer/em.pem
2. Edit the /var/opt/BESServer/besserver.config file, adding the following two
entries, and using /etc/opt/BESServer/em.pem as an example:
[Software\BigFix\EnterpriseClient\Settings\Client\
_BESRelay_HTTPServer_SSLCertificateFilePath]
value = /etc/opt/BESServer/em.pem
[Software\BigFix\EnterpriseClient\Settings\Client\
_BESRelay_HTTPServer_UseSSLFlag]
value = 1
3. Stop and restart the BigFix root server.

Private key and certificate format

Ensure that the private key and the certificate files have the following format and
structure:
Private key format
PEM-encoded and without a password protection. The pvk format is not
supported. Ensure that the private key (private.key) is enclosed between the
following statements:
-----BEGIN PRIVATE KEY-----
<<base64 stringfrom private.key>>
-----END PRIVATE KEY-----
X509 certificate format
PEM-encoded. If you have also received the intermediate and root
certificates as separate files, you should combine all of them into a single
one. For example, if you have the primary certificate file (certificate.crt) and
the intermediate certificate file (ca_intermediate.crt), ensure that you
combine them in the following order, primary certificate first followed by
the intermediate certificate:
BEGIN CERTIFICATE-----
<<primary certificate: base64 stringfrom certificate.crt>>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<<intermediate certificate: base64 stringfrom ca_intermediate.crt>>
-----END CERTIFICATE-----

If you received the root certificate (ca_root.crt) in addition to the

intermediate certificate, combine them as follows:
BEGIN CERTIFICATE-----
<<primary certificate: base64 stringfrom certificate.crt>>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<<intermediate certificate: base64 stringfrom ca_intermediate.crt>>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<<root certificate: base64 stringfrom ca_root.crt>>
-----END CERTIFICATE-----
Single file (private key with certificates) format
PEM-encoded. This file can contain both the private key and the primary
certificate, or the private key and the chain of certificates, combined in the
following order, and with the beginning and end tags on each certificate:

Chapter 7. Configuring secure communication 51

 v Private key and primary certificate:
-----BEGIN CERTIFICATE-----
<<primary certificate: certificate.crt>>
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
<<private key: base64 stringfrom private.key>>
-----END PRIVATE KEY-----
v Private key, primary certificate and intermediate certificate:
BEGIN CERTIFICATE-----
<<primary certificate: base64 stringfrom certificate.crt>>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<<intermediate certificate: base64 stringfrom ca_intermediate.crt>>
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
<<private key: base64 stringfrom private.key>>
-----END PRIVATE KEY-----
v Private key, primary certificate, intermediate certificate and root
certificate:
BEGIN CERTIFICATE-----
<<primary certificate: base64 stringfrom certificate.crt>>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<<intermediate certificate: base64 stringfrom ca_intermediate.crt>>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
<<root certificate: base64 stringfrom ca_root.crt>>
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
<<private key: base64 stringfrom private.key>>
-----END PRIVATE KEY-----
If your file has DER-encoded or other formats, you can convert it to the
PEM format, for example by using openSSL.

Creating private keys and certificates

To improve security, create your own private key and a certificate instead of using
the self-signed ones that are available in BigFix WebReports by default. You can
use openSSL to create a private key and a certificate signing request (CSR) that can
be transformed into a certificate after it is signed by a certificate authority (CA).

This procedure is valid for all operating systems that support openSSL.

If you are generating an encrypted private key in the pkcs8 format, add the
following line to the installation_dir/jre/lib/security/java.security file:
security.provider.10=org.bouncycastle.jce.provider.BouncyCastleProvider

Then, restart the BigFix WebReports server.

1. Open the command line.
2. Create a new private key.
openssl genrsa -out key_name.key key_strength -sha256

For example, openssl genrsa -out private_key.key 2048 -sha256

Where:
key_name
File name for your new private key.

52 IBM Bigfix: Configuration Guide

 key_strength
Key strength, measured in bits. The maximum value that you can use
for BigFix WebReports is 2048 bits.
3. Create a certificate signing request (CSR). The request is associated with your
private key, and is later transformed into a certificate.
openssl req -new -key path_to_private_key.key -out csr_name.csr

For example, openssl req -new -key private_key.key -out CSR.csr

Where:
path_to_private_key
Path to your private key.
csr_name
File name for your certificate signing request (CSR).
After you run the command, you are asked to provide information that helps
your users to identify your certificate and ensure that it can be trusted. The
following excerpt from the command line is filled in with sample information:
Country Name (2 letter code) [XX]: US
State or Province Name (full name) []: New York
Locality Name (eg, city) [Default City]: New York
Organization Name (eg, company) [Default Company Ltd]: IBM
Organizational Unit Name (eg, section) []: Software
Common Name (eg, your name or your server’s hostname) []: webreports.ibm.com
Email Address []: [email protected]

After completing these steps, two files are created: your private key (.key) and the
certificate signing request (.csr). You must now sign the request to transform it
into the certificate. For information about how to create a private certificate
authority (CA) to sign the request, see Signing certificates.

Signing certificates
Your certificate signing request (CSR) must be signed by a certificate authority
(CA) to transform it into a certificate that can be uploaded to BigFix WebReports.
You can use the openSSL cryptographic library to create a private CA and sign
your request.

There are other ways to sign the request aside from using a private CA. You can
also use the CA of your organization or send the request to internationally trusted
CAs, such as Entrust or Verisign. The certificates of these CAs are often trusted by
default and do not display any warnings in the browser. Warnings might be
displayed if you use a private CA.
1. Create a private certificate authority (CA) and a certificate for it.
a. Create a private CA. This step creates a private key (.key) and a request
(.csr) similar to those that you created in Creating private keys and
certificates.
openssl req -new -newkey rsa:key_strength -nodes
-out CA_csr_name.csr -keyout CA_key_name.key -sha256

For example, openssl req -new -newkey rsa:2048 -nodes -out CA_CSR.csr
-keyout CA_private_key.key -sha256
Where:
key_strength
Key strength, measured in bits. The maximum value that you can
use for BigFix WebReports is 2048 bits.
Chapter 7. Configuring secure communication 53
 CA_csr_name
File name for the certificate signing request (CSR). The certificate
authority (CA) requires a separate request.
CA_key_name
File name for the private key. The certificate authority (CA) requires
a separate private key.
b. Create a certificate for your private CA. This step creates a certificate (.arm)
that you can use to sign your CSR.
openssl x509 -signkey path_to_CA_key.key -days
number_of_days -req -in path_to_CA_csr.csr
-out CA_certificate_name.arm -sha256

For example, openssl x509 -signkey CA_private_key.key -days 90 -req

-in CA_CSR.csr -out CA_certificate.arm -sha256
Where:
key_strength
Key strength, measured in bits. The maximum value that you can
use for BigFix WebReports is 2048 bits.
path_to_CA_csr
File name for the certificate signing request (CSR) that you created
for the certificate authority (CA).
path_to_CA_key
File name for the private key that you created for the certificate
authority (CA).
number_of_days
Number of days for the new certificate to be valid.
CA_certificate_name
File name for the certificate of your CA. This certificate is used to
sign your CSR.
2. Use the CA certificate to sign the certificate signing request that you created in
Creating private keys and certificates.
openssl x509 -req -days number_of_days -in path_to_csr.csr -CA path_to_CA_certificate.arm
-CAkey path_to_CA_key.key -out new_certificate.arm -set_serial 01 -sha256

For example, openssl x509 -req -days 90 -in CSR.csr -CA

CA_certificate.arm -CAkey CA_private_key.key -out certificate.arm
-set_serial 01 -sha256
Where:
number_of_days
Number of days for the new certificate to be valid.
path_to_csr
Path to certificate signing request (CSR) that you want to sign.
path_to_CA_certificate
Path to certificate that you created for the certificate authority (CA).
path_to_CA_key
Path to the private key that you created for the certificate authority
(CA).

54 IBM Bigfix: Configuration Guide

 new_certificate
File name for the new certificate that is created from your certificate
signing request (CSR). You upload this certificate together with your
private key to BigFix WebReports.

You signed your certificate signing request and obtained a new certificate. You can
now enable SSL in BigFix WebReports and upload your private key and the
certificate. These files replace the self-signed certificate that is already available in
BigFix WebReports, and thus ensure secure communication.

Chapter 7. Configuring secure communication 55

56 IBM Bigfix: Configuration Guide
Chapter 8. Downloading files in air-gapped environments
In air-gapped environments, to download and transfer files to the main BigFix
server, use the Airgap utility and the BES Download Cacher utility.

Overview
In an air-gapped environment where a secure network is physically isolated from
insecure networks, such as the public Internet or an insecure local area network,
and the computers on opposite sides of the air gap cannot communicate, to
download and transfer files to the main BigFix server, you can use the Airgap
utility and the BES Download Cacher utility.

Note: The Airgap utility does not support a configuration where the clients are
air-gapped separately from the main BigFix server. The clients must be air-gapped
together with the main BigFix server to be able to gather across the network from
the main BigFix server.

Starting from BigFix Version 9.5.5, you have two different modes to work in an
air-gapped environment. The "Extraction usage" mode, that was already available
before Version 9.5.5, and the new "Non-extraction usage" mode.

Non-extraction usage overview

The "Non-extraction usage" mode is available only starting from BigFix Version
9.5.5.

Airgap might need to work without extracting any information from the BigFix
server because in some places a rule forbids to extract any information in a secure
network and move to an external network, such as Internet. To satisfy these
requirements, the Airgap tool can now work without creating any Airgap request.

You can use the Airgap tool in three different ways:

Gather site contents

1. Run the Airgap tool on the internet facing computer to gather license
information and create a site list file, which contains information related to the
sites that you have licensed.
2. Edit the site list file and change the flags to specify the sites that you want to
gather contents from.
3. Run the Airgap tool on the internet facing computer to gather license
information and site contents as specified by the site list file into the Airgap
response.
4. Move the Airgap response to the BigFix server.
5. Run the Airgap tool on the BigFix server to load the Airgap response into the
BigFix server.

© Copyright IBM Corp. 2010, 2018 57

 Gather site contents and download files
1. Run the Airgap tool on the internet facing computer to gather license
information and create a site list file, which contains information related to the
sites that you have licensed.
2. Edit the site list file and change the flags to specify the sites that you want to
gather contents from, and the sites from which you want to download
referenced files.
3. Run the Airgap tool on the internet facing computer to gather license
information and site contents as specified by the site list file into the Airgap
response, and then download the files referenced by the Fixlets.
4. Move the Airgap response and the downloaded files to the BigFix server.
5. Run the Airgap tool on the BigFix server to load the Airgap response into the
BigFix server, and copy the downloaded files to the cache folder of the BigFix
server.

58 IBM Bigfix: Configuration Guide

Gather site contents and download files selectively
1. Run the Airgap tool on the internet facing computer to gather license
information and create a site list file, which contains information related to the
sites that you have licensed.
2. Edit the site list file and change the flags to specify the sites that you want to
gather contents from, and sites from which you want to download referenced
files.
3. Run the Airgap tool on the internet facing computer to gather license
information and site contents as specified by the site list file into the Airgap
response, and then create a file list file, which contains information about the
referenced files.
4. Edit the file list file to specify the files that you want to download.
5. Run the Airgap tool on the internet facing computer to download the files as
specified by the file list file.
6. Move the Airgap response and the downloaded files to the BigFix server.
7. Run the Airgap tool on the BigFix server to load the Airgap response into the
BigFix server, and copy the downloaded files to the cache folder of the BigFix
server.

Chapter 8. Downloading files in air-gapped environments 59

 Extraction usage overview
In this mode, the Airgap tool extracts information from the BigFix server. You run
the Airgap tool starting from the BigFix server by performing the following steps:
1. Run the Airgap tool on the BigFix server to create the Airgap request.
2. Move the Airgap request to the internet facing computer.
3. Run the Airgap tool on the internet facing computer to gather the license
information and the site contents into the Airgap response.
4. Move the Airgap response to the BigFix server.
5. Run the Airgap tool on the BigFix server to load the Airgap response into the
BigFix server.

60 IBM Bigfix: Configuration Guide

In this mode, Airgap gathers the contents of the site, but not the files. To download
the files referenced by the Fixlets, such as the patch modules, run the BES
Download Cacher utility by performing the following steps:
1. Locate the site masthead files for the sites you want to download files for, and
copy the site masthead files to the computer with internet access.
2. On the internet facing computer, run the BES Download Cacher utility for each
site masthead file to download files referenced from the site that the site
masthead file represents.
3. Move the downloaded files to the cache folder of the BigFix server.

Chapter 8. Downloading files in air-gapped environments 61

Requirements
When your BigFix server is installed in an air-gapped environment where a secure
network is physically isolated from insecure networks, such as the public Internet
or an insecure local area network, and the computers on opposite sides of the air
gap cannot communicate, you need a workstation that has access to the public
Internet to download Fixlet site contents using the Airgap tool, and to download
files referenced in the Fixlet action scripts. This workstation cannot be a BigFix
server or a BigFix relay.

The Airgap tool is platform dependent, but the AirgapRequest.xml (for extraction
usage only) and AirgapResponse files are not. For the workstation that has access to
the public Internet, you can use different operating systems available for the BigFix
server.

Depending on sites gathered, the AirgapResponse file can be larger than 4GB. Your
workstation must have enough free disk space to save the Airgap tool, the
AirgapResponse file, and the files to download.

To run the Airgap tool on Windows computers, you must have the following
libraries and files installed:
BESAirgapTool.exe
libBEScrypto.dll
libBEScryptoFIPS.dll
msvcm90.dll

62 IBM Bigfix: Configuration Guide

 msvcp90.dll
msvcr90.dll
Microsoft.VC90.CRT.manifest
ca-bundle.crt

You can get all the above files by downloading a compressed file (Airgap Tool)
from the Utilities page.

To run the Airgap tool on Linux computers, you must have the following files
installed:
Airgap
Airgap.sh
libBEScrypto.so
libBEScryptoFIPS.so
ca-bundle.crt

If DB2 is not installed on the Linux computer that has access to the public Internet,
to run the Airgap tool you must have installed the IBM Data Server Client or IBM
Data Server Runtime Client using the db2setup command. The DB2 instance must
be created with user db2inst1.

Using the Airgap tool

Non-extraction usage
The "Non-extraction usage" mode is available only starting from BigFix Version
9.5.5.

The Airgap command line interface can gather site information without having to
access the BigFix server and can optionally download files without passing
through a download cacher. You can download the Airgap command line interface
tool for the version of the BigFix server you are using from this Utilities page.

With the non-extraction usage, the Airgap tool can download the files specified in
Fixlets from download sites like Windows that do not require to authenticate.
When you need to download files from sites that require to authenticate with an
userid and password, or to download files not specified by prefetch or download
commands in Fixlets, as in the case of patch modules for AIX, CentOS, HP-UX,
RedHat, Solaris or SUSE, you must use a download cacher.

To gather site information without accessing the BigFix server, complete the
following steps:
1. Create a site list
Run the tool on a workstation that has access to the public Internet
specifying the license serial number, the email address used to register
your license, and the name of the file in which the tool lists the sites for
your license. You must have writing access for the folder where the Airgap
tool is located. Enter the following command:
On Windows operating systems:
BESAirgapTool.exe -serial serial_number -email
mail_addess -createSiteList site_list_filename [-proxy
[user:password@]hostname:port] [-usehttps]
[-cacert crt_filename] [-othersites site_foldername]

Chapter 8. Downloading files in air-gapped environments 63

 On Linux operating systems:
./Airgap.sh -serial serial_number -email
mail_addess -createSiteList site_list_filename [-proxy
[user:password@]hostname:port] [-usehttps]
[-cacert crt_filename] [-othersites site_foldername]

where mail_addess is the mail address that you specified in your license; if
it does not match, the Airgap tool fails. Option -email can be used only
together with option -createSiteList. Option -proxy is used when the
workstation that has access to the public Internet can connect only by a
proxy server. In this case, after the -proxy option, specify the hostname
and port of the proxy server in the form hostname:port. If the proxy is an
authenticating proxy, add also the userid and password in the form
userid:password@hostname:port. When option -usehttps is specified, "https"
is used to contact the license server. Use option -cacert to specify a path
in which to put the file ca-bundle.crt if you want to use a different folder
from that in which the Airgap tool runs. The file ca-bundle.crt is used to
validate the server certificate when you use the -usehttps option, or when
the url in the Fixlet begins with "https". The option -cacert can only be
used together with option -usehttps. Use option -othersites if your
license is entitled to AllowOtherSites, to include sites of your choice to
your site list. Create a folder, copy in it all the masthead files (*.efxm files)
related to your mastheads not included in your license, and specify the
name of this folder with option -othersites when you create a site list.

After running the tool, a file is created with the name that you specified as
site_list_filename.

Note: The site list file, once created, can be used until you change the
license, or IBM adds a new site to the existing license. If you delete the site
list file for any reason, you can create it again with the same command, as
the history of downloaded files is maintained as long as the license serial
number does not change.
2. Edit the site list file
Each line of the file created in step 1 contains three pieces of information
separated by a double colon:
flag::site_name::site_url

You can edit only the flag parameter, that can have one the following
values:
A Site contents are gathered when a newer site version is available
and stored in the AirgapResponse file, and used for downloading
files or creating a file list.
R Site contents are always gathered and stored in the AirgapResponse
file regardless of the version of the site, and used for downloading
files.
G Site contents are gathered when a newer site version is available
and stored in the AirgapResponse file, but not used for
downloading files or creating a file list.
Q Site contents are always gathered and stored in the AirgapResponse
file regardless of the version of the site, but not used for
downloading files or creating a file list.
D Site contents are not gathered, but are used for downloading files

64 IBM Bigfix: Configuration Guide

 or creating a file list. This flag is useful when you want to keep the
current contents of a site without updating it and download files to
run Fixlets at your current site. This option is valid only when the
site contents have already been gathered.
N Site is ignored, but site information is kept in the file for future
reference.

Note: When you create a site list file, the default values for the BES
Support and Web UI Common components are set to G. If you are not
interested in the Web UI component, modify the default Web UI Common
value from G to N. The default values for the other components are set to
N. At the first run after installing the BigFix server, the license information,
the BES Support and the Web UI Common components must be gathered.
Only after moving this first Airgap response generated on the workstation
that has access to the public Internet to the BigFix server, you can enable
the other components that you can access from the License Overview
dashboard of the console and continue with the process. Be sure to enable
the required components other than default before gathering.
3. Gather site contents and create the Airgap response file
After you have edited the flags in the site list file, run the Airgap tool
again to complete one of the following site operations:
a. Gather site contents
To gather site contents for sites with flag A or R or G or Q, run the
following command:
On Windows operating systems:
BESAirgapTool.exe -site site_list_filename
On Linux operating systems:
./Airgap.sh -site site_list_filename

On completion, you have created the Airgapresponse file.

b. Gather site contents and download files
To gather site contents for sites with flag A or R or G or Q, and
download files referenced by Fixlets on sites with flag A or R or D,
run the following command:
On Windows operating systems:
BESAirgapTool.exe -site site_list_filename -download
[-cache cache_name]
On Linux operating systems:
./Airgap.sh -site site_list_filename -download
[-cache cache_name]

where cache_name is the folder path where to store the downloaded

files. On completion, you have created the Airgapresponse file and
downloaded the files to the cache_name folder.
c. Gather site contents and download files selectively
To gather site contents for sites with flag A or R or G or Q, and
create a list of files referenced by Fixlets on sites with flag A or R
or D, run the following command:
On Windows operating systems:
BESAirgapTool.exe -site site_list_filename
-createFileList referenced_list

Chapter 8. Downloading files in air-gapped environments 65

 On Linux operating systems:
./Airgap.sh -site site_list_filename
-createFileList referenced_list

On completion, you have created the Airgapresponse file and the

file list with the name specified in referenced_list.
In all cases, site contents gathered for sites with flag A or R or G or Q are
put in the AirgapResponse file. When you run the Airgap tool for the first
time, all sites with flag A or R or G or Q are gathered. For subsequent
times, the contents of sites with flag A or G are gathered only if either they
have not been previously gathered or a newer site version is available. For
sites with flag R or Q, contents are always gathered.
Optionally, you can also specify the following options:
-usehttps
License information and site contents are gathered using "https".
For case "b. Gather site contents and download files", all urls
beginning with "http" are forced to use "https". Note that some urls
in Fixlets begin with "https" and some patch sites might redirect
requests to urls beginning with "https".
-proxy [user:password@]hostname:port
Used when the workstation that has access to the public Internet
can connect only through a proxy server. In this case, after the
-proxy option, specify the host name and port of the proxy server
in the format hostname:port. If the proxy is an authenticating proxy,
add also the user ID and password in the format
userid:password@hostname:port.
-cacert crt_filename
To specify a path in which to put the file ca-bundle.crt if you
want to use a different folder from that in which the Airgap tool
runs. The file ca-bundle.crt is used to validate the server
certificate when you use the -usehttps option, or when the url in
the Fixlet begins with "https". The option -cacert can only be used
together with option -usehttps.
-timeout timeout_seconds
This option is available starting from V9.5.7. It specifies a http
timeout interval in seconds. Values range from 30 to 3600. The
default value is 30. In the event you get the error "HTTP Error 28:
Timeout was reached" while using a proxy, try also to use option
-usehttps as it makes proxy to work in tunneling mode and that
might help avoiding timeouts.
For cases b and c, you can also use other options to reduce the number of
files to download or to gather in the file list. These filtering options select
Fixlets that refer to files, not the files themselves. For example, when you
specify last 5 days, it means files referenced by Fixlets modified in the last
5 days, not files added or changed by vendors in the last 5 days. To create
a list of possible values for filtering options, run the following command:
On Windows operating systems:
BESAirgapTool.exe -site site_list_filename -createfilterList
filter_list
On Linux operating systems:
./Airgap.sh -site site_list_filename -createfilterList
filter_list

66 IBM Bigfix: Configuration Guide

 The list of available values is limited to the following options: -fcategory,
-fcve, -fproduct, -fseverity, -fsource, and -fsourceid. The following
options are available for filtering:
-fcategory
Fixlet category property.
-fcve To specify the CVE (Common Vulnerabilities and Exposures) id
associated with a security patch.
-fdays To select Fixlets whose last modified date falls within a specified
number of days from the date you run the command.
-fproduct
To specify the product name to which the Fixlet is applicable, such
as Win2008 or Win7. This information is not shown in the Console.
This option is available only for sites related to patches for
Windows operating systems.
-fseverity
To specify the severity that a vendor associates with a security
patch.
-fsource
Provider of file, such as BigFix, Adobe, or Microsoft.
-fsourceid
Identification specified by the provider.
-includeCorrupt
To include Fixlets marked as Corrupted, that are excluded by
default when this option is not specified.
-includeSuperseded
To include Fixlets marked as Superseded, that are excluded by
default when this option is not specified.

When multiple filter conditions are specified, only Fixlets that satisfy all
conditions are selected. For options -fsource, -fsourceid, -fcve,
-fcategory, and -fseverity, you can specify multiple comma-separated
values, for example: -fseverity "Critical, Important". When you use
commas to separate values, or values contain spaces, enclose parameters in
double quotes, as in the previous example. Note that values are case
sensitive.
4. Edit the file list
Applicable only to case c. Gather site contents and download files
selectively of step 3.
With -createFileList option, you create a file that contains a list of files.
Each line of the list contains pieces of information separated by a double
colon:
flag::site_name::Fixlet_id::site_url::
size::hash_value::hash algorithm

For example:
N::site=site_name::fixletid=fixlet_id::
url=url_address::size=file_size::hash=hash_value::
hashtype=hash_type

You can edit only the flag value, changing it to Y to download the file, or
to N to not download the file.

Chapter 8. Downloading files in air-gapped environments 67

 5. Run the tool on the Internet facing workstation to download files
Applicable only to case c. Gather site contents and download files
selectively of step 3.
After editing the file list in step 4, to download only the files with flag Y in
the file list, run the Airgap tool by issuing the following command:
On Windows operating systems:
BESAirgapTool.exe -file file_list_filename -download
-cache cache_foldername
[-proxy [user:password@]hostname:port] [-usehttps]
[-cacert crt_filename]
On Linux operating systems:
./Airgap.sh -file file_list_filename -download
-cache cache_foldername
[-proxy [user:password@]hostname:port] [-usehttps]
[-cacert crt_filename]

where cache_foldername is the folder path where to store the downloaded

files. The files already in the cache folder are not downloaded again.
6. Move the Airgap response file to the BigFix server and run the Airgap tool on
the BigFix server
Copy in a portable drive the AirgapResponse file, and the file list that you
have created in step 3 or the downloaded files that you collected in step 5,
and transfer them to the BigFix server computer. Make sure that the
AirgapResponse file is in the same folder as the Airgap tool, and run it by
issuing the following command:
On Windows operating systems:
BESAirgapTool.exe
On Linux operating systems:
./Airgap.sh -run [-temp temp_folder]

This imports the response file with the Fixlet content and license updates
into your deployment.

Note: The Airgap tool passes site contents in the response file to the
GatherDB component of your BigFix server, and the GatherDB component
imports site contents. For sites other than WebUI sites, you can monitor the
import progress in the DebugOut of the GatherDB component (default
name GatherDB.log).
Copy the downloaded files also into the BigFix server cache folder. The
cache folder default location is:
On Windows operating systems:
%PROGRAM FILES%\BigFix Enterprise\BES Server\wwwrootbes\
bfmirror\downloads\sha1
On Linux operating systems:
/var/opt/BESServer/wwwrootbes/bfmirror/downloads/sha1

Repeat these steps periodically to keep updated the Fixlet content in the main
BigFix server. Join the new Fixlet mailing list to receive notifications when Fixlets
are updated.

Always make sure that the Airgap tool version is compatible with the version of
the BigFix server installed.

68 IBM Bigfix: Configuration Guide

Optional actions:
Check if all required files have been downloaded
To check if you have downloaded all the files required for the
Fixlet you are planning to apply, use option -checkfixlet when
you run the Airgap tool. For example:
On Windows operating systems:
BESAirgapTool.exe -site site_list.txt -checkfixlet
-fdays 100 -fseverity Critical -cache MyCache
On Linux operating systems:
./Airgap.sh -site site_list.txt -checkfixlet
-fdays 100 -fseverity Critical -cache MyCache

For Fixlets satisfying the specified filtering conditions, the tool

checks the downloaded history and contents of destination folder,
and if there are still files to download, Fixlet names and urls are
displayed.
Files to be downloaded manually
Some files referenced by Fixlets might not be downloaded because
they can be obtained only by contacting the vendor support center,
or because the download site requires that you explicitly accept the
license terms and this action cannot be automated for legal reasons.
In these cases, the involved files have the download url containing
the string MANUAL_BES_CACHING_REQUIRED and must be downloaded
manually. To create a list of these files, use option
-createmanuallist as in the following example:
On Windows operating systems:
BESAirgapTool.exe -site site_list.txt -createmanuallist
manual_list -fseverity Critical
On Linux operating systems:
./Airgap.sh -site site_list.txt -createmanuallist
manual_list -fseverity Critical

You can also use the -checkmanual option to check if your

destination folder contains all the files that must be manually
downloaded, as in the following example:
On Windows operating systems:
BESAirgapTool.exe -site site_list.txt -checkmanual
-fseverity Critical
-fdays 30 -cache MyCache
On Linux operating systems:
./Airgap.sh -site site_list.txt -checkmanual
-fseverity Critical
-fdays 30 -cache MyCache
Reset history
The Airgap tool keeps a history of downloaded files. Even if you
move all the downloaded files from your public Internet facing
workstation to the BigFix server, this history is maintained and
files previously downloaded are not downloaded again to save
time and disk space. If you deleted part or all of your previously
downloaded files and you need them again, you can use the
-resync option. This option clears the download history and
checks the files in the folder specified with -cache option. Note

Chapter 8. Downloading files in air-gapped environments 69

 that the newly-created download history is based only on the files
contained in the folder specified with the -cache option.
Changing license
If you want to manage another license, you must erase the history
of gathered sites and downloaded files. To complete this action,
use the -force option as in the following example:
On Windows operating systems:
BESAirgapTool.exe -serial serial_number -email
mail_addess -createSiteList site_list_filename -force
On Linux operating systems:
./Airgap.sh -serial serial_number -email
mail_addess -createSiteList site_list_filename -force
Miscellaneous options
By default, the Airgap tool simultaneously downloads two files.
You can change the number of files to download concurrently by
specifying a number after the -download option . This number can
range from 1 to 8. For example, to download 3 files at the same
time, specify -download 3. Note that you need a larger band width
when downloading more than 2 files simultaneously.
When the url specified in a Fixlet begins with "https", or if you
specify the -useHttps option, the Airgap tool tries to verify that the
server specified in the url has an appropriate SSL Server
Certificate. If, for any reason, you want to skip this check and
avoid a download failure when the Airgap tool cannot verify the
server certificate, use the -noverify option. With this option, the
Airgap tool does not validate any server certificate and you must
check that your workstation translates correctly host names by
checking your DNS.
To have the Airgap tool to print more information than usual, use
the -verbose option.
Working with multiple BigFix servers
If you want to use the same public Internet facing workstation for
several BigFix servers, like a test server and a production server,
create a folder for each server, copy the Airgap tool in each folder,
and work with each folder separately. You can share the same site
list among the different folders, but each server keeps its own
history in its folder. When using multiple Airgap tools with
different servers, you can also share a cache folder to download
only once files that are common to different servers, but you must
ensure to run only one instance of the Airgap tool at the same
time.
In case you need to gather set of sites, load them to your test
server, then perform tests with the gathered sites and load the
tested sites, not the latest ones, to your production server, you can
load one AirgapResponse file to multiple BigFix servers when they
are licensed for the same products (like IBM BigFix Lifecycle, IBM
BigFix Compliance, etc.). When you intend to load one
AirgapResponse file to multiple BigFix servers, it is recommended
to gather only sites enabled on all of your BigFix servers.

Note: At the first run after installing the BigFix server, the license
information, the BES Support, and the Web UI Common

70 IBM Bigfix: Configuration Guide

 components must be gathered for each installation. For this step,
an AirgapResponse file must be created for each BigFix server
because license information is unique to each serial number.
If you want to update the license information of a particular BigFix
server without changing version on any site, you can create an
AirgapResponse file that contains only license information by
running the Airgap tool with a site file containing no lines or with
site files where all sites have the flag N. Run the following
command:
On Windows operating systems:
BESAirgapTool.exe -site empty_site_list_filename
-allowemptysite
On Linux operating systems:
./Airgap.sh -site empty_site_list_filename
-allowemptysite
Enabling WebUI in air-gapped environments
To install the WebUI in air-gapped environments, perform the
following steps:
1. Gather the latest BES Support and WebUI Common sites, and
download the required files to install the WebUI Service. Load
them to your BigFix server.
2. Install the WebUI Service by using the task "Install IBM BigFix
WebUI Service" in BES Support site.
3. After the installation completes, wait for the activation of a
WebUI Service (on Windows operating systems) or process (on
Linux operating systems) on the WebUI targeting system. The
WebUI initialization has started; wait for its completion.
Initialization usually completes in few minutes, but it is
suggested to wait 30 minutes or more before proceeding with
step 4.
4. Gather all the latest WebUI sites and load them to your BigFix
server. You can gather WebUI sites before running the task to
install the WebUI service, but you can load them only after the
WebUI initialization has completed.

Extraction usage
Important: If you have a BigFix 9.5.7 fresh installation, to make the WebUI sites
available, you must complete the following steps:
1. Install the WebUI and run the Airgap tool
2. Wait a few minutes for the WebUI initialization to complete
3. Rerun the Airgap tool.

To make Fixlet content and product license updates available in the isolated
network, the utility must be transferred from a computer with internet connectivity
using the following steps:

On Windows operating systems

1. Run on the BigFix server
From the BigFix server installation directory, run the BESAirgapTool.exe on the
BigFix server computer to create a Fixlet update request file. Save this request

Chapter 8. Downloading files in air-gapped environments 71

 to a portable drive together with the BESAirgapTool.exe, the Microsoft C/C++
Runtime Libraries, the ca-bundle.crt file, and the following libraries:
v libBEScrypto.dll
v libBEScryptoFIPS.dll
The BESAirgapTool.exe does not run successfully without the .dll files included
in the same directory as the BESAirgapTool.exe tool.
2. Move the Airgap request and run on the internet facing computer
Bring the portable drive to a computer with Internet connectivity and run the
BESAirgapTool.exe. You must have the rights to write in the folder where the
BESAirgapTool.exe is located because the Airgap response is created in the
same folder. This exchanges the request file for a response file.
Optionally, you can also specify the following options:
-usehttps
All urls beginning with "http" are forced to use "https" to gather license
information and site contents. Note that some urls in Fixlets begin with
"https" and some patch sites might redirect requests to urls beginning
with "https".
-proxy [user:password@]hostname:port
This option is available only starting from BigFix Version 9.5.5. Used
when the workstation that has access to the public Internet can connect
only through a proxy server. In this case, after the -proxy option,
specify the host name and the port of the proxy server in the format
hostname:port. If the proxy is an authenticating proxy, add also the user
ID and the password in the format userid:password@hostname:port. In
extraction usage, when a proxy server is configured in the client
registry settings or in the Internet Explorer settings for the current user
and the -proxy option is not specified, the proxy settings are used as in
earlier versions of the Airgap tool. When you use the -proxy option, the
specified values are used regardless of other settings.
-cacert <full_path_to_ca-bundle.crt_file>
To specify a path in which to store the file ca-bundle.crt, if you want
to use a different folder from that where the Airgap tool runs. The file
ca-bundle.crt is used to validate the server certificate when you use
the -usehttps option, or when the URL in the Fixlet begins with
"https". The option -cacert can only be used together with the
-usehttps option.
3. Move the Airgap response to the BigFix server and run the Airgap tool on
the BigFix server
Take the portable drive back to the BigFix server computer and run the
BESAirgapTool.exe again as an Administrator. This imports the response file
with the Fixlet content and license updates into your deployment.
The Airgap tool creates temporary files in the folder specified by the TEMP
environment variable. If you want to use a different folder for temporary files,
set the TEMP environment variable to that folder before you run the
BESAirgapTool.exe.
To update the Fixlet content on the main BigFix server, repeat these steps
periodically. You can join the new Fixlet mailing list to receive notifications
when Fixlets are updated.
Ensure that the Airgap tool version is compatible with the installed BigFix
version.

72 IBM Bigfix: Configuration Guide

On Linux operating systems
1. Run on the BigFix server
Ensure that on the Linux computer, the Airgap utility is in the same path where
you installed the BigFix server. The default path is /opt/BESServer/bin. Open
the Linux Terminal, and enter the following commands to create a tar file
named airgap.tar, containing the AirgapRequest.xml file based on the BigFix
database information:
# cd /opt/BESServer/bin
# ./Airgap.sh -remotedir directory

Where:
-remotedir directory
Runs Airgap to generate the request file in the specified folder.
2. Move the Airgap request and run on the internet facing computer
Copy the airgap.tar file to a portable drive, and extract the airgap.tar file
content by issuing the following command:
# tar -xf airgap.tar

Ensure that you have the DB2 libraries listed in the Preparation steps section
available in the folder specified by the LD_LIBRARY_PATH environment variable,
connect the portable drive to an Internet facing computer and run the
Airgap.sh command. This exchanges the request file for a response file:
# cd airgap
# ./Airgap.sh

Note that the Airgap.sh and AirgapRequest.xml files must be in the same
folder and you must have writing rights to that folder.
Optionally, you can also specify the following options:
-usehttps
All urls beginning with "http" are forced to use "https" to gather license
information and site contents. Note that some urls in Fixlets begin with
"https" and some patch sites might redirect requests to urls beginning
with "https".
-proxy [user:password@]hostname:port
Used when the workstation that has access to the public Internet can
connect only through a proxy server. In this case, after the -proxy
option, specify the host name and the port of the proxy server in the
format hostname:port. If the proxy is an authenticating proxy, add also
the user ID and the password in the format
userid:password@hostname:port.
-cacert <full_path_to_ca-bundle.crt_file>
To specify a path in which to store the file ca-bundle.crt, if you want
to use a different folder from that where the Airgap tool runs. The file
ca-bundle.crt is used to validate the server certificate when you use
the -usehttps option, or when the URL in the Fixlet begins with
"https". The option -cacert can only be used together with the
-usehttps option.
3. Move the Airgap response to the BigFix server and run the Airgap tool on
the BigFix server
Connect the portable drive back to the BigFix server computer and run the
Airgap.sh command. This imports the response file with Fixlet content and
license updates into your deployment.

Chapter 8. Downloading files in air-gapped environments 73

 # cd airgap
# ./Airgap.sh -run
Optionally, you can also specify the following option:
-temp directory
The Airgap tool creates temporary files under the /tmp directory, but in
the event you do not have enough space left in it, you can use this
option to specify a different folder where you have enough space.
Note that the Airgap.sh and AirgapRequest.xml files must be in the same
folder.
To update the Fixlet content on the main BigFix server, repeat these steps
periodically. You can join the new Fixlet mailing list to receive notifications
when Fixlets are updated.
Ensure that the Airgap tool version is compatible with the installed BigFix
version.

Transferring downloaded files

Deploying Fixlets on the main BigFix server requires downloaded patches and
other files from the Internet. You can use the Airgap tool in extraction usage for
gathering site contents and in non-extraction usage for downloading files (you can
ignore the AirgapResponse file generated in non-extraction usage). As an
alternative, you can use the BES Download Cacher utility. This utility helps to:
v Download and transfer files to the main BigFix server.
v Download patch contents in a Fixlet site or single file downloads from a url.
You can download the current utility from http://software.bigfix.com/download/
bes/util/BESDownloadCacher.exe. To see the list of available options run
BESDownloadCacher.exe /?. If the BigFix server or an BigFix relay is installed on
the system where you run the BES Download Cacher utility, the -x utility
parameter is optional because the utility detects relevant local BES settings and
reuse them as defaults

Some sites require additional steps to download content from patch vendors that
restrict access. For additional information see the following Knowledge documents
that describe using a tool to manually download patches for Solaris, Red Hat
Enterprise Linux, SuSE Linux Enterprise, and AIX.

These sites require a three step process:

1. Run the BESAirgapTool.exe to download Fixlets and Tasks for each site.
2. Run the BES Download Cacher utility to download any site tools from IBM
BigFix.
3. Run the download tool for each vendor to download patch contents.

Transferring all files from Fixlet sites:

To transfer files from Fixlet sites, perform the following steps:

1. Locate the .efxm file for the site from which you want to gather downloads, for
example, BES Asset Discovery.efxm.
2. Run the BES Download Cacher utility with the following command:
BESDownloadCacher.exe -m BES Asset Discovery.efxm -x downloads

74 IBM Bigfix: Configuration Guide

 Note: This might take a very long time because it downloads every file
referenced in the Fixlet site and puts the files into the downloads folder. If the
files already exist in the downloads folder, they are not re-downloaded. Files
are named with their sha1 checksum.
3. When the download finishes, copy the contents of the downloads folder (just
the files, not the folder) into the sha1 folder on the main BigFix server. The
default location for the sha1 folder is:
v On Windows systems: %PROGRAM FILES%\BigFix Enterprise\BES
Server\wwwrootbes\bfmirror\downloads\sha1
v On Linux systems: /var/opt/BESServer/wwwrootbes/bfmirror/downloads/
sha1
The BigFix server uses these files instead of trying to download them from the
Internet.

Note: If you run the BES Download Cacher utility later, you can look at the
modification time of the files to see which files are the newest. Using this
method, you transfer only the newest files to the Main BigFix server instead of
copying every file each time.

You might need to increase the size of the cache on the main BigFix server so that
it does not try to delete any files from the cache. Run the BES Download Cacher
utility to increase the size of the cache with the following command:
BESDownloadCacher.exe -c 1024

The default size of the cache is 1024 MB.

Note: Use the -c option only when the BigFix server or a relay is installed on the
system where you run the BES Download Cacher utility. If no BigFix component is
installed, cache has no limit.

After the files are cached in the BigFix server sha1 folder, they are automatically
delivered to the BigFix relays and BigFix clients when you click an action in the
Fixlet message that references a downloaded file. If the file is not cached, the
BigFix console gives you a status of Waiting for Mirror Server after you deploy
an action. For additional information about how the BigFix cache works, see How
does the TEM Server and TEM Relay cache work.

Transferring a single file:

To transfer a single file from a Fixlet site, perform the following steps:
1. Run the BES Download Cacher utility with the following command:
BESDownloadCacher.exe -u http://www.mysite/downloads/myplugin.exe -x downloads
2. When the download finishes, copy the contents of the downloads folder (just
the file, not the folder) into the sha1 folder on the main BigFix server. The
default location for the sha1 folder is:
v On Windows systems: %PROGRAM FILES%\BigFix Enterprise\BES
Server\wwwrootbes\bfmirror\downloads\sha1
v On Linux systems: /var/opt/BESServer/wwwrootbes/bfmirror/downloads/
sha1

You might need to increase the size of the cache on the main BigFix server so that
it does not try to delete any files from the cache. Run the BES Download Cacher
utility to increase the size of the cache with the following command:

Chapter 8. Downloading files in air-gapped environments 75

 BESDownloadCacher.exe -c 1024

The default size of the cache is 1024 MB.

Note: Use the -c option only when the BigFix server or a relay is installed on the
system where you run the BES Download Cacher utility. If no BigFix component is
installed, cache has no limit.

After the files are cached in the BigFix server sha1 folder, they are automatically
delivered to the BigFix relays and BigFix clients when you click an action in the
Fixlet message that references a downloaded file. If the file is not cached, the
BigFix console gives you a status of "Waiting for Mirror Server" after you deploy
an action. For additional information about how the BigFix cache works see How
does the TEM Server and TEM Relay cache work?.

Log files
The Airgap tool produces two types of log files: normal log files and debug log
files.

Normal log files record the messages you see in the command window so you can
check Airgap tasks, such as sites gathered on a specific date. Debug log files are
intended for the IBM Support team. The naming convention for normal log files is:
On Windows operating systems:
BESAirgapTool_yyyy-mm-dd.log
On Linux operating systems:
Airgap_yyyy-mm-dd.log

where yyyy-mm-dd is the date when the file has been created. Starting from V9.5.7,
files older than 30 days are deleted.

The debug log file is AirgapDebugOut.txt. Starting from V9.5.7, this file contains
only information of the last day and older log files are renamed to
AirgapDebugOutyyyymmdd.txt, where yyyymmdd is the date when the file has been
created; files older than 10 days are deleted. The Airgap tool can write more
information to the debug log file by using the verbose option -verbose.

76 IBM Bigfix: Configuration Guide

Chapter 9. Getting client information by using BigFix Query
The BigFix Query feature allows you to retrieve information and run relevance
queries on client workstations from the WebUI BigFix Query Application or by
using REST APIs.

Use the BigFix Query feature to:

v Quickly collect data from clients without impacting BigFix environment
performance.
v Run your query in relevance language on targets identified using an
applicability relevance or on a set of target agent IDs.
v Show the collected results in the WebUI Query Application, optionally paging
them. The results displayed are updated periodically as new values are received
from clients.
v Test relevance expressions on a few selected clients before rolling out to
production.

This guide contains the information about how to configure BigFix for using BigFix
Query. Additional information is available clicking the following links:
v BigFix Query section of the WebUI User's Guide
v IBM BigFix Configuration Settings
v REST API for BigFix Query

BigFix Query requirements

The clients that are targeted by BigFix Query requests must satisfy specific
conditions.

The following requirements must be satisfied to run BigFix Query on clients:

v The client can receive UDP notifications. The BigFix Query feature does not
support components that are connected to the BigFix server through proxies or
firewalls.
v BigFix V9.5 Patch 2 or later must be installed on the client machine and on all
the intermediate relays that must be passed through to reach the client.

BigFix Query restrictions

Some restrictions apply when using the BigFix Query feature.

The following limitations affect the use of the BigFix Query feature:
v The feature is available only for IBM® BigFix Lifecycle or IBM BigFix
Compliance version 9.5 Patch 2 or later licenses.
v The feature does not support requests requiring the agent context.
v If you configured your environment in a Disaster Server Architecture (DSA), be
aware that:
– The information about BigFix Query is not replicated among the multiple
servers.
– Each server can run BigFix Query requests only on the clients that connect
either directly or through relays to the server where the query is submitted.

© Copyright IBM Corp. 2010, 2018 77

Who can use BigFix Query
BigFix Query requests can be run by Master Operators and Non-Master Operators.
Specific permissions must be set to allow operators to use this feature.
To access the WebUI Query application from the WebUI toolbar:
The user must have, at operator or role level, the effective permission on
the query WebUI Application set to Allowed, for example:

As an alternative, you can see which permissions are assigned to the users
on the WebUI Applications in the working area of the WebUi Apps
Domain. The WebUi Apps Domain is available under All Contents after
you enable the WebUI.For more information about how to access the
WebUI Query Application, see “How to run BigFix Query from the
WebUI” on page 79.
To run BigFix Query requests and see their results:
Master Operators can run queries by default. A Non-Master Operator must
have, at operator or role level, the Can Submit Queries permission set to
Yes in the Details tab:

The default value of the Can Submit Queries permission for Non-Master
Operators is No.

78 IBM Bigfix: Configuration Guide

 For more information about operator permissions and roles, see Adding Local
Operators.

How to run BigFix Query from the WebUI

You can access the BigFix Query on the WebUI user interface by selecting Content
-> Query.

The Query panel opens:

For information about using this feature from the Query panel, see WebUI
Enablement.

How BigFix manages BigFix Query requests

A BigFix Query request is processed in a sequence of customizable steps.

The following picture shows the internal flow of a BigFix Query. Each step lists
which variables you can configure to tune how BigFix Query requests and
responses are managed.

Chapter 9. Getting client information by using BigFix Query 79

 1. The operator that logged on to the WebUI submits a request from the BigFix
Query Application.
What can you customize for this step?
You can decide to run this step as an operator that is not a master
operator. In this case ensure that either the operator permissions or the
permissions specified in the role assigned to the operator contain the
Can Submit Queries value set to Yes.

Note: If you are using the REST API to manage the query, be aware that only
the operator issuing the query can see its responses.
2. The submitted request is propagated through the relay hierarchy to the target
clients using dedicated memory queues on each relay. This ensures that the

80 IBM Bigfix: Configuration Guide

 request quickly reaches the targets without impacting normal BigFix processing.
If a target or a child relay does not answer within a given amount of time, then
it is no longer requested to answer.
What can you customize for this step?
From the BigFix Console you can customize, for the server and for each
relay, how the memory queues are cleaned up:
How often the cleanup task is run.
The default value is 10 minutes and the name of the setting is
_BESRelay_Query_RemovalTask.
How long a request can stay in the queue before being deleted by
the cleanup task.
The default value is 60 minutes and the name of the setting is
_BESRelay_Query_MinTime.
The maximum size of the memory queue dedicated to BigFix Query
requests.
Before running the cleanup task, BigFix checks if the size of this
memory queue exceeds the maximum size specified. If it
exceeds, when the cleanup task runs, it removes the entries in
the queue until the size of the queue returns within the
threshold. The default value is 100 MB and the name of the
setting is _BESRelay_Query_MemoryLimit.

For more information about these settings, see Configuration Settings.

3. When the request reaches the target client parent relay, the relay informs the
client, using the UDP protocol, that there is a new request to process, and, in
turn, the agent retrieves the request.
4. For each responsive target, the client passes the query to the local QnA to run
the query and return the results.
What can you customize for this step?
From the BigFix Console you can customize for the client:
How long can the QnA process a query issued by a Master Operator
before the request timeout elapses
The default value is 60 seconds and the name of the setting is
_BESClient_Query_MOMaxQueryTime.
How long can the QnA process a query issued by a Non Master
Operator before the request timeout elapses
The default value is 10 seconds and the name of the setting is
_BESClient_Query_NMOMaxQueryTime.
How long the QnA waits for new queries to process before stopping.
The default value is 600 seconds and the name of the setting is
_BESClient_Query_IdleTimeout.
How much CPU is used by the QnA process running the query.
You can limit the CPU used by the QnA process by defining
time slots during which the QnA runs. By default the QnA
processing the query runs for 10 milliseconds and then sleeps
for 480 milliseconds, which corresponds to a CPU usage lower
than 1-2 %, and the name of the settings that define this
behavior are _BESClient_Query_WorkTime and
_BESClient_Query_SleepTime.

For more information about these settings, see Configuration Settings.

Chapter 9. Getting client information by using BigFix Query 81

 Note: These settings are not considered when running the QnA tool connected
as local user to the client system.
5. When the agent receives the response from the QnA, it creates a report
containing the response and delivers it to the parent relay in parallel the other
reports.
6. The report is delivered back to the server through the relay hierarchy. On each
relay the report is stored in a memory queue while waiting to be delivered to
the parent relay. If the parent relay is not available, the report waits in the
queue and is delivered as soon as the parent relay becomes available again. The
same criteria for encryption and signing used for normal reports are applied
also to these reports.
What can you customize for this step?
From the BigFix Console you can customize for each relay:
The maximum size of the memory queue dedicated to BigFix Query
results.
Before running the cleanup task, BigFix checks if the size of this
memory queue exceeds the maximum size specified. If it
exceeds, when the cleanup task runs, it removes the entries in
the queue until the size of the queue returns within the
threshold. The default value is 100 MB and the name of the
setting is _BESRelay_Query_ResultsMemoryLimit.

For more information about this setting, see Configuration Settings.

7. When the server receives the result, it stores it in a dedicated queue from
where a dedicated FillDB thread gets the data to store it in the database. In this
way, the normal processing on the BigFix server is not impacted.
The database stores, for a specified time period, both the BigFix Query request
and its responses, that can be used, for example, to be filtered, displayed, or to
create reports. On a timely basis the BigFix Query Application checks the
database for updates and updates the displayed results accordingly.
What can you customize for this step?
From the BigFix Administrative Tool you can customize on the server:
For how long the BigFix Query requests are stored in the database
before being deleted.
The default value is 1440 hours (60 days) and the name of the
advanced option is queryHoursToLive.
For how long the BigFix Query responses are stored in the database
before being deleted.
The default value is 4 hours and the name of the advanced
option is queryResultsHoursToLive.
How many requests and responses, for which queryHoursToLive or
queryResultsHoursToLive elapsed, are deleted at a time from the
database.
The default value is 100000 entries and the name of the
advanced option is queryPurgeBatchSize.

For more information about these advanced options, see Advanced Options.

For information about how to edit computer settings, see Edit Settings for
Computer.

82 IBM Bigfix: Configuration Guide

Chapter 10. Archiving Client files on the BigFix Server
You can collect multiple files from BigFix clients into an archive and move them
through the relay system to the server. This allows the BigFix Administrator to
automatically log data from specific managed computers.

To do this, a new component called the Archive Manager has been added to the
BigFix Client which can collect files periodically or on command. It passes the
resultant compressed tar-ball to the Upload Manager on the BigFix Client. The
Upload Manager has an input directory that queues the files for uploading.

The Upload Manager performs one upload operation at a time, moving the data in
manageable chunks to reduce network traffic. It sends these chunks to the nearest
BigFix relay or server, where the PostFile program reassembles the chunks back
into the original file.

PostFile then passes the file up the chain, to the next BigFix relay or to its ultimate
destination at the BigFix server. It again uses the Upload Manager to slice the file
into chunks and send them on to the next PostFile program in the hierarchy. When
the file finally arrives at the BigFix server, it is saved in a special directory location
based on the ID of the client computer.

Along the way, both the Upload Manager and the PostFile program can alter the
chunk size or throttle the upload speed to smooth out network traffic.

Note: When it encounters an unregistered BigFix Client, the Upload Manager

pauses. This can happen for a variety of reasons, including a downed network, a
busy server, or a disconnected client. As soon as the BigFix client can register with
the BigFix system again, it restarts the Upload Manager and continues from where
it stopped.

Editing the archive manager settings

A typical archive is a collection of logs and configuration files that are compiled
regularly and posted to the server. There are many settings available to help you
customize your logging needs.

To initialize the various archive settings, follow these steps:

1. Start the BigFix Console.
2. Select the Computers tab.
3. From the filter/list, select the set of computers that you want to start archiving.
4. Select Edit Computer Settings from the Edit menu. Typically, you select
multiple computers, so you see a tabbed dialog box.
5. Select the Settings tab.
6. Check the Custom Setting box.
7. Enter the Names and corresponding Values of the desired settings.

© Copyright IBM Corp. 2010, 2018 83

Creating a Custom Action
You can create custom actions that can post attributes about the BigFix client to an
archive file.

To create a custom action:

1. Start the BigFix Console.
2. Select the Computers tab.
3. From the filter/list, select the set of computers that you want to target for the
action.
4. Select Take Custom Action from the Tools menu.
5. Select the Action Script tab.
6. Enter the desired Action Script in the text box provided.

Archive Manager
Archive Manager is a component of the BigFix Client that can collect files
periodically or on command. It passes the resultant compressed tar-ball to the
Upload Manager on the BigFix Client.

Archive Manager Settings

These are the settings of the Archive Manager component:
_BESClient_ArchiveManager_OperatingMode
The OperatingMode dictates the style of archiving, allowing periodic or
triggered archiving. The following modes are available:
0: Disable all archival operations (default value).
1: Automatic, with a period =
BESClient_ArchiveManager_IntervalSeconds.
2: Enables the archive now action command.
To allow a custom action to post client attributes to an archive file, make
sure the OperatingMode is set to 2.
The default value of 0 disables archiving.
_BESClient_ArchiveManager_FileSet-<tag>
This setting (actually a group of settings with optional tags) specifies the
files to be archived. This technique lets you specify multiple named
batches of files. Each setting starts with
"_BESClient_ArchiveManager_FileSet-" and ends with a batch name (the
<tag> part).
The value of each setting is a path on the client file system. It can be a
single file, in which case that file is part of the archive; a single directory,
in which case all files in the directory will be part of the archive; or a
directory path ending with wild cards, in which case all files in the
directory matching the wild cards will be part of the archive.
For example, the setting _BESClient_ArchiveManager_FileSet-(log),
representing all the log files in a temporary log folder, could have a value
like c:\temp\log.

84 IBM Bigfix: Configuration Guide

 Everything after the dash (-) is used as the default prefix of the files as
they are unpacked on the root server. Therefore a file named x.log in the
c:\temp\log folder would be unpacked as (Log)x.log.
_BESClient_ArchiveManager_SendAll
This setting allows you to send just the archives that have changed,
avoiding redundant uploads. There are two possible values for this setting:
0: Only send files that have changed since the last archive operation
(default).
1: Send all files, even if they have not changed.

The default value of 0 is recommended for most applications.

_BESClient_ArchiveManager_MaxArchiveSize
This setting limits the size (in bytes) of the uploaded archive. Because a
typical archive might be composed of several files, the archive size
corresponds to the sum of the file sizes.
If the limit is exceeded, an archive that contains only the index file is
created and uploaded by the Archive Manager. The index contains the
following header line:
MaxArchiveSize: Exceeded

The default value is 1000000 (one million bytes), however, since IBM
Endpoint Manager V8.0, the file system is 64-bit. This means that the
actual maximum file size is 2^64 – 1, sufficient for any reasonably sized
file.

Note: For additional information about the index file see “Archive
Manager Settings” on page 84.
_BESClient_ArchiveManager_IntervalSeconds
When the OperatingMode is set to 1, this setting determines the interval at
which the client triggers an archive.
The default value is 86400 seconds (24 hours).

Archive Manager internal variables

These are the internal variables of the Archive Manager component:
__BESClient_ArchiveManager_LastArchive
The Archive Manager updates this setting whenever it posts an archive.
The value of the setting is the secure hash algorithm (sha1) of the file that
was posted.
__BESClient_ArchiveManager_LastIntervalNumber
The BigFix Client updates this setting whenever it posts an archive. It
represents the interval number from 1970 to the time when the archive was
last collected. If the interval is a day long (the default), then the setting
indicates the number of days from 1970 to the day when it created the last
archive. It is calculated such that when the interval number changes, it is
time to create a new archive.
The value is also offset by a time corresponding to the computer id, to
stagger the collecting of archives.

Chapter 10. Archiving Client files on the BigFix Server 85

 Archive Manager Index File Format
During the building of the archive, the Archive Manager creates an index
containing metadata about the archive. This is a sample index from an archive
with a single file:
MIME-Version: 1.0
Content-Type: multipart/x-directory2; boundary="==="
Unique-ID: 1077307147
Archive-Size: 105
SendAll: 0
Date: Wed, 17 Mar 2004 02:23:01 +0000
FileSet-(LOG): c:\temp\log\newfile.log

--===

URL: file:///c:/temp/log/newfile.log
NAME: (LOG)newfile.log
SIZE: 105
TYPE: FILE
HASH: 3a2952e0db8b1e31683f801c6384943aae7fb273
MODIFIED: Sun, 14 Mar 2004 18:32:58 +0000

--===--

Upload Manager
The Upload Manager coordinates the sending of files in chunks to the Post File
program. You can throttle the upload dataflow to conserve bandwidth. Since IBM
BigFix version 8.0, the file system uses 64 bits, sufficient for file sizes of up to 2^64
– 1 bytes in length.

Upload Manager Settings

These settings apply to the Upload Manager component:
_BESClient_UploadManager_BufferDirectory
The Archive Manager always sets the Upload Manager input Buffer
Directory to __BESData/__Global/Upload. This directory is on the client
computer, in the BigFix Client folder.
_BESClient_UploadManager_ChunkSize
Uploads are done one chunk at a time. In a conflict between this computer
and the upstream computer, the size of the chunk is set to the smaller of
the two.
The local chunk size setting is specified in bytes. The default value is
131072 that corresponds to 128 KB.
Values range from 1024 to 4294967295. If you set a value less than 1024, it
is automatically reset to 1024.
A BES Client restart is needed to update the value of this setting.
_BESClient_UploadManager_ThrottleKBPS
After each chunk is uploaded, the Upload Manager calculates the amount
of time to sleep to maintain the throttle speed in kilobytes per second
(ThrottleKBPS). This allows you to compensate for network bottlenecks.
For example, a BigFix client that is connected over a slow VPN to the relay
might have a low upload throttle rate to minimize the bandwidth on that
network segment.

86 IBM Bigfix: Configuration Guide

 In a conflict between this computer and the upstream relay (or server), the
throttle KBPS is set to the smaller of the two.
The default value is 0, which disables throttling.
_BESRelay_UploadManager_BufferDirectory
Like the BigFix Client, the BigFix Relay also has an Upload Manager, and
it also has a buffer directory, whose path is specified by this setting. The
Upload Manager uploads the files in the sha1 subdirectory of the specified
directory. It sorts the files by modification time and then, just like the
BigFix Client, it uploads them in chunks to smooth out the bandwidth
requirements.
_BESRelay_UploadManager_BufferDirectoryMaxSize
This setting denotes the maximum amount of space on disk that can be
used to store the data uploaded from the BigFix Clients using the Upload
Manager. You can specify this setting on the BigFix Server and on the
BigFix Relays. Depending on the role of the system in the BigFix topology,
the behavior of this setting differs as follows:
On a BigFix Relay:
v You can set the maximum file size to be as large as 2^64 – 1
bytes. Its default value is 1 GB.
v A check against this setting is run every time a new file is
received.
On the BigFix Server:
v By default the setting is not specified on the system, meaning
that the maximum size of the Buffer Directory is unlimited.
Specify this setting to define a threshold size for the Buffer
Directory. You must remove the setting to restore the default
value.
v The BigFix Server checks every 15 minutes if the size of the
Buffer Directory exceeds the value set in
_BESRelay_UploadManager_BufferDirectoryMaxSize. If this check
is true, the BigFix Server does not accept any additional
uploaded files. Change the value of the setting either manually
or using the appropriate Fixlet, or reduce the content of the
Buffer Directory to resume uploading files.

Note: Starting from version 9.5 Patch 5, the

_BESRelay_UploadManager_BufferDirectoryMaxSize checking is
listed among the prerequisite checks for running the upgrade. For
more information, see Upgrading on Windows systems or
Upgrading on Linux systems.
_BESRelay_Uploadmanager_BufferDirectoryMaxCount
This setting denotes the maximum number of files that the Upload
Manager Buffer Directory is allowed to store. You can specify this setting
on the BigFix Server and on the BigFix Relays. Depending on the role of
the system in the BigFix topology, the behavior of this setting differs as
follows:
On a BigFix Relay:
v Its default value is 10,000.
v A check against this setting is run every time a new file is
received.

Chapter 10. Archiving Client files on the BigFix Server 87

 On the BigFix Server:
v By default the setting is not specified on the system, meaning
that the maximum number of files in the Buffer Directory is
unlimited. Specify this setting to define a threshold to the
number of files stored in the Buffer Directory. You must remove
the setting to restore the default value.
v The BigFix Server checks every 15 minutes if the number of
uploaded files stored in the Buffer Directory exceeds the value
set in _BESRelay_UploadManager_BufferDirectoryMaxCount. If
this check is true, the BigFix Server does not accept any
additional uploaded files. Change the value of the setting either
manually or using the appropriate Fixlet, or reduce the content
of the Buffer Directory to resume uploading files.

Note: Starting from version 9.5 Patch 5, the

_BESRelay_UploadManager_BufferDirectoryMaxCount checking is
listed among the prerequisite checks for running the upgrade. For
more information, see Upgrading on Windows systems or
Upgrading on Linux systems.
_BESRelay_UploadManager_CompressedFileMaxSize
This setting denotes the amount of space of the largest compressed file the
Upload Manager is allowed to handle. You can set the maximum file size
to be as large as 2^64 – 1 bytes. It applies only to the server and it is
evaluated during the decompression of the uploaded archive.
_BESRelay_UploadManager_ChunkSize
Uploads are done one chunk at a time. In a conflict between this computer
and the upstream computer, the size of the chunk is set to the smaller of
the two.
The local chunk size setting is specified in bytes. The default value is
131072 that corresponds to 128 KB.
Values range from 1024 to 4294967295. If you set a value less than 1024, it
is automatically reset to 1024.
A BES Relay restart is needed to update the value of this setting.
_BESRelay_UploadManager_ThrottleKBPS
After each chunk is uploaded, the Upload Manager calculates the amount
of time to sleep to maintain the throttle speed in kilobytes per second
(ThrottleKBPS). This allows you to compensate for network bottlenecks.
For example, a BigFix relay that is connected over a slow VPN to the
server might have a low upload throttle rate to minimize the bandwidth
on that network segment.
In a conflict between this computer and the upstream server (or relay), the
throttle KBPS is set to the smaller of the two.
The default value is 0, which disables throttling.
_BESRelay_UploadManager_CleanupHours
Sometimes archived files accumulate but do not get uploaded. This might
happen with a network outage, a downed server or other communication
problem. To avoid overloading the system, these old files are deleted or
cleaned up. This setting determines how old a file can get before it is
deleted.
The default value is 72 hours (three days).

88 IBM Bigfix: Configuration Guide

 Note: IBM BigFix Inventory and IBM BigFix License Metric Tool upload a lot of
data from the BigFix Clients. If you plan to use any of these two applications you
are suggested to specify a value for the settings
_BESRelay_UploadManager_BufferDirectoryMaxSize and
_BESRelay_UploadManager_BufferDirectoryMaxCount to limit the disk space usage.

PostFile
The PostFile program receives the chunks of files posted by the Upload Manager
and appends them to its own copy of the file. The Upload Manager specifies the
range of bytes being posted and the sha1 of the file, which is used as the filename.
These parameters are appended to the URL as in the following example:
postfile.exe?sha1=51ee4cf2196c4cb73abc6c6698944cd321593007&range=1000,1999,20000

Here the sha1 value identifies the file, and the range in this case specifies the
second 1,000 byte chunk of a 20,000 byte file.

When PostFile receives a chunk of the file it first checks to make sure it is the
correct segment. If so, it appends the posted data to its local copy of the file. It
returns the size of this file, as well as the current chunk size and throttle BPS
settings.

PostFile has to handle several BigFix clients feeding into it at the same time. To
balance that load, it adjusts the throttle rate. The effective throttling rate is
determined by dividing the limiting PostFile rate by the number of concurrently
uploading files.

For example, if PostFile has a throttle setting of 100 KBPS and 50 clients are
simultaneously uploading files, the throttle value returned to each client would be
adjusted to 2 KBPS. By setting custom throttle values to specific BigFix relays, you
can efficiently deal with any bottlenecks in your network.

PostFile stores the partially uploaded files in the Upload Manager's buffer
directory with an underscore in front of them (the Upload Manager does not
upload files that begin with underscore). When PostFile receives the last chunk of
the file, it calculates the sha1 of the file and checks that it matches the sha1
parameter in the URL. If so, it removes the leading underscore.

The Upload Manager can then upload the file to the next relay up the hierarchy
(or any other server, if so specified).

PostFile determines whether or not the Upload Manager is running. If not, PostFile
assumes that it has reached its root server destination. It renames the uploaded
file, extracts the files from the archive, and deposits them in a subfolder of the
Upload Manager's buffer directory.

The program calculates the subfolder path using a modulus of the computer ID.
This has the effect of spreading out file directory accesses and preventing an
overpopulation of any single directory.

For example, the path to file "log" from computer ID1076028615 is converted to the
path "BufferDir/sha1/15/1076028615/log" where 15 is the remainder modulo 100
(the lower two digits) of the id.

Chapter 10. Archiving Client files on the BigFix Server 89

 If the uploaded file is a valid BigFix archive and is successfully extracted, then the
original uploaded file is deleted.

PostFile Settings
PostFile uses the _BESRelay_PostFile_ChunkSize and
_BESRelay_PostFile_ThrottleKBPS settings for the chunk size and throttle values
for incoming data. These values can be adjusted for varying connection speeds or
other network anomalies.

When PostFile communicates with the upload manager, it passes along these
values. As mentioned before, if there is a conflict between any two computers over
these settings, it favors the smaller value.

The default values are 128K for ChunkSize and 0 for ThrottleKBPS (disable
throttling).

Resource Examples
Example 1

In this example, we want to collect all the files in the c:\log folder and all the .ini
files in the c:\myapp folder once an hour. Send up only the differences and don't
send the archive if it exceeds 1,000,000 bytes in size. To set this up, create the
following settings in the BigFix Console:
_BESClient_ArchiveManager_FileSet-(Log) = c:\log
_BESClient_ArchiveManager_FileSet-(Ini) = c:\myapp\*.ini
_BESClient_ArchiveManager_OperatingMode = 1
_BESClient_ArchiveManager_Interval_Seconds = 3600
_BESClient_ArchiveManager_SendAll = 0
_BESClient_ArchiveManager_MaxArchiveSize = 1000000

Example 2

In this example, we want the same set of files as above, but we also want to collect
some useful attributes (retrieved properties) from the client computer. A custom
action can generate these attributes and trigger an archive when it completes. It
uses the same settings as above, but sets the operating mode to 2 to enable the
archive now action command:
_BESClient_ArchiveManager_OperatingMode = 2

You can then create a custom action, specifying the attributes you want to collect.
For example, to append the operating system, computer name, and DNS name to
the log file, create a custom action like this:
appendfile {"System:" & name of operating system}
appendfile {"Computer:" & computer name}
appendfile {"DNS name:" & dns name}
delete "c:\log\properties.log"
copy __appendfile "c:\log\properties.log"
archive now

The appendfile command creates a temporary text file named __appendfile . Each
time you invoke the command, it appends the text you specify to the end of this
temporary file.

90 IBM Bigfix: Configuration Guide

The delete and copy commands clear out the old log file (if any) and copy the
__appendfile to the log. This has the effect of creating a new properties.log file.
The archive now command immediately creates an archive, as long as the
OperatingMode is set to 2.

You can then target this action to any subset of BigFix Clients, using whatever
scheduling you choose. Using variations on this scheme, you could perform a full
archive once a week, in addition to nightly differences.

Chapter 10. Archiving Client files on the BigFix Server 91

92 IBM Bigfix: Configuration Guide
Chapter 11. Additional configuration steps
These topics explain additional configuration steps that you can run in your
environment.

Installing and configuring the email notification service

You can use the email notification service to send automatic email notifications to
notify you about the completion status of Baselines that you run. To use this
notification feature, you must first install the notification service by running a Task.
After you have installed the service, you must configure it by running another
Task.

The BES Server Plugin Service must be installed on the BigFix Server and the REST
API master operator credentials must be configured using Fixlet 1294 on BES
Support.

To install and set up the notification service, you must be subscribed to the BES
Support site. The installation and setup Task are available from the BES Support
site. To help you ensure that you run Task in the correct order, the installation and
setup Task become relevant in the order in which you need to run them. So each
Task will become relevant only when you need to run it.

Complete the following steps to install and set up the notification service.
1. To install the notification service, from the Fixlets and Tasks node of the
navigation tree in BES Support, select one of the following Task, depending on
whether you are installing the notification service on Windows or Linux:
v Task 2238 Install Latest Notification Service to install the notification
service on Windows operating system. When you run the Task, target the
BigFix Server and enter the port number on which you want the notification
service to listen. This Task downloads and installs the notification service.
v Task 2241 Install Latest Notification Service (RHEL) to install the
notification service on Linux. When you run the Task, target the BigFix
Server and enter the port number on which you want the notification service
to listen. This Task downloads and installs the notification service.
If the installation does not complete successfully, check to see if a Task has
become relevant in the Notification > Warnings folder. If there is a Task that is
relevant in the Warnings folder, run the relevant Task. After the Task has
completed, run the installation Task again.
2. Activate analysis 2243 Notification Service Details.
3. Run Task 2240 Configure Settings for Notification Service to configure the
SMTP login settings for the email notification service. Complete the form, as
follows, and then click Take Action:
v Notification Service Port: you can change the value here to update the port
number that the notification service listens on, as set in Task 2238 Install
Latest Notification Service or Task 2241 Install Latest Notification
Service (RHEL).
v From Email Address: you can change the value here to update the default
From email address that is displayed in the From field of the notification email

© Copyright IBM Corp. 2010, 2018 93

 and the email address as configured in Task 165 Send an Email Notification,
which is the Task that you use to send the email notification.
v SMTP Method: select an SMTP method for the notification service, either
Plain or None. If you select None, no SMTP authentication is used and the
User name and Password fields are disabled. If you select Plain, you must
authenticate with a user name and password is required.
v SMTP Host: enter the IP address, host name or fully qualified host name of
the SMTP server. This is a required field.
v SMTP Port: accept the default port number value of 25 or enter a different
value for the port number of the SMTP server. This is a required field.
v User name: enter the user name for the email account. This is a required
field if you selected Plain as the SMTP method.
v Password: enter the password for the email account. This is a required field
if you selected Plain as the SMTP method.
v Confirm Password: confirm the password that you entered in the previous
field. This is a required field if you selected Plain as the SMTP method.
After you have completed this step, the notification service is set up and ready
to use.

The notification service is set up and configured according to your settings.

Note: To uninstall the notification service, use Task 2239 Uninstall Notification
Service to uninstall from Microsoft Windows platforms or Task 2242 Uninstall
Notification Service (RHEL) to uninstall from Linux platforms.

Sending email notifications

You can use the email notification service to send automatic email notifications to
notify you about the completion status of Baselines that you run.

Before you can send email notifications, you must set up and configure the
notification service.

After you have installed and configured the notification service, you can send
email notifications to notify you about the completion status of Baselines.

Complete the following steps to send email notifications.

1. To use the notification service, add a modified copy of Task 2245 Sample Task:
Send an Email Notification as a component in a Baseline at the point at
which you want the notification to be sent. For example, if you want an email
notification to be sent when the Baseline has completed, add the Task as the
last component in the Baseline. Copy and modify the Task as follows:
v Copy Task 2245 Sample Task: Send an Email Notification using Static
Action Script Content.
v Modify the copy of the Task by changing the details in the action script to
include your specific settings for the following keys. The keys included in
the following example represent the minimum required keys to send a
notification:
// NOTIFICATION_START
// to: "< your comma separated list of recepient email addresses goes here >"
// from: "< your single email address that will be shown as the sender of
the email goes here >"
// subject: "< your email title goes here >"
// body: "< your main email detail content goes here >"
// NOTIFICATION_END

94 IBM Bigfix: Configuration Guide

 The complete list of keys are listed in the following table.
Table 2. Notification keys
Key Description
to The email addresses to whom the notification is be sent. The
valid values are a comma (,) separated list of valid email
addresses. This is a required key.
from The email address that is displayed as the sender of the
notification email. The email address does not have to exist, but
the value that you specify must be in the format of a valid email
address. This is a required key.
subject The notification summary that appears as the subject of the email.
Any text is a valid entry for this key. The text that you enter can
include tokens that are replaced at run-time. This is a required
field.
body The main notification text content for the email. You can enter
any text for this key, including tokens that are replaced at
run-time. This is a required field.
failure-trigger This defines the number of failures that cause the notification to
be sent. When this key is specified, the notification is sent when
the specified number of failures occurs. When this key is omitted,
the notification is sent when it completes. Enter a whole number
greater than zero. This is an optional key.
scope Determines which action is examined for result statuses when
determining if an action failed or completed successfully. When
this key is omitted, the results of the action containing these
notification comments are examined. The valid value is parent,
which means the results of the parent Baseline are examined
instead of the action containing the notification comments. This is
an optional key.

v Save the modified copy of the Task.

v Add your modified copy to the Baseline for which you want to send the
email notification.
Review the Task description for complete information about how to modify the
Task and include in a Baseline. Examples are included in the Example section
below.
2. Run the Baseline. When the Baseline completes, an email notification is sent to
the email addresses that you specified.

The following examples show how you can use the keys:

If you add the Task with the following notification comments as a component in a
baseline, it sends an email when this Task (component) completes (for example,
this may be useful if added to the middle of a baseline):
// NOTIFICATION_START
// to: "[email protected], [email protected]"
// from: "[email protected]"
// subject: "Basline component ’{actionName}’ has completed successfully"
// body: "Baseline is 50% complete now"
// NOTIFICATION_END

When a Task consisting of the following notification comments is added as a

component in a Baseline, it sends an email when that overall Baseline completes:

Chapter 11. Additional configuration steps 95

 // NOTIFICATION_START
// to: "[email protected], [email protected]"
// from: "[email protected]"
// subject: "Basline ’{actionName}’ with ID {actionID} has completed successfully"
// body: "The Baseline is complete!"
// scope: "parent"
// NOTIFICATION_END

You can add the previous two examples only to baselines that are statically
targeted. Baselines targeted by group, property or name list do not enable a
notification to be sent.

You can specify the following example in Baselines targeted statically or

dynamically:
// NOTIFICATION_START
// to: "[email protected], [email protected]"
// from: "[email protected]"
// subject: "Basline ’{actionName}’ with ID {actionID} has failed on 5 or more computers"
// body: "Review the results of Baseline ’{actionName}’ (ID: {actionID})"
// failure-trigger: "5"
// scope: "parent"
// NOTIFICATION_END

Configuring FillDB
The FillDB process runs on the BigFix Server system and is responsible for storing
the information returned from the BigFix Agents into the BigFix database. This
information can be:
v Data, such as the value of retrieved properties or the result of the evaluation of
the applicability relevance or the success criteria of Fixlets and Tasks.
v The information contained in a report returning the result of a BigFix Query.
This is how you can configure FillDB processing:
v “Configuring the FillDB database insertion level”
v “Increasing the size of the FillDB buffer directory” on page 97
v “Enabling FillDB parallel processing” on page 98

Configuring the FillDB database insertion level

The FillDB utility offers a parameter called DatabaseBoostLevel to optimize BigFix
performance.

On 9.5 Windows systems: The possible values for the DatabaseBoostLevel

parameter are 1 for enabled and 0 for disabled. The default value is 0.

On 9.5 Linux systems (fresh installations and upgrades): The DatabaseBoostLevel

parameter value is always: Database Boost Level is ON with maxBatchSize = 1000.

The improvements to BigFix performance depend on the environment in which

BigFix runs. To find the best performance configuration for your environment, tune
the data insertion mechanism in the FillDB database as follows:
1. Enable the performance log.
Set the following string value in the [HKLM\Software\Wow6432Node\BigFix\
Enterprise Server\FillDB] registry:
"PerformanceDataPath"[REG_SZ] = "[IEM Server folder]\FillDB\FillDBperf.log"

96 IBM Bigfix: Configuration Guide

 2. Restart the FillDB service and monitor the performance log for a while,
registering the database insertion rate in "rows per second" of the various
tables.
3. Add the DatabaseBoostLevel DWord value to the registry key
HKLM\Software\Wow6432Node\BigFix\Enterprise Server\FillDB and set it to 1.
4. Restart the FillDB service and monitor the performance log again for a while,
registering the database insertion rate in "rows per second" of the various
tables.
5. Compare the insertion rate before and after setting the new value of the
DatabaseBoostLevel parameter, ensuring that you keep the same level of
workload during the monitoring. The more rows that are processed per second,
the better the performance. The key tables to monitor are: questionresults,
fixletresults, actionresults and longquestionresults. The number of rows
processed per table is an indicator of the importance that the table has in your
environment.

Increasing the size of the FillDB buffer directory

The FillDB buffer directory temporarily stores reports from the clients before they
are stored into the database.

By default the directory is full if it contains 3MB of files or if it has more than
10,000 files. The consequence is that the information is not sent to the IEM server
quickly, and it might be a severe problem.

You can configure the FillDB buffer directory and the maximum number of hold
files by performing the following steps:

On Windows systems:
1. Add the following keys to the registry HKLM\Software\Wow6432Node\BigFix\
Enterprise Server\PostResults:
BufferDirectoryMaxSize
It defines the maximum size of the FillDB buffer directory, in bytes. The
default value is 3MB.

Note: Do not increase this value over 20MB without specific guidance
from IBM Support.
BufferDirectoryMaxCount
It defines the maximum number of files allowed in the FillDB buffer
directory. The default value is 10,000.
2. Restart the FillDB service.

On Linux systems:
1. Add the following lines to the /var/opt/BESServer/besserver.config file:
[Software\BigFix\Enterprise Server\PostResults]
BufferDirectoryMaxSize = <SIZE_IN_BYTES>

[Software\BigFix\Enterprise Server\PostResults]
BufferDirectoryMaxCount = <MAX_NUMBER_OF_FILES>

where:

Chapter 11. Additional configuration steps 97

 BufferDirectoryMaxSize
It defines the maximum size of the FillDB buffer directory, in bytes. The
default value is 3MB.
BufferDirectoryMaxCount
It defines the maximum number of files allowed in the FillDB buffer
directory. The default value is 10,000.
2. Restart the FillDB service.

Enabling FillDB parallel processing

On the BigFix Server the FillDB process is responsible to run in a single thread the
following activities:
v Read the buffer directory content.
v Parse the report, which includes:
– Decrypting the encrypted reports.
– Decompressing the compressed reports.
v Store the report data in the database.
v Replicate content from other DSA servers (optional).

An additional thread is responsible for performing the same type of processing for
the reports returned by BigFix Query processing.

Starting from V9.5 Patch 5, the parallel processing is enabled by default during a
fresh installation and upgrade according to the following rules:
v If the machine has 6 to 9 cores, the parallelism is enabled for normal reports by
configuring 3 parsing threads and 3 database update threads.
v If the machine has at least 10 cores, the parallelism is enabled both for normal
and for query reports by configuring for each of them 3 parsing threads and 3
database update threads for a total of 12 threads.

You can manually enable or disable the FillDB parallel processing by configuring
the following settings on the BigFix Server:
v ParallelismEnabled
v ParallelismEnabledForQuery

Once you enabled the FillDB parallel processing, you can configure its behavior by
specifying the following settings on the BigFix Server:
v NumberOfParsingThreads
v NumberOfDBUpdatingThreads
v MaxNumberOfReportsReadyForDB
v MinNumberOfReportsReadyForDB
v MaxNumberOfReportsInParsingQueue
v NumberOfParsingThreadsForQuery
v NumberOfDBUpdatingThreadsForQuery
v MaxNumberOfQueryReportsReadyForDB
v MinNumberOfQueryReportsReadyForDB
v MaxNumberOfQueryReportsInParsingQueue

98 IBM Bigfix: Configuration Guide

 For more information about these settings, see https://www.ibm.com/
developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Endpoint
%20Manager/page/Configuration%20Settings.

Run the following steps to activate changes on one or more of the settings
specified above:
If the BigFix Server is installed on a Windows system:
1. Stop the BES FillDB service.
2. Update the values of the settings as appropriate in the Windows
registry.
3. Start the BES FillDB service
If the BigFix Server is installed on a Linux system:
1. Stop besfilldb, for example /etc/init.d/besfilldb stop
2. Stop besserver, for example /etc/init.d/besserver stop
3. Update the values of the settings as appropriate in the
besserver.config file.
4. Start besserver, for example /etc/init.d/besserver start
5. Start besfilldb, for example /etc/init.d/besfilldb start

Configuring ODBC
This topic describes how to use Open DataBase Connectivity (ODBC) to set up and
configure ODBC Data Sources with BigFix. Each ODBC Data Source is identified
by an ODBC Data Source Name (DSN), like bes_bfenterprise used to access data
in a variety of DBMS such as Microsoft SQL or IBM DB2 in an easier way. DSNs
are stored locally on the computer used to reach the database. Each DSN is used to
save authentication and setting information for a database connection. In this way
users can connect with a database once and save the information for future use.

To access a database easier, a DSN can be used to save authentication and setting
information for a database connection. In this way users can connect with a
database once and save the information for future use. DSNs are stored locally on
the computer used to reach the database. Each DSN is identified by a name, like
bes_bfenterprise.

BigFix can use several DSNs to connect to the same database. Each DSN has
different settings and each one can be used to connect to the database in different
ways. For example, the primary distinction between the bes_bfenterprise and
bes_EnterpriseServer DSNs is that bes_bfenterprise connects to the BigFix
database using Windows NT authentication and bes_EnterpriseServer connects
using SQL authentication.

On Windows systems you can view your DSNs by running Control Panel >
Administrative Tools > Data Sources (ODBC), which launches the ODBC Data
Source Administrator tool. The first tab, User DSN, specifies DSNs that are
available only to the currently logged in user. Most of the BigFix DSNs are found
and created in the System DSN which contain DSNs that are available to anyone
using the machine and by the System account of the machine itself. Only a user
with Administrative privileges can make changes in the System DSN tab. If you
create a new DSN it uses SQL Server as a Driver.

Chapter 11. Additional configuration steps 99

 Microsoft SQL Database Connection
To configure an ODBC connection for Microsoft SQL database, you must define the
following settings of the DSN used by BigFix:
Name The name of the DSN used to identify stored an ODBC Data Source. BigFix
looks for DSNs with names like enterprise_setup and bes_bfenterprise.
BigFix components expect a DSN with a certain name to exist and
automatically attempts to use those DSNs to connect to the database. For
example the Console and the Administration Tool use any DSN with the
bes_ prefix on it even if these DSNs are displayed without the prefix when
launched.
Server This field specifies the machine where the BigFix database, to which the
DSN connects, resides. If you are setting a remote database, change this
field to point to the database machine for all DSNs that are created
automatically by BigFix installers.
When you perform any upgrade, the system resets the DSNs to point to
the BigFix Server. Therefore, after any upgrade to the BigFix Consoles or to
the BigFix Server, ensure that you set again the DSNs to the values
previously specified.
Authentication Method
You can set two types of authentication: Windows NT or SQL
authentication.
The Windows NT authentication method uses your Windows Login and
Password as the Login ID and Password to the database.
The SQL authentication method requires a Login ID and Password
supplied manually every time a connection to the database is made.
You can set up the BigFix components to use either of these two
authentication methods. Choose one approach and maintain the use of that
scheme for configuring DSNs, apart from the bes_EnterpriseServer DSN
which must always use the SQL authentication.
Default Database
The default database is the database instance that this DSN uses. The
defaultBigFix database instances are: bfenterprise and BESReporting by
default. If the DSN is going to be used for Web Reports it will default to
the BESReporting database instance. Otherwise the DSN uses bfenterprise
by default. Your authentication information is used to access this database
instance as well. There are two levels of permissions on SQL Server, the
first is to access the database itself and the second to access database
instances.

Note: Select Connect to SQL Server to obtain default settings for the
additional configuration options and provide an ID and password only if
you want to test the connection. The Login ID and Password you provide
are not stored with the DSN. They are used to obtain default settings and
test the DSN. After the configuration of the DSN is complete, this
information is discarded. You must provide the same credentials every
time the SQL authenticated DSN attempts to connect to the database.
Table 3. BigFix Components and DSNs
BigFix Component DSN Authentication Methods
BigFix server installation enterprise_setup NT

100 IBM Bigfix: Configuration Guide

 Table 3. BigFix Components and DSNs (continued)
BigFix Component DSN Authentication Methods
BigFix server bes_bfenterprise NT or SQL
BigFix console any DSN beginning with NT or SQL
bes_
BigFix Administration tool any DSN beginning with NT or SQL
bes_
BigFix Web Reports LocalBESReportingServer NT or SQL
Note: the
LocalBESReportingServer
DSN contains configuration
and login data and not data
shown in Web Reports
reports. In Web Reports on
the Database Settings page
when adding a new database
or configuring a remote
database, use the
bes_bfenterprise DSN.

DB2 Database Connection

Before setting the server ODBC connections, download the latest version of
BES\Shared\Database\DB2Schema and create the IBM BigFix database on the
Windows operating system using the command:
<script_location>\DB2createdb.bat <DB2 Admin User> <DB2 Admin Password> <drive letter>

as shown in the following example:

C:\TEMDB2\DB2createdb.bat db2admin db2_password C:

After you create the database, perform the following steps to set the Server ODBC
connections:
1. Open the Microsoft Open Database Connectivity (ODBC) Data Source
Administrator tool and create a new data source bes_bfenterprise_db2 as
shown in the next steps.
A 64-bit version of the Windows operating system (such as Windows 2008 R2)
includes the following versions of the ODBC Data Source Administrator tool
(Odbcad32.exe):
v The 32-bit version of the Odbcad32.exe file is located in the
%systemdrive%\Windows\SysWoW64 folder.
v The 64-bit version of the Odbcad32.exe file is located in the
%systemdrive%\Windows\System32 folder
This tool adds a new user data source.
2. In the Create New Data Source window, choose the driver for which you are
adding a user data source and click Finish:

Chapter 11. Additional configuration steps 101

 3. In the driver-specific setup dialog box enter the data source name, the DB2
database alias, and a description.

4. In the CLI/ODBC Settings window, click Advanced Settings:

102 IBM Bigfix: Configuration Guide

5. Add the following ODBC parameters:

6. Test the ODBC connection, then remove the MSSQL ODBC created by the IEM
installation.
7. Create the following registry keys to run the BESAdmin Administration tool:
v HKEY_CURRENT_USER\Software\BigFix\BFEadmin\Database
name = dsn
type = REG_SZ
Value = bes_bfenterprise_db2
v HKEY_CURRENT_USER\Software\BigFix\BFEadmin\Settings

Chapter 11. Additional configuration steps 103

 name = AllowCustomUsername
type = REG_DWORD
Value = 1
8. Run BESAdmin.exe to create a schema and populate the database. See the
following log files: BESAdmin.log located under C:\Documents and
BESAdminDebugOut.txt located under Settings\Administrator\Local
Settings\Application Data\BigFix.
9. Enter the user name and the password to connect to the DB2 database:

10. Connect the BESRootServer service to DB2, by creating the following registry
keys:
name = User
type = REG_SZ
Value = db2admin
name = Password
type = REG_SZ
Value = Bigfix11
name = DSN
type = REG_SZ
Value = bes_bfenterprise_db2

under HKEY_LOCAL_MACHINE\Software\Wow6432Node\BigFix\Enterprise
Server\Database.
11. Before working with the DB2 database, remove the content of the following
server folders:
%PROGRAM FILES%\BigFix Enterprise\BES Server\wwwrootbes\bfmirror\bfsites
%PROGRAM FILES%\BigFix Enterprise\BES Server\wwwrootbes\bfsites
%PROGRAM FILES%\BigFix Enterprise\BES Server\Mirror Server\Inbox
12. Restart all IBM BigFix services.

Configuring the number of Web Reports results

To avoid excessive use of memory when displaying Web Reports results on
Explore Computers reports, you can configure the MaxReportResults keyword. This
keyword sets the maximum number of rows that can be displayed in a web report.
Its default value is 1000000. The valid value range of the keyword is 1-4294967295.

When you get the message:

Unable to update data table: server aborted or there was an error processing your request

on the report page and you see the exception:

Too many results returned from computer report. Report execution has been aborted

104 IBM Bigfix: Configuration Guide

 in the log files, indicating that the number of lines to be displayed exceeds the
default value, tune the keyword value by taking into account the type of report,
the computer properties, and the resources of the system where Web Reports is
running.

You can set this keyword both on Windows and Linux systems where Web Reports
is running, by completing the following steps:

On Windows systems:

Run regedit and locate the path HKEY_LOCAL_MACHINE\Software\Wow6432Node\

BigFix\Enterprise Server\BESReports.

Create the string value (reg_sz) MaxReportResults and set it to the identified value.
"MaxReportResults"[REG_SZ] = "1000000"

On Linux systems:

Add the MaxReportResults keyword to the [Software\BigFix\Enterprise

Server\BESReports] section of the beswebreports.config file and set it to the
identified value:
MaxReportResults = 1000000

Managing Daylight Saving Time (DST) for Web Reports

By default Web Reports track scheduled activity next attempt times using UTC
rather than the local time zone. So, when the local time zone changes, for example
from daylight saving time to non-daylight saving time, reports run an hour earlier
or later, depending on the direction of the change.

Starting from BigFix version 9.5 you can prevent to run scheduled reports an hour
earlier or later because of the change due to the daylight saving time by setting the
AdjustScheduleForDST keyword to 1.

You can set this keyword both on Windows and Linux systems where Web Reports
is running, by completing the following steps:

On Windows systems:

Run regedit and locate the path HKEY_LOCAL_MACHINE\Software\Wow6432Node\

BigFix\Enterprise Server\BESReports.

Create the string value AdjustScheduleForDST and set it to 1.

"AdjustScheduleForDST" = "1"

On Linux systems:

Add the AdjustScheduleForDST keyword to the [Software\BigFix\Enterprise

Server\BESReports] section of the beswebreports.config file and set it to 1:
AdjustScheduleForDST = 1

Important: The Daylight Saving Time setting becomes effective when the first
event after the change is triggered.

Chapter 11. Additional configuration steps 105

FIPS 140-2 cryptography in the BigFix environment
BigFix uses the BigFix Cryptographic Module to perform cryptographic functions
throughout its environment. For instance, every time an operator logs into the
BigFix console, creates a new user, initiates an action, or subscribes to new content
there are cryptographic operations performed by this module.

The BigFix Cryptographic Module has been certified by NIST as compliant with
the FIPS (Federal Information Processing Standard) 140-2 standard. Successful
validation under the FIPS 140-2 standard means that these software routines have
received an exceptional level of scrutiny and testing by a government approved
laboratory. FIPS 140-2 has four evaluation levels with Levels 1 and 2 applicable to
software. BigFix chose the more stringent Level 2 validation and was certified on
12 computing platforms. BigFix stops to run or does not start if the BigFix
Cryptographic Module enters an error state.

Configuring FIPS 140-2 on the BigFix Server

You can configure the BigFix server to use FIPS 140-2. In this way when the state
of BigFix Cryptographic Module is in error, BigFix does not start or stops running.

To verify the appropriate setup and initialization of the module you must check
the client log file by completing the following steps:
1. On the BigFix server launch the BigFix Admin Tool by selecting Start > All
Programs > Tivoli BigFix > Tivoli BigFix Administration Tool.
2. Browse to the location of your site license and click OK
3. Select the Masthead Management tab.
4. Click Edit Masthead.
5. Check Require use of FIPS 140-2 compliant cryptography to enable FIPS 140-2.
6. Click OK.
7. Enter the Administrator password to perform the action.
8. To ensure that the setting has been enabled check the client log file (default log
path: C:\Program Files\BigFix Enterprise\BES Client\__BESData\__Global\
Logs\YYYYMMDD.log for the following types of messages:
v FIPS 140-2 Enable log file message
At 14:36:12 -0700 -
FIPS mode enabled by masthead.
At 14:36:13 -0700 -
Cryptographic module initialized successfully in FIPS mode.
v FIPS 140-2 Disabled log file message
At 14:58:28 -0700 -
FIPS mode disabled by default.
Unrestricted mode

You can enforce the FIPS mode, by setting the __BESClient_Cryptography_FipsMode

value on the client. In this way the client does not run in FIPS mode when the
Cryptographic Module encounters an error at startup.

To force BigFix components to use only the FIPS validated Cryptographic library,
complete the following steps:
1. Launch the BigFix Console.

106 IBM Bigfix: Configuration Guide

 2. From the Computers tab, right-click any listed computer and choose Edit
Computer Settings.
3. Click Add.
4. In the Add Custom Settings dialog enter: __BESClient_Cryptography_FipsMode
in the Setting Name and required in the Setting Value
5. Click OK.
6. In the Target tab select All computers. When FIPS mode is enabled all
cryptographic operations such as digital signatures, encryption and SHA1,
SHA2 hashing are performed using the FIPS 140-2 Level 2 certified
cryptographic module.
7. In the Execution tab of the dialog choose Reapply this action whenever it
becomes relevant again and click OK

Note:
v When enabling the FIPS module, the OpenSSL library must be loaded at a static
address to satisfy its own self tests.
v The most common error related to the FIPS mode startup occurs on AIX and
HP-UX systems when there is not enough system entropy available for the
Cryptographic Module.
v The FIPS Mode setting and the Message Level Encryption (MLE) setting are
independent. You can set FIPS without setting the MLE and viceversa.

For information on Message Level Encryption see “Message Level Encryption

(MLE) Overview” on page 110 and “Message Level Encryption and DSA” on page
39

Managing Client Encryption

Server and relay-bound communications from clients can be encrypted to prevent
unauthorized access to sensitive information. To enable it, you must generate a key
and provide a setting value. The value is set in the console and is described in the
IBM BigFix Installation Guide.

On Windows server the key is generated from the Encryption tab of the IBM
BigFix Administration Tool:
1. Launch the IBM BigFix Administration Tool by selecting Start > Programs >
IBM BigFix > IBM BigFix Administration Tool.
2. Select the Encryption tab.

Chapter 11. Additional configuration steps 107

 At the top of the dialog is a statement of the current state (in this example: Report
encryption is currently DISABLED). Client encryption has four states: Disabled,
Pending, Enabled, and Pending Rotation:
Disabled
This state indicates that no encryption certificate is included in your
deployment masthead, which means that Clients cannot encrypt their
reports even if they are told to do so. Click Generate Key to create an
encryption certificate (and the corresponding private key, which can be
used to decrypt reports at the receiving end). The state is set to Pending
state.
Pending
In this state, an encryption certificate has been generated and is ready for
deployment, but the private key has not yet been distributed to all
necessary decrypting relays and servers. When you have manually
distributed the private key, click the Enable Encryption button to embed
the certificate in the masthead and send it out to all clients. The state is set
to Enabled. Click Cancel to return to the Disabled state.
Enabled
In this state, an encryption certificate has been found in your deployment
masthead, which means that you are able to turn on encryption (using the
setting discussed previously) for any of the clients in your deployment. At
any time, you can click Generate new key to create a new encryption
certificate. This is useful if you have a key rotation policy or if your
encryption key is ever compromised (see next section). Generating a new
key returns the state to Pending (unless you choose to deploy immediately
as described in the next section). You can also click Disable to move back
to the Disabled state.
Pending Rotation
In this state, an encryption certificate is included in your deployment
masthead, and a new certificate has been generated and is ready to replace
the existing certificate.

On Linux server you can encrypt clients by completing the following steps as
super user:
1. Generate the key:

108 IBM Bigfix: Configuration Guide

 ./besadmin.sh -reportencryption -generatekey -privateKeySize=max -deploynow=no
-outkeypath=<path> -sitePvkLocation=<path+license.pvk> -sitePvkPassword=<password>
2. Activate the key:
./besadmin.sh -reportencryption -deploynow=yes
-sitePvkLocation=<path+license.pvk> - sitePvkPassword=<password>

To list all the available options run:

./BESAdmin.sh -reportencryption -h

Generating a new encryption key

If your private key is compromised or if you have a policy of rotating keys, you
can generate a new key from the IBM BigFix Administration Tool.
1. Launch the IBM BigFix Administration Tool by selecting Start > Programs >
IBM BigFix > IBM BigFix Administration Tool.
2. Select the Encryption tab.
3. Click the Generate key button. The Create Encryption Credentials dialog
opens.

4. From this dialog, select the key size. The default is 2048, which is adequate for
most purposes. Check the box to use this key immediately. However, if you
have established relays that use encryption, leave this box unchecked until you
can distribute the new key to those relays.
5. Click OK to distribute this new key to your clients. You must provide your Site
Administration Private Key to propagate the action. A final dialog asks for
confirmation. For more information about encryption key sizes and server
requirements, see the knowledge-base article on server requirements at the IBM
BigFix support site.

Creating top-level decrypting relays

When an actionis deployed, thousands of clients might report back in a short time
frame, typically to a relay. If you have chosen to encrypt these reports, the relay
bundles the reports together and passes them to the server, which must then split
up and decrypt each one of them. With many thousands of clients, this can impose
a significant computational burden on the server.

Chapter 11. Additional configuration steps 109

 To improve performance, you can lighten the load on your server by allowing your
top-level relays to do the bulk of the decryption. If you have over 50,000 clients,
you might be able to substantially reduce the load on your server by moving
decryption down into the relay chain. If the relay has its own decryption key, it
can first decrypt the client messages into plain text and then bundle thousands of
them into a single archive. This can then be compressed, encrypted, and passed to
the server. At that point, the server can perform a single decryption on the entire
archive, noticeably reducing its overhead.

To spread the decryption tasks, distribute your encryption keys to your top-level
relays. For normal server-level encryption, IBM creates an encryption key for you
and places it in the program folder:

On Windows systems:
%PROGRAM FILES%\BigFix Enterprise\BES Server\Encryption Keys

On Linux systems:
var/opt/BES Server/Encryption Keys

To allocate the load to your top-level relays, place the encryption key in the
equivalent relay directory:

On Windows systems:
%PROGRAM FILES%\BigFix Enterprise\BES Relay\Encryption Keys

On Linux systems:
var/opt/BES Relay/Encryption Keys

These top-level relays decrypt all the documents received, bundle them together,
and then re-sign them with a single signature. You can put as many keys as you
want in the folder and the relay attempts to use each of them when it gets an
encrypted client report. clients encrypt against the key found in the masthead file,
which should be the last key created. However, it is possible that a client transmits
a report with an older version of the masthead (and thus a different encryption
key) if it has not gathered the latest actionsite for any reason.

When you use top-level encryption, consider the following best practices:
v You must manually transfer the key file from the server to the relay every time
you create a new encryption key.
v During the transfer process, it is important not to expose your private key file.
This means that you must not move the key over the internet because anyone
listening might be able make a copy of your private key file. Instead, physically
transfer the key from one computer to another, for example, with a USB key.
v During the encryption key creation process, you have the option to create the
private key file, but not propagate it out in the masthead. This step gives you
time to transfer the new key file to the relays before clients start posting
encryption messages with that key.

Message Level Encryption (MLE) Overview

Message Level Encryption (MLE) allows your Clients to encrypt upstream data
using a combination of an RSA public/private key-pair and an AES session key.

110 IBM Bigfix: Configuration Guide

 The RSA key-pair can be of 2048- or 4096-bit key length, with longer keys offering
additional security, but requiring more processing power for decryption at the
server. The AES session key uses the maximum FIPS-recommended length of 256
bits. You can configure your Relays to reduce the load on the Server by decrypting
and repackaging the Client data before relaying it.

The RSA public key encrypts the session key and adds it to the AES-encrypted
report. At the IBM BigFix Server (or a decrypting Relay) the corresponding RSA
private key is used to decrypt the AES session key, which is then used to decrypt
the Client report.

There are three levels of report encryption:

Required
Clients require encryption of reports and uploads. The client does not
report or upload files if it cannot find an encryption certificate or if its
parent relay does not support receipt of encrypted documents.
Optional
Clients prefer, but do not require encryption of reports and uploads. If
encryption cannot be performed, reports and uploads are done in
clear-text.
None Clients do not encrypt, even if an encryption certificate is present.

For more information about how to set encryption on Clients, see the Installation
Guide.

Changing the Client Icon

By default, the icon in the upper left corner of the client UI is the IBM BigFix logo.
This same icon is shown in the tray when an action is pending and in the task bar
when the program is running. You can change this icon to help you clarify to your
users who is the source of the action, and also to comply with corporate branding
and trademark requirements. Follow these steps to change the icon:
v On Windows systems:
1. Run the IBM BigFix Administration Tool from Start > Program Files > IBM
BigFix > IBM BigFix Administration Tool.
2. Click System Options tab.
3. Click Add Icon and use the Open dialog to browse for your icon (.ico) file.

On Linux systems:
1. Identify the path of the new icon, for example: /IEM/newicon.ico.
2. From the /opt/BESServer/bin command prompt, start the command line:
./iem login --server=servername:serverport --user=username --password=password
3. From the /opt/BESServer/bin command prompt, run the following command:
./iem post /IEM/newicon.ico admin/icon

where: /IEM/newicon.ico represents the full path of the new icon and admin/icon
is the parameter to use to upload the new icon.

The icon is propagated to the clients, but it is not incorporated into the interface
until the client restarts. After that, when a client interface opens (in response to an
action, a dashboard or an offer), it includes the graphic icon you specified.

Chapter 11. Additional configuration steps 111

Optimizing the servers
IBM BigFix operates efficiently, with minimal impact on network resources.
However, there might be installations that stretch the recommended configurations,
where there are too many clients for the allotted server power. The best solution is
to choose a server with the required characteristics for your environment; you
might be able to modify some preferences to get better performance. Most of these
optimizations involve a trade-off between throughput and responsiveness, so
proceed with caution. Your IBM Software Support has more information about
which modifications might be best for your particular deployment.

Here are some possible optimization techniques:

v Deploy Relays to reduce the load on the server. This is the most effective way to
increase the performance and responsiveness of IBM BigFix. Generally, the more
relays, the better the performance (as a rule of thumb, one relay for 500 to 1000
clients is a good choice, although it can be much higher for a dedicated
computer).
v Slow down the Client heartbeat from File > Preferences. This decreases the
frequency of messages that are regularly dispatched by the clients to update
their retrieved properties. Reducing this frequency reduces the amount of
network traffic generated, but also decreases the timeliness of the retrieved
properties. However, regardless of the heartbeat settings, the clients always send
their latest information whenever they receive a refresh ping from the server or
when they notice that a Fixlet is relevant.
v Slow down the Fixlet List Refresh rate from File > Preferences. This decreases
the update frequency for the information displayed in the console. If there are
many clients or consoles simultaneously connected or the database is very large,
reducing this frequency can substantially reduce the load on the server. If
multiple console operators are going to be simultaneously using the console, set
the refresh rate to be something higher than the default (15 seconds) to reduce
the load on the IBM BigFix database. Consider changing it to 60-120 seconds or
more if there are many console operators. The IBM BigFix Administration Tool
on the server allows you to set a global minimum refresh rate.
v Your database administrator might be able to help you with the following
optimizations:
– Change the SQL server Recovery Model for the BFEnterprise database to
Simple transaction logging.
– Reduce the percentage of memory allocated to SQL server from 100% to 85%,
to ensure that the web server and operating system are not short of memory.

More performance recommendations can be found at the IBM BigFix support site.

Optimizing the consoles

To be responsive, the console requires reasonable CPU power, memory, and cache
space. If you have a console that is taking a long time to load or that is performing
sluggishly, there are several techniques you can use to speed it up:
v Make sure you have sufficient memory. The IBM BigFix console benefits
greatly from capacious memory to speed up the viewing, filtering, and sorting of
content (Fixlet messages, tasks, actions, and so on). If your computer does not
have enough physical memory, the console will run noticeably slower. You can
check memory usage from the Task Manager (Ctrl-Shift-ESC). Select the

112 IBM Bigfix: Configuration Guide

 Performance tab and refer to the Physical Memory section. If the available
memory is less than 10% of the total memory, you are running low on RAM and
can benefit by adding more.
v Use high-speed network connections between your consoles and servers,
preferably with LAN connections of at least 100 MBPS. The IBM BigFix Database
can be sizeable for a large network, so running the console from a computer
with a slow connection often results in very long load times.
v Use remote control software. With so much data to load and display, operating
the console in a remote office over a slow link can be tedious. In situations like
this, you might be able to benefit from solutions such as Citrix, Terminal
Services, or other remote control software. Set up the remote control server on a
computer with fast access to the server. Allow that machine to present instances
of the console and have the branch office run these consoles remotely. The
database stays in the main office, and the remote office has optimal performance.
For more information, see the IBM BigFix Installation Guide.
v Delete old actions. The IBM BigFix database stores information about old
actions, which the console loads in at startup and saves out at shutdown. If you
do not need to track these old actions, you can delete them, allowing the console
to load and close faster. Note that deleted actions continue to exist in the
database, but are not loaded into the console or Web Reports and can be
undeleted if necessary.
v For more information about how to enhance performance, seePerformance
Configurations.

Managing Bandwidth
File downloads consume the bulk of the bandwidth in a typical installation. You
can control the bandwidth by throttling, which limits the number of bytes per
second. You can specify the bandwidth throttling on either the server, on the client,
or on both (in which case the lower of the two values is used). This can be
important whenever you have bandwidth issues, as in the following situations:
v A remote office with a thin channel
v Remote dial-in users or users on a slow connection
v A shared channel with higher-priority applications
v A WAN or LAN that is already saturated or has stringent load requirements

Bandwidth throttling settings (and other relay, server, and client settings) can be set
using the tasks from the Support site. Select the BigFix Management domain and
select the BES Component Management node in the navigation tree to see the
entire task list.

For more information about bandwidth throttling, see Overview of Bandwidth

Throttling.

Dynamic Throttling
When a large download becomes available, each link in your deployment might
have unique bandwidth issues. There are server-to-client, server-to-relay, and
relay-to-client links to consider, and each might require individual adjustment. As
explained in the previous section, it is possible to set a maximum value (throttle)
for the data rates, and for this there are broad-based policies you can follow. You
might, for example, throttle a client to 2KB/sec if it is more than three hops from a

Chapter 11. Additional configuration steps 113

 relay. However, the optimal data rates can vary significantly, depending on the
current hierarchy and the network environment.

A better technique is to use dynamic bandwidth throttling, which monitors and

analyzes overall network capacity. Whereas normal throttling simply specifies a
maximum data rate, dynamic throttling adds a “busy time” percentage. This is the
fraction of the bandwidth that you want to allocate when the network is busy. For
example, you could specify that downloads must not use more than 10% of the
available bandwidth whenever IBM BigFix detects existing network traffic.
Dynamic throttling also provides for a minimum data rate, in the case that the
busy percentage is too low to be practical.

When you enable dynamic throttling for any given link, IBM BigFix monitors and
analyzes the existing data throughput to establish an appropriate data rate. If there
is no competing traffic, the throughput is set to the maximum rate. In the case of
existing traffic, it throttles the data rate to the specified percentage or the minimum
rate, whichever is higher.

You control dynamic bandwidth throttling with computer settings. There are four
basic settings for each link:
DynamicThrottleEnabled
This setting defaults to zero (disabled). Any other value enables dynamic
throttling for the given link.
DynamicThrottleMax
This setting usually defaults to the maximum unsigned integer value,
which indicates full throttle. Depending on the link, this value sets the
maximum data rate in bits or kilobits per second.
DynamicThrottleMin
This setting defaults to zero. Depending on the link, this value sets the
minimum data rate in bits or kilobits per second. This value places a lower
limit on the percentage rate given below.
DynamicThrottlePercentage
This setting defaults to 100%, which has the same effect as normal
(non-dynamic) throttling. It represents the fraction of the maximum
bandwidth you want to use when the network is busy. It typically has a
value between five and ten percent, to prevent it from dominating existing
network traffic.

Note: A zero for this setting is the same as 100%.

As with any other setting, you can create or edit the dynamic bandwidth settings
by right-clicking an item (or group of items) in any computer list and choosing
Edit Computer Settings from the context menu.

The specific variable names include the Server/Relay settings:

_BESRelay_HTTPServer_DynamicThrottleEnabled
_BESRelay_HTTPServer_DynamicThrottleMaxKBPS
_BESRelay_HTTPServer_DynamicThrottleMinKBPS
_BESRelay_HTTPServer_DynamicThrottlePercentage

The IBM BigFix Client settings:

_BESClient_Download_DynamicThrottleEnabled
_BESClient_Download_DynamicThrottleMaxBytesPerSecond
_BESClient_Download_DynamicThrottleMinBytesPerSecond
_BESClient_Download_DynamicThrottlePercentage

114 IBM Bigfix: Configuration Guide

 The IBM BigFix Gathering settings:
_BESGather_Download_DynamicThrottleEnabled
_BESGather_Download_DynamicThrottleMaxBytesPerSecond
_BESGather_Download_DynamicThrottleMinBytesPerSecond
_BESGather_Download_DynamicThrottlePercentage

Note: For any of these settings to take effect, you must restart the affected services
(server, relay, or client).

If you set a Server and its connected Client to differing maximums or minimums,
the connection chooses the smaller value of the two.

For more information about bandwidth throttling, see Overview of Bandwidth

Throttling.

Managing Downloads
IBM BigFix uses several methods to ensure that downloads are efficient and make
the best use of available bandwidth. Among other techniques, caching is used
extensively by all the IBM BigFix elements, including servers, relays, and clients.

When an action on a client runs a download file command, the existence of the file
is checked first in the client local cache. If the client cannot find it locally, it
requests the file from its parent, typically a relay. In turn, the relay checks its own
cache. If it finds the file, it immediately sends it down to the requesting client.
Otherwise, it passes the request up to its parent, which might be another relay and
the process continues. Ultimately, a server retrieves the file from an internal server
or the Internet, caches it, and then passes it back down the chain. After receiving
the file, each relay in the chain caches it, and continues to forward it down to the
original client, which also caches it.

If the agent runs the download now command while performing the action, the file
is requested and collected from the URL specified in the action script.

Each cache retains the file until it runs out of space. At that point, the cache is
purged of the least-recently used (LRU) files to provide more space. You can view
the relay cache size and other relay information by activating the Analysis ID# 227
BES Relay Cache Information available from the BES Support Site. The default
cache size is 1 GB, but you can change it by using the Task ID# 148 BES
Relay/Server Setting: Download Cache Size, also from the BES Support site.

There might be situations that require files to be manually downloaded and

cached, typically because such files are not publicly available, in which case you
must download the files directly from the source. Review the Fixlet Description
tab for more information about specific manual cache requirements. You can
pre-populate the download cache by copying files to the download cache location
__Download. You can also delete these files manually.

The caches are stored as sub-folders of the program folder, which is created by
default at %PROGRAM FILES%\BigFix Enterprise on Windows systems, and
/var/opt/BES Server on Linux systems. The server download cache is BES
Server\wwwrootbes\bfmirror\downloads\sha1, and the client download cache is
found at BES Client\__BESData\__Global\__Cache\Downloads.

As well as the download cache, relays maintain an action cache (also 1 GB)
holding all the files needed for each Action, and clients maintain a Utility cache.

Chapter 11. Additional configuration steps 115

 For information about troubleshooting relays, including bandwidth and
downloading, see Relay Health.

The client collects the file by requesting it from the url listed in the action script in
one of the following ways:
v When the complete set of downloads can be computed by parsing the action
script, the complete set of downloads is computed by the server. The agent can
ask the relay with a single request if the prefetch downloads are available for a
specific action. In this request, the agent sends up the action ID, and the server
response indicates all the files are available, or they are not. If these are all
available, the agent starts requesting the files by their ordinal number (1
indicates the first file in the script, 2 indicates the second file in the script, etc.).
If the files are not available, the relay informs the agent they are not and begins
the process of fetching them, and the agent notifies that it is waiting for
downloads to be available and put itself into a pending downloads state for that
action for 10 minutes, at which time it asks the relay again, if the downloads are
available for the specific action.
When the downloads for an action become available on a relay, a notification is
sent to the children of the relay, which uses the notification to accelerate
requesting the downloads again. If notification messages are blocked for any
reason, the agents 10 minute 'ask the relay again' behavior will eventually result
in the agent detecting that the downloads are available, and begin to collect
them. Child relays are also notified by their parent when the downloads based
on the action ID and the ordinal numbers become available. They use this
notification to accelerate their own request for the downloads again.
v For downloads where any of the download url, size, and hash value are listed in
the action script such that only the agents can compute them, the agents query
their parent relay using an itemized downloads available request. The request
contains a list of download items the particular agent needs. The relay and client
behave the same way as described above, delaying subsequent requests, waiting
for notifications

Resuming a download

If the download fails for connection problems, the download process is resumed as
follow:
v If the client is downloading from a BigFix Relay or Server, the download can be
restarted at 10,000 byte chunks. This means that, when the client process is
restarted, it verifies the 10,000 byte blocks already received, and then it resumes
the download after the last verified block.
v If the client is running a direct download from another server's URL, when the
client process restarts, the download starts again from the beginning.

Enabling data pre-cache

You can specify for each Client if the data to download to run an action must be
pre-cached on the Client or not and how.

You can decide whether the data requested to run an action on a Client can start to
be downloaded:
After all constrains are satisfied.
If you do so, after all constraints are satisfied, the action needs to wait for
the entire data to be downloaded, in the pre-fetch area, before starting to
run. In this case the data download is a constraint itself. When the data
download to the pre-fetch area completes, the action satisfies all the

116 IBM Bigfix: Configuration Guide

 constraints so the data is moved in the __Download area and the action can
start running. The risk is that the download might take longer than
expected and, in the worst case, the time window during which the action
can run could elapse before the data download completes, preventing the
action from running.
Before all constrains are satisfied.
In this case the data download starts as soon as the action becomes
relevant for the Client and before all constraints, such as start time, are
evaluated. The data is downloaded on the Client disk in the pre-cache area.
When all the constraints are met, the downloaded data is moved from the
pre-cache area to the pre-fetch area. When the action is ready to start, the
data is moved in the __Download area and the action starts running.
By doing so you allow the action to start earlier and, in case of an offer
displayed to the user, you shorten the time that a user must wait for the
offer to be downloaded after acceptance.The potential risks in this case
consist of the possibility of an action deadlock due to a lack of disk space,
and, if running a group action, the possibility that the group will never
starts because the disk space configuration does not allow the
simultaneous existence of all downloads of the group in the Client system.
Starting from BigFix V9.5.10, you can prevent the risk to affect the group
action processing by using the client setting
_BESClient_Download_PreCacheStageContinueWhenDiskLimited. If you
set _BESClient_Download_PreCacheStageContinueWhenDiskLimited=1,
on that Client a group action can start, assuming that all other constraints
are met, as long as the first sub action requiring downloads can collect all
downloads for that sub action, and the action processing can continue even
when the pre-cached downloads for all sub action cannot be available on
the system at the same time due to disk space requirements (DiskLimited
or DiskFreeLimited constraints).

Note: This setting does not affect single action processing, In other words,
a single action or sub-action can still be constrained and blocked from
running by insufficient disk space to hold downloads required for that
specific action.
By default, on a BigFix Client
_BESClient_Download_PreCacheStageContinueWhenDiskLimited=0,
which means that a group action can start only after all the sub action
downloads are available at the same time on the system.

Dynamic download White-lists

Dynamic downloading extends the flexibility of action scripts, adding the ability to
use relevance clauses to specify URLs.

As with static downloads, dynamic downloads must specify files with the
confirmation of a size or sha1. However, the URL, size, and sha1 are allowed to
come from a source outside of the action script. This outside source might be a
manifest containing a changing list of new downloads. This technique makes it
easy to access files that change quickly or on a schedule, such as antivirus or
security monitors.

This flexibility entails extra scrutiny. Because any client can use dynamic
downloading to request a file, it creates an opportunity for people to use your
server to host files indiscriminately. To prevent this, dynamic downloading uses a

Chapter 11. Additional configuration steps 117

 white-list. Any request to download from a URL (that is not explicitly authorized
by use of a literal URL in the action script) must meet one of the criteria specified
in a white-list of URLs that is contained in the following file:
On Windows systems:
<Server Install Path>\Mirror Server\Config\DownloadWhitelist.txt
On Linux systems:
<Server Install Path>/Mirror Server/config/DownloadWhitelist.txt

This file contains a newline-separated list of regular expressions using a Perl regex
format, such as the following:
http://.*\.site-a\.com/.*
http://software\.site-b\.com/.*
http://download\.site-c\.com/patches/JustThisOneFile\.qfx

The first line is the least restrictive, allowing any file at the entire site-a domain to
be downloaded. The second line requires a specific domain host and the third is
the most restrictive, limiting the URL to a single file named "JustThisOneFile.qfx".
If a requested URL fails to match an entry in the white-list, the download
immediately fails with status NotAvailable. A note is made in the relay log
containing the URL that failed to pass. An empty or non-existent white-list causes
all dynamic downloads to fail. A white-list entry of “.*” (dot star) allows any URL
to be downloaded.

Creating custom client dashboards

You can create custom Client Dashboards, similar to those in the console.
Dashboards are HTML files with embedded Relevance clauses that can analyze the
local computer and print out the current results. Clients with a dashboard have an
extra tab to display the resulting report. Note that dashboard global variables can
be accessed from custom dashboards owned by other operators regardless of
permissions.

To create a Client Dashboard, you must create a new folder named __UISupport
(note the leading underlines) in the __BESData folder. This is a subfolder of the
client folder, so the final pathname looks like:

Program Files/BigFix Enterprise/BES Client/__BESData/__UISupport

Place the Dashboard file (named _dashboard.html) and any accompanying graphics
files into this folder. The next time the client starts, it incorporates these files into
its interface, adding to the Dashboard tab. When you clicks this tab, the
Dashboard calculates the latest values of each Relevance clause and displays them.

The Relevance statements are embedded in the HTML inside special tags with the
form:
<?relevance statement ?>

For example, to find and print the time, use the following:
<?relevance now ?>

When the client displays the page containing this statement, the client evaluates
the Relevance clause “now” and substitutes the value for the tag. The following
sample HTML prints out the word “Date:” and then the current date and time:

118 IBM Bigfix: Configuration Guide

<html>
<body>
Date: <?relevance now ?>
</body>
</html>

To refresh the Relevance evaluation, add this line to the file:

<html>
<body>
Date: <?relevance now ?>
<A href="cid:load?page=_dashboard.html"> Refresh </A>
</body>
</html>

This link, labeled Refresh, causes the page to reload. When it does, it reevaluates
the relevance clauses. It is easy to see how you would add other Relevance
expressions to this page.

For example, to print out the operating system and the computer name, add these
two lines:
<html>
<body>
Date: <?relevance now ?>
Operating System: <?relevance name of operating system ?>
Computer Name: <?relevance computer name ?>
<A href="cid:load?page=_dashboard.html"> Refresh </A>
</body>
</html>

You can use style sheets to format the output. You can use the default style-sheet,
offer.css for some preset formatting. Here is an example of a Dashboard with a
title, a header, a refresh link, and a section of retrieved property values:
<html>
<head>
<link type="text/css" rel="stylesheet" href="offer.css"></link>
<title>BigFix Dashboard Example</title>
</head>
<body>

<div class="header">
<div class="headerTitle">
<font size="6"><?relevance computer name ?></font>
</div>
<div class="headerCategory">
<font size="1">(Last updated: <?relevance now ?>)</font><BR>
<div><font size="1">
<a href="cid:load?page=_dashboard.html">Refresh</a></font>
</div>
</div>
</div>

<div class="section">
<div class="sectionHeader">Computer Information</div>
<div class="subsection">
<table>
<tr>
<td valign="top">OS: </td>
<td><?relevance operating system ?></td>
</tr>
<tr>
<td valign="top">RAM: </td>
<td><?relevance (size of ram)/1048576 ?> MB</td>
</tr>

Chapter 11. Additional configuration steps 119

 <tr>
<td valign="top">DNS Name: </td>
<td><?relevance dns name ?></td>
</tr>
</table>
</div>
</div>
</body>
</html>

For the offer.css to work correctly, the following graphics files must be copied to
the __UISupport directory from the Client directory:
bodyBg.jpg,
bodyHeaderBg.jpg
bullet.gif
sectionHeaderBG.gif

When run from the Client, this dashboard produces the following output:

To learn more about Relevance expressions, see the Relevance Language Reference.

Geographically locating clients

Because clients are often deployed in remote offices, it is useful to create a property
that lets the clients report their own location. You can create a location property in
IBM BigFix using the Location Property Wizard.
1. In the console, go to the BigFix Management domain, click Computer
Management , and then click Location Property Wizard . A wizard document
opens.
2. The wizard creates a named property allowing the clients to identify
themselves based on their subnet, IP range, or other information. Read the
instructions in the wizard to create the property.

120 IBM Bigfix: Configuration Guide

Locking clients
You can change the locked status of any IBM BigFix client in the network. This lets
you exclude specific computers or groups of computers from the effects of Fixlet
actions. This could be useful, for example, if you wanted to exclude certain
development computers from any changes or updates. It also provides a powerful
technique for testing new Fixlet actions on a limited set of unlocked computers,
while keeping the rest of the network locked down. client computers can be locked
forever (until explicitly unlocked) or for a defined period of time.

Changes are made to the locked status of a client by sending an action. As a

consequence, the Console operator must supply proper authentication to lock or
unlock any computer. Even though a client is locked, there is still a subset of
actions that can be accepted by the client, including clock changes and unlock
actions as well as actions from the BES Support site.

To lock or unlock a computer, follow these steps:

1. Click the Computers icon in the Domain Panel navigation tree to see the List
Panel of networked IBM BigFix client computers.
2. Select the computers that you want to lock.
3. Right-click and select Edit Computer Settings from the pop-up menu (or select
Edit Computer Settings from the Edit menu). The Edit Setting dialog opens.
4. Click the checkbox to either lock or unlock the computer.

Although the console does not provide an explicit interface for setting an
expiration date on the lock, you can create a custom action to do this. For more
information, see the IBM BigFix Developer site.

Editing the Masthead on Windows systems

You can change default parameters stored in the masthead by using the IBM
BigFix Administration Tool:
1. Launch the program from Start > Programs > IBM BigFix > IBM BigFix
Administration Tool.
2. Browse to the private key (license.pvk) and click OK.
3. Select the Masthead Management tab and click Edit Masthead.

Chapter 11. Additional configuration steps 121

 4. Enter the parameters of the masthead file that contains configuration and
license information together with a public key that is used to verify digital
signatures. This file is saved in your credential folder.

You can edit the following options:

Server Port Number:
In general, you do not need to change this number. 52311 is the
recommended port number, but you can choose a different port if that is
more convenient for your particular network. Typically, you choose a port

122 IBM Bigfix: Configuration Guide

 from the IANA range of private ports (49152 through 65535). You can use a
reserved port number (ports 1-1024), but this might reduce the ability to
monitor or restrict traffic correctly and it prevents you from using port
numbers for specific applications. Do not change the server port number
after installing the clients and creating the masthead, because BigFix might
not work correctly. For additional information, see Modifying port numbers in
the next section.
Gathering Interval:
This option determines how long the clients wait without hearing from the
server before they check whether new content is available. In general,
whenever the server gathers new content, it attempts to notify the clients
that the new content is available through a UDP connection, circumventing
this delay. However, in situations where UDP is blocked by firewalls or
where network address translation (NAT) remaps the IP address of the
client from the servers perspective, a smaller interval becomes necessary to
get a timely response from the clients. Higher gathering rates only slightly
affect the performance of the server, because only the differences are
gathered; a client does not gather information that it already has.
Initial Action Lock:
You can specify the initial lock state of all clients, if you want to lock a
client automatically after installation. Locked clients report which Fixlet
messages are relevant for them, but do not apply any actions. The default is
to leave them unlocked and to lock specific clients later on. However, you
might want to start with the clients locked and then unlock them on an
individual basis to give you more control over newly-installed clients.
Alternatively, you can set clients to be locked for a certain period of time
(in minutes).
Action Lock Controller:
This parameter determines who can change the action lock state. The
default is Console, which allows any Console operator with management
rights to change the lock state of any client in the network. If you want to
delegate control over locking to the end user, you can select Client, but this
is not recommended.
Exempt the following site URL from action locking:
In rare cases, you might need to exempt a specific URL from any locking
actions. Check this box and enter the exempt URL. You can specify only
one site URL and it must begin with http://.

Note: Baseline components are not exempt from action locking because
they can come from different sites.
Require use of FIPS 140-2 compliant cryptography
Check this box to be compliant with the Federal Information Processing
Standard in your network. This changes the masthead so that every IBM
BigFix component attempts to go into FIPS mode. By default, the client
continues in non-FIPS mode if it fails to correctly enter FIPS, which might
be a problem with certain legacy operating systems. Be aware that checking
this box can add a few seconds to the client startup time.
Allow use of Unicode filenames in archives
This setting specifies the codepage used to write filenames in the IBM
BigFix archives. Check this box to write filenames UTF-8 codepage.

Chapter 11. Additional configuration steps 123

 Do not check this box to write filenames using the local deployment
codepage, for example Windows-1252 or Shift JIS. If you run a fresh install
of IBM BigFix V9.5, by default, the filenames are written in UTF-8.

Note: If you upgraded your IBM BigFix environment to V9.5, by default,

the filenames are written in the local deployment codepage.
5. Click OK to enter the changes.

Note: The masthead changes do NOT affect clients that are already deployed, but
you can export the masthead using the Administration Tool (Masthead
Management tab) and replace the masthead in the BES Installers directory of the
BigFix server (default directory: <drive>:\Program Files\BigFix Enterprise\BES
Installers) so that newly deployed or installed clients use these changes.

Editing the Masthead on Linux systems

To modify the masthead, run the following command as super user:
./BESAdmin.sh -editmasthead -sitePvkLocation=<path+license.pvk>
[ -sitePvkPassword=<password> ]
[ -display ] [ -advGatherSchedule=<0-10> ] [ -advController=<0-2> ]
[ -advInitialLockState=<0|2> | -advInitialLockState=1 -advInitialLockDuration=<num> ]
[ -advActionLockExemptionURL=<url> ] [ -advRequireFIPScompliantCrypto=<true|false> ]

where:
-sitePvkLocation=<path+license.pvk>
Specifies the private key file (filename.pvk). This private key file and its
password are required to run the Administration Tool. Only users with
access to the site level signing key and password are able to create new
BigFix operators.

Note: The notation <path+license.pvk> used in the command syntax

stands for path_to_license_file/license.pvk.
-sitePvkPassword=<password>
Specifies the password associated to the private key file (filename.pvk).
This setting is optional, if you omit it you will be asked to specify the
password interactively when the command runs.
-display
Displays the current settings for the masthead.
advGatherSchedule (optional, integer)
Determines how long the clients wait without hearing from the server
before they check whether new content is available. In general, whenever
the server gathers new content, it attempts to notify the clients that the
new content is available through a UDP connection, circumventing this
delay. However, in situations where UDP is blocked by firewalls or where
network address translation (NAT) remaps the IP address of the client from
the servers perspective, a smaller interval becomes necessary to get a
timely response from the clients. Higher gathering rates only slightly affect
the performance of the Server, because only the differences are gathered; a
client does not gather information that it already has. Valid values are:
0=Fifteen Minutes,
1=Half Hour, 2=Hour,
3=Eight Hours,
4=Half day,
5=Day,

124 IBM Bigfix: Configuration Guide

 6=Two Days,
7=Week,
8=Two Weeks,
9=Month,
10=Two Months
advController (optional, integer)
Determines who can change the action lock state. The default is Console,
which allows any Console operator with management rights to change the
lock state of any client in the network. If you want to delegate control over
locking to the user, you can select Client, but this is not recommended.
Valid values are:
0=console,
1=client,
2=nobody
advInitialLockState (optional, integer)
Specifies the initial lock state of all clients. Locked clients report which
Fixlet messages are relevant for them, but do not apply any actions. The
default is to leave them unlocked and to lock specific clients later on.
However, you might want to start with the clients locked and then unlock
them on an individual basis to give you more control over newly-installed
clients. Alternatively, you can set them to be locked for a certain period of
time. Valid values are:
0=Locked,
1=timed (specify duration),
2=Unlocked
advInitialLockDuration (optional, integer)
Defines the period of time in seconds the clients must be locked.
advActionLockExemptionURL (optional, string)
In rare cases, you might need to exempt a specific URL from any locking
actions. Check this box and enter the exempt URL.

Note: You can specify only one site URL and it must begin with http://.
advRequireFIPScompliantCrypto (optional, boolean)
Implements the Federal Information Processing Standard on your network.
This changes the masthead so that every IBM BigFix component attempts
to go into FIPS mode. By default, the client continues in non-FIPS mode if
it fails to correctly enter FIPS, which might be a problem with certain
legacy operating systems. Be aware that checking this box can add a few
seconds to the client startup time.

| Note: Enabling FIPS mode prevents the use of some authentication

| methods when connecting to a proxy. If you selected to use a proxy to
| access the Internet or to communicate with IBM BigFix subcomponents,
| ensure that the proxy configuration is set up to use an authentication
| method other than digest, negotiate or ntlm.

Obfuscating server passwords

You can replace the passwords on the server with obfuscated passwords, by
indicating the type of password that you want to replace and the new password.

The password is obfuscated and stored in the registry on Windows systems and in
the configuration files on Linux systems.

Chapter 11. Additional configuration steps 125

 Run the following command to obfuscate server password:
On Windows systems:
BESAdmin.exe /updatepassword /type:<type> [ /password:<password> ]
/sitePvkFile:<path+license.pvk> [ /sitePassword:<pvk_password> ]

where:
type:<type>
Specifies one of the following types of password:
server_db
The password to be updated and recorded obfuscated is
related to the connection with the server database
dsa_db
The password to be updated and recorded as obfuscated is
related to the connection with the DSA database
password:<password>
Specifies the password to be obfuscated and then recorded.
sitePvkFile:<path+license.pvk>
Specifies the private key file (filename.pvk). This private key file
and its password are required to run the Administration Tool. Only
users with access to the site level signing key and password are
able to create new BigFix operators.

Note: The notation <path+license.pvk> used in the command

syntax stands for path_to_license_file\license.pvk.
sitePassword:<password>
Specifies the password associated to the private key file
(filename.pvk). This setting is optional, if you omit it you will be
asked to specify the password interactively when the command
runs.
On Linux systems:
where:
type=<type>
Specifies one of the following types of password:
server_db
The password to be updated and recorded obfuscated is
related to the connection with the server database
dsa_db
The password to be updated and recorded as obfuscated is
related to the connection with the DSA database
password=<password>
Specifies the password to be obfuscated and then recorded.
sitePvkLocation=<path+license.pvk>
Specifies the private key file (filename.pvk). This private key file
and its password are required to run the Administration Tool. Only
users with access to the site level signing key and password are
able to create new BigFix operators.

Note: The notation <path+license.pvk> used in the command

syntax stands for path_to_license_file/license.pvk.

126 IBM Bigfix: Configuration Guide

 -sitePvkPassword=<password>
Specifies the password associated to the private key file
(filename.pvk). This setting is optional, if you omit it you will be
asked to specify the password interactively when the command
runs.

Modifying Global System Options

To modify a few basic system defaults, such as the minimum refresh time and the
Fixlet visibility perform the following steps:

On Windows systems:
1. Launch the Administration Tool from Start > Programs > IBM BigFix > IBM
BigFix Administration Tool.
2. Select the System Options tab.
3. At the top, you can set the global Minimum Refresh. The default is 15 seconds,
which is a good balance between responsiveness and low network load. If you
find that these communications are impacting your network, you can increase
the minimum to 60 seconds or more.
4. External sites are visible to all console operators by default, but you can change
that in the section marked Default Fixlet Visibility. Click the lower button to
make external content invisible to all except Master Operators. On the IBM
BigFix console, master operators can show hidden external content sites by
clicking the Show Hidden Content button available in console toolbar.

On Linux systems:
1. From the /opt/BESServer/bin command prompt start the command line:
./iem login --server=servername:serverport --user=username --password=password
2. From the /opt/BESServer/bin command prompt run the following command:
./iem get admin/options > /appo/options.xml
3. In the /appo/options.xml file:
<?xml version="1.0" encoding="UTF-8"?>
<BESAPI xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="BESAPI.xsd">
<SystemOptions Resource="https://nc926065:52311/api/admin/options">
<MinimumRefreshSeconds>15</MinimumRefreshSeconds>
<DefaultFixletVisibility>Visible</DefaultFixletVisibility>
</SystemOptions>
</BESAPI>

edit the following keywords to set the minimum refresh time in seconds and
the external sites as visible to all the console operators or to only the Master
operators:
<MinimumRefreshSeconds>15</MinimumRefreshSeconds>
<DefaultFixletVisibility>Visible</DefaultFixletVisibility>

If you change the value assigned to these keywords, you must restart the IBM
BigFix console active sessions to activate changes.

Note: On the IBM BigFix console, Master operators can show hidden external
content sites by clicking the Show Hidden Content button available in console
toolbar.
4. Upload the modified file by running the following command:
./iem post /appo/options.xml admin/options

Chapter 11. Additional configuration steps 127

Extending the IBM BigFix License
When you first request your action site license, your query is archived with IBM
and you are issued a license for a specific period of time. Before your license
expires, IBM BigFix warns you, giving you sufficient time to renew your license.
When you are coming close to the expiration date, IBM BigFix notifies you by
using a Fixlet message. Similarly, if you start to exceed the number of clients
allocated by your license, IBM BigFix alerts you. To extend your license expiration
or add new client licenses to your installation, follow these steps:
1. Notify your IBM representative (if you have not paid for the extended license,
you must talk to your sales person or reseller to buy an extended license).
2. Your server checks daily for a new version of your license. If you want to force
your server to check immediately, in the console, go to the BigFix Management
domain, click License Overview node, and click the Check for license update.

For additional information about how to manage licenses see the Managing licenses
chapter of the Administration Guide.

Re-creating Site Credentials

Private and public key encryption creates a chain of signing authority from the
IBM BigFix root down through the Site Administrator and including each console
operator. If you lose your site credential or change the IP address of your server,
the chain is broken. The consequences are serious: you must start again with a new
request to IBM for a site certificate. Then you must reinstall the entire system,
including all the clients (contact your support technician for details about how you
might migrate your clients to a new server) and re-create all the users. If this
happens, contact your support technician. To protect your site certificate, follow
these important rules:
v Do not lose the certificate (license.crt) and the private key for your site
(license.pvk). Follow standard procedures for backing up and securing critical
confidential information.
v Do not change the IP address and hostname or port number of the server,
because it is the primary identifier for your site certificate. Any change to the IP
address or port number that was specified when the license was requested
negates the license and necessitates a fresh installation of the IBM BigFix system.
If you plan to decommission a server, be sure to apply the same IP address and
port number to the replacement server.
v Do not forget your password. Follow your corporate standards for noting and
storing your password.

Note: The IBM BigFix Site Administrator can change the password of the site-level
key, if they know the current password.

128 IBM Bigfix: Configuration Guide

Chapter 12. Maintenance and Troubleshooting
If you are subscribed to the Patches for Windows site, you can ensure that you
have the latest upgrades and patches to your SQL server database servers. This
means that you must install the client on all your computers, including the server
and console computers. In addition, you might want to take advantage of these
other tools and procedures:
v If you have the SQL Server installed, you should become familiar with the MS
SQL Server Tools, which can help you keep the database running smoothly.
v It is standard practice to back up your database on a regular schedule, and the
IBM BigFix database is no exception. It is also wise to run the occasional
error-check to validate the data.
v If you start to notice any performance degradation, check for fragmentation. IBM
BigFix writes out many temporary files, which might create a lot of disk
fragmentation, so defragment your drive when necessary. Regular maintenance
also involves running the occasional error-check on your disk drives.
v The IBM BigFix Diagnostics Tool performs a complete test on the server
components and can be run any time you experience problems. For additional
information see the IBM BigFix Installation Guide.
v Check the BigFix Management domain often. There are a number of Fixlets
available that can detect problems with any of your IBM BigFix components.
This can often prevent problems before they ever affect your network.
v Check the IBM BigFix Knowledge Base at IBM BigFix Support site. This site is
continually updated, and if you cannot find an existing knowledge-base article
about your question, you can find information about how to submit a question
to IBM Software Support.
v Add relays to improve the overall system performance and pay close attention
to them. Healthy relays are important for a healthy deployment.
v Review the Deployment Health Checks dashboard in the BigFix Management
domain for optimizations and failures.
v Set up monitoring activities on the servers to notify you in the event of a
software or hardware failure, including:
– Server powered off or unavailable
– Disk failure
– Event log errors about server applications
– Server services states
– FillDB buffer directory data back-up situations

Monitoring relays health

IBM BigFix allows you to monitor your client and relay setups to ensure they are
working optimally. Before deploying a large patch, you might want to check the
status of your relays to guarantee a smooth rollout.

Here are some suggestions for monitoring your relay deployment:

v Click the BigFix Management domain and the Analyses node and activate the
relay Status analysis. This Analysis contains a number of properties that give
you a detailed view of the relay health.

© Copyright IBM Corp. 2010, 2018 129

 v Click the Results tab for the analysis to monitor the Distance to relay property
in the relay status analysis to see what is normal in your network. If your
topology suddenly changes, or you notice that some of your clients are using
extra hops to get to the server, it could indicate the failure of a relay.
v Try to minimize the number of clients reporting directly to the server because it
is generally less efficient than using relays. You can see which computers are
reporting to which relays by studying this analysis.

Relay and Server diagnostics

To monitor your BigFix environment setup and status and to complete actions on
your clients.

You can use the following diagnostics functions to get information about your
server and your relay settings and to complete actions on your clients. Starting
from V9.5.6, the relay diagnostics page is disabled by default and can be protected
by a password when enabled; for more information, see: Configuration Settings.

To access the diagnostics, open a browser and type in the address field:
http://<computer_name>:52311/rd

or
http://<computer_name>:52311/RelayDiagnostics

where:
<computer_name>
Is the address of the workstation where the server or the relay that you
want to check is installed.

The diagnostics page is divided in the following sections:

Relay or Server Diagnostics
In this section, you can gather information about your environment
settings. Click the + sign to expand the different types of setting and see
their values.

Note: The entry Query Settings refers to BigFix Query processing. For
more information about this function, see Chapter 9, “Getting client
information by using BigFix Query,” on page 77.
Relay Status Information
In this section, you can view information about the cache used on the relay
in the queues dedicated to FillDB and toBigFix Query requests and results.
v FillDB File Size Limit
v FillDB File Counter Limit
v Timeout for queries in queue displays how long the BigFix Query
requests can stay in the queue before being removed.
v Size of queries in queue shows the size of the cache that is used on the
relay to store the BigFix Query requests.
v Size of results in queue shows the size of the cache that is used on the
relay to store the BigFix Query results.
If you click the Empty Query Queues buttons, the queues that store the
BigFix Query requests and results in the relay cache are cleaned up.

130 IBM Bigfix: Configuration Guide

 Console user information
In this section, you can check whether an user is authorized to access IBM
BigFix. This section is available only when you access the server
diagnostic.
Click Check User Authorization and type the user's credentials to verify
whether that user is granted access to the IBM BigFix console without the
need to actually log in with those credentials.
Site gathering information
In this section, you can collect information related to your environment
sites.
v Click Gather Status Page to get information about site gathering status.
v Click Gather All Sites button to gather the latest version of site
contents.
v In Fixlet Site Requests, you can collect information about different types
of requests related to a site. Select the type of request, the URL of the
site in the list provided, whether you want to use CRC or not and then
click Submit.
Client register
In this section, you can perform requests either for a single computer or for
all the computers in your environment.
v Click Get Computer ID button to know the computer ID of your relay.
v In Single Computer Requests, you can choose different types of
requests related to a single computer by selecting one of the requests in
the list and by clicking the Submit button. Depending on the request
type, you might need to fill one or more text fields. The needed fields
are automatically enabled.
v In All Computer Requests, you can select different types of requests
related to all the computers in your environment by selecting one of the
requests in the provided list and clicking the Submit button. Depending
on the request type, you might need to specify the Action ID, if enabled.
Download information
In this section, you can collect information about the downloads that are
run on the system.
v Click Download Status Page to get information about downloads active
on your server or relay.
v Click Download Status Text Page to get information, in xml language,
about downloads active on your server or on your relay.
v In Download Requests, you can collect information about a specific
action for a specific site by providing the Action ID and the Site URL in
the related fields. Click Gather Download Request button to run your
request.

Virtualized environments and virtual machines

To run your operating system in multiple virtual machines.

In IBM BigFix you can run your operating system in multiple images to benefit
from the ability to share hardware and software resources. This is true especially
on IBM z Systems where, within the z/VM environment, Linux images benefit
from the reliability, availability, and serviceability of IBM z Systems servers and

Chapter 12. Maintenance and Troubleshooting 131

 from internal high-speed communications. z/VM offers an ideal platform for
consolidating Linux workloads on a single physical server where you can run
hundreds to thousands of Linux images.

In IBM BigFix design, the BESClient agent works in a loop checking the activity to
run based on the contents of its directory <BESClient_installation_path>/
__BESData. These activities, together with a large number of concurrent virtual
machines as it is common in z/VM environments, might result in a 100% CPU
usage. To avoid this problem and control the CPU assignment to processes, you
can use some configuration settings that are described here: Configuration settings.

Some useful parameters are _BESClient_Resource_WorkIdle and

_BESClient_Resource_SleepIdle, that have default values of 10 and 480
milliseconds respectively, to control the CPU consumption by balancing the
amount of work with the amount of idle time; with the default values, this means
about 2% of work for each virtual machine. You can change these values if you
need to have a lower percentage; the negative side in this instance is that the IBM
BigFix client becomes slower when a new activity must be processed. By setting
new values, you can take account of the number of virtual machines and avoid the
overall CPU being 100% busy.

With other parameters you can set your agents to remain quiet during a part of the
day and become active for the remainder of the day; during the quiet period the
CPU consumption is almost 0%. The parameters that control this behavior are
_BESClient_Resource_QuietEnable, _BESClient_Resource_QuietStartTime, and
_BESClient_Resource_QuietSeconds. For example, by setting the following values:
_BESClient_Resource_QuietEnable=1
_BESClient_Resource_QuietSeconds=43200
_BESClient_Resource_QuietStartTime=07:00

the agent enters quiet mode at 07:00 AM each day, remains in this state for 43,200
seconds, that is for 12 hours, and wakes up at 07:00 PM. During quiet mode, the
agent uses almost 0% of CPU time and does not process activities.

Other useful parameters to control the amount of time a client stays in sleep mode,
especially suitable when there are battery low power problems or the need to
reduce CPU utilization, are _BESClient_Resource_PowerSaveEnable and
_BESClient_Resource_PowerSaveTimeout0. Good results can be obtained by setting
them to 1 and 30 respectively; in this instance, clients remain in sleep mode for 30
minutes between each activity cycle. When sleep mode is active, the command
polling is paused.

You might find useful also these parameters:

_BESClient_Resource_PowerSaveTimeout1,
_BESClient_Resource_PowerSaveTimeout2,
_BESClient_Resource_PowerSaveTimeout3, _BESClient_Resource_PowerSaveTimeout4
and, _BESClient_Resource_PowerSaveTimeout5.

For a full description of all of these parameters and many more, see the
configuration settings in the link listed previously.

132 IBM Bigfix: Configuration Guide

Appendix. Support
For more information about this product, see the following resources:
v IBM Knowledge Center
v IBM BigFix Support Center
v IBM BigFix Support Portal
v IBM BigFix Knowledge Base
v IBM BigFix Customer Support Technical Information Newsletter
v IBM BigFix Wiki
v IBM BigFix Forum

© Copyright IBM Corp. 2010, 2018 133

134 IBM Bigfix: Configuration Guide
Notices
This information was developed for products and services offered in the US. This
material might be available from IBM in other languages. However, you may be
required to own a copy of the product or product version in that language in order
to access it.

IBM may not offer the products, services, or features discussed in this document in
other countries. Consult your local IBM representative for information on the
products and services currently available in your area. Any reference to an IBM
product, program, or service is not intended to state or imply that only that IBM
product, program, or service may be used. Any functionally equivalent product,
program, or service that does not infringe any IBM intellectual property right may
be used instead. However, it is the user's responsibility to evaluate and verify the
operation of any non-IBM product, program, or service.

IBM may have patents or pending patent applications covering subject matter
described in this document. The furnishing of this document does not grant you
any license to these patents. You can send license inquiries, in writing, to:

IBM Director of Licensing

IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
United States of America

For license inquiries regarding double-byte character set (DBCS) information,

contact the IBM Intellectual Property Department in your country or send
inquiries, in writing, to:

Intellectual Property Licensing

Legal and Intellectual Property Law
IBM Japan Ltd.
19-21, Nihonbashi-Hakozakicho, Chuo-ku
Tokyo 103-8510, Japan

The following paragraph does not apply to the United Kingdom or any other
country where such provisions are inconsistent with local law:
INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS
PUBLICATION "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or
implied warranties in certain transactions, therefore, this statement may not apply
to you.

This information could include technical inaccuracies or typographical errors.

Changes are periodically made to the information herein; these changes will be
incorporated in new editions of the publication. IBM may make improvements
and/or changes in the product(s) and/or the program(s) described in this
publication at any time without notice.

© Copyright IBM Corp. 2010, 2018 135

 Any references in this information to non-IBM websites are provided for
convenience only and do not in any manner serve as an endorsement of those
websites. The materials at those websites are not part of the materials for this IBM
product and use of those websites is at your own risk.

IBM may use or distribute any of the information you supply in any way it
believes appropriate without incurring any obligation to you.

Licensees of this program who wish to have information about it for the purpose
of enabling: (i) the exchange of information between independently created
programs and other programs (including this one) and (ii) the mutual use of the
information which has been exchanged, should contact:

IBM Director of Licensing

IBM Corporation
North Castle Drive, MD-NC119
Armonk, NY 10504-1785
US

Such information may be available, subject to appropriate terms and conditions,

including in some cases, payment of a fee.

The licensed program described in this document and all licensed material
available for it are provided by IBM under terms of the IBM Customer Agreement,
IBM International Program License Agreement or any equivalent agreement
between us.

The performance data discussed herein is presented as derived under specific

operating conditions. Actual results may vary.

Information concerning non-IBM products was obtained from the suppliers of

those products, their published announcements or other publicly available sources.
IBM has not tested those products and cannot confirm the accuracy of
performance, compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be addressed to the
suppliers of those products.

Statements regarding IBM's future direction or intent are subject to change or

withdrawal without notice, and represent goals and objectives only.

All IBM prices shown are IBM's suggested retail prices, are current and are subject
to change without notice. Dealer prices may vary.

This information is for planning purposes only. The information herein is subject to
change before the products described become available.

This information contains examples of data and reports used in daily business
operations. To illustrate them as completely as possible, the examples include the
names of individuals, companies, brands, and products. All of these names are
fictitious and any similarity to actual people or business enterprises is entirely
coincidental.

COPYRIGHT LICENSE:

This information contains sample application programs in source language, which

illustrate programming techniques on various operating platforms. You may copy,

136 IBM Bigfix: Configuration Guide

 modify, and distribute these sample programs in any form without payment to
IBM, for the purposes of developing, using, marketing or distributing application
programs conforming to the application programming interface for the operating
platform for which the sample programs are written. These examples have not
been thoroughly tested under all conditions. IBM, therefore, cannot guarantee or
imply reliability, serviceability, or function of these programs. The sample
programs are provided "AS IS", without warranty of any kind. IBM shall not be
liable for any damages arising out of your use of the sample programs.

© (your company name) (year).

Portions of this code are derived from IBM Corp. Sample Programs.
© Copyright IBM Corp. _enter the year or years_.

Trademarks
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of
International Business Machines Corp., registered in many jurisdictions worldwide.
Other product and service names might be trademarks of IBM or other companies.
A current list of IBM trademarks is available on the web at www.ibm.com/legal/
copytrade.shtml.

Adobe, Acrobat, PostScript and all Adobe-based trademarks are either registered
trademarks or trademarks of Adobe Systems Incorporated in the United States,
other countries, or both.

IT Infrastructure Library is a registered trademark of the Central Computer and

Telecommunications Agency which is now part of the Office of Government
Commerce.

Intel, Intel logo, Intel Inside, Intel Inside logo, Intel Centrino, Intel Centrino logo,
Celeron, Intel Xeon, Intel SpeedStep, Itanium, and Pentium are trademarks or
registered trademarks of Intel Corporation or its subsidiaries in the United States
and other countries.

Linux is a trademark of Linus Torvalds in the United States, other countries, or

both.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of
Microsoft Corporation in the United States, other countries, or both.

ITIL is a registered trademark, and a registered community trademark of The

Minister for the Cabinet Office, and is registered in the U.S. Patent and Trademark
Office.

UNIX is a registered trademark of The Open Group in the United States and other
countries.

Java™ and all Java-based trademarks and logos are trademarks or registered
trademarks of Oracle and/or its affiliates.

Cell Broadband Engine is a trademark of Sony Computer Entertainment, Inc. in the

United States, other countries, or both and is used under license therefrom.

Linear Tape-Open, LTO, the LTO Logo, Ultrium, and the Ultrium logo are
trademarks of HP, IBM Corp. and Quantum in the U.S. and other countries.

Notices 137
Terms and conditions for product documentation
Permissions for the use of these publications are granted subject to the following
terms and conditions.

Applicability

These terms and conditions are in addition to any terms of use for the IBM
website.

Personal use

You may reproduce these publications for your personal, noncommercial use
provided that all proprietary notices are preserved. You may not distribute, display
or make derivative work of these publications, or any portion thereof, without the
express consent of IBM.

Commercial use

You may reproduce, distribute and display these publications solely within your
enterprise provided that all proprietary notices are preserved. You may not make
derivative works of these publications, or reproduce, distribute or display these
publications or any portion thereof outside your enterprise, without the express
consent of IBM.

Rights

Except as expressly granted in this permission, no other permissions, licenses or

rights are granted, either express or implied, to the publications or any
information, data, software or other intellectual property contained therein.

IBM reserves the right to withdraw the permissions granted herein whenever, in its
discretion, the use of the publications is detrimental to its interest or, as
determined by IBM, the above instructions are not being properly followed.

You may not download, export or re-export this information except in full
compliance with all applicable laws and regulations, including all United States
export laws and regulations.

IBM MAKES NO GUARANTEE ABOUT THE CONTENT OF THESE

PUBLICATIONS. THE PUBLICATIONS ARE PROVIDED "AS-IS" AND WITHOUT
WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING
BUT NOT LIMITED TO IMPLIED WARRANTIES OF MERCHANTABILITY,
NON-INFRINGEMENT, AND FITNESS FOR A PARTICULAR PURPOSE.

138 IBM Bigfix: Configuration Guide

Notices 139
IBM®

Printed in USA