|
[an error occurred while processing this directive]
|
|
|
|
Archived Windows Edition 1.xx - 2.xx Articles
|
Applies to: Releases 1.xx and 2.xx
To install Linux on target servers using a scripted install job,
the ProLiant Integration Module on the NFS Server must be installed on an
operational Linux NFS Server. A single NFS Server can be used to deploy multiple Linux
distributions. Be sure that the hardware and software of the NFS Server meets
the minimum requirements as specified in the appropriate Rapid Deployment Pack
version installation guide including allocating enough file space for /usr
where the ProLiant Integration Module files will be placed.
To create a Red Hat Enterprise Linux 3 or Red Hat Enterprise Linux 4 NFS Server:
| 1. |
Boot the first Red Hat distribution CD.
|
| 2. |
Follow the on-screen installation instructions, noting the following setup options:
| a. |
At the Network Configuration screen, be sure to configure a static IP address
and the Miscellenous Settings.
|
| b. |
At the Firewall Configuration screen, select No firewall. If a firewall
is required, enable the appropriate ports for NFS. NOTE: For Enterprise Linux 4, the
firewall port settings are configured after the installation.
|
| c. |
At the Package Installation Defaults screen, select Customize software packages
to be installed. The Package Group Selection screen appears. Leave the default package
groups selected and for HP ProLiant Support Pack support, additional select
| |
For Enterprise Linux 3: Development Tools, Kernel Development,
X-Software Development, Gnome Software Development,
Legacy Software Development, and System Tools.
|
| |
For Enterprise Linux 4: Development Tools, X-Windows Development,
Gnome Software Development, Legacy Software Development, and
System Tools.
|
|
|
| 3. |
Install the HP ProLiant Support Pack (PSP) on the NFS Server by either
| |
downloading them from www.hp.com,
|
| |
mounting the SMB share on the Deployment Server and obtaining the appropriate PSP from
.\lib\software\, or
|
| |
mounting the Rapid Deployment Pack CD and obtaining the appropriate PSP from
/pim/lib/software.
|
|
| 4. |
Insert the Rapid Deployment Pack CD, and install the ProLiant Integration Module on the NFS Server.
|
To create a SUSE LINUX NFS Server:
| 1. |
Boot the first SUSE LINUX distribution CD.
|
| 2. |
Follow the on-screen installation instruction, noting the following setup options:
| a. |
At the YaST Installation Settings screen, note the following setup options:
| |
The default file system for SUSE is reiser. If you intend to keep an image
of the NFS server using RDP, you need to choose either ext2 or ext3
as the file system. Altiris' rdeploy utility does not support the reiser filesystem.
|
| |
For software selection in addition to the default software selections, also select
File Server (NFS, Samba).
|
| |
For HP ProLiant Support Pack support, use the package search feature
and search on kernel. Select the kernel-source package.
|
|
| b. |
At the Network Configuration screen, click on Network interfaces and configure the NIC
with a static IP, a hostname and Domain name, and enter Name server IP and Domain Search.
|
| c. |
Verify that no firewall is installed. However, if a firewall is required then enable the
appropriate ports for NFS after the installation.
|
|
| 3. |
Follow steps 3 and 4 from the Red Hat Enterprise Linux steps above to install the HP ProLiant Support Pack and
the Rapid Deployment Pack HP ProLiant Integration Module.
|
|
|
Applies to: All releases
The display name is the name shown in the Deployment Server Console. The computer name is the name
of the target server. The display name and computer name are two separate fields in the Deployment Server
database and are not always the same value. The information in this article describes how the
display name and the computer name fields are populated depending on the Deployment Server options,
the Deployment Agent, and the method the operating system is installed on the target server.
When a Server Connects to Deployment Server for the First Time:
Using the Deployment Agents (DOS, Windows, or Linux) under automation, either by way of PXE or a boot diskette, it is
added to the New Computers group. The initial display name:
-
for ProLiant ML/DL and Integrity rx servers is based on the Primary Lookup Key. The Primary
Lookup Key could be defined as the MAC Address, Serial Number, UUID, or Asset
Tag. The initial computer name is the same value as the initial display name.
-
for HP BladeSystem servers, the initial display name is the concatenation of the Rack
name, Enclosure name, and Bay number, for example,
UnnamedRack-HP-1.
The initial computer name is the last 15 characters of the initial display name.
-
for VMware ESX virtual machines and with the Primary Lookup Key defined as Serial Number,
the initial display name will be of form,
VMware-XX XX XX XX XX XX where
XX XX XX XX XX XX is a hexadecimal string including spaces. Spaces in the name
are not NETBIOS compliant for Windows scripted installs. For Releases 2.20 and greater,
the spaces will be removed automatically during the scripted install by code in the default unattend text file.
With previous releases, the name must be changed at the console without the
spaces before performing the Windows scripted install. The initial computer name is the same value
as the initial display name.
-
for Microsoft Virtual Server virtual machines and with the Primary Lookup Key defined as Serial Number,
the initial display name will be the virtual machine serial number. The initial computer name is the same value
as the initial display name.
-
NOTE: There is a database limitation that could cause the beginning of the name to be truncated if
the name is greater than the number of characters allowed for that database field.
Using the Deployment Agent for Windows (aclient) under production, it is added to the New Computers group.
The initial display name is the actual computer name.
Using the Deployment Agent for Linux (adlagent) under production, it is added to the New Computers group.
The initial display name is the actual hostname.
When a Server is Deployed:
Using a Windows scripted install job,
the default behavior as of Release 2.00 will set the computer name to
the last 15 characters of the display name. If the Synchronize the
display name with computer names option is enabled,
the display name will change to the computer name.
Using a Linux scripted install job,
the default behavior as of Release 3.00 will set the computer name
(hostname) to the display name.
Using a VMware ESX scripted install job,
the default behavior will set the computer name (hostname) to the DNS name if DNS has been configured,
or localhost. If the Synchronize the
display name with computer names option is enabled,
the display name will change to the hostname.
Using an image deploy job,
the computer name will be set to the value of the computer name database field.
The provided deploy image install jobs have the
Automatically perform configuration task after completing this imaging task
option enabled. If this option is not enabled, the computer name will be a duplicate of
the computer name in the image.
If the Synchronize the display name with computer names option is enabled,
then the display name will change to the computer name.
|
|
Applies to: All releases
To resolve this issue, upgrade the firmware of the RILOE to
version 2.40 or later. For firmware downloads and documentation, refer to:
www.hp.com/servers/lights-out.
|
|
Applies to: Releases 1.xx and 2.xx
ProLiant servers using ROM-Based Setup Utility (RBSU) 1.0 or earlier (System Config-based
systems) do not have the ability to bypass the F1 prompt when the server is unconfigured.
To resolve this issue during a PXE-based boot, use RILOE, iLO, or
the local console to press the F1
key. To resolve this issue during a diskette-based boot, use the SIGNDISK
utility in the SmartStart Scripting Toolkit.
|
|
Applies to: Releases 2.00 through 3.50
Add the following code to the Red Hat Enterprise Linux 3 kickstart file before
performing a Linux scripted install.
cat >> /etc/fstab << EOF
device mountpoint auto mountoptions 0 0
EOF
mkdir -p mountpoint
where
device is the device,
mountpoint is the device mount point, and
mountoptions is the mount options separated by commas.
Examples:
| |
to include a virtual floppy drive with /media/vfloppy as the mount point:
/dev/sda /media/vfloppy auto noauto,user 0 0
|
| |
to include a virtual USB drive with /media/vusb as the mount point:
/dev/sda /media/vusb auto noauto,user 0 0
|
| |
to include a virtual cd-rom drive with /media/vcdrom as the mount point:
/dev/scd0 /media/vcdrom auto pamconsole,fscontext=system_u:object_r:removable_t,exec,noauto,managed 0 0
|
|
|
Applies to: Release 1.40 through 2.20
The script called to create or join the cluster in the Packaged
Cluster deployment jobs resets the IP address of the private NIC in each cluster
node. During deployment, the private NIC on the secondary node can temporarily
be assigned the same IP address as the primary node. This is resolved when the
secondary node joins the cluster and will not affect cluster functionality.
|
|
Applies to: Releases 1.xx and 2.xx
The Linux NFS Server may drop its network connection on ProLiant
servers using an Intel-based NIC and the eepro100 driver (the default driver
loaded by Linux).
To resolve this issue, use the e100 driver instead of the eepro100 driver on the NFS server:
| 1. |
If necessary, install the e100 driver for the appropriate kernel. |
| 2. |
Edit the /etc/modules.conf file changing all occurrences of eepro100 to e100. |
| 3. |
Reboot the server. |
|
|
Applies to: All releases
Most ProLiant and Integrity servers support the one-time boot to PXE; however, a few
servers including virtual machines need to have PXE or Network Boot first
in the BIOS boot order. The platforms that require PXE or Network Boot first
in the boot order are:
| |
ProLiant DL100 series, such as DL140 G2 and DL145 G2 |
|
ProLiant DL320 (first generation) with PXE enabled (PXE is disabled by default) |
| |
ProLiant DL360 (first generation) with PXE "User Interface" disabled, otherwise only
boots PXE when F12 key is pressed. |
| |
Microsoft Virtual Server virtual machine |
| |
VMware ESX Server virtual machine |
|
NOTE: With Release 3.50 and greater, if a Create Virtual Machine toolbox job
is used, it will set Network Boot first in the boot order.
|
IMPORTANT: Never change the boot order of the Menu Items
listed under the Boot Configuration tab of the PXE Configuration
Utility. This will not impact the server boot order, but causes problems with
the ability of the PXE server to select the correct boot image.
|
|
Applies to: Releases 1.xx and 2.xx
This error is caused by a known issue when using 2.88-MB PXE
images based on Win95a DOS. This version of DOS is not compatible with 2.88-MB
images.
To resolve this issue, either:
| |
Use a later version of Windows 95 or Windows 98 as the DOS file source.
|
| |
Do not use the 2.88-MB image option when creating PXE images based on Windows 95a.
|
|
|
Applies to: Release 1.40 through 2.20
PXE is only enabled by default on NIC1 for ProLiant DL380 G2 and
G3 servers. Ensure that NIC2 in each node is cabled as the heartbeat/cluster
interconnect and that NIC1 in each node is cabled as the public network
(visible to the Deployment Server).
This configuration is recommended for Packaged Clusters using the Rapid Deployment
Pack and PXE, even though this is contradictory to the information provided in
the Packaged Cluster documentation.
|
|
Applies to: Releases 1.xx and 2.xx
The ProLiant DL320 (first generation) server allows a connection to a PXE server by
means of an embedded NIC. The server defaults to disabling PXE support on the
embedded NIC.
To enable PXE support:
| 1. |
Press the F9 key when prompted during the system POST to run the ROM-Based Setup Utility (RBSU). |
| 2. |
Select Advanced Options, and press the Enter key. |
| 3. |
Select PXE Options, and press the Enter key. |
| 4. |
Select Embedded PXE Support, and press the Enter key. |
| 5. |
Change the option to Enabled, and press the Enter key. |
| 6. |
Select User Interface, and press the Enter key. |
| 7. |
Change the option to Disabled, and press the Enter key to cause the server to automatically boot to the network instead of requiring pressing the F12 key. |
| 8. |
Press the Esc key to exit each menu and RBSU. |
| 9. |
Press the F10 key to confirm that you wish to exit. |
NOTE: The server does not display the F12 prompt when PXE is disabled, regardless of the setting for User Interface.
|
|
Applies to: Releases 1.xx and 2.xx
The ProLiant DL360 (first generation) server allows a connection to a PXE server by
means of embedded NICs. The server defaults to disabling PXE support on the
embedded NICs.
PXE support on the ProLiant DL360 server requires a system ROM
(P21) dated later than 08/03/2001
and version 2.53 or later of the System Configuration Utility.
PXE support can be enabled for either of the embedded NICs.
However, PXE support cannot be enabled for both NICs at the same time. Enable
PXE support for the NIC connected to the network containing the PXE server.
Unlike the ProLiant DL320 server, the ProLiant DL360 server always attempts to boot
from the network. The only way to modify the default boot order is by using the
stbtordr.exe utility found in the SmartStart Scripting Toolkit. PXE boot order
is not configurable through the System Configuration Utility.
To enable PXE support:
| 1. |
Press the F10 key during system POST to run the System Configuration Utility. |
| 2. |
At the HP logo screen, press any key to continue. |
| 3. |
Select System Configuration, and press the Enter key. |
| 4. |
Select Hardware Configuration, and press the Enter key. |
| 5. |
Press the Enter key to continue through the Configuration Changes screen. |
| 6. |
Select Review or modify hardware settings, and press the Enter key. |
| 7. |
Select Step 3: View or edit details, and press the Enter key. |
| 8. |
Select the appropriate NIC, and press the Enter key. |
| 9. |
Modify the setting using the up or down arrow keys, and press the Enterkey. |
| 10. |
Press the F10 key to exit this screen. |
| 11. |
Select Step 5: Save and exit, and press the Enter key. |
| 12. |
Select Save the configuration and restart the computer, and press the Enter key. |
|
|
Applies to: Release 1.40 through 2.20
Occasionally the secondary node successfully completes the Create Shared
Partitions task, but pauses on the following Power Control Task.
To resolve this issue, right-click on the failed job and select Retry Task.
|
|
Applies to: Release 1.40 through 2.20
Intermittently, an error occurs when determining the node roles (primary or secondary)
for Packaged Cluster deployment. This prevents either
node from being assigned the primary node role and both nodes act as the
secondary.
To resolve this issue, restart the Packaged Cluster deployment job.
|
|
Applies to: Release 1.40 through 2.20
The Packaged Cluster deployment jobs for Windows (image and scripted)
require a domain administrator level username and password for the
Run Script - Create/Join Cluster task. In Windows 2000 deployments, the job pauses
during the Run Script - Create/Join Cluster task waiting
for a valid user name, domain, and password in order to join the cluster.
To resolve this issue, on the Deployment Server, cancel the Packaged Cluster deployment
job. Using a remote management technology such as iLO, RILOE or Terminal
Services, cancel the cluster installation on the cluster node. Update the
Run Script - Create/Join Cluster task in the Packaged Cluster deployment job with a valid
user name, domain, and password by using the Specify user button in the task.
Retry the task on the failed node.
|
|
Applies to: Releases 1.xx and 2.xx
After performing an system erase on a ProLiant DL380 server, a ProLiant
DL580 server, ProLiant ML370 server, ProLiant ML530 server, or a ProLiant ML570
server, you are prompted to select the operating system for which to configure
the server during the next POST. If you select an operating system other than
UnixWare and then Linux, a server with two processors may not be configured to
use both processors in the operating system, regardless of using the Symmetric
Multiprocessing (SMP) kernel.
To resolve this issue, when prompted during POST, select UnixWare and then Linux
as the operating system.
|
|
Applies to: Releases 1.xx and 2.xx
After performing an system erase on a ProLiant DL 580 server, ProLiant
ML 370 server, ProLiant DL 380 server, or ProLiant ML 570 server, you are
prompted during the next POST to select the operating system for which to
configure the server. If you select an operating system different than the one that
is deployed, the server hangs at the first operating system boot because the
system BIOS settings are not correct.
To resolve this issue, when prompted during POST to select an
operating system, select the same operating system that will be deployed.
|
|
Applies to: Releases 1.xx and 2.xx
The 4-GB memory boundary is special because to some DOS programs,
such as emm386.exe, it appears as if there is no memory at all.
To resolve this issue, in Boot Disk Creator, REM out the emm386.exe statement
in the config.sys file for
all applicable configurations and regenerate the PXE images or boot diskettes.
NOTE: The emm386.exe statement is commented out by default.
|
|
Applies to: Releases 1.xx and 2.xx
This error is caused by one of the following:
| |
When a DOS-embedded script or batch file is
executed, the Bootworks program is loaded in a DOS command shell and the
commands are executed within that environment.
To resolve this issue,
use the REM BOOTWORK UNLOAD statement within the embedded script or batch file.
This statement causes Bootworks to unload from memory freeing up approximately
80 KB. After the embedded script or batch file ends, Bootworks reloads and task
processing continues.
|
| |
Some DOS programs, such as Windows 2003
winnt.exe, have a large memory footprint. Systems with Broadcom-based NICs and
older PXE firmware do not have enough available memory to run the program.
To resolve this issue,
update the system ROM and/or NIC option ROM to get version 3.1.15 or later of the PXE
firmware, or use the Broadcom Q57.DOS NDIS2 driver version 3.07 or later.
|
|
|
Applies to: Releases 1.xx and 2.xx
When a DOS embedded script or batch file is executed, the
Bootworks program is loaded in a DOS command shell and the commands are
executed within that environment. When the task ends, so does the Bootworks
environment causing the loss of the variables defined within the task.
To resolve this issue, use the REM BOOTWORK UNLOAD statement
within the embedded script or batch file. This statement causes Bootworks to
unload from memory thus allowing execution within a normal DOS environment.
|
|
Applies to: Releases 1.xx and 2.xx
There are many reasons why this error may occur. Some possible reasons are:
| |
The Deployment Server hostname cannot be
resolved because either there is no WINS service or no entry in the LMHOST
file.
|
| |
The Deployment Server and target server are on
different subnets and no network route exists between them.
|
| |
The permissions on the eXpress share on the
Deployment Server changed and the default account no longer has access rights.
|
| |
You are using a non-default account in the PXE
images or boot diskettes to access the eXpress share on the Deployment Server
and it either doesn't have the correct permissions or has the User must change password at next logon
option selected.
|
|
|
Applies to: All releases
No, Microsoft Windows 2000 Dynamic Disks are not
currently supported by the Altiris imaging tool.
|
|
Applies to: All releases
No, the provided jobs, scripts, and configuration files do not
provide support for ProLiant pre-ML/DL servers. However, the SmartStart
Scripting Toolkit for DOS version 1.7 and earlier does provide support for capturing
and deploying the hardware configuration of these servers. Those familiar with
the SmartStart Scripting Toolkit can modify the provided jobs, scripts, and
configuration files to support older servers.
|
|
Applies to: Releases 1.xx and 2.xx
No, the provided jobs, scripts, and configuration files do not
provide support for configuring the ATA RAID capability of the ProLiant ML330
G2 server. However, the SmartStart Scripting Toolkit does provide the HYPERCFG
utility for configuring ATA RAID on the ProLiant ML330 G2 server. Those
familiar with the SmartStart Scripting Toolkit can modify the provided jobs,
scripts, and configuration files to use the HYPERCFG utility.
|
|
Applies to: Releases 1.xx and 2.xx
Rapid Deployment Pack supports image capture and deployment
of Microsoft Windows NT 4.0. It does not support scripted installations.
However, the SmartStart Scripting Toolkit does provide support and examples for
installing Windows NT 4.0. Those familiar with the SmartStart Scripting Toolkit
can modify the provided jobs, scripts, and configuration files to support
Windows NT 4.0.
|
|
Applies to: Releases 1.xx and 2.xx
No, DOS versions other than the Windows 9x (Windows 95 OSR2 or higher, or Windows 98)
may not work with the SmartStart Scripting Toolkit utilities.
|
|
Applies to: Releases 1.xx and 2.xx
The utilities in the SmartStart Scripting Toolkit for DOS are DOS
programs and thus only use 8.3 file names.
To resolve this issue, use 8.3 compliant names for the output files.
|
|
Applies to: Releases 1.xx and 2.xx
The target server may experience a file lockup during the blue
screen file copy phase of the Windows unattended install when the target server
is connected to the Deployment Server on a gigabit network. The following error
message displays:
Unattended Windows installation: Setup was unable to copy the following file: "misc.file"
Press ENTER to retry the copy operation.
Press ESC to ignore the error and continue Setup.
Press F3 to exit setup
To resolve this issue, either:
| |
Press the Enter key several times until the file copy succeeds, or
|
| |
On the Deployment Server, open up the Properties dialog for the
gigabit NIC, go to the Advanced tab and change the
Offload Transmit TCP Checksum setting to Off.
|
|
|
Applies to: All releases
Some companies institute domain security policies that enable a
logon banner, or an extra dialog box that displays between the execution of the
Ctrl+Alt+Delete keys and the login
dialog box. This logon banner causes a scripted install using a slipstream
Windows 2000 with Service Pack 2 to pause at the dialog box and wait for
interaction.
To resolve this issue, either:
| |
Use a non-slipstreamed version of Windows 2000 and apply any service packs later, or
|
| |
Do not add the server into the domain during the scripted installation.
|
|
|
Applies to: All releases
NOTE: For related information, refer to the Microsoft Knowledge Base Article found at:
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q262688.
This situation occurs when Windows discovers additional adapters
or PCI devices that are interpreted as network adapters (infrared devices or
possibly the RILOE board) after setting the initial network configuration. The
introduction of a new adapter modifies the adapter instances, and the device
configurations are no longer valid. When this occurs, Windows resets the
adapters to the default of DHCP.
To resolve this issue, either:
| |
Use a slipstream version of Windows 2000 that includes Service Pack 2, or
|
| |
Obtain and use the NETSET utility from the
Microsoft Windows 2000 Server Resource Kit. The NETSET utility
reinitializes the networking components according
to the settings in the unattend text file and restores the individualized
networking parameters including static IP addresses.
| 1. |
Copy netstat.exe into the .\lib\osoem\proliant.zzz\yyy\$oem$\proliant
directory where yyy is the Windows version.
|
| 2. |
Edit .\lib\osoem\proliant.zzz\yyy\$oem$\proliant\postoem.cmd and add the following line:
c:\$oem$\proliant\netset c:\unattend.txt
|
|
|
|
Applies to: All releases
The installation process was unable to read the specified kickstart file.
For Releases 3.00 and greater, several possible causes are:
| |
The job does not contain the correct IP address or a fully-qualified FTP server hostname
that can be resolved by a DNS server.
|
| |
The job does not contain the correct file name of the kickstart file. Regardless of the actual
name of the kickstart file, the error is always ks.cfg.
|
| |
The NIC labeled, eth0, is not plugged into a network that has access to the FTP Server.
NOTE: The first physical NIC is not always labeled eth0 on some ProLiant servers.
|
| |
A firewall is enabled on the FTP Server and is blocking access to the appropriate ports.
|
| |
FTP services are not setup properly. Refer to the HP ProLiant Essentials Rapid Deployment
Pack Installation Guide for creating an IIS FTP virtual directory.
|
| |
The switch port connected to the PXE NIC is running Spanning Tree Protocol (STP). This can
cause a timeout before a response can be given.
|
For Releases 2.xx, several possible causes are:
| |
The job does not contain the correct IP address or a fully-qualified NFS hostname
that can be resolved by a DNS server.
|
| |
The job does not contain the correct file name of the kickstart file. Regardless of the actual
name of the kickstart file, the error is always ks.cfg.
|
| |
The first NIC, eth0, is not plugged into a network that has access to the NFS Server.
|
| |
A firewall is enabled on the NFS Server and is
blocking access to the appropriate ports.
|
| |
The NFS exports are not configured correctly. To verify, from a different
Linux server, attempt to mount and view the NFS share using the following commands:
mkdir /mnt/nfs
mount -t nfs hostname.domain:/usr/rdp/osconfig/yyyy /mnt/nfs
ls /mnt/nfs
where hostname.domain is the fully qualified name or IP address of the NFS Server and
yyyy is the operating system shortcut name, such as rhas3u2
for Red Hat Enterprise Linux AS 3 Update 2.
|
| |
The path to the directory containing the kickstart file is not in the
exports file or the exports file is unreadable. Rerun the NFS Server script
described in the Rapid Deployment Pack documentation.
|
| |
The /etc/resolv.conf file does not contain a valid DNS IP address.
|
| |
The switch port connected to the PXE NIC is running Spanning Tree Protocol (STP).
This can cause a timeout before a response can be given.
|
|
|
Applies to: Releases 1.xx and 2.xx
The installation kernel and the initrd.img files found on the
Deployment Server do not match the
distribution files on the NFS Server. These
files must be of the same Linux version and update.
To resolve this issue, reinstall the ProLiant Integration Module
on the Deployment Server to update the kernel and initrd.img files.
Reinstall the ProLiant Integration Module on the NFS to update
the distribution files. For Rapid Deployment Pack 1.50 and 1.60,
the kernel and initrd.img files are not found on the RDP CD-ROM and you will be
required to use your Red Hat CD #1 to copy these files.
|
|
Applies to: All releases
Releases 3.00 and greater
The intallation process found the kickstart file, but failed
to find the operating system distribution files located on the FTP server.
There are several possible causes:
| |
The distribution files do not exist on the FTP server at
.\lib\osdist\yyyy
where yyyy is the operating system shortcut
name, such as rhel5 for Red Hat Enterprise Linux 5.
|
| |
The dslib Virtual Directory on the FTP server is not
accessible or the Local Path is not c:\Program Files\Altiris\eXpress\Deployment Server\lib.
|
| |
A firewall is enabled on the FTP Server and is blocking access to
the appropriate ports.
|
Releases 2.xx
The installation process found the kickstart file, but failed to
find the operating system distribution files at the location specified by the
following line in the kickstart file:
nfs --server hostname.domain --dir /usr/rdp/osdist/yyyy
where hostname.domain is the fully qualified name or IP address of the
NFS Server, and yyyy is the operating system shortcut name,
such as rhel5 for Red Hat Enterprise Linux 5.
| |
The distribution files do not exist on the NFS
server at /usr/rdp/osdist/yyyy.
|
| |
The name specified in the kickstart file, hostname.domain,
cannot be resolved by a DNS server.
|
| |
A firewall is enabled on the NFS Server and is
blocking access to the NFS ports.
|
| |
The NFS exports are not configured correctly because the distribution directory path
is not in the exports file or the exports file is unreadable. To
verify, from a different Linux server, attempt to mount and view the NFS share
by using the following commands:
mkdir /mnt/nfs
mount -t nfs hostname.domain:/usr/rdp/osdist/yyyy /mnt/nfs
ls /mnt/nfs
Rerun the NFS Server script setup.sh as described in the Rapid
Deployment Pack - Windows Edition Installation Guide.
|
|
|
Applies to: Releases 1.00 through 3.10
The serial port is set as the primary console on the ProLiant BL10e or BL10e G2
so that all messages are visible from the Integrated Administrator remote
console. For Releases 2.xx using the
deploy BL10e Red Hat scripted install jobs, the serial port set as the primary
console is the default. For Releases 3.00 and greater,
the serial port would be set as the primary console if using the bl10e.cfg
kickstart file. Refer to Knowledge Base article
How To Set The Serial Port As The Primary Console For
Red Hat Linux On The ProLiant BL10e Or BL10e G2 To View Messages From The Integrated
Administrator Remote Console (Article 174) for how to use the bl10e.cfg
kickstart file.
Using the diagnostic adapter, the installation process displays the following message:
Uncompressing Linux... OK, booting the kernel
Normally the following message displays several minutes into the
installation process:
Kickstart installation in progress.
You can view the install process by using the
Integrated Administrator Remote Console feature.
If this message does not display, unhook the diagnostic adapter,
and then use the virtual power button in the Integrated Administrator to
restart the blade server. You can watch the installation process using the remote
console in the Integrated Administrator and resolve the problem based on the
error messages displayed.
|
|
Applies to: Releases 1.xx and 2.xx
Yes, except for Red Hat Linux 7.2 and Red Hat Enterprise Linux 2.1.
To use ISO images, either:
| |
During the ProLiant Integration Module installation on the NFS server, choose
the options to copy over the .iso images, or
|
| |
On the NFS server, replace the distribution files with the distribution .iso images in
the /usr/rdp/osdist/yyyy directory, where yyyy
is the operating system shortcut name, such as rhas3u4 for Red Hat Enterprise Linux AS 3 Update 4.
|
|
|
Applies to: Releases 1.40 through 2.20
Red Hat and SUSE provide kernel patches or fixes to resolve security
issues and program errors. These patches are typically distributed as binary rpms.
If Red Hat or SUSE provide only a source rpm, the appropriate kernel must be built to
generate the binary rpm used in the following steps.
IMPORTANT: Only certain errata kernels
are supported by HP and the provided ProLiant Support Pack files. Verify that
you are installing an errata kernel that is supported by all the drivers needed
for that system.
IMPORTANT: Red Hat has specific kernels that install on servers with x86 processors that
have 64-bit extensions. Verify that you are installing the correct errata kernel for your server.
For Releases 2.00 through 2.20, to add a Linux errata kernel into a Linux scripted install:
| 1. |
On the NFS server, create an errata subdirectory under
the /usr/rdp/osdist/yyyy directory where yyyy is the operating system
shortcut name, such as rhas3u3 for Red Hat Enterprise Linux AS 3 Update 3.
|
| 2. |
Copy the errata kernel binary rpm files that you wish to install to this new directory,
/usr/rdp/osdist/yyyy/errata.
IMPORTANT:All kernels installed by the default distribution installation will be upgraded with the errata
kernels found in this directory during the scripted install. Code is in the Red Hat Linux kickstart files and
SUSE LINUX control files to install rpm files found in the ./errata directory.
|
| 3. |
From the Deployment Server, execute the Linux scripted install job.
NOTE:The post installation of the operating system installation may take longer in order
for the errata kernels to be installed.
|
For Releases 1.40 through 1.60, to add a Red Hat Linux
errata kernel into a Red Hat scripted install:
| 1. |
On the NFS server, copy the errata kernel binary rpm files that you
wish to install, to the /usr/cpqrdp/ss.xxx/yyyy/csp directory,
where xxx is the ProLiant Support Pack version,
and yyyy is the operating system shortcut name, such as rhas21 for Red Hat Enterprise Linux AS 2.1.
|
| 2. |
Copy and rename the kickstart file Located at /usr/cpqrdp/ss.xxx/yyyy.
Make the following changes, if applicable, at the location within the POST section of the new
kickstart file with the comment # install Red Hat errata kernels here.
| a. |
Uncomment the kernel rpm install command line
rpm -Uvh /tmp/cpq/kernel-version.i686.rpm and replace
version with the rpm kernel version.
|
| b. |
Add a separate line for each kernel to be
installed replacing the appropriate version name for each. Be sure the
rpm files were placed in the previously-mentioned directory.
IMPORTANT: Do not add kernel install
command lines elsewhere within the kickstart file or the appropriate storage
drivers may not install for that kernel.
|
| c. |
Uncomment the kernel source rpm install command
line rpm -Fvh /tmp/cpq/kernel-source-version.i386.rpm and replace version
with the rpm kernel version.
|
| d. |
Uncomment the kernel headers rpm install command
line rpm -Fvh /tmp/cpq/kernel-headers-version.i386.rpm and replace
version with the rpm kernel version.
|
| e. |
Verify if .i686 or .i386 rpms and edit to match rpm names.
For example, to install
the Red Hat Enterprise Linux AS 2.1 SMP kernel, the rpm install command lines
would look like:
rpm -Uvh /tmp/cpq/kernel-smp-2.4.9-e.12.i686.rpm
rpm -Fvh /tmp/cpq/kernel-source-2.4.9-e.12.i386.rpm
rpm -Fvh /tmp/cpq/kernel-headers-2.4.9-e.12.i386.rpm
|
|
| 3. |
On the Deployment Server, copy and rename the scripted install job. Modify the new job with the new kickstart file created in step 2.
|
| 4. |
Execute the Linux scripted install job.
|
|
|
Applies to: Release 2.00 or greater
For Red Hat Linux, to install GNOME or KDE within the kickstart file:
| 1. |
Locate the appropriate kickstart file.
For Releases 3.xx, the kickstart files are on the Deployment Server
under .\lib\osconfig\yyyy and
for Releases 2.xx, the kickstart files are on the NFS server under
/usr/rdp/osconfig/yyyy where yyyy is
the operating system shortcut name.
|
| 2. |
Within the kickstart file, locate the appropriate package text line and
remove the # (comment symbol) from the beginning of the line.
Package text lines may be:
#@ GNOME
#@ gnome-desktop
#@ KDE
or
#@ kde-desktop
|
| 3. |
Modify the parameters for the xconfig command:
| |
For platforms other than VMWare ESX virtual machines, add to the xconfig
command the parameters
--startxonboot and --defaultdesktop gnome or
--defaultdesktop kde.
For example,
xconfig --monitor "generic monitor" --startxonboot --defaultdesktop gnome
or
xconfig --monitor "generic monitor" --startxonboot --defaultdesktop kde
|
| |
For VMWare ESX virtual machines, replace the existing xconfig line with
xconfig --card "VMWare" --resolution "800x600" --depth "16" --monitor "generic monitor" --startxonboot
|
|
For SUSE LINUX, to install GNOME or KDE within the control file:
| 1. |
Locate the appropriate control file.
For Releases 3.00 and greater, the kickstart files are on the Deployment Server
under .\lib\osconfig\yyyy and
for Releases 2.00 through 2.20, the kickstart files are on the NFS server under
/usr/rdp/osconfig/yyyy where yyyy is
the operating system shortcut name.
|
| 2. |
Within the control file, locate the <configure>
text line in the control file and add the following after the text line:
<x11>
<color_depth config:type="integer">16</color_depth>
<configure_x11 config:type="boolean">true</configure_x11>
<display_manager>kdm</display_manager>
<enable_3d config:type="boolean">false</enable_3d>
<monitor>
<display>
<frequency config:type="integer">60</frequency>
<height config:type="integer">600</height>
<width config:type="integer">800</width>
</display>
<monitor_device>800x600@60HZ</monitor_device>
<monitor_vendor>VESA</monitor_vendor>
</monitor>
<resolution>800x600</resolution>
<window_manager>kde</window_manager>
</x11>
NOTE: For GNOME installation, replace kdm with gdm on the
<display_manager> line, and kde with gnome
on the <window_manager> line.
|
| 3. |
Locate the <addons> text line and add the following after the text line:
| |
For GNOME, <addon>Gnome</addon> |
| |
For KDE, <addon>Kde-Desktop</addon> |
|
| 4. |
To change the runlevel, locate the runlevel text line and change
the <default>3</default> to <default>5</default>.
|
|
|
Applies to: All releases
For Releases 3.xx, to create a Windows scripted install job that uses a localized version of Windows:
| 1. |
Create a new directory in the .\lib\osdist directory for the distribution files.
For example, .\lib\osdist\w50s-xx, where xx is a language code like "DE".
|
| 2. |
Copy the entire CD into the new directory.
Following the example, copy the files to .\lib\osdist\w50s-de.
|
| 3. |
Create a new directory in the .\lib\osconfig directory for the answer files.
Following the example, create .\lib\osconfig\w50s-de.
|
| 4. |
Copy an appropriate, existing unattend text file into the new directory.
Following the example, copy .\lib\osconfig\w50s\default.txt to .\lib\osconfig\w50s-de\default.txt.
It may be necessary to edit the new file to match your environment.
|
| 5. |
Copy the default ProLiant driver unattend.txt file.
Following the example, copy .\lib\osoem\proliant.zzz\w50\$oem$\unattend.txt
to .\lib\osoem\proliant.zzz\w50\$oem$\unattend-de.txt.
|
| 6. |
In a text editor, edit the new driver unattend.txt file.
Change the following to the appropriate localized string.
"IDE CD-ROM (ATAPI 1.2)/PCI IDE-Controller"=RETAIL
The correct string can be obtained from the SCSI section in \i386\txtsetup.sif file
on the localized Windows CD.
|
| 7. |
Copy and rename one of the Windows scripted install jobs.
Following the example, name the new job Deploy ProLiant ML/DL/BL + Windows 2000 Server (German) + PSP {WinPE}.
|
| 8. |
Edit the tasks to use the new files.
| a. |
In the Run Script - Copy Unattend.txt task, change the three Windows shortcut name
references to the directory created in step 3 and add set driverunattendfile= variable
with the value of the file created in step 5. Following the example,
rem Copy Unattend.txt
rem replacetokens .\lib\osconfig\w50s-de\default.txt .\lib\osconfig\w50s-de\%ID%.txt
set unattendfile=w50s-de\%ID%.txt
set driverunattendfile=unattend-de.txt
call f:\lib\bin32\winpe\osconfig1.cmd
|
b. |
In the Run Script - Copy Distribution Files task, change the dist= variable
to point to the directory created in step 1.
|
|
| 9. |
Execute the new job on the managed server(s).
|
For Releases 2.xx, to create a Windows scripted install job that uses a localized version of Windows:
| 1. |
Create a new directory in the .\lib\osdist directory for the distribution files.
For example, .\lib\osdist\w50s-xx, where xx is a language code like "DE".
|
| 2. |
Copy the \i386 directory from the CD into the new directory.
Following the example, copy the files to .\lib\osdist\w50s-de\i386.
|
| 3. |
Create a new directory in the .\lib\osconfig directory for the answer files.
Following the example, create .\lib\osconfig\w50s-de.
|
| 4. |
Copy an appropriate, existing unattend text file into the new directory.
Following the example, copy .\lib\osconfig\w50s\default.txt to .\lib\osconfig\w50s-de\default.txt.
|
| 5. |
In a text editor, open the appropriate ProLiant driver unattend.txt file.
Following the example, .\lib\osoem\proliant.zzz\w50\unattend.txt.
IMPORTANT: This file will be used by all Windows 2000 or 2003 scripted install jobs.
The file must be restored after job execution to support the default Windows distribution.
In the [MassStorageDrivers] section, replace the last four lines ending
in =RETAIL, with the appropriate lines from the SCSI section in the
txtsetup.sif file in the \i386 directory from the CD. For example:
Windows CD (German) \i386\txtsetup.sif
[SCSI]
atapi="IDE CD-ROM (ATAPI 1.2)/PCI IDE-Controller"
sym_hi="Symbios Logic C896 PCI SCSI-Hostadapter"
symc810="Symbios Logic C8100 PCI SCSI-Hostadapter"
symc8xx="Symbios Logic C8xx PCI SCSI-Hostadapter"
new unattend.txt file .\lib\osoem\proliant.zzz\w50\unattend.txt
[MassStorageDrivers] (leave all of the lines that end in "=OEM")
"IDE CD-ROM (ATAPI 1.2)/PCI IDE-Controller"=RETAIL
"Symbios Logic C896 PCI SCSI-Hostadapter"=RETAIL
"Symbios Logic C8100 PCI SCSI-Hostadapter"=RETAIL
"Symbios Logic C8xx PCI SCSI-Hostadapter"=RETAIL
|
| 6. |
Copy and rename one of the Windows scripted install jobs.
Following the example, name the new job Deploy ProLiant ML/DL/BL + Windows 2000 Server (German) + PSP.
|
| 7. |
Edit the tasks to use the new files.
| a. |
In the Run Script - Copy Distribution Files task, change the dist= variable
to point to the directory created in step 1.
|
| b. |
In the Run Script - Create Boot Environment task, change the three Windows shortcut name
references to the directory created in step 3.
|
|
| 8. |
Execute the new job on the managed server(s).
|
|
|
Applies to: All releases
To disable the Configure Your Server wizard:
| 1. |
Browse to the Windows distribution directory,
.\lib\osdist\yyyy\i386, where yyyy
is the appropriate Windows shortcut name, e.g. w50s.
|
| 2. |
Using any text editor, open the file hivedef.inf.
|
| 3. |
Locate the following line (note that this is one line) and change the value at the end of the line
from 1 to 0:
HKCU, "Software\Microsoft\Windows NT\CurrentVersion\Setup\Welcome", "srvwiz" 0x00010003, 1
|
| 4. |
Save and close the file.
|
| 5. |
Execute the Windows 2000 scripted install job.
|
|
|
Applies to: Releases 1.xx and 2.xx
Scripted installs of the HP Management agents cannot activate the
clustering information agent because clustering is not installed at the time
the agents are installed.
To activate the clustering information agent in the Management Agents control panel:
| 1. |
Click Start > Programs > Control Panel.
|
| 2. |
Double-click HP Management Agents.
|
| 3. |
Select Clustering Information, and click Add.
|
| 4. |
Click OK to close the window, then click OK.
|
|
|
Applies to: Releases 1.xx and 2.xx
The target server may experience a file lockup at 100% during the blue
screen file copy phase of the Windows unattended install when using PXE
or boot diskette images created with the original version of Windows 95 (Windows 95a).
This is because Windows 95 doesn't support partitions over 2GB in size.
To resolve this issue, recreate the PXE and/or boot diskette images using a newer version of Windows 9x.
|
|
Applies to: Releases 1.xx and 2.xx
When attempting a Windows 2003 scripted install using the Japanese
version of Windows via PXE, the install will fail with an "Out Of Memory" message.
This error occurs because the Japanese winnt.exe has large memory
requirement that can not be accommodated with the PXE network stack loaded.
To resolve this issue, use a boot diskette instead of PXE.
|
|
Applies to: Releases 1.xx and 2.xx
While initializing the DOS network stack, the target hangs with the
message "Initializing TCP/IP via DHCP". This message is coming from
the DOS driver TCPTSR.EXE. A possible reason for this error is that
the DOS driver has received an IP address from the DHCP Server that has
been statically defined by another client on the network.
To verify the problem is a duplicate IP address, get the IP address
assigned to the target server by watching the PXE post message (the
IP address given to the target is displayed by the PXE firmware). Turn
off the target server, and then ping the address DHCP assigned to
the target server from the Deployment Server. If the ping is answered,
another server on the network has the same IP address.
To resolve this issue, create a DHCP reservation for all static
IP addresses so that they will not be dynamically assigned.
|
|
Applies to: All releases
When Red Hat Linux is installed without Logical Volume Manager (LVM)
on a system with multiple logical drives, the Linux partitions are
installed across all the drives so all available space is used.
When a disk image is captured, by default, only the partitions on the first disk are captured. Thus, when
this image is deployed, some of the partitions are missing, which can lead to an "Invalid Partition" error.
To resolve this issue, either:
| |
Install Red Hat Linux with LVM. Refer to Knowledge Base article
How To Install Logical Volume Manager (LVM) During A Red Hat Linux Scripted Install.
(Article 152).
|
| |
Force the partitions to be installed on the first drive during the scripted install as follows:
| 1. |
For Releases 3.00 and greater, copy and rename the kickstart file on the FTP server.
For Releases 2.xx, copy and rename the kickstart file on the NFS server.
|
| 2. |
Modify the new kickstart file by adding the following line to the
end of each part command in your kickstart file:
--ondisk=XXX
If the kickstart files is using the autopart command instead of
separate part command lines, replace the autopart
command with the following, for example:
part /boot --size 75 --ondisk=XXX
part swap --recommended --ondisk=XXX
part / --size 5120 --grow --ondisk=XXX
where XXX is the device label, such as sda or cciss/c0d0.
For Red Hat Enterprise Linux 3, add the following to the end of the
bootloader command in the kickstart file:
--driveorder=XXX
|
| 3. |
On the Deployment Server, copy and rename the job. Modify the new job to use
the new kickstart file created in step 1.
|
|
|
|
Applies to: All releases
When performing a scripted or image installation, the job may fail with an error 255 in the
Deployment Server Console or Web Console. A detailed text error message for the failure is
available for the failed job.
Select Status Detail when viewing the Job
Schedule Information of the failed job. The Status column lists the detailed
text error message.
|
|
Applies to: Release 2.00 or greater
To add a custom Altiris Deployment Agent for Linux (adlagent) configuration file into a Linux scripted install:
| 1. |
Create a source configuration file (adlagent.conf) from a target server that is currently connected
to the Deployment Server.
| a. |
On the target server, modify the /opt/altiris/deployment/adlagent/conf/adlagent.conf
file with your custom changes.
|
| b. |
Restart adlagent using the following commands:
/etc/init.d/adlagent stop
/etc/init.d/adlagent start
|
| c. |
Verify the target server is still connected to the Deployment Server.
|
|
| 2. |
For Releases 3.00 and greater, copy the source configuration file to the FTP Server under the
directory, .\lib\osoem\altiris and rename it to adlagent.conf.custom.
For Releases 2.xx
for Linux, copy the source configuration file to the NFS Server under the directory,
/usr/rdp/osoem/altiris and rename it to adlagent.conf.custom.
For VMware, copy the source configuration file to the Deployment Server under the directory,
.\lib\osoem\altiris and rename it to adlagent.conf.custom.
|
| 3. |
Execute a Linux scripted install job.
|
IMPORTANT: This custom adlagent configuration file will be used by all VMware or Linux scripted install jobs.
The file must be removed or renamed after the job execution if it is not to be used by all jobs.
|
|
Applies to: Releases 1.xx and 2.xx
For Releases 3.00 and greater, the Altiris Deployment Agent for Linux (adlagent) by default uses
the deployment server ip address for communication with the deployment server. No change is necessary.
For Releases 2.xx, adlagent by default uses multicast to connect with the
Deployment Server. To change this setting for target servers to connect with the Deployment Server
using the Deployment Server IP, use one of the following methods:
| |
Before a VMware or Linux scripted install is executed on a target, create a custom adlagent
configuration file following the steps in the Knowledge Base article
How To Integrate A Custom Altiris Deployment Agent For Linux
Configuration File Into A Linux Scripted Install (Article 142).
Make the following changes to the custom configuration file:
| 1. |
Replace UseMCast=true with UseMCast=false.
|
| 2. |
Set TcpAddr=xxx.xxx.xxx.xxx to the IP address of your
Deployment Server replacing the xxx.xxx.xxx.xxx value.
|
|
| |
On a managed server, edit the /opt/altiris/deployment/adlagent/conf/adlagent.conf file
with the above listed changes for UseMCast and TcpAddr.
Restart adlagent using the following commands:
/etc/init.d/adlagent stop
/etc/init.d/adlagent start
|
| |
On a managed server, run /opt/altiris/deployment/adlagent/bin/configure. Answer N
for No to use Multicast to connect with the Deployment Server and entering the IP address of
the Deployment Server.
|
|
|
Applies to: Release 2.xx
There are several reasons why the autorun utility will erroneously mark the MSDE 2000 + SP3a component as installed:
| |
MSDE 1.0 is installed on the server.
|
| |
MSDE was installed and then uninstalled.
|
The autorun utility is looking for the registry key, HKLM\SOFTWARE\Microsoft\Microsoft SQL Server, to
determine if a Microsoft SQL database is locally present. Unfortunately, uninstalling MSDE does not delete this registry key.
If you plan on using MSDE for your database, to resolve this issue, uninstall MSDE 1.0, delete the above registry key
and restart the autorun utility.
|
|
Applies to: Releases 2.00 or greater
To create a job that distributes Microsoft Virtual Server 2005 R2:
| 1. |
On the Deployment Server, create a directory for the install package.
For example, .\lib\software\Microsoft Virtual Server 2005 R2.
|
| 2. |
Download the install package into the new directory. If the install package
is in .exe format, run the following command-line to extract the .msi file:
setup.exe /c /t .
|
| 3. |
Create a new job. For example, Install Microsoft Virtual Server 2005 R2.
| a. |
Add a Distribute Software task with the following options:
|
| Field |
Value |
|
| Name |
The .msi install file downloaded in step 2 |
| | | | |