Best Practices for Integrated Lights-Out and Integrated Lights-Out 2

best practice, 3rd edition

Abstract.............................................................................................................................................. 4 Introduction......................................................................................................................................... 4 Planning the use of Lights-Out technology ............................................................................................... 5 Network configuration.......................................................................................................................... 5 Private management network............................................................................................................. 5 Network cabling in dense rack environments....................................................................................... 6 Out-of-band management ..................................................................................................................... 6 iLO configuration................................................................................................................................. 7 Single iLO device............................................................................................................................. 7 Multiple iLO devices ......................................................................................................................... 7 Automated setup .......................................................................................................................... 7 Initial deployment ......................................................................................................................... 8 Naming conventions ........................................................................................................................ 8 Enhancing security ............................................................................................................................... 8 Change the default login password .................................................................................................... 8 Implement directory access................................................................................................................ 9 Two-factor authentication .................................................................................................................. 9 Checking certificate revocation .................................................................................................... 11 Restrict access to the Remote Console port ........................................................................................ 11 iLO ........................................................................................................................................... 11 iLO 2 ........................................................................................................................................ 11 Protect SNMP traffic ....................................................................................................................... 12 Networks settings .............................................................................................................................. 12 Proxy servers ................................................................................................................................. 12 Browser configuration..................................................................................................................... 12 Configuring IP port assignments ....................................................................................................... 13 Remote Console performance.............................................................................................................. 14 Host server settings: Windows ......................................................................................................... 14 Server display properties............................................................................................................. 14 Server mouse properties (iLO only) ............................................................................................... 14

High performance mouse ............................................................................................................ 15 Host server settings: Linux................................................................................................................ 15 Server display properties............................................................................................................. 15 Server mouse properties .............................................................................................................. 15 Host server settings: Novell NetWare (iLO only) ................................................................................ 15 Server display properties............................................................................................................. 15 Client and browser settings ............................................................................................................. 16 Display properties ...................................................................................................................... 16 Mouse properties ....................................................................................................................... 16 Single-cursor mode (iLO only) .......................................................................................................... 16 Dual-cursor mode (iLO only) ............................................................................................................ 17 Terminal Services pass through mode ............................................................................................... 17 Remote serial console......................................................................................................................... 17 Integrated Remote Console ................................................................................................................. 18 Integration with HP Systems Insight Manager ........................................................................................ 19 Managing multiple iLO devices ........................................................................................................... 20 HP Systems Insight Manager ........................................................................................................... 20 CPQLOCFG.EXE, HPONCFG.EXE, and script files ............................................................................. 21 CPQLODOS (iLO only) ................................................................................................................... 21 Directory services............................................................................................................................... 22 Setting up the directory server ...................................................................................................... 23 Local versus directory accounts .................................................................................................... 23 HP extended schema method........................................................................................................... 23 Required software ...................................................................................................................... 24 Migration utilities........................................................................................................................ 24 Extending the directory schema.................................................................................................... 24 Roles......................................................................................................................................... 25 Schema-free method ....................................................................................................................... 25 Deploying headless servers ................................................................................................................. 26 Unattended server deployment ............................................................................................................ 27 Deploying servers using Rapid Deployment Pack ................................................................................... 27 Virtual Media/USB support................................................................................................................. 28 Scripted Virtual Media ....................................................................................................................... 29 XML scripting................................................................................................................................. 29 XML examples............................................................................................................................ 30 CLP scripting ................................................................................................................................. 30 CLP examples ............................................................................................................................ 31 Scripting Web server requirements................................................................................................... 31 Using RILOE-II in an iLO server (iLO only).............................................................................................. 32 Linux tips .......................................................................................................................................... 32 Telnet support ................................................................................................................................ 32 Kickstarting Linux OS with Virtual Floppy .......................................................................................... 33 Appendix A ...................................................................................................................................... 34 Using barcode scanning to ease mass-configuration of iLO devices...................................................... 34 Command-line switches................................................................................................................... 34 Deploying iLO devices.................................................................................................................... 35 Updating iLO devices ..................................................................................................................... 35 Appendix B....................................................................................................................................... 36 Using a RAM drive to ease mass-deployment of iLO-based servers ....................................................... 36 Overview ...................................................................................................................................... 36

The Master Boot Diskette................................................................................................................. 36 The Custom Deployment Tool........................................................................................................... 38 For more information.......................................................................................................................... 39 Call to action .................................................................................................................................... 39

Abstract
This document identifies specific practices for using the HP Integrated Lights-Out (iLO) and the HP Integrated Lights-Out 2 (iLO 2) management processors to reduce complexity and simplify management of the datacenter and remote sites. Although, they may not be applicable in all computing environments, HP recommends implementing these practices as they are appropriate for a specific IT infrastructure.

Introduction
The HP Integrated Lights-Out (iLO) device is an autonomous management processor that resides on the system board of a host server. It contains its own processor, memory, and network interface that allow it to operate independently from the host server. Using iLO, IT administrators can manage a ProLiant server remotely through its entire life cycle: initial deployment, operation, and redeployment. Unlike other management solutions, iLO devices are entirely independent of the state of the operating system (OS) or server hardware. They provide seamless control of remote servers in full graphics mode (when using the iLO Advanced feature set). The Virtual Media feature of iLO allows IT administrators to perform remote ROM upgrades and server deployments. All these capabilities combine to provide administrators the ability to respond quickly to downtime events, diagnose OS or server problems remotely, increase uptime, and reduce the loss of business revenue. This paper discusses best practices in system planning, deployment, and operation of iLO management processors. It is assumed that the reader is familiar with the general features of iLO. Reference material for this subject and related subjects discussed herein is available, check the For more information section at the end of this document for locations. This document supports both iLO platforms; however, certain functions described herein may only be supported on one and not the other. A designation of iLO only or iLO 2 only indicates that the function is exclusive to that platform. If no designation is present then the function is supported on both platforms. More information about iLO is available from the website at www.hp.com/servers/ilo.

Planning the use of Lights-Out technology

Before deploying and configuring an iLO device, it is helpful to assess the IT environment. Table 1 outlines areas to consider when planning the use of Lights-Out technology.
Table 1. Assessing the IT environment Environment factor Asset management Assessment criteria Where are servers located (in datacenters or at remote sites)? Where would it be helpful to use iLO? How many servers exist in the computing environment? Systems management How are remote sites and data center servers currently managed? Can the servers be managed remotely through lights-out technology? Security Is the network as secure as possible? Does the datacenter use virtual private networks or include firewalls? Can all servers use directory services and authentication? Can the datacenter benefit from two-factor authentication? Potential for improvement Deploying iLO can eliminate the need for keyboards, video monitors, and mice, which reduces cabling complexity and increases server density in the datacenter. The iLO device provides seamless access to the server, which eliminates the need for an administrator to be present in front of the server. The iLO device provides multiple levels of security, including directory authentication, Secure Sockets Layer (SSL) encryption, event generation for failed login attempts, lockout of configuration utilities, enforced delay after unsuccessful login attempts, twofactor authentication, and configurable internet protocol (IP) port assignments.

When planning future server purchases, a customer can determine whether a server includes iLO by referring to this webpage: http://h18013.www1.hp.com/products/servers/management/riloe2/supported-servers.html. Customers that have a large installed based of iLO devices and frequently add more may want to purchase a Master License Agreement (MLA) from HP. An MLA allows the customer to purchase a single activation key for multiple licenses of the ProLiant Essentials Value Packs, such as the iLO Advanced Pack. After the MLA is in place with HP, the customer purchases the desired number of license-only part numbers whenever additional licenses for iLO Advanced are needed. This simplifies the software licensing process and reduces the amount of physical documentation that is shipped to the customer. Additional information is available from the HP website: http://h18013.www1.hp.com/products/servers/proliantessentials/valuepack/licensing.html.

Network configuration
Before deploying iLO devices, an administrator should consider the setup and design of the network on which the iLO devices will reside.

Private management network

The iLO devices allow browser access to the host ProLiant servers through a seamless, hardwarebased, OS-independent remote console. For security reasons, HP recommends that customers establish a private management network that is separate from their data network and that only administrators are granted access to that management network.

The Shared Network Port feature on ProLiant servers allows system administrators to access iLO using a network connection shared with the host operating system. This feature reduces the number of network connections required to manage the server. The Shared Network Port operates like a miniature network switch, routing iLO information to the iLO network interface and server operating system information to the operating system network interface.
NOTE: The ProLiant server Shared Network Port feature implements a sideband connection between the main NIC and the iLO. This sideband connection maintains a second (and separate) MAC address. This separate MAC address is assigned to iLO and allows iLO to obtain a separate IP address. Thus, iLO and the servers NIC each have their own separate MAC and IP addresses.

Network cabling in dense rack environments

When deploying multiple iLO-enabled servers in very dense rack environments, it is beneficial to consolidate all of the iLO network connections to a rack-mounted hub or access switch (Figure 1). The administrator may then uplink all Lights-Out Management network traffic via a single output from the hub/switch into a distribution switch in the enterprise network infrastructure. Using an access switch for Lights-Out management traffic on the network provides the following benefits: Simplifies cable management inside the rack Makes more efficient use of available bandwidth Reduces the number of network cables run to the rack for management traffic Reduces usage of more expensive enterprise network infrastructure ports

Figure 1. Consolidating multiple iLO devices into a single rack-mounted access switch

Out-of-band management
An iLO device can be used for remote management even if there is no Ethernet local area network (LAN) connection to a remote host server. IT administrators can use a modem gateway or a remote access server (RAS) login into the local LAN to enable out-of-band (dial-up) access to the host server. If there were multiple servers at the remote site, this solution would require only one telephone line to

access all iLO devices installed at that site (Figure 2). The modem gateway handles the dial-up telephone line on one side and the Ethernet LAN on the other side. The administrator dials in to the modem gateway and then directs access to the specific iLO using the iLOs network address.

Figure 2. Example of out-of-band access configuration

iLO configuration
Each iLO device can be configured individually in multiple ways: through the ROM-Based Setup Utility (RBSU), through the web browser interface, through the Command Line Protocol (CLP), or through a scripted setup over the network or from the host. This allows the administrator to configure iLO using the appropriate means for their environment, and enables 1:1 configuration (such as using a browser) or 1:many configuration (such as using a scripted setup).

Single iLO device

RBSU is the recommended method to set up a single iLO device initially. RBSU allows configuration of the iLO network address as well as a local user account. After initial setup using iLO RBSU, the iLO device is available on the network; and subsequent configuration and management can be accomplished by other means. RBSU is available every time the server is booted and can be run remotely using the iLO Remote Console. RBSU is not intended for continued administration. Other tools such as the web browser or scripting tools are better suited for that. See the iLO User Guide for more information about each of the three configuration methods (www.hp.com/servers/ilo).

Multiple iLO devices

Automated setup Deploying a large number of iLO-enabled servers is best accomplished by using several OS specific, automated setup enablers. These enablers include the Lights-Out Configuration Utility (CPQLOCFG.EXE), the Online Configuration Utility (HPONCFG.EXE), and a Perl interpreter that communicates with iLO. These utilities support the use of script files allowing administrators to configure and manage user accounts on multiple iLO devices simultaneously. HP has developed and made available sample XML and Perl scripts files that can be adjusted for your environment. Additionally, HP recommends using a bar code scanner (see Appendix A) to further facilitate automation.

Administrators can expand or change the sample XML scripts to perform other functions such as to power up or down servers or determine who has access rights to iLO. The iLO User Guide includes the supported XML commands for additional script development. Appendix A discusses, in detail, how to use these utilities, their respective sample script files and the bar code reader in order to automate the deployment and configuration of multiple iLO devices. The CPQLOCFG.EXE, HPONCFG.EXE, and the sample scripts files are available from the HP website: http://h18004.www1.hp.com/support/files/lights-out/us/index.html. The CPQLOCFG.EXE version 2.5 or greater must be used for iLO devices. Initial deployment HP recommends that administrators use these sample files and a bar code reader to scan all the passwords and Domain Name System or Service (DNS) names from the network settings tag into a spreadsheet or database. (An administrator can manually enter the passwords and DNS names into a spreadsheet; however, manual entry is much more time-consuming and error-prone than scanning.) Then, using the appropriate XML script, the administrator can configure the group of iLO devices, add the license keys for the iLO Advanced functionality, upgrade firmware on the iLO devices, add a new user, or change user privileges. For example, if a customer established an MLA for the iLO Advanced Pack, the administrator could use an XML script to add the license keys for all applicable ProLiant servers. After initially configuring iLO, it is possible to continue deploying the server, including the operating system installation. Various methods are available to perform operating system installation and configuration, including iLO virtual media, Rapid Deployment Pack, or custom installation tools. Appendix B outlines a sample custom installation tool that allows installation of the operating system during a mass deployment operation.

Naming conventions
When deploying many iLO devices, it is helpful to name them according to a consistent convention, for example: ServerName_iLO. This convention clearly identifies which server is hosting the iLO device and makes it easier to set up proxy settings for wildcard usage.

Enhancing security
Because they are completely autonomous and can be used to control the server, iLO devices should be treated in the same manner as other servers. For example, the administrator should include the iLO devices in the security and network audits and should review the access logs daily. More detailed information concerning iLO security is available from the HP website:
www.hp.com/servers/ilo

Change the default login password

Each iLO device comes with a network settings tag that shows the default password for that device. The default password is a randomly generated, eight-character, alphanumeric string. It should be changed immediately to a more relevant password. Thereafter, it should be changed with the same frequency and according to the same guidelines as the administrative passwords for the server. In the event that login passwords are lost or forgotten, there is a way to temporarily override the security of iLO. In servers with an iLO device, there is an iLO Security Override Switch on the system board. This switch temporarily disables authentication security, allowing a user to log in without using a password. It does not give a user access to read existing passwords or to erase any existing account information, but it does allow that user to change existing passwords and to add or delete user accounts.

To change the state of the iLO Security Override Switch, an administrator must have physical access to the inside of the server. Depending on the server, the iLO Security Override Switch may be a single jumper or a specific switch position on a dipswitch panel. Refer to the server documentation to locate the iLO Security Override Switch. Do not routinely leave iLO security disabled as a convenience to access iLO.

Implement directory access

An administrator can implement directory services to improve security. As a licensed feature, directory services integration is supported by current iLO firmware and allows an administrator to authenticate a user and authorize user privileges by means of the same login process employed throughout the rest of the network. Directory integration has these virtues: Users are less likely to share an iLO account when they can use their directory user accounts. This reduces potential anonymous access or the treatment of iLO user accounts as roles. The directory becomes the single point for password maintenance, instead of each iLO instance. This allows implementation of a secure password policy and avoids the downsides of maintaining password lists. Single changes at the directory can impact all of the iLO processors without visiting each. The directory scales. Using directory access provides greater protection against malicious attacks. For instance, using a local account, each network connected iLO presents a unique logon opportunity for an intruder. However, with directory services, the intruder would have only a single access point to multiple iLO devices. Additionally, after each unsuccessful logon attempt, the iLO introduces a progressively longer delay before presenting subsequent logon prompts. This design thwarts automated attacks and reduces the chance that intruders may log in to any iLO device. Because the directory accounts provide these security benefits, an administrator using directories may want to disable local accounts or to remove them entirely. For more information about directory services, see the section titled Directory services later in this paper.

Two-factor authentication
Many environments desire additional security such as a physical token in addition to user credentials for access. This security is called two-factor authentication: a physical item and knowledge. As a licensed feature, current iLO firmware supports two-factor authentication. iLO uses digital certificates to authenticate users when the Two-Factor Authentication feature is enforced. Directory users and iLO users can interoperate with two-factor authentication. The administrator should obtain the public certificate of the certificate authority (CA) which issues user certificates in the organization. This certificate must be configured as the trusted CA certificate in iLO. For local iLO users, the administrator must obtain the public certificate of each user who requires access to iLO. The public certificate for each user must be configured in iLO using the User Administration page. Use the View/Modify feature to add the appropriate certificate to each local user account. For directory users, the administrator should pick the certificate field to be used for authentication. The certificate field may vary depending on the directory integration method. The following examples examine the three most common circumstances.

Example 1: Authentication using the Schema-free method The distinguished name for a user in the directory is: CN=John Doe,OU=IT,DC=MyCompany,DC=com The following are the attributes of John Doe's certificate: Subject: DC=com/DC=MyCompany/OU=IT/CN=John Doe SAN/UPN: john.doe@MyCompany.com Authenticating to iLO with username:john.doe@MyCompany.com and password, may work if twofactor authentication is not enforced. After two-factor authentication is enforced, if SAN is selected on the Two-Factor Authentication Settings page, the login page automatically populates the Directory User field with john.doe@MyCompany.com. The password can be entered, but the user will not be authenticated. The user is not authenticated because john.doe@MyCompany.com, which was obtained from the certificate, is not the distinguished name for the user in the directory. In this case, you must select Subject on the Two-Factor Authentication Settings page. Then the Directory User field on the login page will be populated with CN=John Doe,OU=IT,DC=MyCompany,DC=com, which is the user's actual distinguished name. If the correct password is entered, the user is authenticated. Example 2: Authentication using the Schema-free method The distinguished name for a user in the directory is: CN=john.doe@MyCompany.com,OU=IT,DC=MyCompany,DC=com The following are the attributes of John Doe's certificate: Subject: DC=com/DC=MyCompany/OU=Employees/CN=John Doe/E=john.doe@MyCompany.com SAN/UPN: john.doe@MyCompany.com Search context on the Directory Settings page is set to: OU=IT,DC=MyCompany,DC=com In this example, if SAN is selected on the Two-Factor Authentication Settings page, the Directory User field on the login page is populated with john.doe@MyCompany.com. After the correct password is entered, the user is authenticated. Contrary to the previous example, the user is authenticated even though john.doe@MyCompany.com is not the distinguished name for the user. The user is authenticated because iLO attempts to authenticate using the search context fields (CN=john.doe@MyCompany.com, OU=IT, DC=MyCompany, DC=com) configured on the Directory Settings page. Because this is the correct distinguished name for the user, iLO successfully finds the user in the directory.
NOTE: Selecting Subject on the Two-Factor Authentication Settings page would cause authentication to fail, because the subject of the certificate is not the distinguished name for the user in the directory. iLO must have the distinguished name of the user object in order to authenticate with the Schema-free method. iLO can get this information from the certificate, or it can derive it from information in the certificate combined with search contexts as in Example 2.

Example 3: Authentication using the HP extended schema method When using the HP extended schema method, HP recommends selecting the SAN option on the TwoFactor Authentication Settings page.

10

Checking certificate revocation Due to the small amount of memory available to iLO, the size of Certificate Revocation Lists(CRLs) that can be downloaded into iLO memory is limited. If a CRL is larger than 128KB, iLO cannot determine whether a client certificate is in the list and is therefore revoked. In this case, iLO will assume that the certificate is revoked and will not allow authentication with that certificate. HP recommends that CRLs be no larger than 128KB. The CA which issues and revokes certificates should be configured to keep CRL files smaller than this size. If this recommendation is not feasible in your organization, HP recommends disabling the Check for Certificate Revocation feature on the Two-factor Authentication Settings page in iLO, to prevent locking out legitimate users.

Restrict access to the Remote Console port

Because Telnet is not an inherently secure protocol, administrators may be reluctant to use its functionality. The following describes how iLO overcomes this limitation and facilitates secure Telnet access. The Remote Console port (port 23) allows an authorized user to establish a Remote Console session with the host server. To provide tighter security, a user with supervisor rights can restrict access to the Remote Console port and can turn on Remote Console encryption. The following lists indicate the available options for access to the iLO and iLO 2 Remote Console ports respectively: iLO The Remote Console port is always disabled. A user trying to access the Remote Console will always be denied access when this setting is in place. This setting provides the highest security, but it may not allow adequate management capabilities. The Remote Console port is set to auto-enable. This setting is the default for the Remote Console port. This setting disables the port except when iLO senses the Remote Console applet starting. In that case, iLO automatically enables the Remote Console port and automatically disables it when the Remote Console session has ended. The iLO device actively refuses any other connection attempt to port 23 so that the host server will be inaccessible via a standard Telnet application. iLO maintains exclusive control over the port when using the remote console applet. The Remote Console is enabled. An authorized user can access the Remote Console port at any time. This allows a Telnet connection or a Remote Console applet connection to be made to the Remote Console port. iLO 2 The Enabled setting turns-on the telnet port and disables encryption so that telnet access is available. The Disabled setting turns-off the telnet port so that telnet access is not available. Regardless of this setting, the iLO remote console and integrated remote console are always available in the encrypted mode. For maximum security when the Remote Console is enabled, HP recommends that the administrator turn on the Remote Console encryption. For maximum security for customers who do not require the Remote Console feature, HP recommends disabling the Remote Console port.
NOTE: Because Telnet sessions connect to port 23, an administrator that has disabled the Remote Console port or set the Remote Console port to auto-enable will not have Telnet support. Telnet support is available only when the Remote Console port is enabled and Remote Console encryption is disabled.

11

To configure the availability of the Remote Console port, complete the following steps:
1. Log on to the iLO management device using an account that has supervisor status. 2. In the Administration section,

For iLO, click Global Settings then click Access. For iLO 2, click Settings then click Access.
3. In the Remote Console Port Configuration section, click the appropriate option.

Protect SNMP traffic

Because SNMP uses passwords (known as community strings) that are sent across the network in clear text, it is important to enhance the network security when using SNMP traffic. Here are two suggestions: Reset the community strings (read-write, read-only, and trap) with the same frequency and according to the same guidelines as the administrative passwords. For example, select alphanumeric strings with at least one uppercase letter, one numeral, and one symbol. Set firewalls or routers to accept only specific source and destination addresses. For example, an administrator can allow inbound SNMP traffic into the host server only if it comes from one of the predetermined management workstations.

Networks settings
Proxy servers
Each iLO device can be accessed by its short name (for example, remote21), fully qualified name (for example, remote21.domain.com), or Internet protocol (IP) address. The browser needs to be configured to bypass the proxy server for each method used to access the iLO device.

Browser configuration
To configure Microsoft Internet Explorer 5.5 (SP2) or above:
1. Click Tools, Internet Options, and then Connections. 2. Click LAN Settings (or the appropriate dial-up or VPN connection and click Settings). Make sure

that the Bypass proxy server for local addresses box is checked. This selection will ensure that short names will not use a proxy server. 3. Click Advanced. The Proxy Setting window will appear. 4. Under Exceptions, enter the IP address and/or the fully qualified name of the iLO device. Wildcards can be used to indicate all addresses within a certain domain, (for example, *.domain.com or 199.199.199.*). When an attempt to access a website is made, Internet Explorer crosschecks that address with a list to determine if a proxy server should be used. If a proxy server is not required to access external Internet sites, uncheck the Use a proxy server box. The Advanced settings can then be skipped. To configure Netscape Navigator 6.2 or above:
1. Click Edit and then Preferences. 2. Click the + next to Advanced and then on Proxies. 3. Click the radio button next to Manual proxy configuration. 4. Click View.

12

5. In the Exceptions list, add the names, domain names, or IP addresses of the iLO device. Netscape

Navigator does not support the use of wildcards.

6. If a proxy server is not required to access external Internet sites, click the radio button next to

Direct connection to the internet. The Exceptions list can then be skipped. To configure Mozilla1.0 or 1.1, follow the same steps used for Netscape Navigator. To use a Mozilla browser with the Linux OS, set the browser to use 12-point font to improve screen legibility.

Configuring IP port assignments

Administrators can manually configure the HTTP, Remote Console, and Virtual Media ports used by the iLO device. Normally, a web browser automatically attempts to connect with port 80 when given an IP address. Using the port configuration capability, the administrator can redirect the HTTP, Remote Console, and Virtual Media ports to administrator-defined ports. This redirection prevents others from accessing the HTTP, Remote Console, and Virtual Media ports without specific knowledge of the port numbers. Once the HTTP port is re-directed, a user must specify that port along with the IP address to access the login screen. This feature may be particularly useful for customers who wish to access iLO through a firewall and use HP Systems Insight Manager (HP SIM) as the data collection vehicle for port changes.
TIP: For an iLO device to work properly when going across routers using port blocking and/or firewalls, ports 23, 80, 443, and 17988 must be open. The directory services LDAP port (636) may be required. The Terminal Services RDP port (3389) may be required. Port 23 is for the Telnet ports where the remote and graphical Remote Console is used, port 80 is for HTTP communications, port 443 is required for the HTTPS connection, and port 17988 is for Virtual Media. LDAP traffic from a directory server uses random port numbers to enter the iLO device. The inability to access the iLO management ports is often confused with incorrect proxy settings. When in doubt, disable proxy in Internet Explorer or Netscape.

Table 2. Default port locations for iLO Port number 22 23 80 161 162 443 Protocol SSH (Secure Shell) Telnet Remote Insight port SNMP get/set SNMP trap Remote Insight encrypted port Lightweight Directory Assisted Protocol (LDAP) Virtual Media Terminal Services RDP Can be changed Yes Yes Yes No No Yes Supports SSH Connections Remote Console HTTP interface to iLO management board HP SIM polls HP SIM agent events SSL access to iLO management board Secure connection to the directory server Virtual Media RDC/TS Enabled by default Yes Yes Yes No No Yes Yes, if directory support is enabled Yes Yes

636

Yes

17988 3389

Yes No

13

Remote Console performance

The performance of the graphical Remote Console depends on various system parameters relating to the OS environment, network bandwidth, and screen resolution. Performance optimization is accomplished by adjusting specific host server and client browser settings relating to particular OS conditions. iLO 2 implements Virtual KVM technology providing a higher-performance remote console. Ideally, the screen resolution of the host server OS should be the same, or lower, than that of the client browser. For example, if the client browser uses a resolution of 1024x768, then the host server screen resolution should be no greater than 1024x768. The higher the resolution of the host servers screen, the slower the overall performance.
NOTE: Color depth does not affect Virtual KVM performance.

Host server settings: Windows

HP recommends these settings for a host server using Windows NT 4.0, Windows 2000, or Windows Server 2003. Server display properties Plain Background (no wallpaper pattern) Smaller display resolutions (800x600 or 1024x768 pixels) 256 color mode or 24 bits per pixel color setting (iLO only) Server mouse properties (iLO only) Select None for mouse pointer Scheme. Uncheck Enable pointer shadow. Select Motion or Pointer Options and set the pointer Speed slider to the middle position. Disable pointer Acceleration to None (on Windows NT or Windows 2000). Uncheck Advanced Pointer Precision (on Windows Server 2003). The HPLOMOPT.EXE utility can be used to automatically optimize the Windows mouse properties. An option also exists in the HPONCFG.EXE utility to optimize the Windows mouse properties. These utilities can be downloaded from the website at http://h18004.www1.hp.com/support/files/lightsout/us/index.html. iLO 2 Virtual KVM should be configured with the High Performance Mouse set to Enabled or Automatic. This setting will enable absolute mouse positioning resulting in the local and remote mouse cursors always being in sync.
NOTE: With the Automatic setting, the driver selects the mouse mode which in the case of Windows is always High Performance Mouse Enabled. If the driver has not been installed, Automatic will result in High Performance Mouse not being selected and very poor mouse synchronization will result. In this case manually select High Performance Mouse.

14

High performance mouse The High Performance Mouse improves mouse response and synchronization and is supported on ProLiant servers running Microsoft Windows 2003 or Windows 2000 Service Pack 3 or later. For best performance, run the HP online Configuration Utility (HPONCFG.EXE) for Windows 2003/2000 with the /mouse option to optimize the server mouse settings and use the remote console (not dual cursor).
NOTE: Disable High Performance Mouse support to use remote console during a SmartStart assisted operating system installation.

The High Performance Mouse option can be enabled or disabled via XML scripting using the following command. <RIBCL VERSION=2.0> <LOGIN USER_LOGIN=adminname PASSWORD=password> <RIB_INFO MODE=write> <MOD_GLOBAL_SETTINGS> <HIGH_PERFORMANCE_MOUSE VALUE=Yes /> </MOD_GLOBAL_SETTINGS> </RIB_INFO> </LOGIN> </RIBCL>

Host server settings: Linux

HP recommends these settings on a host server using Red Hat Enterprise Linux or SUSE Linux Enterprise Server: Server display properties Screen resolution of 1024x768 pixels or lower 256 color mode (iLO only) Server mouse properties Set Pointer Acceleration to 1X. For KDE, access the Control Center, select Peripherals/Mouse, and then select the Advanced tab. Configure the iLO 2 Virtual KVM with the High Performance Mouse set to Disabled.

Host server settings: Novell NetWare (iLO only)

HP recommends these settings on a host server using Novell NetWare: Server display properties Screen resolution of 800x600 pixels or lower 256 color mode

15

Client and browser settings

The speed of the Remote Console is dependent on the processing power of the client machine. For best results, HP recommends using a 2GHz or faster processor when operations require using more demanding applications such as viewing video, animation, or screen savers. However, for more typical server management operations a 1GHz client is sufficient. To improve execution of the Remote Console Java applet, HP recommends using a single processor client. It is also important to ensure that the client Remote Console applet can display the entire host server screen. HP recommends that users implement these settings on the client to optimize performance: Display properties Select a display resolution greater than the resolution of the host server. Select an option greater than 256 colors. Mouse properties Set the pointer Speed slider to the middle setting. Set the Mouse Pointer Acceleration to low, or disable the mouse acceleration. HP recommends Microsoft Internet Explorer, version 6.0. If the Remote Console applet is to be used, Java 1.4.2 (or later) or the Microsoft VM is recommended. Additional browsers may or may not work correctly, depending on the OS and specific implementations. The Integrated Remote Console (IRC) is an ActiveX control and is intended to run only on Internet Explorer. The Sun Java Virtual Machine is available at the website: www.hp.com/servers/manage/jvm.
NOTE: The URL will redirect you from the iLO management website to the java.sun website for the latest version available. However, HP recommends using the version specified in the Remote Console Help (available from the iLO browser interface).

Single-cursor mode (iLO only)

The single-cursor mode eliminates the need to synchronize two cursors, which makes navigation easier in the Remote Console window. To enable the single mouse cursor, the administrator must install the Sun Java Plug-in Version 1.4.2 or greater. The Java Virtual Machine applet must be downloaded and installed on the client machine. It is available at www.hp.com/servers/manage/jvm. This procedure is considered to be the best practice; however, if this option is not available, then the Dual-cursor mode is available.

16

Dual-cursor mode (iLO only)

The dual-cursor mode uses two mouse cursors: one representing the mouse cursor of the host server (seen as the standard cursor) and the other representing the mouse cursor of the local client (seen as a crosshair in the Remote Console window). The dual-cursor mode is supported with Java 1.1 JVM and later. If the two cursors drift apart, they can be synchronized and brought back together. Use any of the following techniques to synchronize the remote and local cursors: Right-click-drag and move the local crosshair cursor to align with the mouse cursor of the remote server. Holding the Ctrl key, move the local crosshair cursor to align with the mouse cursor of the remote server. Set the speed of the mouse cursor to the middle setting. Set the mouse cursor Acceleration to low, or disable acceleration entirely.

Terminal Services pass through mode

For faster performance, iLO can pass through the Microsoft RDP protocol used by the Microsoft Terminal Services session. The Terminal Services client is invoked and a connection is made to the Terminal Services client using the iLO network connection.

Remote serial console

The Remote Serial Console (iLO 2) and Virtual Serial Port (iLO) functions allow access to the physical serial port of the server virtually through the iLO network connection. These two functions are technically equivalent; only the names changed between iLO and iLO 2. There are three methods of accessing the Remote Serial Console or Virtual Serial Port. Using a Windows or Linux browser, a Java applet is launched which provides VT320 console capability to the serial port connection. Using a telnet client, a command can be issued to connect to the serial port. Using a SSH client in a manner similar to that from the telnet client. The Remote Serial Console or Virtual Serial Port function enables access to the Microsoft EMS (Emergency Management Services) SAC (Special Administration Console), and the Linux serial console, as well as to the ProLiant System ROM BIOS Serial Console Redirection.

17

Integrated Remote Console

The Integrated Remote Console is a new feature in iLO 2. The Integrated Remote Console integrates system KVM, Virtual Power and Virtual Media under a single console. The Integrated Remote Console uses ActiveX and requires Microsoft Internet Explorer. The Integrated Remote Console can be launched in a window or full screen mode.

Figure 3. Integrated Remote Console

Integrated Remote Console and IRC Fullscreen display a menu bar and buttons rendered onto the screen. The menu bar has the following options: Drives button displays all the media available. Power button displays the power status and allows the user to access the power options. The power button is green when the server is powered up. When the Power button is pressed, the Virtual Power Button screen displays with four options: Momentary Press, Press and Hold, Cold Boot, and Reset System. When either the Drives or Power button is pressed, the menu displayed remains open even when the mouse is moved away from the menu bar. Thumb tack allows the menu bar to remain open or to retract when the mouse is moved away. Exit (red button) allows you to close the console. Integrated Remote Console Fullscreen allows the user to re-size the client display to the same display resolution as the remote host and it attempts to pick the best client display settings for that resolution. However, some monitors might have trouble with the highest screen refresh rates supported by the video adapter. If this occurs, check your desktop properties by right-clicking the Desktop and selecting Properties > Settings > Advanced > Monitor and select a lower screen refresh rate. IRC attempts to match the remote host resolution, but if the client does not support a complementary video mode, fullscreen border-free operation may not function. Exiting the console returns the user to the client desktop.

18

Integration with HP Systems Insight Manager

The Insight Management Suite and management agents are tightly integrated with iLO. Therefore, administrators can view subsystem and status information from a web browser. HP Systems Insight Manager (HP SIM) can identify an iLO processor and create an association between the iLO and its host server. The administrator of the iLO device may configure it to respond to HP SIM identification requests. HP SIM identifies the iLO as a management processor and displays its status within the Systems List. The iLO management processor is displayed as an icon in the device list on the same row as its host server. The color of the icon represents the status of the iLO. The device list provides direct hyperlink access to each iLO device (see Figure 4), giving the administrator the benefit of having a single location for accessing all iLO management devices (including Remote Insight LightsOut Edition II or RILOE II boards).

Figure 4. Device list in HP SIM

The administrator can configure the iLO device for proactive management by allowing SNMP trap delivery to HP SIM. Up to three TCP/IP addresses can be configured to receive SNMP alerts. Typically, the administrator configures one address to be the same as the TCP/IP address of the HP SIM server console, while the others can be backup monitoring consoles.

19

If the administrator has changed the ports that the iLO device uses, some modifications must be made to HP SIM in order to discover these new ports. To change the port number in HP SIM, add the port to the config\identification\additionalWsDisc.props file in the directory where HP SIM is installed. The entry must be on a single line and must start with the HTTP port number for iLO. The following sample entry is for an iLO to be discovered at port 55000: 55000=iLO, ,true,false,com.hp.mx.core.tools.identification.mgmtproc.MgmtProcessorParser No entry is required if iLO remains at the standard port, Port 80. Detailed information on HP Systems Insight Manager is available on the website at www.hp.com/go/hpsim.

Managing multiple iLO devices

Administrators can manage iLO devices as a group rather than one at a time. For example, an administrator can change the user access rights and privileges, add or delete users, update passwords, or update firmware for an entire group of iLO devices. Groups of iLO devices can be managed using HP SIM or CPQLOCFG.EXE and script (batch) files. Appendix A and Appendix B depict specific scenarios to ease mass-configuration of iLO devices and to ease mass-deployment of iLO-based servers, respectively.

HP Systems Insight Manager

Administrators can manage multiple iLO devices through HP SIM by using the following components: Remote Insight board Command Language (RIBCL) an XML-based scripting language Query Definition in HP SIM Custom Command in HP SIM to launch CPQLOCFG.EXE Lights-Out Configuration Utility (CPQLOCFG.EXE). This utility must reside on the same server as HP SIM.
NOTE: The iLO device must be upgraded to firmware version 1.10 (or above) before using this utility. CPQLOCFG.EXE version 2.5 is used for group configuration of iLO.

These components allow an administrator to perform group management of iLO boards. An administrator can also use RIBCL to write scripts that remotely perform a multitude of operations on many servers. For example, an administrator might write a script to remotely upgrade the system BIOS for every server in a rack. The script might instruct the iLO device in each server to do the following: power down the server, download the new BIOS, and then power up the server. With XML-based remote scripting capabilities, every function or task an administrator can do using iLO technology and a web browser can also be done in a secure environment through an XML script running at a remote site. The administrator would perform the following steps to perform a task on a group of iLO devices:
1. Write a RIBCL script file to perform the desired management tasks (such as add a user, delete a

user, or change a user profile). Sample scripts for all iLO commands are available for download from the HP website: http://h18004.www1.hp.com/support/files/lights-out/us/index.html.

2. Perform a device query on iLO devices in HP SIM and save the query list. 3. Set up a Custom Command Task to start CPQLOCFG.EXE on all iLO devices listed in the HP SIM

Management Processor list. The Custom Command can be executed on demand or can be scheduled to run automatically at a specific date and time.

20

4. Specify the script file, query list, and log file destination as parameters to the Custom Command

task. Through HP SIM, CPQLOCFG sends a RIBCL file to a group of iLO devices to manage their user accounts. log file.

5. Each iLO device then performs the action designated by the RIBCL file and sends a response to the

For HP SIM to discover iLO devices and to associate these devices with the host server, the iLOs Data Return configuration parameter must be set to Enabled. Disabled is the most secure setting for this parameter; however, this setting will eliminate all return data from the HP SIM query. The administrator can configure this setting on the SNMP/HP SIM Settings page and preview the data to be returned. The default iLO setting is Enabled.

CPQLOCFG.EXE, HPONCFG.EXE, and script files

HP has developed sample script files that administrators can use with CPQLOCFG.EXE and HPONCFG.EXE to configure and manage user accounts on multiple iLO devices simultaneously. These script files are described in the previous section iLO configuration and in Appendix A. The CPQLOCFG utility is used to provide remote client-side configuration capability. Multiple iLO devices can be accessed from one client device to perform simultaneous configuration and management. The HPONCFG utility provides host-side configuration and management, and can access only the iLO device on the host system it is running on. The advantage of using HPONCFG is that no iLO login is required (the host operating system provides the security), and the network address of the iLO need not be known. For Linux environments, Perl scripts can be used to securely and remotely access iLO devices for configuration and management. Appendix A contains an example Perl script. Sample scripts are available for download. These sample scripts can be used as is, or can be tailored for custom use. Additionally, the HP Lights-Out Online Configuration Utility for Linux (hponcfg RPM) is available for Linux environments. This utility has functionality similar to that of the HPONCFG utility.

CPQLODOS (iLO only)

CPQLODOS is a command-line, host-side configuration utility that is typically used only for the initial configuration of iLO devices. The utility generates a hardware configuration script file that can be used to duplicate the iLO configuration from a source server onto a target server. The iLO DOS Utility is required only for customers who want to use the SmartStart Scripting Toolkit on servers that include an iLO device. For example, an administrator at a central location may want to use the SmartStart Scripting Toolkit to bring a set of iLO devices to a baseline configuration of username and password. Then, when the iLO devices are deployed at remote sites, the local IT administrator can use other methods such as CPQLOCFG to perform detailed configuration over the network.
NOTE: CPQLODOS is intended for initial configuration only. Its scope of configuration is limited, it resets the iLO configuration settings to factory defaults each time it runs and it is unable to configure more than one iLO user account. Therefore, it is suitable only in an initial deployment environment; other methods such as CPQLOCFG are designed to perform subsequent configuration activities.

The CPQLODOS utility is not intended for continued administration; also, it is not supported on Linux operating systems or for use with the Novell NetWare Client. Additional information about this tool is available from the iLO User Guide.

21

Directory services
There are 2 methods that iLO can use to authenticate directory users. The administrator should choose the method that best meets their needs. Method 1 HP extended schema Pros: Provides full access control of all iLO devices from one central location (the directory). Administrators use Role objects within the directory to group users who require the same access rights to iLO. Cons: Requires that the directory schema be extended. Requires that plug-ins provided by HP are installed on the management console, so that new object types can be created and manipulated in the directory.

Method 2 Schema-free Pros: Directory user accounts can be authenticated without extending the directory schema and without installing plug-ins on the management console. Administrators add users to existing or newly created group objects within the directory to give them a specific group of access rights to iLO. Cons: The distinguished name of group objects and specific access rights granted to the groups must be configured on each (every) iLO device that requires access by directory users. This method is only supported with Active Directory. For maximum flexibility and ease of use, this method requires ActiveX to be enabled on client systems that are used to access iLO. Under certain conditions, search contexts must be configured on each iLO, or the users distinguished name may be required to authenticate, see below.

For more information regarding the configuration of directory settings on iLO; see either the HP Integrated Lights-Out 1.80 User Guide or the HP Integrated Lights-Out 2 User Guide, these guides can be found at the HP websites: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00209014/c00209014.pdf and http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00553302/c00553302.pdf respectively. See the Integrating HP ProLiant Lights-Out processors with Microsoft Active Directory integration note found at the HP website: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00190541/c00190541.pdf, for full instructions regarding the configuration of directory groups or extending the directory schema. When authenticating directory accounts to iLO, there are four formats that can be used for the login name: Netbios name: domain\username Email format: username@domain Distinguished name, which is something like: cn=display name, ou=organization unit, dc=domain, dc=com A short name, such that, when combined with any of the search contexts that have been configured, will resolve to the distinguished name.

22

Setting up the directory server The directory server field can be configured with a DNS name or an IP address. The DNS name can be the DNS name of a single server or the DNS name of a domain. This field can be configured with multiple IP addresses or DNS names separated with a comma or space. The directory service may be configured to have a single DNS name that points to multiple TCP/IP addresses. If the directory service is configured for multi-hosting, HP recommends configuring iLO to access the directory server using the DNS name rather than an IP address. This configuration allows iLO to attempt a connection with any address returned in the lookup of the DNS name, which can provide redundancy. This option may be more desirable than using a DNS name that resolves to a single IP address. If the administrator configures the directory server addresses using IP addresses or a single address DNS name, HP recommends never using the host server of an iLO device as the directory server for that iLO device. If the server is down, the directory service is down. For example, if the administrator uses iLO to power off the server, the connection to the directory will be lost. The administrator will be unable to log in using the directory account and will have to use a local iLO account to power on the server remotely. Local versus directory accounts It is important to remember that local iLO user accounts still exist, even after iLO is configured to use directory services. HP recommends using the local accounts only if the directory service has not been configured, if the directory service is unavailable, or if the administrator cannot authenticate to the directory service. To increase security, an administrator using directory accounts may want to disable local accounts or remove them entirely. Customers using a ProLiant p-Class blade server must use a local account when accessing the blade server through the diagnostic cable. Connecting the diagnostic cable to the front of the blade disconnects iLO from the standard network connection, therefore making directory accounts unavailable. The administrator should set up a review process for local accounts on iLO devices that are primarily accessed by directory users. This will help ensure that all local accounts are identified. In the unlikely event that the directory services are unavailable, it may be useful to have an emergency local user account with a tightly controlled password to manage the iLO devices.

HP extended schema method

Administrators that have upgraded to iLO firmware version 1.40 and above can use the HP extended schema method of integration with directory services to authenticate user access and authorize user privileges for groups of iLO management processors. This is beneficial for IT organizations that are already using directories in their network environment and want to integrate their iLO devices into that management scheme. The HP directory-enabled remote management products currently support Microsoft Active Directory running on Windows Server, and Novell eDirectory running on Windows, NetWare, or Linux. Check the following Novell website for currently supported operating systems and versions; http://www.novell.com/products/edirectory/sysreqs.html.

23

Required software To enable directory services using the extended schema method, system administrators must have iLO firmware version 1.40 or above, the iLO Advanced feature set, and the HP Smart Component installation software. The installation software is available for download from the HP website at www.hp.com/servers/ilo and includes the following: Schema Installer, which extends the existing directory schema. Management Snap-in Installer, which provides snap-ins to manage iLO objects in an existing directory-enabled IT environment. Migration Utilities (HPQLOMIG.EXE and HPQLOMGC.EXE), which automate the process of upgrading the firmware. The utilities also configure the iLO management processors (objects), turn on directory authentication, and create the iLO objects in the directory. Migration utilities The HP Lights-Out Migration utility, HPQLOMIG.EXE, includes a graphical user interface (GUI) that provides a step-by-step approach to implementing or upgrading large numbers of management processors. HP recommends using this GUI method when upgrading numerous management processors. The HP Lights-Out Migration Command utility, HPQLOMGC.EXE, offers a command-line approach to migration, rather than a GUI-based approach. This utility works in conjunction with the Application Launch feature of HP SIM. The command-line approach may be preferred for customers that need to configure only a few iLO devices to use directory services. For more information about these migration tools, see the HP Directory Migration Utility User Guide available on the HP website at www.hp.com/servers/ilo. Extending the directory schema The schema is a set of rules that define the directory (in terms of tree structure), object types, object attributes, and relationships. However, the base (or initial) schema does not define all of the objects that can be stored within the directory: For example, the base schema does not recognize an iLO management processor as an object and is not aware of its attributes or relationships. Therefore, the schema must be extended to define the iLO management processor in terms of object classes and attributes within the schema. HP recommends that the administrator carefully review the document Integrating HP ProLiant LightsOut processors with Microsoft Active Directory, available on the HP website at: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00190541/c00190541.pdf, before deploying any iLO management processors within the directory. This schema works on all directories that are compliant with LDAP version 3. When using Microsoft Active Directory and the HP Schema extensions, the administrator must make changes to the directory server before extending the schema. The schema extensions cannot be removed after they are installed. Therefore, it is very important that the administrator understands the changes that will be made before extending the schema. The schema extension tool will require the IP address or DNS name of the server that owns the schema master role. The administrator must use the Active Directory Schema Tool to configure that server to allow schema updates. When deploying iLO to use Microsoft Active Directory with the schema-free method, it is not necessary to install the HP schema extensions as the iLO will use native Active Directory groups. If the Microsoft Active Directory schema has already been extended with the HP schema, this will not prevent iLOs that use the schema-free method from authenticating. Therefore, some iLO devices can be configured to use the HP schema, and others can be configured for the default schema. However, a single iLO device cannot be configured to use both simultaneously.

24

Roles Using role-based access allows the administrator to control user access to iLO objects and the rights and privileges available to them in that role. For example, the administrator might set up a role called local admin and another role called regional admin. Someone defined as having the role of local admin can access only the rights specified for that role (such as login access and Remote Console) and only at specified times (such as from 8:00 a.m. to 5:00 p.m.) and locations (such as from a specific IP address). Roles can model very complex relationships and it is important to remember that users can be grouped into one or more roles. An iLO device object in the directory service may have multiple role objects associated with it. Be aware that a user's total privileges to a device are an accumulation of privileges from all roles associated with the device. One way to simplify role management is to associate existing user groups with roles, and then manage the membership of the groups instead of the membership of the roles. Finally, any role object that is related to the iLO device should be placed in a partition housed on the directory server that iLO is referencing. The iLO device will be reading all of the role objects that manage it; and if iLO has to contact a different server to read the role object, it may result in long latencies or the possibility that iLO cannot read the role object and therefore deny access to a legitimate user.

Schema-free method
Access to iLO can be controlled using directories without requiring schema extensions. This is accomplished using by a login script to get the users login credentials (user name and password) and session information from iLO and combine these into a security cookie. This cookie is then used by iLO to make sure that the user has access to the pages and resources he or she is trying to use. This feature requires a minimum iLO firmware version of 1.80 for iLO or 1.10 for iLO 2. The user authenticates against the Directory, but authorization of iLO privileges occurs locally at the iLO. The iLO must be configured with one or more groups, with each group corresponding to a group in Microsoft Active Directory. Each iLO group is configured to allow specific iLO privileges. When a user attempts to login to iLO, the user credentials are presented to the directory. If the user is authenticated, a list of groups that have this user as a member is returned to the iLO device. The iLO looks up the group(s) in its local group database, and, if found, the privileges associated with the group(s) are established for the user. The local group database on each iLO device can easily be managed using the iLO group configuration tools. However, most of the user administration is managed in the directory. If the Schema-free method is being deployed, it is not necessary to extend the directory schema with the HP schema extensions. If the directory schema has previously been extended, the Schema-free method may also be deployed.

25

The Schema-free method of authenticating directory users is supported only with Microsoft Active Directory. When using this method to authenticate directory user accounts, the Directory Server field on the Directory Settings page on iLO should be configured with one of the following: The DNS name of the domain (domain.com). This setting provides redundancy of directory servers. The DNS name of the directory server, or a list of DNS names of all directory servers separated by a , or a space or both.
NOTE: It is not recommended to specify the IP address of the directory server when iLO is configured to use the Schema-free method unless search contexts are also configured. It will prevent authentication with the username in the form of domain\username or username@domain. If the IP address is specified here, the distinguished name of the user must be provided on the iLO login page or a short name that will resolve to the distinguished name once the search contexts are applied. See the respective iLO Users Guide for more details and information on configuring search contexts.

See the HP Integrated Lights-Out 1.80 User Guide section on maximum login flexibility. The guide is available at the website: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00209014/c00209014.pdf If the client and iLO are in different DNS domains, one of the two might not be able to resolve the directory server name to an IP address. This will prevent a user from authenticating with a login name of domain\username or username@domain, the distinguished name of the user will need to be specified on the login screen.

Deploying headless servers

The use of iLO devices seamlessly enables headless server operation. The term headless refers to running a server without legacy input/output devices such as a keyboard, mouse, or monitor (KVM). Headless servers must be accessed through alternative means, such as network or serial ports. By using iLO rather than local KVM devices, the administrator increases the amount of computing space, reduces cabling, reduces complexity, and increases the security of the computing environment. In a headless server environment, iLO will emulate a PS/2 keyboard. When iLO detects that the server is going through POST, iLO scans for a PS/2 keyboard. If no local PS/2 keyboard is detected, iLO will be the PS/2 keyboard for the server. A consequence of only scanning for a PS/2 keyboard at server POST is that iLO will not implement hot-plug PS/2 keyboard functionality. If a user plugs in a PS/2 keyboard after the server POST, the keyboard will not be detected. If a user unplugs the PS/2 keyboard after the server has gone through POST, but before the OS loads, the OS will be unable to accept keystrokes from the Remote Console. The server must be rebooted to force iLO to rescan for the PS/2 keyboard and use iLO for keyboard input.

26

Unattended server deployment

Using the capabilities of iLO with its Virtual Media, the SmartStart Scripting Toolkit and a network share drive, administrators can deploy a server in a completely unattended fashion (Figure 5). For example, the administrator configures a source server. Then using the SmartStart Scripting Toolkit, the administrator builds a configuration (boot) diskette with script files. This diskette is inserted into a local management workstation, and the administrator logs into the iLO device in the target server. Using the Virtual Floppy functionality of iLO, the administrator can reboot the target server to the Virtual Floppy and run the script file. If the OS image is stored on a network share drive, the administrator can install the complete OS and applications from the share drive.
Figure 5. Server deployment with iLO, the Virtual Floppy, and the SmartStart Scripting Toolkit

Deploying servers using Rapid Deployment Pack

The ProLiant Essentials Rapid Deployment Pack (RDP) gives administrators the ability to easily deploy one or many servers in an unattended, automated fashion. RDP provides a fast, easy-to-use, drag-anddrop solution for deploying standard server configurations and software builds in an automated fashion from a remote console. The Deployment Server function within RDP provides capabilities that incorporate the iLO management features of powering on, powering off, or cycling power on a target server. To use RDP to browse to an iLO management processor and access the iLO interface, complete the following steps:
1. From the Deployment Server Console in RDP, right-click the server. 2. Select Power Control and then RILOE/iLO - Interface as shown in Figure 6. This provides easy

access to the iLO management features.

27

Figure 6. Using RDP to browse to the iLO management interface

Using the Altiris Boot Disk Creator Utility, an administrator can create boot floppies. The administrator can then use these boot floppies with the Virtual Floppy and Virtual Media/universal serial bus (USB) tools to create a bootable image anywhere on the network. The administrator can boot from these virtual floppies and connect to the RDP Deployment Server to complete the installation and deployment process. If a PXE server is available, the administrator can boot into RDP directly via PXE instead of making boot floppies and using Virtual Media. More information is available about RDP from the HP website at www.hp.com/servers/rdp.

Virtual Media/USB support

The Virtual Media functionality of iLO provides remote server access to a local client floppy and CD or to a floppy image available anywhere on the network, at the OS level. The iLO Virtual Media devices are available for all operating systems when the host system is booting. Before the OS loads, the Virtual Media devices are supported through the server ROM. After the OS is booted, a USB-aware operating system will load the standard USB driver that is part of the server OS, without any need for additional HP drivers running on the host server. However, because iLO uses the built-in USB drivers of the operating systems, the level of USB support varies according to the OS. Certain operating systems do not support USB media and therefore do not have access to the Virtual Floppy during system run time. To use the iLO Virtual Media to install a Linux OS, refer to the information in the section titled Linux tips. For more detailed information about OS support, refer to the chapter Operating System USB Support in the User Guide.

28

The Virtual Device may be a physical floppy drive on the client PC, an image file stored on the hard drive of the client PC, or an image file stored on a network drive. For best performance of the Virtual Media, HP recommends using image files stored on the hard drive or on a network drive accessible through a high-speed network link. Additional information about USB support is available at http://h18004.www1.hp.com/products/servers/platforms/usb-support.html.

Scripted Virtual Media

Virtual Media scripting is a method for controlling Virtual Media devices without going through the browser. Scriptable Virtual Media supports insert, eject, and status commands for both floppy and CD-ROM images. For more information on this feature, refer to the HP Integrated Lights-Out 1.70 Scripting and Command Line Resource Guide, available for download from the HP website: http://h20000.www2.hp.com/bc/docs/support/SupportManual/c00294268/c00294268.pdf.

XML scripting
The XML commands enable you to configure Virtual Media in the same manner as the Virtual Media applet. The one exception is that the actual image will be located on a Web server that the iLO can communicate with via the management network. Virtual Media scripting does not support composite devices; it supports only single Virtual Media devices (either Virtual Media Floppy or Virtual Media CD-ROM). The Remote Insight Board Command Language (RIBCL) enables you to write scripts to manage user accounts and to configure settings. These are XML commands common to most Lights-Out Management (LOM) products and servers. Sample scripts for all iLO commands are available for download from the HP website: http://h18004.www1.hp.com/support/files/lightsout/us/index.html. RIBCL scripts are passed to the iLO using the Lights-Out Configuration Utility (CPQLOCFG.EXE), a Windows-based utility that uses a secure connection over the network. The CPQLOCFG utility can be launched from Systems Insight Manager for Group Administration or used independently from a command prompt for batch processing. This utility is available for download from the HP website: http://h18004.www1.hp.com/support/files/lights-out/us/index.html. Version 2.20 or above of CPQLOCFG.EXE is required to configure iLO Directory Settings using RIBCL scripts. Be sure that the Lights-Out Configuration Utility is in a directory referenced by the PATH environment variable. Table 3 identifies the CPQLOCFG.EXE switches and their functions.

29

Table 3. CPQLOCFG.EXE switches Switch -s -f -u -p -l -v Function Determines the iLO that is to be updated. Provides the full path and name of the RIBCL file that contains the actions to be performed. Specifies the user login name. Specifies the user password. Defines where the log file will be generated and what the file name will be. Turns on verbose messaging. If this switch is omitted, a default log file with the DNS name or the IP address is created. Optional Comments The value is either the DNS name or IP address of the target server.

XML examples Below are two examples of XML scripts executed using CPQLOCFG.EXEs command line syntax. CPQLOCFG.EXE calls the XML file using the f switch. Example 1 uses XML file 1 Insert_Virtual_Media.xml and example 2 uses XML file 2 get_vmcd_status.xml. Example 1: cpqlocfg.exe -s 16.100.200.199 -f Insert_Virtual_Media.xml XML file 1: Insert_Virtual_Media.xml <RIBCL VERSION="2.0"> <LOGIN USER_LOGIN="adminname" PASSWORD="password"> <RIB_INFO MODE="write"> <INSERT_VIRTUAL_MEDIA DEVICE="FLOPPY" IMAGE_URL="http://16.100.200.33/images/Floppy/dos.bin"/> </RIB_INFO> </LOGIN> </RIBCL> Example 2: cpqlocfg.exe -s 16.100.200.199 -f get_vm_status.xml XML file 2: get_vm_status.xml <RIBCL VERSION="2.0"> <LOGIN USER_LOGIN="user" PASSWORD="password"> <RIB_INFO MODE="read"> <GET_VM_STATUS DEVICE="CDROM"/> </RIB_INFO> </LOGIN> </RIBCL>

CLP scripting
HP has worked with key industry partners within the Distributed Management Task Force, Inc, to define an industry-standard set of commands. iLO 1.70 implements the command set defined in the Server Management Architecture for Server Hardware (SMASH) Command Line Protocol (CLP) Specification, 1.00 Draft. Either SSH or Telnet access to iLO supports the CLP, which can invoke a Remote Console connection as well as a Virtual Serial Port connection.

Do not use this switch if you are launching from Systems Insight Manager. Systems Insight Manager will provide the address of the iLO when CPQLOCFG.EXE is launched.

30

The oemhp_image value is a URL. The URL is limited to 80 characters, specifies the location of the virtual media image file on a HTTP server, and is in the same format as the scriptable virtual media image location. CLP examples Insert a floppy image into the virtual floppy for immediate connection: cd /map1/oemhp_vm/floppydr show set oemhp_image=http://my.imageserver.com/floppyimg.bin set oemhp_boot=connect show Insert a CDROM image into the virtual CDROM, set for it to connect on all subsequent boots: cd /map1/oemhp_vm/cddr show set oemhp_image=http://my.imageserver.com/ISO/install_disk1.iso set oemhp_boot=always show Insert a CDROM image and set for single boot on the subsequent boot: cd /map1/oemhp_vm/cddr set oemhp_image=http://my.imageserver.com/ISO/install_disk1.iso set oemhp_boot=once show Eject a CDROM image from the virtual CDROM, disconnect the media, and clear oemhp_image: cd /map1/oemhp_vm/cddr set oemhp_boot=disconnect

Scripting Web server requirements

Virtual Media scripting uses a media image that is stored and retrieved from a Web server accessible from the management network. The web server must be an HTTP 1.1 compliant server that supports the Range header. Valid diskette images are raw disk images and can be produced by using any of the following utilities: iLO Virtual Media applet UNIX utility - dd DOS utility - rawrite CPQIMAGE utility CD-ROM images must be ISO-9660 type file system images; no other types of CD-ROM images are supported.

31

Using RILOE-II in an iLO server (iLO only)

RILOE II and iLO cannot be simultaneously used in the same host. The RILOE II board is supported as an option in servers with iLO. With current iLO firmware, iLO automatically recognizes when a RILOE II board is installed in the host server and disables itself. If the administrator subsequently removes the RILOE II board, iLO remains disabled. Re-enable the iLO functionality by using the iLO Security Override Switch:
1. Turn off server power and unplug the power cord to turn off auxiliary power. 2. Enable the iLO Security Override Switch according to the server manual instructions. 3. Power on the server. 4. The server will go through POST and show the following:

iLO security override switch is set. ILO security is disabled!

5. When prompted to do so, press F8 to enter iLO ROM-Based Setup Utility (RBSU). 6. Navigate to the Configure Tab. 7. Set iLO to Enabled.

With the exception of the ProLiant DL560 server, all iLO-enabled servers recognize RILOE II boards automatically. If an administrator wants to use a RILOE II board in a ProLiant DL560 server, the administrator must manually disable the iLO functionality before inserting the RILOE-II board. The iLO functionality can be disabled in either of two ways: Set the Enabled Lights-Out Functionality Global Setting to No. In the iLO RBSU, navigate to the Configure Tab and set iLO to Disabled.

Linux tips
The following tips may be helpful for users of Linux operating systems.

Telnet support
As discussed in the section titled Enhancing security the configuration of the Remote Console port affects the ability to conduct a Telnet session. Because Telnet sessions connect to port 23 (the Remote Console port), an administrator that has disabled the Remote Console port or set the Remote Console port to auto-enable will not have Telnet support. Telnet support is available only when the Remote Console port is enabled and Remote Console encryption is disabled.

32

Kickstarting Linux OS with Virtual Floppy

If the OS on the host server contains USB support, the iLO Virtual Floppy functionality is available when the host system is booting. For versions of Linux that do not include a USB floppy driver, there is a way to successfully perform a kickstart install using a Virtual Floppy image. To do that, complete the following steps:
1. Install the kickstart file, KS.CFG, into the INITRD.IMG file. This can be done using software

utilities. An example of such a utility is the rdstuff utility, available from http://sourceforge.net/projects/rdstuff/. 2. Put the INITRD.IMG file back onto the floppy. 3. Edit the SYSLINUX.CFG file as follows: default ks label ks kernel vm linux append ks = file:/ks.cfg initrd=initrd.img 4. Proceed with the creation of the Virtual Floppy image. With the kickstart file embedded into the initrd.img file, the Linux OS can use the Virtual Floppy.

33

Appendix A
Using barcode scanning to ease mass-configuration of iLO devices
Each iLO device ships with a unique password for the default Administrator account to provide maximum security for the device. Default account information is located on the iLO Default Network Settings tag attached to the server containing the iLO management processor. The iLO ships with DHCP enabled by default, and with a pre-programmed DNS name. In a customer environment that utilizes DHCP, iLO can be configured out of the box by using the default DNS name to contact the device and the unique password for the default Administrator account to login. Mass configuration and deployment tasks can be eased by taking advantage of the barcodes attached to each server. Using a bar code scanner to deploy multiple iLO devices requires the following: Bar code scanner Perl interpreter DHCP server Lights-Out Configuration Utility (CPQLOCFG.EXE file which connects to each iLO- enabled server) ilodply.pl (Perl script which calls the other XML scripts) ilotpl.xml (template XML file for initial setup of iLO devices) Other sample script files include: upgrade.xml (template file for sending new firmware images to iLO devices) deluser.xml (template file for deleting users from the database) These sample script files are available from the website at: http://h18004.www1.hp.com/support/files/lights-out/us/index.html

Command-line switches
Below is an example of the Perl script command: perl ilodply.pl -[s|i|m] <dnsfile.*> <file.*> -d <dnsSuffix>
Table 4. Perl script command-line switches Switch -s Function Switch to scan/enter management processor information. Switch to initially set up a group of management processors. Switch to send an XML script to a group of management processors. Switch to specify a DNS suffix. Comments The desired new DNS names should be located in the file specified by <dnsfile.*>. The scanned information including the new DNS name will be saved to the file specified by <file.*>. The processor information including the new DNS names should be located in the file specified by <dnsfile.*>. The template XML script ilotpl.xml should be specified by <file.*>. The DNS names of the management processors to receive the script should specified in <dnsfile.*>. The XML script to send to each processor should be specified in <file.*>. Optional - The DNS suffix of the domain where the management processors will reside should be specified in <dnsSuffix>. The DNS suffix should omit the beginning period; for example, -d hp.internal.lab.

-i

-m

-d

34

Deploying iLO devices

To deploy a group of new management processors, do the following: Create a file, websrv.dns, that includes the desired DNS name for each management processor. HP recommends that the administrator change the default DNS name to something more easily remembered. Each DNS name in the file should be followed by a carriage return, as shown below. If the default DNS name is desired, create a blank file or create the DNS file by scanning all of the default DNS names from the iLO network settings tags. discostus_lab moestavrn_lab joesgrill_lab Invoke ilodply.pl with the following command line options to save the management processor information to a new file called websrv.txt. perl ilodply.pl -s websrv.dns websrv.txt The Perl script automatically prompts the user for the serial number, default DNS name, password, and Advanced License key for each iLO device. Use the bar code scanner to enter the appropriate information from the iLO network settings tag. If the user desires to use the default DNS name and has created a blank file, the Perl script will prompt for both the default DNS name and the new DNS name. Simply scan the default DNS barcode twice from the network settings tag. The ProLiant p-class BL servers include the advanced license key. Press Enter when prompted for a license on a blade server; otherwise, the XML script will not be executed on the designated server. The Perl script then creates the new websrv.txt file containing all the pertinent iLO information in a single file. If desired, modify the XML template script, ilodply.xml, with any extra options desired for each processor. Now, all management processors defined in websrv.txt can be set up with the XML script, ilotpl.xml, by invoking ilodply.pl with the following command line options: perl -i websrv.txt ilotpl.xml-d nuclear.plant To verify that an XML script executed correctly on a particular management processor, the log file generated by CPQLOCFG.EXE can be viewed. The log file is the DNS name of the management processor receiving the XML script.

Updating iLO devices

To upgrade the firmware on a group of management processors, follow the same procedures as in the deployment script, but invoke the Perl script using the m switch and an XML script such as upgrade.xml. The -m switch can be used to send other XML scripts for maintenance purposes. This is helpful in situations where a user needs to upgrade system firmware, add or delete users, etc. For instance, to upgrade a group of management processors specified in websrv.txt, invoke the Perl script ilodply.pl with the following command line options: perl -m websrv.txt upgrade.xml -d nuclear.plant

35

Appendix B
Using a RAM drive to ease mass-deployment of iLO-based servers
Mass deployment and configuration of operating systems to iLO-based servers can be accomplished in a variety of different ways. One method that can be utilized to ease the task and save time is to utilize the virtual media feature of iLO. Using the iLO scriptable virtual media feature, a virtual media server can be established to house operating system deployment images. Alternatively, a virtual floppy image can be created to boot the server and prepare for an operating system deployment. This method is discussed below. Using the method described in this section, an iLO virtual floppy image can be stored and shared on a single share point, yet accessed by a number of servers for deployment unique to the server, without having to modify the virtual floppy image contained on the share point. Because each deployed server will be installed with a slightly different or unique virtual image, the virtual image typically must be modified to specify the unique items such as IP addresses, server names, etc. This modification of the shared virtual image is undesirable and can be avoided by using a RAM drive in association with the virtual floppy image. To prevent the server-unique changes from having to be written back to the shared virtual floppy image, the deployment process can create a RAM drive in the server memory where a copy of the virtual floppy image can be maintained during deployment of the specific server. The server-unique changes can be maintained in the RAM drive copy, rather than contaminating the shared master copy that is contained on the share point. An additional advantage of this technique is that a greater level of automation can be achieved. Other methods require a person to manually enter server-specific information at a prompt during deployment; however, this method allows a setup file to contain server-specific information, which is mapped to an individual server using the server MAC address as a key.

Overview
A virtual floppy image can be created such that the server will boot to Microsoft DOS, prepare a RAM drive to allow a space for a copy of the virtual floppy image to be stored, and provide a writeable image in memory such that the virtual floppy image need not be modified during the deployment process.
NOTE: The method described below is only an example. It should be modified to allow its use in a custom environment.

The Master Boot Diskette

First, create a bootable DOS floppy diskette. Create a config.sys file that contains the following: files=20 BUFFERS=10 device=a:\ifshlp.sys DEVICE=A:\HIMEM.SYS DOS=HIGH,UMB DEVICEHIGH=A:\RAMDRIVE.SYS 1496 /E STACKS=9,256 LASTDRIVE=Z

36

Create an autoexec.bat file that contains the following: path=c:\;c:\net;c:\batch;a:\ c: md c:\net md c:\batch copy a:\batch\*.* c:\batch\*.* c: a:\pkunzip -d a:\net.zip REM Launch the process c:\batch\cpqlodos /get_nicconfig > c:\batch\ilo.txt c:\batch\SETUPNET.EXE c:\batch\mapping.txt C:\net c:\batch\ilo.txt c:\batch\ghst.bat > c:\batch\setvars.bat c:\batch\netstart The process expands the entire net and batch directories (that come with making a diskette with CPQIMAGE.EXE ) into the RAM drive. The SETUPNET.EXE is a 'C' executable that reads through the mappng.txt file and creates a protocol.ini, system.ini ( which needs a unique NetBIOS computer name, for example, TSXXXXXX where XXXXXX are the 6 'non-vendor' MAC address characters ) and a batch file that maps a drive to the specified image location and launches GHOST with command lines that fully automate the image upload. Then, GHSTWALK is run with command lines that change the SID and computer name. Below are a few lines from the mapping.txt file. This file is 'space' delimited. The first parameter is the reversed MAC address so that it matches the output of CPQLODOS.EXE. The next parameter is the computer name. The next parameters are: IP parameters, Drive letter to map, Share point, Image Path, Citrix Farm, Citrix Zone. Only IP and Image info is used in the DOS portion. This same file is used once the OS is booted as well, to set the IP, computer name, Citrix farm, and Citrix zone. 04:75:a2:02:08:00 SERVERNAME-A 192.168.0.10 255.255.255.0 \\sharepoint-a\image$ \CPP\G2\CPP0001.GHO MPS MN-Zone1 34:6c:a2:02:08:00 SERVERNAME-B 192.168.0.11 255.255.255.0 \\sharepoint-a\image$ \CPP\G2\CPP0001.GHO MPS MN-Zone1 78:54:ee:02:08:00 SERVERNAME-C 192.168.0.12 255.255.255.0 \\sharepoint-b\image$ \CPP\G2\CPP0001.GHO MPS MN-Zone1 18:67:a2:02:08:00 SERVERNAME-D 192.168.0.13 255.255.255.0 \\sharepoint-b\image$ \CPP\G2\CPP0001.GHO MPS MN-Zone1 fc:5e:ee:02:08:00 SERVERNAME-E 192.168.0.14 255.255.255.0 \\sharepoint-c\image$ \CPP\G2\CPP0001.GHO MPS MN-Zone1 3e:72:ee:02:08:00 SERVERNAME-F 192.168.0.15 255.255.255.0 \\sharepoint-c\image$ \CPP\G3\CPP0001.GHO MPS MN-Zone1 20:fe:f1:02:08:00 SERVERNAME-G 192.168.0.16 255.255.255.0 \\sharepoint-d\image$ \CPP\G3\CPP0001.GHO MPS MN-Zone1 10.91.197.1 R: 10.91.197.1 R: 10.91.197.1 R: 10.91.197.1 R: 10.91.197.1 R: 10.91.197.1 R: 10.91.197.1 R:

37

The Custom Deployment Tool

In this example, a custom deployment tool named SETUPNET.EXE was created to handle the installation parameter mapping for each individual deployed server. The main responsibility of the SETUPNET.EXE is to use the servers MAC address (obtained via the CPQLODOS query) to index into the mapping.txt file and pull the installation parameters that are unique to the specific server, and to create protocol.ini and system.ini files on the RAM disk based on the obtained information. Once this information has been written to the initialization files (protocol.ini and system.ini), the operating system installation on this server can proceed. Note that this method can be modified to incorporate additional or different setup/configuration information for the specific desired operating system deployment. The information content is simply placed into the mapping.txt file, on the line that pertains to the specified server. This method allows the deployment operation to be fully automated, such that it can proceed unattended and at fullspeed. Note that this example utilized parameters for IP address; in an environment that incorporates a DHCP server, these parameters would not be needed.

38

For more information

Table 5. For additional information, refer to the resources listed below. Resource description Integrated Lights-Out Documentation Includes links to the Integrated LightsOut security paper, Integrated LightsOut user guide, and other documents related to iLO Directory support on Lights-Out management products HP Systems Insight Manager Web address http://h18004.www1.hp.com/products/servers/management/ ilo/documentation.html

http://h18004.www1.hp.com/products/servers/management/ directorysupp/index.html www.hp.com/go/hpsim

Call to action
To help us better understand and meet your needs for ISS technology information, please send comments about this paper to: TechCom@HP.com.

2003, 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein. Microsoft, Windows, and Windows NT are U.S. registered trademarks of Microsoft Corporation. TC060403BP, 04/2006