Manage the Unattended Target environment

Learn how to manage the Unattended Target environment.

The Unattended Status Cache

The information about the Target Heartbeat and the Unattended Target Status is stored on a volatile cache on the server for performance reasons. The actual Unattended Target Status is visible from the Target Status page (after selecting the single target), from the Deployment Status Dashboard from the Server log file or from the Target List on the Controller.

The volatile nature of the cache implies that if you restart, the server starts to populate with real-time information as they are processed on the server.

You can set the rc.dashboard.preload.on.startup option to preload the cache at server startup. In this case, the status of the preloaded target appears as Unknown until the target reaches the server again.

Call Home v/s Heartbeat

A Managed Target performs a Call Home every rc.heartbeat_timeout minutes.

An Unattended Target perform a Call Home every rc.heartbeat_timeout minutes and a Heartbeat (also named Pulse) every rc.unattended.heartbeat.interval.minutes.

The target asset information is updated on Call Homes. That information includes LAST_UPDATE time stamp, IP ADDRESS LIST, BROKER. For an Unattended Target, this information indicates the last Call Home information.

The information about the target Heartbeat and the Unattended Target Status is stored on a volatile cache on the Server.

An Unattended Target can be recognized by the presence of a broker in the BROKER column of the All Target View.

Heartbeat Interval and Offline Grace

An Unattended Target contacts the server every rc.unattended.heartbeat.interval.minutes to report its status and to check if there is any pending session request.

When you initiate a Remote Control Session with an Unattended Target, the rc.unattended.heartbeat.interval.minutes also indicates the maximum amount of time you need to wait before the session is established.

The target heartbeat contact is used by the server to determine the target status. The property rc.unattended.heartbeat.offline.grace indicates how many missing target heartbeats are allowed before the target is considered Offline.

Controlling Unattended Session Timeout

It is possible to control the timeout value of the Unattended Target sessions.

When starting sessions from the Start Session entry from the Remote Control Server, the controller must be started within 15 minutes (the same as in standard Managed sessions). You can control this timeout value using the rc.unattended.controller.token.minutes property.

When operating via the target list (from the Start Unattended Session either via the Remote Control Server or via the Lite Web Portal), the controller is authorized to operate for 60 minutes from the initial session request. If the controller is closed, a new start session is required. You can control this timeout value using the rc.unattended.targetlist.token.minutes property.

To define a value for the rc.unattended.targetlist.token.minutes, you must consider the operating environment (either via portal or via server interface) as well as what other security feature you are planning to adopt. Using a higher timeout value requires less session restart. If Controller UUID or Two Factor Authentication is used, you must consider increasing this timeout value.

Target Groups

Unattended Targets can be assigned to a Target Group during initial registration or at every Call Home in accordance with the same rules that apply for Managed Targets.

If you are using rules based on IP address and you have indicated rc.tmr.at.registration, rc.tmr.at.every.callhome, or rc.tmr.at.triggered.callhomes and the UnattendedInternetAccess is set to Auto, the target might change its group depending on target location. Review your rules and ensure the targets are assigned to the desired group.

Using the Asset Tag

You can use the Target Asset Tag to add notation to a target or a group of targets to make it easier to search for targets.

You can set the Asset Tag using the BigFix Remote Control Target Wizard on the BigFix Console.

Controlling Log Content

As you operate with an increasing number of targets, the log information that is produced can be impractical.

You can set the Broker log level to 1.

In addition, the following properties are available in the Unattended Target - Log control section of the trc.properties to control logging functions.
  • Set rc.unattended.log.incoming.heartbeat to False to prevent every Unattended Target heartbeat to produce a log entry.
  • Set rc.unattended.log.heartbeat.trend to True to produce a periodic summary in the Server Log File on how many heartbeats were received in the last rc.unattended.heartbeat.interval.minutes interval. The same information is available in graphical form from the Deployment Status Dashboard.
The rc.unattended.log.cache.report produces a periodic summary in the Server Log File on the Status of Targets as known to the server. On each periodic summary, a list of targets for each status is included in the summary based on the status of the respective property in the Unattended Target - Log cache entries at cache report section.

Debug Options

The following properties are available in the Unattended Target - Tuning and debug options section of the trc.properties.

You must use those properties following the indication of the HCL Support Team.

The rc.unattended.force.guid.check enables extensive verification of target information at Heartbeat time. This option must be used if Targets in Error status are noticed.

The rc.unattended.log.timing.records and rc.unattended.log.timing.completed provide processing time information on the Server Log File to collect performance information. The produced log file must be provided to the HCL Support team for investigation.

Monitoring the Unattended System Health

When the Unattended Target Support is enabled, the Deployment Status Dashboard provides a real-time status view of the targets and broker status that is based on the Unattended Status Cache.

Targets when performing the Heartbeat connect to the server through all the Brokers that are listed in the BrokerList. The target connects the first broker that responds to the request. Operating with more than one broker hence produces a load balancing and redundancy effect.