HP ProLiant xw2x220c Remote Graphics Software 5.2.5 User Guide - Page 170
Administrator alerts, Anticipating user disconnects and reconnects, General agent design guidelines
View all HP ProLiant xw2x220c manuals
Add to My Manuals
Save this manual to your list of manuals |
Page 170 highlights
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 post mortem 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 170