Additional Safeguard Features For Windows Systems - HP Xw460c - ProLiant - Blade Workstation User Manual

Administrator alerts
Situation—Instead of shutting down an environment, an agent can be designed to alert an administrator or
•
operator to determine the status of the user before taking action. This watchdog approach can further be
defined to exploit redundant network connection support to a remote system to allow user-directed
shutdowns to occur.
Benefit—System agents are not required to take destructive action—they serve only as alarms and monitors
•
for alternative human intervention.
Issue—May require redundant networking channel. Requires administrator or operator availability to
•
support.
Anticipating user disconnects and reconnects
Situation—Users must first be warned about the consequences of disconnection. Agents that provide
•
protection for a disconnected session may become a nuisance for unsuspecting users if they fail to address
protective measures in place for their safety. For example, users must know how much time they have to
reconnect before safeguards take action. If a remote agent arms itself for application termination, users
should be presented with a large, unmistakable disarming "opt-out" panel that, upon login and discovery,
they can halt any agent actions before termination. Organizations should carefully discuss and publicize
safety measures due to potential data loss.
Issue—Users should not be able to disable or specify their own timeouts due to potential irreversible data
•
loss.
General agent design guidelines
In developing an agent, HP recommends following these guidelines:
The agent should externally log its decisions and actions for postmortem analysis.
•
Independent agents should provide their own opt-out, disarming dialogs with countdown feedback before
•
taking action.
Expect the unexpected—where possible, limit your actions to those areas you are certain of the outcomes to
•
minimize loss of data and productivity.
Always inspect error codes when reading event logs—the reliability of this RGS communication method
•
depends upon the Windows Event Log system. While we have yet to see a failure in this path, we
recommend using all information available to its fullest potential.

10-5 Additional safeguard features for Windows systems

The following optional procedures for the RGS Sender service can improve the reliability of your remote agent
solution.
RGS Sender Service Recovery Settings
This section discusses restart options for the RGS Sender and possible interactions of the agent with the Sender.
By default, most Windows services are installed without any automatic restart/recovery settings. This means
•
that, when a service terminates, Windows will, by default, not restart the service unless explicitly set. When
RGS Sender software is first installed, it is installed with the Windows default (do not restart).
Restarting the RGS Sender service can support RGS reconnection with a RGS Receiver client (unless a system
•
error prevents the RGS service from restarting).
In designing the agent, you should consider whether or not to check for the existence of a running RGS
•
Sender service as an indication of a sufficient primary user connection. If service restarts are programmed
for your environment, this test may be unnecessary.
To set the RGS Sender service for automatic restart, adjust its Recovery Property through the "Administrative
•
Tools" and "Services" control panel options.
Actions to take for the first failure, second failure, and subsequent failures are available in the properties
•
menu (see Figure 10-1). The Recovery options include:
Take No Action
•
Restart the Service
•
Run a Program
•
Restart the Computer
•
Remote Application Termination 174