OS Build Plans - HPE Support Center

OS Build Plans - HPE Support Center
HPE Insight Control Server Provisioning
7.5.1
Build Plans Reference Guide
HP Part Number: 5200-0267
Published: May 2016
Edition: 1
© Copyright 2012-2016 Hewlett-Packard Development Company, L.P.
Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR 12.211 and 12.212,
Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S.
Government under vendor's standard commercial license. 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. UNIX is a registered trademark of The Open Group.
Acknowledgments
Microsoft®, Windows®, and Windows Server® are registered trademarks of the Microsoft group of companies. VMware® is a registered
trademark of VMware Inc. Red Hat® is a registered trademark of Red Hat, Inc. in the United States and other countries. Linux® is a
registered trademark of Linus Torvalds in the United States and other countries. UNIX® is a registered trademark of The Open Group.
Adobe™ is a trademark of Adobe Systems Incorporated.
For access to applicable source code for the open source software used by HP Insight Control server provisioning, see the website
www.hp.com/software/opensource
2
Contents
Table of contents
Summary
13
OS Build Plans
ProLiant Hardware
ProLiant Operating System
ProLiant Software
ProLiant Combination
13
13
13
13
13
OS Build Plan Steps
Run Script
OGFS
Python
Unix
Windows BAT
Windows VBScript
Powershell
Deploy Package
Deploy Configuration File
Capture Configuration File
14
14
14
14
14
14
14
14
14
14
15
Working with OS Build Plans
Modifying Configuration Files
Adding Scripts
Modifying Build Plan Step Parameters
Combining Build Plans
15
15
15
16
16
Detailed Breakdown of Sample Build Plans
Sample Build Plan: Windows Scripted Install
Sample Build Plan: Windows Image Capture
Sample Build Plan: Windows Image Install
Sample Build Plan: Linux Scripted Install
Sample Build Plan: ESXi Scripted Install
Sample Build Plan: ProLiant Hardware Configuration
Sample Build Plan: ProLiant Software Install
Sample Build Plan: Combination Hardware, Windows Scripted Install,
and SPP
How these build plans were combined
What this build plan does
16
16
20
23
25
28
30
32
Build Plan and Build Plan Steps Reference
OS Build Plans
Summary
36
36
36
33
35
35
ProLiant COMBO - BFS + Windows 2012 R2 + SPP
ProLiant COMBO - BFS + RHEL7.2 + SPP
ProLiant HW - Add Migrated Linux Server
ProLiant HW - Add Migrated Windows Server
ProLiant HW - Boot Linux Service OS
ProLiant HW - Boot WinPE Service OS
ProLiant HW - Boot Local Disk
ProLiant HW - Clear UEFI Boot Menu
ProLiant HW - Erase Server
ProLiant HW - Fibre Channel HBA Configure Boot Device
ProLiant HW - Fibre Channel HBA Display Configuration
ProLiant HW - iLO Capture Configuration
ProLiant HW - iLO Set Minimum Password Length
ProLiant HW - Prepare for Linux Reprovisioning
ProLiant HW - Prepare for Windows Reprovisioning
ProLiant HW - Smart Array Capture Settings
ProLiant HW - Smart Array Erase
ProLiant HW - Smart Array Set RAID 1
ProLiant HW - Switch to Legacy BIOS boot mode and Power Off
ProLiant HW - Switch to UEFI boot mode and Power Off
ProLiant HW - System ROM Capture Settings
ProLiant HW - System ROM Enable Boot from SAN
ProLiant HW - System ROM Enable Boot from SAN on Bladeserver
ProLiant HW - System ROM Enable Virtualization
ProLiant OS - ESXi 5.0 U1 Scripted Install
ProLiant OS - ESXi 5.0 U2 Scripted Install
ProLiant OS - ESXi 5.0 U3 Scripted Install
ProLiant OS - ESXi 5.1 Scripted Install
ProLiant OS - ESXi 5.1 U1 Scripted Install
ProLiant OS - ESXi 5.1 U2 Scripted Install
ProLiant OS - ESXi 5.1 U3 Scripted Install
ProLiant OS - ESXi 5.5 Scripted Install
ProLiant OS - ESXi 5.5 U1 Scripted Install
ProLiant OS - ESXi 5.5 U2 Scripted Install
ProLiant OS - ESXi 5.5 U3 Scripted Install
ProLiant OS - ESXi 6.0 Scripted Install ProLiant OS - ESXi 6.0 U1
Scripted Install ProLiant OS - ESXi 6.0 U2 Scripted Install
ProLiant OS - RHEL 5.9 x64 Scripted Install
ProLiant OS - RHEL 5.10 x64 Scripted Install
ProLiant OS - RHEL 5.11 x64 Scripted Install
ProLiant OS - RHEL 6.3 x64 Scripted Install
ProLiant OS - RHEL 6.4 x64 Scripted Install
ProLiant OS - RHEL 6.4 x64 KVM Scripted Install
ProLiant OS - RHEL 6.5 x64 Scripted Install
36
37
37
37
38
38
38
38
38
38
39
39
39
39
39
40
40
40
40
40
41
41
41
41
42
42
42
42
42
42
42
42
42
42
42
42
42
42
42
42
42
42
42
4
ProLiant OS - RHEL 6.5 x64 KVM Scripted Install
ProLiant OS - RHEL 6.6 x64 Scripted Install
ProLiant OS - RHEL 6.6 x64 KVM Scripted Install
ProLiant OS - RHEL 6.7 x64 Scripted Install
ProLiant OS - RHEL 6.7 x64 KVM Scripted Install
ProLiant OS - RHEL 7.0 x64 Scripted Install
ProLiant OS - RHEL 7.0 x64 KVM Scripted Install
ProLiant OS - RHEL 7.1 x64 Scripted Install
ProLiant OS - RHEL 7.1 x64 KVM Scripted Install
ProLiant OS - RHEL 7.2 x64 Scripted Install
ProLiant OS - RHEL 7.2 x64 KVM Scripted Install
ProLiant OS - SLES11 SP2 x64 Scripted Install
ProLiant OS - SLES11 SP3 x64 Scripted Install
ProLiant OS - SLES11 SP4 x64 Scripted Install
ProLiant OS - SLES12 x64 Scripted Install
ProLiant OS - SLES12 SP1 x64 Scripted Install
ProLiant OS – Ubuntu Server 14.04 x64 Scripted Install
ProLiant OS - Windows 2008 SP2 Standard x64 Image Capture
ProLiant OS - Windows 2008 R2 SP1 Standard x64 Image Capture
ProLiant OS - Windows 2012 Standard x64 Image Capture
ProLiant OS - Windows 2012 R2 Standard x64 Image Capture
ProLiant OS - Windows 7 SP1 Professional x64 Image Capture
ProLiant OS - Windows 8.1 Pro x64 Image Capture
ProLiant OS - Windows 2008 SP2 Standard x64 Image Install
ProLiant OS - Windows 2008 R2 SP1 Standard x64 Image Install
ProLiant OS - Windows 2012 Standard x64 Image Install
ProLiant OS - Windows 2012 R2 Standard x64 Image Install
ProLiant OS - Windows 7 SP1 Professional x64 Image Install
ProLiant OS - Windows 8.1 Pro x64 Image Install
ProLiant OS - Windows 2008 SP2 Standard x64 Scripted Install
ProLiant OS - Windows 2008 R2 SP1 Standard x64 Scripted Install
ProLiant OS - Windows 2012 Standard x64 Scripted Install
ProLiant OS - Windows 2012 R2 Standard x64 Scripted Install
ProLiant OS - Windows 7 SP1 Professional x64 Scripted Install
ProLiant OS - Windows 8.1 Pro x64 Scripted Install
ProLiant SW - Configure NIC Teaming for RHEL 7
ProLiant SW - Configure Multiple NIC Team for Windows
ProLiant SW - Install Linux SPP
ProLiant SW - Install Windows SPP
ProLiant SW - Install Linux HPSUT
ProLiant SW – Install Windows HPSUT
ProLiant SW - Intelligent Provisioning Firmware Update
ProLiant SW - Offline Firmware Update
ProLiant SW – Post Install Network Personalization
42
42
42
42
42
42
42
42
42
42
42
43
43
43
43
43
43
44
44
44
44
44
44
44
44
44
44
44
44
45
45
45
45
45
45
46
46
46
46
47
47
47
48
48
ProLiant SW - Validate Media Server Settings
Scripts
Summary
Add ESXi Boot Option To UEFI Boot Order
Add ESXi Module
Add iLO User
Add Windows Hyper-V Role
Add Windows Multipath IO Feature
Add Windows Server to Domain
Adjust Windows System Disk Number on HP ProLiant Gen8
An Empty Template OGFS Script
An Empty Template Python Script
An Empty Template Unix Shell Script
An Empty Template Windows Batch Script
An Empty Template Windows VBScript
Apply WIM Image
Boot
Capture Windows Image
Check iLO Service
Collect and Store System Data
Configure Boot From SAN
Configure Fibre Channel HBA Boot Device
Configure NIC Teaming for RHEL 7
Configure NIC Teaming for Windows
Configure Multiple NIC Teaming for Windows
Continue SuSE AutoYaST Installation
Control Server Bootmode
Copy Boot Media
Create Stub Partition
Create Windows System Drive
Decommission Server
Delete iLO User
Deploy Agent
Display Media Server Settings
Embed files initrd
Embed Monitoring SA Agent
Erase Server Disk
Find SD Card on Server
Get Deployment Interface Details
Hide Intelligent Provisioning drives
Inject AutoYaST Personalization Settings
Inject Kickstart Personalization Settings
Inject Kickstart Personalization Settings for ESXi 5
Inject Multi-NIC Kickstart Personalization Settings
48
49
49
49
49
50
50
50
50
50
51
51
51
51
51
51
51
52
52
53
54
54
54
55
55
56
56
57
57
57
58
58
59
59
59
59
60
60
60
60
61
61
61
61
6
Inject Multi-NIC Personalization Settings
Inject Multi-NIC Required ESXi 5 Kickstart Settings
Inject Personalization Settings
Inject Required AutoYaST Settings
Inject Required ESXi 5 Kickstart Settings
Inject Required ESXi 6.0 U1 Kickstart Settings
Inject Required Kickstart Settings
Inject Required Unattend.xml Settings
Inject Windows Domain or Workgroup Personalization Settings
Install and boot into local WinPE
Install bootloader for ESXi
Install bootloader for RedHat Enterprise Linux Server
Install bootloader for SuSE Linux Enterprise Server
Install bootloader for RedHat Enterprise Linux 7 Server
Install Linux SPP
Install Windows SPP
Install Windows SPP In Background
Integrate HP SA Agent
Integrate Linux HP SA Agent
Manage iLO Configuration
Manage Smart Array Configuration
Manage System Configuration
Monitor Installation
Move PXE To The End Of UEFI Boot Order
Partition Disk for Windows
Personalize Network Settings of Installed System
Prepare Windows for Image Capture
Prevent WIM File Overwrite
Reboot
Reboot to Apply BIOS Changes and Power Off
Remove Custom Attributes From Server
Remap Windows Drives
Report Windows SPP Installation Results
Reset System Configuration
Run Windows 2008 R2 x64 Setup
Run Windows 2008 x64 Setup
Run Windows 2012 x64 Setup
Run Windows 2012 R2 x64 Setup
Sample - Capture Linux Server Image
Sample - Create New Filesystem RHEL
Sample - Create New Filesystem SLES
Sample - Deploy Linux Image
Sample - Fixup RHEL Deployment
Sample - Fixup SLES Deployment
61
62
62
62
63
63
63
63
64
64
65
65
65
65
65
65
66
66
67
67
67
67
67
68
68
69
69
69
70
70
71
71
71
71
72
72
72
72
72
72
72
72
72
72
Sample - Mount the RHEL Filesystem
Sample - Mount the SLES Filesystem
Sample - Re-Install RHEL HP SA Agent
Sample - Re-Install SLES HP SA Agent
Sample - Remove RHEL Old Partition
Sample - Unmount RHEL Disk Partition
Set Media Source
Set One Time PXE Boot
Shutdown Server
Skip steps based on Custom Attribute
Uninstall HP ProLiant Utilities
Unmap Network Drive
Unmount All Boot Disk Partitions
Unmount Intelligent Provisioning WinPE Drive
Update Firmware Using SPP
Update Intelligent Provisioning Firmware
Validate Custom Attributes
Validate Gateway Setting for Static Network Configuration
Validate ImageX Package Contents
Validate Media Server
Validate Windows OS Version
Validate WinPE Version
Verify Supported Boot Modes
Verify server has iLO4 or newer
Validate Server Platform
Wait for ESXi installation
Wait for HP SA Agent
Windows Image Capture
Configuration Files
Summary
Configure Windows Partitioning Scheme for Legacy
Configure Windows Partitioning Scheme for Uefi
ESXi 5.0 U1 Kickstart
ESXi 5.0 U2 Kickstart
ESXi 5.0 U3 Kickstart
ESXi 5.1 Kickstart
ESXi 5.1 U1 Kickstart
ESXi 5.1 U2 Kickstart
ESXi 5.1 U3 Kickstart
ESXi 5.5 Kickstart
ESXi 5.5 U1 Kickstart
ESXi 5.5 U2 Kickstart
ESXi 5.5 U3 Kickstart
ESXi 6.0 Kickstart
72
72
72
72
72
72
72
74
74
74
75
75
75
75
75
76
76
77
77
77
78
78
79
79
79
80
80
80
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
8
ESXi 6.0 U1 Kickstart
ESXi 6.0 U2 Kickstart
iLO Configuration - Set Minimum Password Length
ImageX Configuration - Exclude Boot Directory
RHEL 5.9 x64 en_us Kickstart
RHEL 5.10 x64 en_us Kickstart
RHEL 5.11 x64 en_us Kickstart
RHEL 6.3 x64 en_us Kickstart
RHEL 6.4 x64 en_us Kickstart
RHEL 6.4 x64 KVM en_us Kickstart
RHEL 6.5 x64 en_us Kickstart
RHEL 6.5 x64 KVM en_us Kickstart
RHEL 6.6 x64 en_us Kickstart
RHEL 6.6 x64 KVM en_us Kickstart
RHEL 6.7 x64 en_us Kickstart
RHEL 6.7 x64 KVM en_us Kickstart
RHEL 7.0 x64 en_us Kickstart
RHEL 7.0 x64 KVM en_us Kickstart
RHEL 7.1 x64 en_us Kickstart
RHEL 7.1 x64 KVM en_us Kickstart
RHEL 7.2 x64 en_us Kickstart
RHEL 7.2 x64 KVM en_us Kickstart
SLES 11 SP2 x64 en_us Autoyast
SLES 11 SP3 x64 en_us Autoyast
SLES 11 SP4 x64 en_us Autoyast
SLES 12 x64 en_us Autoyast
SLES 12 SP1 x64 en_us Autoyast
Ubuntu Server 14.04 preseed
Smart Array Configuration - Delete RAID Logical Volumes
Smart Array Configuration - Set RAID 1
Smart Array Configuration - Set RAID 5
System ROM Configuration – Enable Boot from SAN
System ROM Configuration - Enable Virtualization
Windows 2008 SP2 DataCenter x64 en_us Unattend
Windows 2008 SP2 Enterprise x64 en_us Unattend
Windows 2008 SP2 Standard x64 en_us Unattend
Windows 2008 SP2 Web Server x64 en_us Unattend
Windows 2008 R2 SP1 DataCenter x64 en_us Unattend
Windows 2008 R2 SP1 Enterprise x64 en_us Unattend
Windows 2008 R2 SP1 Standard x64 en_us Unattend
Windows 2008 R2 SP1 Web Server x64 en_us Unattend
Windows 2012 DataCenter x64 en_us Unattend
Windows 2012 Standard x64 en_us Unattend
Windows 2012 R2 DataCenter x64 en_us Unattend
81
81
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
82
83
83
83
83
83
83
83
83
83
84
84
84
84
84
84
85
Windows 2012 R2 Standard x64 en_us Unattend
Windows 7 SP1 Professional x64 en_us Unattend
Windows 7 SP1 Enterprise x64 en_us Unattend
Windows 8.1 Pro x64 en_us Unattend
Windows 8.1 Enterprise x64 en_us Unattend
Packages
Summary
ESXi Installation Utilities
GRub Boot Loader x86
Hponcfg for Windows x64 with One Time PXE Boot
ImageX
LinuxPE add-on packages
LinuxPE HBA add-on packages
ProLiant Drivers for RHEL 5.9 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 5.10 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 5.11 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 6.3 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 6.4 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 6.5 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 6.6 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 6.7 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 7.0 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 7.1 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 7.2 x64 - yyyy.mm.x
ProLiant Drivers for SLES 11 SP2 x64 - yyyy.mm.x
ProLiant Drivers for SLES 11 SP3 x64 - yyyy.mm.x
ProLiant Drivers for SLES 11 SP4 x64 - yyyy.mm.x
ProLiant Drivers for SLES 12 x64 - yyyy.mm.x
ProLiant Drivers for SLES 12 SP1 x64 - yyyy.mm.x
ProLiant Drivers for Windows 2008 x64 - yyyy.mm.x
ProLiant Drivers for Windows 2008 R2 x64 - yyyy.mm.x
ProLiant Drivers for Windows 2012 - yyyy.mm.x
ProLiant Drivers for Windows 2012 R2 - yyyy.mm.x
ProLiant Scripting Toolkit for Linux x64
Appendix A – Changes in Build Plans for each release
New Changes for IC server provisioning Release 7.5.1
Linux Combo Build Plan updated to use RHEL 7.2
Modification to Windows Build Plans
New Changes for IC server provisioning Release 7.5.0
“Install and boot into local WinPE” step now added in all Windows
Scripted Install Build Plans to facilitate WinPE version switching.
All Build Plans check the server boot mode and were updated to
reflect support of UEFI Secure Boot mode
85
85
85
85
85
86
86
86
86
86
86
86
86
87
87
87
87
87
87
87
87
87
87
87
87
87
87
87
87
87
87
87
87
87
87
88
88
88
88
88
88
10
Modifications to ProLiant OS - Windows 2008 & Windows 2008 R2
build plans
RHEL 6.5 and 6.6 Kickstart files updated with i40e drivers
Linux Combo Build Plan updated to use RHEL 7.1
Driver name change in driver packages
New Changes for IC server provisioning Release 7.4.1
Driver packages from IC server provisioning 7.2.1 and 7.2.2 will be
deprecated
New Build Plan step to validate Windows OS version
New Build Plan to do Post Install Network Personalization
New Changes for IC server provisioning Release 7.4
New Steps and Build Plans for enabling Boot from SAN
New Build Plan step to validate server hardware platform support
New RHEL7 specific steps
The Validate Custom Attribute script was updated to require a
parameter
Driver name change in ProLiant Drivers for RHEL 6.4 x64 – 2014.09.0
and ProLiant Drivers for RHEL 6.5 x64 - 2014.09.0 driver packages
New Changes for IC server provisioning Release 7.3.2
The ProLiant SW - Offline Firmware Update build plan was modified
for running in LinuxPE PXE service OS
New Changes for IC server provisioning Release 7.3.1
All Build Plans updated to support Proliant Servers with UEFI Boot
Capability
Windows 2008 SP2 and Windows 2008 R2 SP1 Build Plans updated to
check for WinPE Version
Windows unattend answer files now use EncryptedAdminPassword
custom attribute instead of the AdminPassword custom attribute
Linux and ESXi kickstart and autoyast answer files use
encrypted_root_password custom attribute instead of the
root_password custom attribute
Set Media Source parameter changed from /mnt/ms to /mnt/media in
some build plans
All Windows image OS build plans - Uninstall HP Agents and Utilities
replaced with Uninstall HP ProLiant Utilities
Windows SPP Build Plans – New scripts used to install the SPP and
collect results
New Changes for IC server provisioning Release 7.2.2
Custom Attribute added for several ProLiant HW build plans
Script step added to ESXi build plans for network gateway validation
New ProLiant Driver package naming to include SPP version
Windows build plans contain comment information regarding disk
partitioning in the unattend answer files
88
88
88
88
89
89
89
89
89
89
89
89
90
90
90
90
90
90
90
90
91
91
91
91
91
91
91
91
92
Linux build plans have firewall disabled in default kickstart or
autoyast answer files
Modifications to the Erase Server Disk build plan
92
92
Appendix B – Network Personalization Custom Attribute Details
Personalize Network Settings
Example
Mandatory and Optional Fields
Description of Individual Fields
enabled
hostname, domain
interfaces
macAddress
dhcpv4
ipv6Autoconfig
provisioning
dnsServers, dnsSearch, winsServers
staticNetworks
ipv4gateway/ipv6gateway
vlanid
virtualInterfaces
interfaceName
92
92
92
93
93
93
93
93
94
94
94
94
94
94
94
94
94
94
For more information
95
12
Summary
Insight Control (IC) server provisioning provides OS Build Plans, scripts, packages, and configuration files that are used
to deploy operating systems, configure hardware, and update firmware.
OS build plans are the way tasks get done in IC server provisioning. These are the items you actually run to cause actions
like installing a server or updating firmware to happen. OS build plans are simply a collection of ordered steps and
parameters associated with those steps that when placed together, in the proper order, can perform just about any
action you require. IC server provisioning comes ready to run, with sample build plans and build plan steps that are
designed to work right out of the box. These sample build plans are very important, because they demonstrate the steps
needed to perform the most common deployment related operations. Although you can create your own build plans
from scratch, it is expected that most users will start with one of the provided samples and modify it to perform the
functions they need.
This document provides detailed information on
•
the architecture of OS Build Plans,
•
what OS Build Plans, scripts, packages, and configuration files are available in the appliance library,
•
how to use the scripts parameters, and
•
best practices when using these objects.
This technical white paper presumes that the reader is familiar with IC server provisioning. For IC server provisioning
installation information, refer to HP Insight Control Server Provisioning Installation Guide. IC server provisioning
documentation can be found at www.hp.com/go/insightcontrol/docs.
OS Build Plans
Although build plans are referred to as OS Build Plans, they do much more than operating system deployment. For
example, build plans can also be used to
•
Configure a target server’s hardware.
•
Capture a target server’s hardware configuration, so that the same configuration can later be applied to other
servers.
•
Update the firmware on a target server.
•
Install software on a target server with a running operating system.
•
Add scripts to perform additional tasks on the target server after it has been installed.
Since build plans are simply ordered steps, just about anything that can be done by a script, can be done in a build plan.
IC server provisioning provides four types of sample build plans:
ProLiant Hardware
Build plans labeled with ProLiant HW perform hardware-related functions on target servers such as booting the target
server to the proper service OS, or capturing or configuring hardware settings.
ProLiant Operating System
Build plans labeled with ProLiant OS deploy an operating system to target servers either via scripted or image
installation.
ProLiant Software
Build plans labeled with ProLiant SW perform functions on target servers to update the firmware or install/update
software on target servers running a production operating system.
ProLiant Combination
Beginning with IC server provisioning release 7.2.2, build plans labeled with ProLiant COMBO perform a combination of
functions on target servers, such as hardware-related configurations, deploying an operating system, and installing
software.
13
OS Build Plan Steps
Build plans are made up of a series of build plan steps that execute in order to perform the actions. Four types of steps
are available: Run Script, Deploy Package, Deploy Configuration File, and Capture Configuration File.
Run Script
The run script step is the key component of the product, and represents the vast majority of steps used in build plans.
This step type causes a script to be executed, either on the target server or on the appliance. IC server provisioning
comes with an extensive library of scripts that perform many of the most common tasks you will need when creating
build plans. In addition, you can create your own scripts based on the ones HP provides or entirely from scratch.
IC server provisioning supports the following script types:
OGFS
OGFS scripts control the HP Server Automation engine that is inside the IC server provisioning appliance. These are the
only scripts that execute on the appliance. All other script types run on the target server. Most of the OGFS scripts
shipped with the appliance come from Server Automation, are written in Python, and are not meant to be modified in any
way. They provide vital functions like booting target servers, monitoring tasks, and manipulating data. HP does not
recommend creating OGFS scripts unless you have advanced knowledge of Server Automation.
Python
Python scripts execute on the target server. This is the only script type that can be run on either Windows or Linux
systems.
Unix
These are standard Unix/Linux shell scripts that execute on the target server.
Windows BAT
These are standard Windows batch scripts that execute on the target server.
Windows VBScript
These are standard Windows Visual Basic scripts that execute on the target server.
Powershell
IC server provisioning does not currently support PowerShell as a script type. However, a Windows batch script can be
created
•
that dynamically generates the PowerShell script and then runs the script on the target server,
•
pipes the PowerShell content into the PowerShell interpreter to run it,
•
or copies a PowerShell script from the Media Server to the target server and then runs it.
Deploy Package
In IC server provisioning, packages are zip files stored on the appliance. When the deploy package step is used, the zip
file is transferred to the target server and uncompressed into the specified location. Pre-installation and postinstallation scripts may also be specified with the package that will execute before or after the package is saved to the
target server and the files extracted. All the packages on your appliance are provided by HP. They are typically things
like driver bundles and software libraries needed for installing on ProLiant servers. At this time, there is no option to
allow you to upload your own packages or save and modify copies on the appliance, although that functionality is
planned for a future IC server provisioning release. A package or file may be stored on the Media Server and uploaded to
a target server using simple build plan steps. The HP Insight Control server provisioning Adding Drivers to OS Build Plans
technical white paper uses this method to add drivers to an OS deployment build plan.
Deploy Configuration File
Configuration files are text files stored on the appliance that are used for text-based data such as unattended
installation files or hardware configuration files. The deploy configuration file step takes the specified configuration file
and writes it to a user-specified location on the target server. These steps are often followed by a run script step that
makes use of the configuration file. HP provides many sample configurations. You can use these or create your own.
14
Capture Configuration File
This step allows you to capture a text file from the target server and upload it to your appliance database so that it can
later be used as part of a deploy configuration file step. This capture step is typically used to capture the configuration
of a hardware component, so that the same configuration can be applied to other servers. Use caution with this step as
you can easily create a large number of configuration files if you run a build plan against many servers.
Working with OS Build Plans
All of the HP-provided build plans and build plan steps are read only which gives you a consistent and reliable source for
working samples. Although most of the HP-provided build plans will work without modification, it is highly unlikely the
HP-provided build plans will exactly meet your requirements. It is expected that you will create your own build plans
based on the examples we have provided.
Here is a very common customization example of how to modify a build plan to use a new configuration file:
1.
Open the HP-provided configuration file to be modified and make a copy using Actions > Save as.
2.
Modify the new configuration file.
3.
Open the HP-provided build plan to be modified with the new configuration file and make a copy using Actions
> Save as.
4.
Edit the newly copied build plan.
a.
In the Steps section of the edit page, find the HP sample configuration file to be replaced and select
the Edit icon for that step. This will open the edit screen for that step.
b.
Click the drop down and select Select Another and then the newly modified configuration file
created in Step 2.
c.
The parameters from the original configuration file will remain, although they can be edited if
necessary.
d.
Click OK to save the step change.
e.
Click OK to save the new build plan.
It is important to understand that the steps listed in a build plan are references or links. That means that if the contents
of a script or a configuration file are modified, every build plan that uses that step will change with that modification.
However, the parameters that are specified for that build plan step are stored with the build plan and can be changed
without affecting the other build plans.
Modifying a build plan should not require a lot of changes. Most of the steps in the sample build plans are required,
because they do actions such as boot the server, setup the installation and install agents. The following sections cover
some of the most common types of changes that you may need to make. The detailed build plan descriptions in later
sections will give indications as to which steps commonly need to be changed.
Modifying Configuration Files
The default build plans come with sample configuration files. These might be sample unattended files for installing
Windows, kickstart or autoyast files for installing Linux, or hardware configuration files for configuring a system option.
Additionally, sample configuration files are provided for each supported Windows edition. By far, the most common
modification will be to replace the HP sample configuration file with a customized configuration file.
Adding Scripts
Another common modification is to perform additional tasks on the target server after it has been installed. You can do
this by creating scripts, and then adding those scripts to the end of the build plan after the operating system installation
is complete.
15
Modifying Build Plan Step Parameters
Some build plan steps are controlled by the parameters associated with that step. You may wish to change these
parameters to better suit your needs. For most of the HP-provided scripts, a summary of parameters for that script are
listed in the script’s description field.
Combining Build Plans
Combining multiple build plans into one build plan may be desired if a series of build plans are frequently run in the same
order. For example, to configure the system ROM, setup the RAID controller, and then install the operating system. In
most cases, combining build plans is as simple as combining all of the steps and parameters from the multiple build
plans and putting them into one large build plan in the same order. This is easily accomplished when editing a build plan,
by selecting Copy steps from existing OS Build Plan when adding steps to your build plan.
Once all of the steps are put together, you may find it beneficial to make slight adjustments to the combined build plan
that will make it more efficient or provide better error checking. HP provides some sample build plans that can be used
as an example of combining build pans and the types of modifications one might make to them once they are combined.
See the detailed breakdown of the combo build plans in the following section for descriptions of such modifications.
Detailed Breakdown of Sample Build Plans
Looking at a build plan for the first time can be somewhat intimidating. Some have many steps you may not fully
understand, which can make modifying and troubleshooting them very challenging.
This section provides information on the various steps of the HP-provided build plans. It will explain what the steps do,
the order they are in, if they are required, and if they are meant to be modified. It will also explain the general methods
used to perform the build plan’s functionality. It is suggested to review all the build plan samples in this section since
information that appears in multiple build plans will not be explained more than once.
NOTE: These examples are just a sampling of all the build plans HP provides and may not exactly match the build plans
on the appliance, but the information provided will still be valid.
Sample Build Plan: Windows Scripted Install
Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted Install build plan sample
Step
Number
1
2
3
4
5
6
16
Step Name
Step Type
Step Parameters
Validate Custom Attributes
OGFS
--custAttrNames "ProductKey_Win2012-Std-x64"
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
--secure=disabled
Boot
OGFS
--serviceOS=winpe64
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
--maintenance --atLeast=3 --atMost=20
7
8
Hide Intelligent Provisioning drives
OGFS
Install and boot into local WinPE
OGFS
--systemDiskNumber=@SystemDiskNumber:0@ --systemDrive=@SystemDrive:c@
Set Media Source
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Python
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSW-MediaWinPath@#z
Configure Windows Partitioning Scheme for Legacy
Deploy configuration file
x:\Windows\Temp\diskpart_legacy.txt
Configure Windows Partitioning Scheme for Uefi
Deploy configuration file
x:\Windows\Temp\diskpart_uefi.txt
Partition Disk for Windows
Python
--systemDiskNumber=@SystemDiskNumber:0@
Windows 2012 Standard x64 en_us Unattend
Deploy configuration file
x:\Windows\Temp\Unattend.xml
Inject Required Unattend.xml Settings
OGFS
Inject Personalization Settings
OGFS
ProLiant Drivers for Windows 2012
Deploy package
@SystemDrive:c@:\$oem$
Run Windows 2012 x64 Setup
Windows .BAT
"z:\Media\win2012-x64-en_us\setup.exe"
Integrate HP SA Agent
OGFS
Reboot
OGFS
Wait for HP SA Agent
OGFS
--production --atLeast=3 --atMost=30
Personalize Network Settings of Installed System
Python
Wait for HP SA
Agent
OGFS
--production
Steps 1 and 3 – Early error detection
These first three steps help catch errors that might affect the running of the build plan later on. Most of the HP-provided
build plans contain a varying number steps like this example. The idea is that it’s better to catch an error right away than
after the build plan has been running for a while.
•
Validate Custom Attributes – This step checks for the existence of custom attributes (CAs) that are required for
the build plan to run, and it will verify that the custom attribute has a value. It will check for any CAs specified
in the parameters section. It does not validate the custom attribute value. For this build plan, it is checking to
17
verify that the product key for this particular OS has been defined. If this build plan step was not included and
the product key custom attribute was not defined, the build plan would fail toward the end of the installation.
This step catches that potential mistake right away so that it can be corrected more quickly. If it is preferred
not to do this type checking up front, this step can safely be removed from any build plan. Also note that if the
build plan is modified to install a different edition of the OS, This step will require modification to include the
matching custom attribute for that version.
•
Check iLO Service – This step verifies that the target server on which the build plan is running on has an iLO
management processor associated with it in the appliance database. This is important, because the boot step
later in the build plan needs to communicate with the iLO to boot the server. If the target server was
discovered by PXE booting, the iLO registration for that server happens after the server appears in the
appliance. The check iLO service step will wait up to 15 minutes for that registration to complete.
•
Verify Supported Boot Modes – This step verifies that the target server is configured in a boot mode that is
supported by the build plan. The boot modes that the build plan supports can be specified as a script
parameter. The parameter --secure=disabled means this build plan can only be run on a server with UEFI
secure boot disabled. See the reference section below for the other available boot modes.
Steps 4 to 6 – Boot the server for provisioning
The next set of steps are used to boot the server into the required service OS and test the status of the server such that
it can be provisioned. Once these steps are done, the server is in maintenance, and ready to start the provisioning
process.
•
Boot – The boot step is used to get the server into the appropriate service OS for provisioning. The desired
service OS is specified in the parameters of the step, in this case, winpe64. When this step runs, it first checks
to see if the server is already in that service OS, and if it is, the step exits. If the server is not in the right service
OS, it contacts the iLO to power down the server, set the required boot parameters, and power the server back
on. Note that once the boot is initiated, the step exits. The Wait for HP SA Agent step below will wait for the
boot to complete.
•
Decommission Server – This step only has an effect if a server is being re-provisioned that was already
installed and running the HP SA agent. It tells the appliance that this target server is no longer going to be used
as a production server and that it can be booted to maintenance and re-provisioned. If the target server was
not previously installed and managed, this step does nothing. If this step is removed from the build plan, and
you choose to reprovision a server, you will need to run either one of the Prepare Server for Reprovisioning
build plans, or delete the target server from the appliance and re-add it. Note that this step must always come
between the Boot and Wait for HP SA Agent steps. When combining build plans, make sure the decommission
step only appears after the first boot step, and remove any subsequent instances of it.
•
Wait for HP SA Agent – A boot step will always have this step after it. It waits for the boot to complete and the
agent to contact the appliance. It then verifies that the server is in the appropriate mode as specified by the
parameter, in this case “maintenance”. The other parameters specify the minimum and maximum wait times
for this step. In this case, the step will wait 3 minutes, and then start checking if the agent is running on the
target server. If communication with the agent has not been established after 20 minutes, the build plan fails.
Depending on the circumstances, it may be necessary to adjust these parameters.
Steps 7 to 16 – Stage the installation
These steps perform all the work of setting up for the installation by partitioning the system drive, copying files, putting
drivers in place, and preparing the unattended file.
•
Hide Intelligent Provisioning drives – HP ProLiant Gen8 and newer servers have multiple embedded flash drives
that are part of the new advanced features of these platforms. Some OS installation programs can see these
flash drives and incorrectly try to install the operating system to them causing the installation to fail. This step
does some work to help the OS installation program identify these drives and not install to them. The
SystemDiskNumber custom attribute is modified by this step if not already set. For HP ProLiant servers prior
to Gen8, this step has no effect.
•
Install and boot into local WinPE – This step makes sure that your server is running the proper version of
WinPE for this particular Build Plan and also helps to correct boot mode mis-matches when booting Intelligent
Provisioning. If this step detects that the currently running WinPE version does not match the version specified
in the parameters to this step, it will write the correct version of WinPE to a temporary partition and boot that
partition. This way the server will always be running the correct version of WinPE.
You will note that the parameters in this Build Plan do not explicitly call out a version of WinPE. That is because
Windows 2012 can use either WinPE version, but if you look at Build Plans for Windows 2008 and 2008 R2, you
will see the version parameter in action.
18
This step is recommended for all Windows Build Plans to always make sure the correct version of WinPE is
running before starting the actual OS installation. See the complete description of this step later in this
document for more information.
•
Set Media Source – This is the step that points the build plan to the OS distribution media on the media server.
The parameter for this step is made up of three special custom attributes all strung together. These are hidden
custom attributes that correspond to the information specified in the Media Server Settings page. These
custom attributes should always be used together like this when installing a Windows OS. At run time, these
custom attributes are substituted, and the result is a URI that takes this form:
smb://username:password@media-server-IP/share-name#drive-letter
where username:password are the credentials for the media server, and drive-letter is the drive
letter the share will be mounted. Optionally, all three custom attributes can be replaced with customized
values as long as it conforms to URI specification above.
For Windows build plans, the Set Media Source step actually does the mapping of the network drive into the
service OS.
If the Media Server is Windows Server 2012 and a domain account is being used to access the media server,
parameters for the Set Media Source step within the HP-provided build plans must be modified as follows:
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSW-MediaWinPath@#/mnt/ms?noserverino,domainname=icspmedia-01
where icspmedia-01 is the HOSTNAME of the Media Server, because the Media-Winuser is a local user on the
server.
NOTE: Due to text formatting within this document, the above line is actually one line not set separated by
spaces.
If a domain account is being used to access the share, you need to specify the domain instead of the hostname.
•
Configure Windows Partitioning Scheme for Legacy – Configuration file that contains diskpart commands,
which create a BIOS/MBR system partition. This file is written to the disk but is only used if the server is
running in Legacy mode.
•
Configure Windows Partitioning Scheme for Uefi – Configuration file that contains diskpart commands, which
create a UEFI/GPT system partition. This file is written to the disk but is only used if the server is running in
UEFI boot mode.
•
Partition Disk for Windows – This step uses one of the two configuration files written in the previous steps to
partition the hard drive for OS installation. The configuration file used depends on whether the server is in
Legacy or UEFI boot mode. Partitioning is performed using the diskpart utility.
•
Windows 2012 Standard x64 en_us Unattend – This is a deploy configuration file step. It writes the HPprovided unattend file to the target server’s ram drive. It is recommended to replace this step with a
customized unattend file using the HP-provided configuration files as a template since these template files
contain the Custom Attribute syntax. The path specified by the parameter is where the file is written.
Subsequent build plan steps expect to find this file in that location, so it is recommended that the path not be
changed. NOTE: The partitioning of the boot disk is performed in the previous Partition Disk for Windows OSBP
step. Refer to the Partition Disk for Windows script description in the Scripts section within this document for
important information about disk partitioning.
•
Inject Required Unattend.xml Settings – This is a script that adds required items to the unattend file to make it
work properly with the appliance. This script is required and always comes right after the step that writes out
the unattend file.
•
Inject Personalization Settings – This step is used when static IP addressing information is specified as part of
the installation in the Run OS Build Plan page. Setting network information there causes a server-level custom
attribute named, hpsa_netconfig, to be created and assigned to each server being provisioned.
hpsa_netconfig is not created or set manually by the user. The Inject Personalization Settings step checks for
the existence of that custom attribute. If it exists, the network information is read and the unattend file is
modified to include the static IP information. This step should always follow the Inject Required Settings step.
Note: The hpsa_netconfig custom attribute is not removed after it is set, so it could be there if another build
plan is run against the same target server.
19
•
ProLiant Drivers for Windows 2012 – This is a zip file containing the latest ProLiant drivers for this operating
system. They are placed in the directory specified by the parameter, which is where the Windows OS installer is
expecting to find them.
Steps 17 to 20 – Perform the installation and post-install tasks
These steps actually perform the OS installation, add the production agent, and perform the final reboot of the server.
•
Run Windows 2012 x64 Setup – This is the step that runs the Windows installation. It is a batch script that calls
the Windows setup.exe program to perform the installation. The parameter for this step is the full path to the
setup.exe program on the Media Server. Note that it references drive Z, which is the drive specified in the Set
Media Source step. If the drive letter in Set Media Source is changed, it needs to be changed here as well.
•
Integrate HP SA Agent – This step adds the HP Server Automation agent to the newly installed operating
system.
•
Reboot – Initiates a reboot of the server to finalize the installation. Note that the Reboot step is used here
instead of the Boot step. The Reboot step is specifically meant for rebooting a server to its local disk and back
into production.
•
Wait for HP SA Agent – This is the same step as before, but this time it is waiting for the agent to register in
production mode. Also, note that the atMost parameter is now 30 minutes since booting Windows for the
first time after an installation takes extra time while automatic configuration is performed.
Steps 21 and 22 – Perform the post install network personalization
Earlier in the Build Plan, there were steps to configure the deployment NIC on the target server. These final steps apply
any requested network configuration to the remaining NICs, allowing all the NICs of the server to be configured as part
of a single OS deployment job.
•
Personalize Network Settings of Installed System – This step does the work of personalizing all the NICs on the
target server based on the values provided in the hpsa_netconfig custom attribute. This step can only be run
against an installed OS which is why it appears here after the OS installation has completed. If no
hpsa_netconfig custom attribute is found, the step does nothing. If you know you will never do network
personalization, this step can be safely removed.
•
Wait for HP SA Agent – The previous step may cause the network settings of your target server to change,
which may interrupt communication between the agent and the appliance. This step is required after the
network personalization step in case the network connection is broken. The step waits for communication to
be restored and the agent to come back online before exiting. The default wait time is 15 minutes. If you
remove the previous step, you should remove this step as well.
Sample Build Plan: Windows Image Capture
Table 2 – ProLiant OS – Windows 2012 Standard x64 Image Capture build plan sample
Step
Number
1
2
3
4
5
20
Step Name
Step Type
Step Parameters
Validate Windows OS Version
--version=Win2012
Validate Custom Attributes
OGFS
OGFS
--custAttrNames "WimFileName"
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
--secure=disabled
Unmap Network Drive
Python
--driveLetter=Z
Set Media Source
6
7
8
9
10
11
@__OPSW-Media-WinUser@@__OPSW-MediaWinPassword@@__OPSW-Media-WinPath@#z
Prevent WIM File Overwrite
14
15
16
17
18
19
Windows .BAT
"Z:\Images\@WimFileName@"
ImageX
Deploy package
%SystemDrive%\HPPROVTEMP
Validate ImageX Package Contents
Windows .BAT
Uninstall HP ProLiant Utilities
Windows VBScript
Prepare Windows for Image Capture
Windows .BAT
Boot
OGFS
12
13
Python
--serviceOS=winpe64
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
--maintenance --atLeast=3 --atMost=20
Hide Intelligent Provisioning drives
OGFS
Remap Windows Drives
Python
ImageX
Deploy package
X:\Windows\System32
Validate ImageX Package Contents
Windows .BAT
Unmap Network Drive
Python
--driveLetter=Z
Set Media Source
20
21
@__OPSW-Media-WinUser@@__OPSW-MediaWinPassword@@__OPSW-Media-WinPath@#z
ImageX Configuration - Exclusion List
Deploy configuration File
x:\wimscript.ini
Windows Image Capture
22
Python
Python
--wimFilePath="Z:\Images\@WimFileName@"
--systemDiskNumber=@SystemDiskNumber:0@
21
Important: On a new appliance, the ImageX zip package used in build plan steps 6 and 14 contains a dummy file and
does not contain the imagex.exe utility. imagex.exe is one of the things that are uploaded to the appliance when you
build and upload WinPE as described in the installation guide.
Steps 1 to 4 – Early error detection
The first four steps help catch errors that might affect the running of the build plan later on.
•
Validate Windows OS Version - The first step verifies that the target server is running a Windows version that is
appropriate for this particular Build Plan. It is used in capture Build Plans because it is possible to capture a
Windows image using the wrong version of the Build Plan, and you will not find out that it did not work until
you try to deploy. For more information about this step, refer to the Validate Windows OS Version script.
•
For steps 2 to 4, Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted Install build plan sample
and the detailed descriptions in the Steps 1 to 3 – Early error detection section for that table
Steps 5 to 7 – Test for an existing image
These steps provide more early error detection. They ensure that a previously captured WIM image file is not
accidentally overwritten. If you want this capture build plan to be able to overwrite a previous image, all three of these
steps can be removed from the build plan.
•
Unmap Network Drive – This step unmaps the network drive to ensure that a drive used by a previous build
plan is available for use by the current build plan.
•
Set Media Source – This step mounts the file share from the Media Server so that the following, Prevent WIM
File Overwrite step can check if there is already an image on the Media Server with the same file name specified
in the @WimFileName@ custom attribute.
•
Prevent WIM File Overwrite – This step ensures that a WIM file that was previously captured is not accidentally
overwritten. The @WimFileName@ custom attribute used by the build plan contains the name of the file
where the captured image will be saved. If the intent is truly to replace a previously captured image using the
same file name, remove the file for the old image from the Media Server.
Steps 8 and 9 – Test for valid ImageX package
These steps ensure that the ImageX package contains the imagex.exe utility and not the dummy file as mentioned
above in the note. Like the early error detection build plan steps, these steps are for early detection that the imagex.exe
utility was uploaded properly to the appliance and fails the build plan before it is rebooted into the service OS where the
imagex.exe utility will actually be run.
•
ImageX – This is a zip package containing the imagex.exe utility that is needed to capture the Windows OS.
•
Validate ImageX Package Contents – Verifies that the ImageX package from the previous step contained the
required imagex.exe utility and not the dummy file.
Steps 10 and 11 – Prepare production OS for capture
These steps ensure that the production OS is left in a state where it can be captured and will not cause any conflicts
when it is deployed to a different target server.
•
Uninstall HP ProLiant Utilities – Some HP ProLiant Utilities store server-specific information and, therefore,
must not be included in the captured image. These agents or utilities will not operate properly when deployed
to a different target server. This step removes these agents before the system is captured.
•
Prepare Windows for Image Capture – This step removes unique information from the Windows OS using
sysprep so that the image can be safely used on a different target server, and configures the Windows
installation to boot to Out-of-box Experience (OOBE) the next time that the server boots.
Steps 12 through 14 – Boot the server for capture
The next set of steps is used to boot the target server into WinPE for the purpose of capturing the image.
•
Boot – Reboots the target server into WinPE.
•
Decommission Server – Turns off the agent management connection as described in Table 1.
•
Wait for HP SA Agent – Waits for WinPE to boot and the SA agent to be available.
Steps 15 and 16 – Adjust the drives
These steps make any necessary adjustments to the drive letters due to the presence of embedded flash drives on HP
ProLiant Gen8 servers.
•
22
Hide Intelligent Provisioning drives – Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted
Install build plan sample and the detailed description in the Steps 7 to 15 – Stage the installation section.
•
Remap Windows Drives – For cases where the previous Hide Intelligent Provisioning drives step hid the
embedded flash drives, this step will remap the drive letters, so that the boot disk is assigned the “C:” drive,
and the remaining disks are assigned to sequential drive letters.
Steps 17 and 18 – Prepare for image capture
These steps ensure that the ImageX package contains the imagex.exe utility and lands the files in the service OS to be
used for the capture. Refer to Table 2 – ProLiant OS – Windows 2012 Standard x64 Image Capture build plan sample and
the detailed description in the Steps 7 and 8 – Test for valid ImageX package section.
Steps 19 to 22 – Create WIM Image on the Media Server
These steps mount the file share from the Media Server and capture the WIM image onto the Media Server. The target
server is left in maintenance, because the Prepare Windows for Image Capture step left the server in an OOBE state and,
therefore, cannot be booted to production.
•
Unmap Network Drive – This step unmaps the network drive to ensure that a drive used by a previous build
plan is available for use by the current build plan.
•
Set Media Source – This step mounts the file share from the Media Server so that the captured image can be
saved onto the Media Server.
•
ImageX Configuration - Exclusion List – Excludes the /Boot directory for image capture.
•
Windows Image Capture – Creates a WIM image of the captured Windows OS, which it stores on the Media
Server in a file whose name is specified by the WimFileName custom attribute. Also, includes the disk number
from where ImageX will capture the system partition. Default value is set to 0.
Sample Build Plan: Windows Image Install
Table 3 – ProLiant OS – Windows 2012 Standard x64 Image Install build plan sample
Step
Number
1
2
3
4
5
6
7
8
9
Step Name
Step Type
Step Parameters
Validate Custom Attributes
OGFS
--custAttrNames "WimFileName ProductKey_Win2012-Std-x64"
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
--secure=disabled
Boot
OGFS
--serviceOS=winpe64
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
--maintenance --atLeast=3 --atMost=20
Hide Intelligent Provisioning drives
Configure Windows Partitioning Scheme for Legacy
OGFS
Deploy configuration file
x:\Windows\Temp\diskpart_legacy.txt
Configure Windows Partitioning Scheme for Uefi
Deploy configuration file
23
x:\Windows\Temp\diskpart_uefi.txt
10
Partition Disk for Windows
--systemDiskNumber=@SystemDiskNumber:0@
Set Media Source
11
12
13
16
17
18
19
ImageX
22
Deploy package
X:\Windows\System32
Validate ImageX Package Contents
Windows .BAT
Windows Image Deploy
Python
--wimFilePath="Z:\images\@WimFileName@" -systemDiskNumber=@SystemDiskNumber:0@
Windows 2012 Standard x64 en_us Unattend
Deploy configuration file
@SystemDrive:C@:\Windows\Panther\unattend.xml
Inject Required Unattend.xml Settings
OGFS
Inject Personalization Settings
OGFS
Integrate HP SA Agent
OGFS
Reboot
OGFS
Wait for HP SA Agent
OGFS
20
21
Python
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSW-MediaWinPath@#z
14
15
Python
--production --atLeast=3 --atMost=30
Personalize Network Settings of Installed System
Python
Wait for HP SA
Agent
OGFS
--production
Steps 1 and 3 – Early error detection
These first three steps help catch errors that might affect the running of the build plan later on. Refer to Table 1 –
ProLiant OS – Windows 2012 Standard x64 Scripted Install build plan sample and the detailed descriptions in the Steps 1
to 3 – Early error detection section for that table.
Steps 4 to 6 – Boot the server for provisioning
The next set of steps are used to boot the server into the required service OS and reset the status of the server such that
it can be provisioned. Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted Install build plan sample and
the detailed descriptions in the Steps 4 to 6 – Boot the server for provisioning section for that table.
24
Steps 7 to 11 – Stage the installation
These steps perform all the work of setting up for the installation by partitioning the system drive and mapping a drive
to the media server’s file share. Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted Install build plan
sample and the detailed description in the Steps 7 to 15 – Stage the installation section.
Steps 12 and 13 – Test for valid ImageX package
Refer to Table 2 – ProLiant OS – Windows 2012 Standard x64 Image Capture build plan sample and the detailed
description in the Steps 7 and 8 – Test for valid ImageX package section.
Steps 14 to 18 – Install and Customize Image
These steps install the image and perform any customization.
•
Windows Image Deploy – This step takes a previously captured image that is saved on the Media Server and
installs it on the target server’s boot disk.
•
Windows 2012 Standard x64 en_us Unattend – Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64
Scripted Install build plan sample and the detailed description in the Steps 7 to 15 – Stage the installation
section. The configuration file used with the image installation build plan is the same as with the scripted
install.
•
Inject Required Unattend.xml Settings – Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted
Install build plan sample and the detailed description in the Steps 7 to 15 – Stage the installation section.
•
Inject Personalization Settings – Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted Install
build plan sample and the detailed description in the Steps 7 to 15 – Stage the installation section.
•
Integrate HP SA Agent – This step adds the HP Server Automation agent to the newly installed operating
system.
Steps 19 and 20 – Boot the server to production
These final steps boot the server into production.
•
Reboot – Initiates a reboot of the server to finalize the installation. Note that the Reboot step is used here
instead of the Boot step. The Reboot step is specifically meant for rebooting a server to its local disk and back
into production.
•
Wait for HP SA Agent – This is the same step as before, but this time it is waiting for the agent to register in
production mode as opposed to maintenance. Also, note that the atMost parameter is now 30 minutes. This is
because rebooting Windows for the first time after an installation takes extra time while automatic
configuration is performed.
Steps 21 and 22 – Perform the post install network personalization
These final steps actually perform the network personalization of target server after OS installation.
Personalize Network Settings of Installed System – This step personalizes network settings of the server after OS
installation using values provided by custom attribute ‘hpsa_netconfig’Wait for HP SA Agent – This step is required right
after network personalization step to make sure that agent is operational before other steps can be executed. The step
waits for the agent to register in production mode with the default wait time of 15 minutes.
Sample Build Plan: Linux Scripted Install
Table 4 – ProLiant OS – RHEL 6.3 x64 Scripted Install build plan sample
Step
Number
1
2
3
Step Name
Step Type
Step Parameters
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
--secure=disabled
Boot
OGFS
25
--serviceOS=linux64
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
26
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
--maintenance --atLeast=3 --atMost=20
Set Media Source
Python
@__OPSW-Media-LinURI@/rhel63-x64
RHEL 6.3 x64 en_us Kickstart
Deploy configuration file
/tmp/user.ks.cfg
Inject Required Kickstart Settings
OGFS
Red Hat Enterprise Linux Server 6 X86_64
Inject Kickstart Personalization Settings
OGFS
Create Stub Partition
Unix
Copy Boot Media
Unix
ProLiant Drivers for RHEL 6.3 x64
Deploy package
GRuB Boot Loader x86
Deploy package
Deploy Agent
Unix
-d /tmp/opt/opsware/agent/ogfs-agent.zip –u
Embed files initrd
Unix
-s /tmp/user.ks.cfg:/ -s /tmp/opt/opsware/agent:/opt/opsware/ -s /tmp/dud/.:/
Install bootloader for RedHat Enterprise Linux Server
Unix
--kernel_arguments="@kernel_arguments@"
Reboot
OGFS
Wait for HP SA Agent
OGFS
--maintenance --atLeast=3 --atMost=20
Monitor Installation
OGFS
tmp/anaconda.log
Integrate Linux HP SA Agent
OGFS
Reboot
OGFS
22
23
24
Wait for HP SA Agent
OGFS
--production --atLeast=3 --atMost=30
Personalize Network Settings of Installed System
Python
Wait for HP SA
Agent
OGFS
--production
Steps 1 and 2 – Early error detection
The first two steps help catch errors that might affect the running of the build plan later on. Refer to Table 1 – ProLiant
OS – Windows 2012 Standard x64 Scripted Install build plan sample and the detailed description in the Steps 1 to 3 –
Early error detection section.
Steps 3 to 5 – Boot the server for provisioning
The next set of steps are used to boot the server into the required service OS and reset the status of the server such that
it can be provisioned. Once these steps are done, the server is in maintenance ready to start the provisioning process.
Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted Install sample and the detailed description in the
Steps 4 to 6 – Boot the server for provisioning section. For the Linux build plans, the desired service OS Boot step
parameter is linux64.
Steps 6 to 16 – Stage the installation
These steps perform all the work of setting up for the installation by copying files, putting drivers in place, and
preparing the kickstart file.
•
Set Media Source – This is the step that points the build plan to the OS distribution media on the media server.
The parameter for this step is made up of a special custom attribute. This is a hidden custom attribute that
corresponds to the information specified in the Media Server Settings page. At run time, this custom attribute
is substituted and takes this form:
http://media-server-IP/mnt/sharename/media
where /mnt/sharename/media is the mount point and location to the OS distribution media.
•
RHEL 6.3 x64 en_us Kickstart – This is a deploy configuration file step. It writes the HP-provided kickstart file to
the target server’s ram drive. It is recommended to replace this step with a customized kickstart file using the
HP-provided configuration files as a template since these template files contain the Custom Attribute syntax.
The path specified by the parameter is where the file is written. Follow on build plan steps expect to find this
file in that location, so it is not recommended that the path be changed.
•
Inject Required Kickstart Settings – This is a script that adds required items to the kickstart file to make it work
properly with the appliance. This script is required and always comes right after the step that writes out the
kickstart file.
•
Inject Kickstart Personalization Settings – This step is used when static IP addressing information is specified
as part of the installation in the Run OS Build Plan page. Setting network information causes a server-level
custom attribute named, hpsa_netconfig, to be created and assigned to each server being provisioned.
hpsa_netconfig is not created or set manually by the user. The Inject Kickstart Personalization Settings step
checks for the existence of that custom attribute. If it exists, the network information is read and the unattend
file is modified to include the static IP information. This step should always follow the Inject Required Kickstart
Settings step. Note: The hpsa_netconfig custom attribute is not removed after it is set, so it could be there if
another build plan is run against the same target server.
•
Create Stub Partition – Creates partition on the local disk to load the Linux build image.
•
Copy Boot Media – Copies several files to the stub partition in order to boot the installer environment.
•
ProLiant Drivers for RHEL 6.3 x64 – This is a zip file containing the latest ProLiant drivers for this operating
system. They are placed in the directory specified by the parameter, which is where the Linux OS installer is
expecting to find them.
•
GRuB Boot Loader x86 – This is a zip file contain the grub boot loader that will land on the stub partition. Even
though the name contains x86, it is still used with x64 Linux deployments.
27
•
Deploy Agent - Copies the zip file containing the agent to the target server. This agent is used to communicate
with the target server during the operating system installation and is not the same agent that is placed on the
production server.
•
Embed files initrd – Adds additional files to the new initrd image landed during the GRuB Boot Loader x86 step.
•
Install bootloader for RedHat Enterprise Linux Server – Installs the grub bootloader onto the stub partition in
order to enable booting the Red Hat Enterprise Linux Server installation image. It takes the kernel_arguments
optional custom attribute as a parameter to allow for additional kernel arguments to the installation kernel.
Steps 17 to 22 – Perform the installation and post-install tasks
These steps actually perform the OS installation, add the production agent, and perform the final reboot of the server.
•
Reboot – Reboots the target server for the purpose of booting the RHEL6.3 grub image and begin the Red Hat
installation.
•
Wait for HP SA Agent – This is the same step as before, but this time it is waiting for the agent that was
deployed in build plan step 13 to register with the appliance.
•
Monitor Installation - Periodically examines the operating system installation log file to check if the
installation has completed.
•
Integrate Linux HP SA Agent – This step adds the HP Server Automation agent to the newly installed operating
system.
•
Reboot – Initiates a reboot of the server to finalize the installation. Note that the Reboot step is used here
instead of the Boot step. The Reboot step is specifically meant for rebooting a server to its local disk and back
into production.
•
Wait for HP SA Agent – This is the same step as before, but this time it is waiting for the agent to register in
production mode. Also, note that the atMost parameter is now 30 minutes since rebooting Linux for the first
time after an installation takes extra time.
Steps 23 and 24 – Perform the post install network personalization
These final steps apply any requested network configuration to the remaining NICs, allowing all the NICs of the server to
be configured as part of a single OS deployment job. Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64
Scripted Install build plan sample and the detailed description in the Steps 20 and 21 – Perform the post install network
personalization section.
Sample Build Plan: ESXi Scripted Install
Table 5 – ProLiant OS – ESXi 5.1 Scripted Install build plan sample
Step
Number
1
2
3
4
5
6
28
Step Name
Step Type
Step Parameters
Validate Gateway Setting for Static Network Configuration
OGFS
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
--secure=disabled
Boot
OGFS
--serviceOS=linux64
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
--maintenance --atLeast=3 --atMost=20
7
8
9
10
11
12
13
Set Media Source
@__OPSW-Media-LinURI@/esxi51
ESXi 5.1 Kickstart
Inject Required ESXi 5 Kickstart Settings
Inject Kickstart Personalization Settings for ESXi 5
OGFS
Create Stub Partition
Unix
Copy Boot Media
Unix
ESXi Installation Utilities
Deploy package
Deploy Agent
Unix
-d /tmp/opt/opsware/agent/ogfs-agent.zip –p “Red Hat Enterprise Linux Server 5
X86_64” -u
15
18
19
OGFS
--accept-encrypted-password
Add ESXi Module
17
Deploy configuration file
/tmp/user.ks.cfg
14
16
Python
Unix
-s /opt/hpsa_agent –d
Add ESXi Module
Unix
-s /tmp/user.ks.cfg –a ks.cfg
Install bootloader for ESXi
Unix
--kernel_arguments=”@kernel_arguments@”
Reboot
OGFS
Wait for ESXi installation
OGFS
--atLeast=3 –atMost=60
NOTE: For ESXi 5.1 and later, ESXi naming has changed to vSphere; however, OSBPs, scripts and configuration files may
continue to state ESXi.
Step 1 to 3 – Early error detection
The first three steps help catch errors that might affect the running of the build plan later on. Refer to Table 1 –
ProLiant OS – Windows 2012 Standard x64 Scripted Install build plan sample and the detailed description in the Steps 1
to 3 – Early error detection section.
Steps 4 to 6 – Boot the server for provisioning
The next set of steps are used to boot the server into the required service OS and reset the status of the server such that
it can be provisioned. Once these steps are done, the server is in maintenance ready to start the provisioning process.
Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted Install sample and the detailed description in the
Steps 4 to 6 – Boot the server for provisioning section. For the ESXi build plans, the desired service OS Boot step
parameter is linux64.
29
Steps 7 to 17 – Stage the installation
These steps perform all the work of setting up for the installation by partitioning the system drive, copying files, putting
drivers in place, and preparing the kickstart file.
•
Set Media Source – This is the step that points the build plan to the OS distribution media on the media server.
The parameter for this step is made up of a special custom attribute. This is a hidden custom attribute that
corresponds to the information specified in the Media Server Settings page. At run time, this custom attribute
is substituted and takes this form:
http://media-server-IP/mnt/sharename/media
where /mnt/sharename/media is the mount point and location to the OS distribution media.
•
ESXi 5.1 Kickstart – This is a deploy configuration file step. It writes the HP-provided kickstart file to the target
server’s ram drive. It is recommended to replace this step with a customized kickstart file using the HPprovided configuration files as a template since these template files contain the Custom Attribute syntax. The
path specified by the parameter is where the file is written. Follow on build plan steps expect to find this file in
that location, so it is not recommended that the path be changed.
•
Inject Required ESXi 5 Kickstart Settings – This is a script that adds required items to the kickstart file to make it
work properly with the appliance. This script is required and always comes right after the step that writes out
the kickstart file.
•
Inject Kickstart Personalization Settings for ESXi 5 – This step is used when static IP addressing information is
specified as part of the installation in the Run OS Build Plan page. Setting network information there causes a
server-level custom attribute named, hpsa_netconfig, to be created and assigned to each server being
provisioned. hpsa_netconfig is not created or set manually by the user. The Inject Kickstart Personalization
Settings for ESXi 5 step checks for the existence of that custom attribute. If it exists, the network information
is read and the unattend file is modified to include the static IP information. This step should always follow the
Inject Required ESXi 5 Kickstart Settings step. Note: The hpsa_netconfig custom attribute is not removed after
it is set, so it could be there if another build plan is run against the same target server.
•
Create Stub Partition – Creates partition on the local disk to load the Linux build image.
•
Copy Boot Media – Copies several files to the stub partition in order to boot the installer environment.
•
ESXi Installation Utilities - A package containing the boot loader and Master Boot Record needed to boot ESXi.
•
Deploy Agent - Refer to Table 4 – ProLiant OS – RHEL 6.3 x64 Scripted Install build plan sample and the
detailed description in the Steps 6 to 16 – Stage the installation section.
•
Add ESXi Module – Places the file or directory specified as an argument to the “-s” into a compressed tar file so
that it can be loaded as an ESXi module when ESXi is booted. The file or directory will be visible in the file
system when ESXi boots.
•
Install bootloader for ESXi – Installs the grub bootloader onto the stub partition in order to enable booting the
ESXi installation image. It takes the kernel_arguments optional custom attribute as a parameter to allow for
additional kernel arguments to the installation kernel.
Steps 18 and 19 – Perform the installation and post-install tasks
These final steps actually perform the OS installation, add the production agent, and perform the final reboot of the
server.
•
Reboot – Reboots the target server which on next boot will boot the ESXi 5.1 grub image and begin the ESXi
installation.
•
Wait for ESXi Installation – Since there is no SA agent support for ESXi operating system, there is no Wait for
HP SA Agent step here. Instead, this special step is used, and detects when the ESXi installation is complete.
Sample Build Plan: ProLiant Hardware Configuration
Table 6 – ProLiant HW – System ROM Enable Boot from SAN build plan sample
Step
Number
30
Step Name
Step Type
Step Parameters
1
2
3
4
5
6
7
8
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
--secure=disabled
Boot
OGFS
--serviceOS=linux64
Wait for HP SA Agent
OGFS
--maintenance --atLeast=3 --atMost=20
Configure Boot From SAN
OGFS
Shutdown Server
OGFS
Boot
OGFS
--servicesOS=linux64 --force
Wait for HP SA Agent
OGFS
--maintenance --atLeast=3 --atMost=20
Steps 1 and 2 – Early error detection
The first two steps help catch errors that might affect the running of the build plan later on. Refer to Table 1 – ProLiant
OS – Windows 2012 Standard x64 Scripted Install build plan sample and the detailed description in the Steps 1 to 3 –
Early error detection section.
Steps 3 to 4 – Boot the server for provisioning
The next steps are used to boot the server into the required service OS. Once these steps are done, the server is in
maintenance ready to start performing tasks. Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted
Install sample and the detailed description in the Steps 3 to 5 – Boot the server for provisioning section. For the
hardware build plans, the desired service OS Boot step parameter is linux64.
Note that this build plan does not have the Decommission server step. That is because you might choose to use this
build plan on a server in production and would not want to decommission it. However, if you use this build plan as the
first part of a combo build plan, you will want to insert the decommission step between steps 3 and 4.
Steps 5 to 6 – Configure the server to boot from the SAN
These steps make the necessary changes to the System ROM to allow the server to boot from the SAN using the Fibre
Channel Controller.
•
Configure Boot From SAN – Configures the System ROM via the iLO, such that the embedded Smart Array and
SATA Storage Controllers are disabled, leaving only the Fibre Channel Controller enabled. This step does not
attempt to enable the Fibre Channel Controller if it is disabled.
•
Shutdown Server – This step shuts down the server in order to fulfill the requirement of a cold boot when
disabling the storage controllers.
Steps 7 to 8 – Perform the post configuration tasks
These final steps perform the final cold boot of the target server to apply the new configuration.
•
Boot – Boots the target server back into the service OS to allow the changes that were made in the System
ROM to take effect.
•
Wait for HP SA Agent – This is the same step as before, waiting for the reboot to complete and the system to
boot back into maintenance. The parameters for these two steps could be modified to boot the server back
into production mode, if that is preferred.
31
Sample Build Plan: ProLiant Software Install
Table 7 – ProLiant SW – Offline Firmware Update build plan sample
Step
Number
1
2
3
4
Step Name
Step Type
Step Parameters
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
--secure=disabled
Boot
OGFS
--serviceOS=linux64
Wait for HP SA Agent
--maintenance --atLeast=3 --atMost=20
Set Media Source
5
6
7
8
9
10
OGFS
Python
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSW-MediaWinPath@#/mnt/media?noserverino
LinuxPE add-on packages
Deploy package
/
LinuxPE HBA add-on packages
Deploy package
Update Firmware Using SPP
Unix
--spp_version=@SPPversion:latest@
Boot
OGFS
--servicesOS=linux64 --force
Wait for HP SA Agent
OGFS
--maintenance --atLeast=3 --atMost=20
Steps 1 and 2 – Early error detection
The first two steps help catch errors that might affect the running of the build plan later on. Refer to Table 1 – ProLiant
OS – Windows 2012 Standard x64 Scripted Install build plan sample and the detailed description in the Steps 1 to 3 –
Early error detection section.
Steps 3 and 4 – Boot the server for provisioning
The next set of steps are used to boot the server into the required service OS and reset the status of the server such that
it can be provisioned. Once these steps are done, the server is in maintenance ready to start the provisioning process.
Refer to Table 1 – ProLiant OS – Windows 2012 Standard x64 Scripted Install sample and the detailed description in the
Steps 4 to 6 – Boot the server for provisioning section. For the hardware build plans, the desired service OS Boot step
parameter is linux64.
Steps 5 and 7 – Prepare for firmware update
These steps perform the work of setting up for firmware update on the target server by connecting to the Media Server
where the SPP files are located and landing appropriate libraries needed in the service OS environment.
•
32
Set Media Source – This is the step that points the build plan to the SPP bundle on the Media Server. The
parameter for this step is made up of three special custom attributes all strung together. These are hidden
custom attributes that correspond to the information specified in the Media Server Settings page. These
custom attributes should always be used together. At run time, these custom attributes are substituted, and
the result is a URI that takes this form:
smb://username:password@media-server-IP/share-name#mount_point?noserverino
where username:password are the credentials for the media server, and mount_point is the share that
will be mounted. Optionally, all three custom attributes can be replaced with customized values as long as it
conforms to URI specification above. Note that the noserverino option is necessary when mounting a
Windows share using the Linux service OS Samba client.
•
LinuxPE add-on packages – This is a zip file containing additional libraries and utilities required in the LinuxPE
PXE service OS.
•
LinuxPE HBA add-on packages – This is a zip file containing additional libraries and utilities required in the
LinuxPE PXE service OS for managing storage HBAs.
Steps 8 to 10 – Perform the update and post-install tasks
These final steps actually perform the firmware update and perform a reboot of the server.
•
Update Firmware Using SPP – This step actually runs the HP Smart Update Manager to upgrade the firmware on
the target server. Since the Media Server can contain several SPP versions, this script takes a parameter with a
SPP version custom attribute name to assign a specific SPP version or it’ll use the latest in the Media Server.
This script expects the SPP location on the Media Server to be /Media/SPP/yyyy.mm.x where
yyyy.mm.x is the SPP version number. This path cannot be easily changed.
•
Boot – Reboots the target server back into the service OS to force the ProLiant Scripting Toolkit utility changes
to be available at next reboot.
•
Wait for HP SA Agent – This is the same step as before, but this time it is waiting for the agent to register in
production mode.
Sample Build Plan: Combination Hardware, Windows Scripted Install, and
SPP
Table 8 – ProLiant COMBO - BFS + Windows 2012 R2 + SPP build plan sample
Step
Number
1
2
3
4
5
6
7
Step Name
Step Type
Step Parameters
Validate Custom Attributes
OGFS
--custAttrNames "ProductKey_Win2012-Std-x64"
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
--secure=disabled
Boot
OGFS
--serviceOS=winpe64
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
--maintenance --atLeast=3 --atMost=20
Configure Boot From SAN
OGFS
33
8
9
10
11
Shutdown Server
OGFS
Boot
OGFS
--serviceOS=winpe64
Wait for HP SA Agent
--maintenance --atLeast=3 --atMost=20
Install and boot into local WinPE
12
14
15
16
17
18
19
20
21
22
23
24
34
OGFS
--systemDiskNumber=@SystemDiskNumber:0@ --systemDrive=@SystemDrive:C@
Set Media Source
13
OGFS
Python
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSW-MediaWinPath@#z
Hide Intelligent Provisioning drives
OGFS
Configure Windows Partitioning Scheme for Legacy
Deploy configuration file
x:\Windows\Temp\diskpart_legacy.txt
Configure Windows Partitioning Scheme for Uefi
Deploy configuration file
x:\Windows\Temp\diskpart_uefi.txt
Partition Disk for Windows
Python
--systemDiskNumber=@SystemDiskNumber:0@
Windows 2012 R2 Standard x64 en_us Unattend
Deploy configuration file
x:\Windows\Temp\Unattend.xml
Inject Required Unattend.xml Settings
OGFS
--WindowsPartitionID=Autodetect
Inject Personalization Settings
OGFS
--require-netconfig=@require_netconfig:false@
ProLiant Drivers for Windows 2012 R2 – yyyy.mm
Install ZIP
@SystemDrive:c@:\$oem$
Run Windows 2012 R2 x64 Setup
Windows .BAT
"z:\Media\win2012-x64-en_us\setup.exe"
Integrate HP SA Agent
OGFS
Reboot
OGFS
Wait for HP SA Agent
OGFS
--production --atLeast=3 --atMost=30
Personalize Network Settings of Installed System
Python
25
Wait for HP SA Agent
26
--production
Set Media Source
27
28
29
30
31
32
OGFS
Python
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSW-MediaWinPath@#z
Install Windows SPP In Background
Python
--spp_version=@SPPversion:latest@
Wait for HP SA Agent
OGFS
--production --atLeast=2 --atMost=60
Report Windows SPP Installation Results
Python
Reboot
OGFS
Wait for HP SA Agent
OGFS
--production --atLeast=3 --atMost=30
How these build plans were combined
This COMBO build plan gives an example of how multiple individual build plans that are frequently used together can be
combined into one large build plan. The steps themselves will not be discussed in this section as they have been
discussed in previous sections. Instead, this section will go into detail about what was done to combine these build
plans and what modifications were made to the build plan once they were combined. Use the information in this section
as a guide when creating other combined build plans.
What this build plan does
This build plan is an example of combining a set of actions that frequently go together; enabling the boot from SAN
functionality, installing the operating system, and installing the SPP. It is a combination of three of the build plans that
are provided with the appliance:
•
ProLiant HW - System ROM Enable Boot from SAN
•
ProLiant OS - Windows 2012 R2 Standard x64 Scripted Install
•
ProLiant SW - Install Windows SPP
It would have been acceptable to take these three build plans and simply concatenate the steps and parameters in order
to make this combined build plan, but several modifications were made to make the build plan more efficient and more
reliable. It is these modifications that are described in the rest of this section.
For clarity, the descriptions below refer to three sections of the build plan. These sections correspond to the groupings
of steps that make up each of the three concatenated build plans.
Step 1 – Move error checking to head of build plan
The Validate Custom Attributes, Check iLO Service, and Verify Supported Boot Modes build plan script steps were moved
from the beginning of the OS installation section to the beginning of the combined build plan. Remember, this step is
used for early error detection. It is better to do all the error checking at the head of the build plan, so if the custom
attribute is not defined, the build plan will fail with this error before the system ROM is modified.
35
Step 5 – Decommission Server after the first Boot step
The Decommission Server build plan script step was moved from the OS installation section to after the first Boot build
plan script step of the combined build plan. As described above, the Decommission Server step is used when
reprovisioning a server that already has an OS installed on it. When using this step, it must always be used after the first
Boot step of the build plan or the target server may not be able to boot into the service OS to perform the OS
installation.
NOTE: Moving this step is mandatory if you plan on reprovisioning a server with this build plan.
Step 9 – Modified Boot step service OS
All hardware configuration build plans run in the Linux service OS, so in the original Boot from SAN hardware
configuration build plan, the step that reboots the server to apply the settings boots the server back into the Linux
service OS. In this build plan, however, we are about to install Windows, so this boot step was modified to reboot the
server into the WinPE service OS. Had this step not been modified, an additional Boot step would have been needed later
to switch to the WinPE service OS which would make the build plan run that much longer while the server was rebooted.
This is strictly efficiency and could have been omitted.
Step 10 – Last step of the Boot from SAN section
The Wait for SA Agent build plan script step will wait for the agent in the WinPE service OS before beginning the OS
installation since the previous boot step was modified to boot to WinPE.
Before Step 11 – Beginning of OS installation section - Unnecessary steps removed
Step 11 begins the OS installation section of the build plan. The first five steps of the original OS installation build plan
have been moved or removed.
•
Validate Custom Attributes was moved to the head of the build plan.
•
Check iLO Service was already done at the head of the build plan so it was removed.
•
Verify Supported Boot Modes was already done at head of the build plan so it was removed.
•
The Boot step was removed since the target server will already be in the WinPE service OS as a result of
modifying Step 11 Boot step. Refer to Step 11 – Modified Boot step service OS section above.
•
Decommission Server was moved to be after the first Boot step of the build plan.
•
Wait for HP SA Agent is not needed since the Boot step was removed.
Steps 11 to 26 – The rest of the OS Installation build plan
These are the steps that perform the actual OS installation and are not modified from the original build plan.
Before Step 27 – Remove unnecessary steps
The Check iLO Service step was removed from the SPP section as that step was already performed at the beginning of
the combined build plan.
Steps 27 to 32 – The rest of the SPP build plan
These are the steps that perform the actual SPP installation and are not modified from the original build plan.
Build Plan and Build Plan Steps Reference
OS Build Plans
Summary
The build plans listed in this section are the HP-provided build plans. Each build plan is listed with detailed descriptions
and usage information. The information in this section is more detailed that what is provided in the Build Plan
description on the appliance.
ProLiant COMBO - BFS + Windows 2012 R2 + SPP
This build plan configures a ProLiant Server’s System ROM to enable Boot from SAN functionality (BFS), performs a
scripted install of Windows 2012 R2 Standard using a generic unattend file, and installs the Service Pack for ProLiant
(SPP) on the Windows operating system. For the BFS functionality, this build plan may be run on any supported HP
ProLiant blade server, DL580 Gen8, or any Gen9 or newer server. It cannot be run on a G6, G7, or Gen8 DL/ML server.
Requirements:
•
36
HP ProLiant Blade server with iLO and fibre channel controller
•
IC server provisioning Media Server must contain the OS distribution
•
IC server provisioning Media Server must contain a SPP
Required Custom Attributes:
•
ProductKey_Win2012R2-Std-x64 set using the Settings > Product Key page
Optional Custom Attributes:
•
ComputerName – Network name of the installed target server. Follow NetBIOS guidelines and 15 character
limit.
•
EncryptedAdminPassword – Administrator password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
SystemDrive – Drive label for the system drive the operating system is installed
•
SystemDiskNumber – Physical drive number for the system drive the operating system is installed. This
custom attribute is not meant to be set by the end user. It is set automatically during build plan execution and
is used to make sure the Windows installer does not install to the Intelligent Provisioning flash drives. During
re-provisioning, this value might be left over from a previous installation and cause the install to fail. Deleting
the custom attribute before running the build plan solves this.
ProLiant COMBO - BFS + RHEL7.2 + SPP
This build plan configures a ProLiant Server’s System ROM to enable Boot from SAN functionality (BFS), performs a
scripted install of Red Hat Enterprise Linux 7.2 x64 using a generic kickstart file, and installs the Service Pack for
ProLiant (SPP) on the Linux operating system. For the BFS functionality, this build plan may be run on any supported HP
ProLiant blade server, DL580 Gen8, or any Gen9 or newer server. It cannot be run on a G6, G7, or Gen8 DL/ML server.
Requirements:
•
HP ProLiant Server with iLO and fibre channel controller
•
IC server provisioning Media Server must contain the OS distribution
•
IC server provisioning Media Server must contain a SPP
Required Custom Attributes: None
Optional Custom Attributes:
•
encrypted_root_password – root password in encrypted form
•
boot_disk
•
kernel_arguments
ProLiant HW - Add Migrated Linux Server
ProLiant HW - Add Migrated Windows Server
Automatically registers an RDP migrated server’s iLO by temporarily rebooting the server into maintenance.
NOTE: These two build plans are designed to work only with target servers that were migrated to this appliance from
RDP. They make use of software that is installed as part of an RDP installation.
NOTE: These build plans will reboot the running target server into maintenance.
When a target server is initially migrated to IC server provisioning from RDP, the iLO from that server is still unknown to
the appliance. Since the iLO is required for most build plans, the iLO must be registered before other build plans can be
run. This can be done manually, or automatically by using these build plans.
Add Migrated Linux Server uses the /sbin/hpbootcfg utility to set the one-time PXE boot to a service OS and is run on
Linux-based targets. Add Migrated Windows Server uses the ProLiant Scripting Toolkit hponcfg utility to set the onetime PXE boot to a service OS and is run on Windows-based targets. The target server will be booted into the LinuxPE
environment where the server's iLO will be registered and then booted back into production.
Requirements:
•
Runs only on ProLiant Servers with iLO that were migrated from an RDP server.
37
•
Appliance must have DHCP/PXE support.
•
Presence of /sbin/hpbootcfg for Linux-based servers.
Custom Attributes: None
ProLiant HW - Boot Linux Service OS
ProLiant HW - Boot WinPE Service OS
Boots the target server into the appropriate service OS, maintenance mode, per the build plan title.
These are the build plans used when adding a server via its iLO and booting to maintenance.
Requirements: HP ProLiant server with iLO
Custom Attributes: None
ProLiant HW - Boot Local Disk
Boots a target server into production via its local disk.
NOTE: The build plan expects an agent to be running on the target when the build plan completes or the build plan will
fail, even if the target boots successfully.
Requirements: HP ProLiant server with iLO
Custom Attributes: None
ProLiant HW - Clear UEFI Boot Menu
Deletes all custom boot options from the UEFI boot menu. These are boot options that were added to the UEFI boot
menu by previously installed operating systems or manually by the user. This build plan removes all the custom boot
options, even the one for the currently installed operating system. This build plan should only be run if planning to
install a new operating system, otherwise the currently installed operating system may fail to boot.
Requirement:
•
HP ProLiant server with iLO that support UEFI
Custom Attributes: None
ProLiant HW - Erase Server
Resets a server and disks to factory defaults.
IMPORTANT: Running this build plan causes data loss.
This build plan deletes the partition table on the server's disks, clears the Smart Array configuration on any attached
Smart Array controllers, and resets the system BIOS settings to default values. The server's state is changed to
unmanaged. Note that when the BIOS is reset, the BIOS date/time becomes incorrect.
This build plan may be modified to meet your needs. For example, if your server has no Smart Array, you might need to
remove the steps that reset it.
NOTE: This Build Plan returns the server to factory default settings. Any required settings for your server including boot
settings and disk settings will need to be reapplied. If all you require is to erase the disk, you can create a build plan
consisting of Check ILO Service, Boot, Decommission Server and Erase Disk steps.
Requirements: HP ProLiant server with iLO
Custom Attributes: None
ProLiant HW - Fibre Channel HBA Configure Boot Device
Configures the boot device for an Emulex HBA, Emulex CNA, or Qlogic HBA using custom attributes.
To support Emulex or QLogic HBA, or Emulex CNA scripted configuration, this build plan configures the boot device using
the settings specified in the HBA_Config custom attribute. The configuration of the boot device is necessary in order to
38
allow the server to boot from SAN. For further information on how this build plan is used, refer to the How Do I … ?
section of the IC server provisioning online help.
Requirements: HP ProLiant server with iLO and an Emulex HBA, Emulex CNA, or QLogic HBA but not Emulex and QLogic
at the same time.
Required Custom Attributes: HBA_Config
ProLiant HW - Fibre Channel HBA Display Configuration
Displays the Emulex or QLogic HBA, or Emulex CNA configuration settings to the job log.
The Emulex or QLogic HBA, or Emulex CNA configuration is displayed to provide information about any HBAs found on
the target server, such as the HBA WWPN, link status, enable BIOS setting, selectable boot setting, primary boot port
name, and LUN.
Requirements: HP ProLiant server with iLO and an Emulex HBA, Emulex CNA, or QLogic HBA but not Emulex and QLogic
at the same time.
Custom Attributes: None
ProLiant HW - iLO Capture Configuration
Captures HP Integrated Lights-Out settings into a configuration file. The configuration file is stored on the target server
and then uploaded to the appliance.
The configuration file format is defined by the ProLiant Scripting Toolkit iLO utility.
Requirements: HP ProLiant server with iLO
Required Custom Attribute: configuration_location – The absolute filename of the captured configuration xml on the
target server. This custom attribute is already set on the HP supplied build plan, but can be modified if you make a copy
of the build plan.
ProLiant HW - iLO Set Minimum Password Length
Sets the HP Integrated Lights-Out minimum password length.
This is a sample build plan that can be modified to set any iLO settings. Just replace the configuration file with one that
specifies the settings you want. The configuration file format is defined by the ProLiant Scripting Toolkit iLO utility.
Requirements: HP ProLiant server with iLO
Custom Attributes: None
ProLiant HW - Prepare for Linux Reprovisioning
ProLiant HW - Prepare for Windows Reprovisioning
Prepares a provisioned target server for reprovisioning by decommissioning it and booting it into a service OS
(maintenance mode).
Target servers provisioned by IC server provisioning contain certificates that uniquely and securely identify the server to
the appliance. The appliance expects to retrieve this information every time the target server boots. This can cause
problems when attempting to reprovision a server or when a server’s hard drive is erased, as the service OS may not be
able to retrieve these certificates. These build plans contain the Decommission Server step, which breaks that security
requirement as part of the process of booting into the service OS.
NOTE: Only run this if you are certain that you will not want the target server to boot into production mode any more.
Once you run this build plan on a server, the production agent on that server will not be able to communicate with the
appliance.
Requirements: HP ProLiant server with iLO
Custom Attributes: None
39
ProLiant HW - Smart Array Capture Settings
Captures the HP Smart Array current configuration into a configuration file. The configuration file is stored on the target
server and then uploaded to the appliance.
The configuration file format is defined by the HP SSACLI scripting utility and may be used as input for Manage Smart
Array Configuration script. This build plan will unmounts the production drives while in the service OS.
Requirements: HP ProLiant server with iLO and a Smart Array controller
Required Custom Attribute: configuration_location – The absolute filename of the captured configuration xml on the
target server. This custom attribute is already set on the HP supplied build plan, but can be modified if you make a copy
of the build plan.
ProLiant HW - Smart Array Erase
This build plan resets the Smart Array, clearing the configuration.
IMPORTANT: Running this build plan causes the loss of all data on the Smart Array disks.
The server's state will change to unmanaged, due to potential loss of critical identification and agent association data.
Requirements: HP ProLiant server with iLO and a Smart Array controller
Custom Attributes: None
ProLiant HW - Smart Array Set RAID 1
Sets the HP Smart Array configuration for RAID 1 using two drives.
This is a sample build plan that can be modified to set any Smart Array settings. Just replace the configuration file with
one that specifies the settings you want. The configuration file format is defined by the ProLiant Scripting Toolkit SSACLI
scripting utility.
IMPORTANT: Any existing configuration is cleared, resulting in loss of existing data on the Smart Array. Additionally, the
server's state will change to unmanaged, due to potential loss of critical identification and agent association data.
Requirements: HP ProLiant server with iLO and a Smart Array controller
Custom Attributes: None
ProLiant HW - Switch to Legacy BIOS boot mode and Power Off
Switches the HP ProLiant target server that supports UEFI to Legacy BIOS boot mode and powers it off. If the boot mode
switching is not successful, the target server will stay powered on and the build plan will fail. If the target is a non-UEFI
server, this build plan will do nothing and pass successfully.
The parameter to the Control Server Bootmode script is --bootmode=LEGACY
Requirement:
•
HP ProLiant server with iLO that supports UEFI and is capable of switching between UEFI and Legacy boot
modes.
Custom Attributes: None
ProLiant HW - Switch to UEFI boot mode and Power Off
Switches the HP ProLiant target server that supports UEFI to UEFI boot mode and powers it off. If the boot mode
switching is not successful, the target server will stay powered on and the build plan will fail. If the target is a non-UEFI
server, this build plan will do nothing and pass successfully.
The parameter to the Control Server Bootmode script is --bootmode=UEFI_OPTIMIZED.
Requirement:
•
40
HP ProLiant server with iLO that supports UEFI and is capable of switching between UEFI and Legacy boot
modes.
Custom Attributes: None
ProLiant HW - System ROM Capture Settings
Captures the ProLiant System ROM settings into a configuration file. The configuration file is stored on the target server
and then uploaded to the appliance.
The configuration file format is defined by the HP System ROM scripting utility and may be used as input for the Manage
System ROM Configuration script.
Requirements: HP ProLiant server with iLO
Required Custom Attribute: configuration_location – The absolute filename of the captured configuration xml on the
target server. This custom attribute is already set on the HP supplied build plan, but can be modified if you make a copy
of the build plan.
ProLiant HW - System ROM Enable Boot from SAN
Configures the System ROM on a ProLiant server to enable Boot from SAN functionality.
This Build Plan modifies the System ROM to enable booting from a SAN using a fibre channel controller. Running this
Build Plan causes the embedded Smart Array and SATA controllers to be disabled in the System ROM, leaving only the
fibre channel controller enabled. This build plan may be run on any supported HP ProLiant blade server, DL580 Gen8, or
any Gen9 or newer server. It cannot be run on a G6, G7, or Gen8 DL/ML server. The ProLiant HW - Fibre Channel HBA
Configure Boot Device Build Plan can be run to configure the HBA or CNA.
See the Script Configure Boot From SAN for information on how to move the fibre channel controller to the top of the
boot order as part of this Build Plan.
As of version IC server provisioning 7.4.0, this Build Plan replaces ProLiant HW - System ROM Enable Boot from SAN on
Bladeserver which has been deprecated. Also note that this Build Plan is no longer used as a sample for configuring the
system ROM. ProLiant HW - System ROM Enable Virtualization is the new System ROM sample Build Plan.
Requirements: HP ProLiant Blade Server, DL580 Gen8, or any Gen9 server with iLO and fibre channel controller
Custom Attributes: None
ProLiant HW - System ROM Enable Boot from SAN on Bladeserver
IMPORTANT: This build plan is no longer available starting with IC server provisioning 7.4.0. It has been replaced with
the ProLiant HW – System ROM Enable Boot from SAN build plan.
Configures the ProLiant BladeSystem ROM to enable Boot from SAN functionality.
This is a sample build plan that can be modified to set any System ROM settings on any ProLiant server. Just replace the
configuration file with one that specifies the settings you want and that is appropriate for that particular server.
In this particular case, boot from SAN is enabled by setting the fibre channel first in the boot order and disabling any
embedded storage controller.
Requirements: HP ProLiant BladeSystem with iLO and fibre channel controller
Custom Attributes: None
ProLiant HW - System ROM Enable Virtualization
Configures the System ROM on a ProLiant server to enable CPU Virtualization and No Execute Memory Protection
settings.
This is a sample build plan that can be modified to set any System ROM settings on any ProLiant server. Just replace the
configuration file with one that specifies the settings you want and that is appropriate for that particular server.
Requirements: HP ProLiant Server with iLO
Custom Attributes: None
41
ProLiant OS - ESXi 5.0 U1 Scripted Install
ProLiant OS - ESXi 5.0 U2 Scripted Install
ProLiant OS - ESXi 5.0 U3 Scripted Install
ProLiant OS - ESXi 5.1 Scripted Install
ProLiant OS - ESXi 5.1 U1 Scripted Install
ProLiant OS - ESXi 5.1 U2 Scripted Install
ProLiant OS - ESXi 5.1 U3 Scripted Install
ProLiant OS - ESXi 5.5 Scripted Install
ProLiant OS - ESXi 5.5 U1 Scripted Install
ProLiant OS - ESXi 5.5 U2 Scripted Install
ProLiant OS - ESXi 5.5 U3 Scripted Install
ProLiant OS - ESXi 6.0 Scripted Install
ProLiant OS - ESXi 6.0 U1 Scripted Install
ProLiant OS - ESXi 6.0 U2 Scripted Install
Performs a scripted install of the selected VMware ESXi version using a generic kickstart file.
NOTE: For ESXi 5.1 and later, ESXi naming has changed to vSphere; however, OSBPs, scripts and configuration files may
continue to state ESXi.
Requirements:
•
HP ProLiant server with iLO
•
IC server provisioning Media Server must contain the OS distribution
Optional Custom Attributes:
•
ProductKey_ESXiZZ corresponding to the selected version of ESXi where ZZ is the version number
•
encrypted_root_password – root password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
boot_disk – disk on which vSphere is installed, for example sda, hdc, cciss/c0d1
•
kernel_arguments – additional kernel arguments for the installed vSphere kernel
ProLiant OS - RHEL 5.9 x64 Scripted Install
ProLiant OS - RHEL 5.10 x64 Scripted Install
ProLiant OS - RHEL 5.11 x64 Scripted Install
ProLiant OS - RHEL 6.3 x64 Scripted Install
ProLiant OS - RHEL 6.4 x64 Scripted Install
ProLiant OS - RHEL 6.4 x64 KVM Scripted Install
ProLiant OS - RHEL 6.5 x64 Scripted Install
ProLiant OS - RHEL 6.5 x64 KVM Scripted Install
ProLiant OS - RHEL 6.6 x64 Scripted Install
ProLiant OS - RHEL 6.6 x64 KVM Scripted Install
ProLiant OS - RHEL 6.7 x64 Scripted Install
ProLiant OS - RHEL 6.7 x64 KVM Scripted Install
ProLiant OS - RHEL 7.0 x64 Scripted Install
ProLiant OS - RHEL 7.0 x64 KVM Scripted Install
ProLiant OS - RHEL 7.1 x64 Scripted Install
ProLiant OS - RHEL 7.1 x64 KVM Scripted Install
ProLiant OS - RHEL 7.2 x64 Scripted Install
ProLiant OS - RHEL 7.2 x64 KVM Scripted Install
Performs a scripted install of the selected Red Hat Enterprise Linux version using a generic kickstart file.
42
The KVM scripted install build plan installs a RHEL x64 Kernel Virtual Machine (KVM) hypervisor on a target server, known
as the KVM host. Once the KVM hypervisor is installed, libvirt utilities such as virsh or virt-manager may be used to add
KVM guests on the KVM host.
Additionally, virtualization must be enabled in the BIOS. Virtualization is enabled by default; however, If it has been
disabled on the target server, it can be enabled in the RBSU under the System Options -> Processor Options menu, or
create a build plan using the ProLiant HW - System ROM Enable Boot from SAN Bladeserver build plan, replacing the
configuration file with the System ROM Configuration – Enable Virtualization configuration file.
NOTE: The driver packages within these build plans are updated to the latest SPP version that is released when IC server
provisioning releases, except for Red Hat EL 6.3 & RHEL 6.4. SPP 2013.09b & SPP 2014.09 was the last SPP where all
drivers supported that operating system version.
Requirements:
•
HP ProLiant server with iLO
•
IC server provisioning Media Server must contain the OS distribution
Optional Custom Attributes:
•
encrypted_root_password – root password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
boot_disk – disk on which Linux is installed, for example sda, hdc, cciss/c0d1
•
kernel_arguments – additional kernel arguments for the installed Linux kernel
ProLiant OS - SLES11 SP2 x64 Scripted Install
ProLiant OS - SLES11 SP3 x64 Scripted Install
ProLiant OS - SLES11 SP4 x64 Scripted Install
ProLiant OS - SLES12 x64 Scripted Install
ProLiant OS - SLES12 SP1 x64 Scripted Install
Performs a scripted install of the selected SUSE Enterprise Linux version using a generic autoyast file.
NOTE: To install SUSE on some newer ProLiant Gen8 and Gen9 servers, special kISO bootloader support is required.
Refer to the IC server provisioning On-line Help.
Requirements:
•
HP ProLiant server with iLO
•
IC server provisioning Media Server must contain the OS distribution
Optional Custom Attributes:
•
encrypted_root_password – root password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
boot_disk – disk on which Linux is installed, for example sda, hdc, cciss/c0d1
•
kernel_arguments – additional kernel arguments for the installed Linux kernel
ProLiant OS – Ubuntu Server 14.04 x64 Scripted Install
Performs a scripted install of Ubuntu Server 14.04 using a generic preseed file.
•
NOTE: To install Ubuntu, one is required to use linux based media server. To setup a linux based media server,
please follow the instruction given in ICsp Administrator guide, at
http://www.hp.com/go/insightcontrol/docs.
Requirements:
•
HP ProLiant server with iLO
43
•
IC server provisioning Media Server must contain the OS distribution
Required Custom Attribute: None
Optional Custom Attributes:
•
encrypted_root_password – root password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
boot_disk – disk on which Linux is installed, for example sda, hdc, cciss/c0d1
ProLiant OS - Windows 2008 SP2 Standard x64 Image Capture
ProLiant OS - Windows 2008 R2 SP1 Standard x64 Image Capture
ProLiant OS - Windows 2012 Standard x64 Image Capture
ProLiant OS - Windows 2012 R2 Standard x64 Image Capture
ProLiant OS - Windows 7 SP1 Professional x64 Image Capture
ProLiant OS - Windows 8.1 Pro x64 Image Capture
Captures the selected version of Windows into a WIM image.
The WIM image can then be used to clone multiple target servers.
IMPORTANT: Upon completion of the build plan, the reference server from which the image was captured is left in a
depersonalized state.
IMPORTANT: The ProLiant OS - Windows 7 SP1 Professional x64 Image Capture build plan is designed to only run on
ProLiant WS460c Gen8 or Gen9 Graphics Server Blades.
The ProLiant OS - Windows 8.1 Pro x64 Image Capture build plan is designed to only run on ProLiant WS460c Gen9
Graphics Server Blades.
Requirements:
•
HP ProLiant server with iLO must be powered on and running the Windows OS to be captured.
•
Media Server share must be writeable.
•
A WinPE image has been generated by the WinPE image generation utility and uploaded to the appliance using
Settings > DHCP page. Uploading a WinPE image to the appliance also adds the imagex.exe utility which is
required for all image capture and deploy operations. The ImageX package shipped with the appliance does not
contain the actual imagex.exe utility by default due to licensing restrictions.
Required Custom Attribute:
•
WimFileName - The file name where the captured image will be stored on the Media Server.
Optional Custom Attribute:
•
CaptureDrive – Drive letter with colon of the default drive from where ImageX will capture the system
partition. Default value is set to C: in the parameter field for Capture Windows Image build plan script.
ProLiant OS - Windows 2008 SP2 Standard x64 Image Install
ProLiant OS - Windows 2008 R2 SP1 Standard x64 Image Install
ProLiant OS - Windows 2012 Standard x64 Image Install
ProLiant OS - Windows 2012 R2 Standard x64 Image Install
ProLiant OS - Windows 7 SP1 Professional x64 Image Install
ProLiant OS - Windows 8.1 Pro x64 Image Install
Applies a previously captured Windows WIM image. This build plan is used to clone servers using an image captured
from a reference server.
IMPORTANT: The ProLiant OS - Windows 7 SP1 Professional x64 Image Install build plan is designed to only run on
ProLiant WS460c Gen8 or Gen9 Graphics Server Blades.
44
The ProLiant OS - ProLiant OS - Windows 8.1 Pro x64 Image Install build plan is designed to only run on ProLiant WS460c
Gen9 Graphics Server Blades.
Requirements:
•
HP ProLiant server with iLO and similar hardware as the reference server.
•
A previously captured WIM image on Media Server.
•
A WinPE image has been generated by the WinPE image generation utility and uploaded to the appliance using
Settings > DHCP page. Uploading a WinPE image to the appliance also adds the imagex.exe utility which is
required for all image capture and deploy operations. The ImageX package shipped with the appliance does not
contain the actual imagex.exe utility by default due to licensing restrictions.
Required Custom Attributes:
•
ProductKey_xxx-yyy corresponding to the selected version of Windows, set using the Settings > Product Key
page where xxx is the Windows version and yyy is the architecture version.
•
WimFileName - A previously captured image file name
Optional Custom Attributes:
•
ComputerName – Network name of the installed target server. Follow NetBIOS guidelines and 15 character
limit.
•
EncryptedAdminPassword – Administrator password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
SystemDrive – Drive label for the system drive the operating system is installed
•
SystemDiskNumber – Physical drive number for the system drive the operating system is installed. This
custom attribute is not meant to be set by the end user. It is set automatically during build plan execution and
is used to make sure the Windows installer does not install to the Intelligent Provisioning flash drives. During
re-provisioning, this value might be left over from a previous installation and cause the install to fail. Deleting
the custom attribute before running the build plan solves this.
ProLiant OS - Windows 2008 SP2 Standard x64 Scripted Install
ProLiant OS - Windows 2008 R2 SP1 Standard x64 Scripted Install
ProLiant OS - Windows 2012 Standard x64 Scripted Install
ProLiant OS - Windows 2012 R2 Standard x64 Scripted Install
ProLiant OS - Windows 7 SP1 Professional x64 Scripted Install
ProLiant OS - Windows 8.1 Pro x64 Scripted Install
Performs a scripted install of the selected Windows version using a generic unattend file.
IMPORTANT: Beginning with IC server provisioning 7.3.1, multiple WinPE PXE versions are provided. Windows 2008 SP2
and Windows 2008 R2 SP1 may only be installed using WinPE 3.1 PXE version or Intelligent Provisioning v1.50 or earlier
which is based on WinPE 3.0.
IMPORTANT: The Proliant OS - Windows 7 SP1 Professional x64 Scripted Install build plan was added with IC server
provisioning 7.4.0 and may only be installed using WinPE 3.1 Service OS. The build plan is also designed to only run on
ProLiant WS460c Gen8 or Gen9 Graphics Server Blades (legacy boot mode only). UEFI boot mode is not supported.
Requirements:
•
HP ProLiant server with iLO
•
IC server provisioning Media Server must contain the OS distribution
Required Custom Attributes:
•
ProductKey_xxx-yyy corresponding to the selected version of Windows, set using the Settings > Product Key
page where xxx is the Windows version and yyy is the architecture version.
Optional Custom Attributes:
•
ComputerName – Network name of the installed target server. Follow NetBIOS guidelines and 15 character
limit.
45
•
EncryptedAdminPassword – Administrator password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
SystemDrive – Drive label for the system drive the operating system is installed
•
SystemDiskNumber – Physical drive number for the system drive the operating system is installed. This
custom attribute is not meant to be set by the end user. It is set automatically during build plan execution and
is used to make sure the Windows installer does not install to the Intelligent Provisioning flash drives. During
re-provisioning, this value might be left over from a previous installation and cause the install to fail. Deleting
the custom attribute before running the build plan solves this.
ProLiant SW - Configure NIC Teaming for RHEL 7
This OSBP configures single or multi NIC teaming for RHEL 7.X on target server. NIC teaming attributes like team name,
type of Ethernet interface and interface values can be passed using nic_teaming custom attribute. It is mandatory to
define nic_teaming CA for this OSBP, otherwise the “Configure NIC Teaming for RHEL 7” script will fail the build plan. See
IMPORTANT: This build plan must be running on target server that is installed with RHEL 7.X production OS. And it is not
recommended to use deployment NIC to form NIC teams.
Requirements:
•
HP ProLiant server with iLO running a RHEL 7 production OS
Required Custom Attribute:
•
nic_teaming
ProLiant SW - Configure Multiple NIC Team for Windows
This OSBP configures multi NIC teaming for windows 2012 or later. This OSBP parses the information provided in
nic_teams custom attribute to form NIC teaming. This OSBP deletes any existing NIC teams on target server before
forming new NIC teams based on nic_teams CA.
IMPORTANT: This build plan must be running on target server that is installed with Windows 2012 or later. And it is not
recommended to use deployment NIC to form NIC teams.
Requirements:
•
HP ProLiant server with iLO running a Windows 2012 or later production OS
Required Custom Attribute:
•
nic_teams
ProLiant SW - Install Linux SPP
ProLiant SW - Install Windows SPP
Installs the Service Pack for ProLiant (SPP) on a Windows or Linux production target server.
By default, the entire SPP will be installed on the server, including firmware. Options can be passed to the Install Linux
SPP, Install Windows SPP, or Install Windows SPP In Background step that can control what gets installed. See the HP
SUM User Guide for information regarding what options are available.
Beginning with IC server provisioning release 7.3.1, the ProLiant SW - Install Windows SPP build plan will reset the agent
to account for NIC drivers or firmware that may have been updated; hence, causing the connection to be temporarily
broken between the target server and the appliance. An additional Wait for SA Agent step was added before the Reboot
step.
Requirements:
•
HP ProLiant server with iLO and running a production operating system
•
IC server provisioning Media Server must contain a SPP
Custom Attributes: None
46
ProLiant SW - Install Linux HPSUT
ProLiant SW – Install Windows HPSUT
Performs online firmware and/or driver updates via iLO management network without the need for OS credentials.
Beginning with IC server provisioning release 7.5.1, ProLiant SW - Install Linux HPSUT and ProLiant SW - Install
Windows HPSUT Build Plans can be used to deploy HP SUT on Linux and Windows managed nodes respectively. IC server
provisioning installs HP SUT and runs it in Auto Stage mode. In this mode, HP SUT only stages the firmware and drivers
to the operating system. The firmware and driver installation can be executed during planned maintenance window to
activate the firmware
Requirements:
•
•
HP ProLiant Gen8 server or newer with iLO4 and running one of the following production operating systems:
•
Windows Server 2008 x64, Windows Server 2008 R2
•
Windows 2012, Windows Server 2012, and Windows Server 2012 R2
•
Red Hat Enterprise Linux 6.0 (x86–64)
•
Red Hat Enterprise Linux 7.0
•
SUSE Linux Enterprise Server 11 (AMD64/EM64T)
•
SUSE Linux Enterprise Server 12
HPSUT folder exists in IC server provisioning Media Server and contains HPSUT files.
NOTE: If HPSUT folder does not exist in IC server provisioning Media Server, follow the below steps to setup Media server
for HPSUT:
•
•
Create folder /media/Media/HPSUT
Download and place HPSUT from hpe.com/info/HPSUT to /Media/HPSUT folder.
Custom Attributes:
•
HPSUT_Linux – Linux HPSUT filename
•
HPSUT_Windows – Windows HPSUT filename
ProLiant SW - Intelligent Provisioning Firmware Update
Updates the Intelligent Provisioning firmware of a ProLiant Gen8 or newer target server. The server will be PXE booted
into the Linux service OS, the firmware will be updated, and the server will be rebooted into the Intelligent Provisioning
Linux service OS to complete the update. The firmware will be updated to latest version available on the media server or
the IPversion custom attribute may be defined for a specific version.
IMPORTANT: This build plan must PXE boot the target server, as updating the Intelligent Provisioning firmware while
booted to an Intelligent Provisioning service OS is not supported.
Requirements:
•
HP ProLiant Gen8 server or newer
•
IC server provisioning Media Server must contain Intelligent Provisioning media
•
Network must support PXE boot
Optional Custom Attribute:
•
IPversion – Intelligent Provisioning firmware version in the form of x.xx, for example 1.60, and aligns with the
Intelligent Provisioning directory on the media server. "latest" may be specified which will automatically select
the latest version on the media server by sort order. This is the default value.
47
ProLiant SW - Offline Firmware Update
Updates the firmware using the Service Pack for ProLiant (SPP).
IMPORTANT: With IC server provisioning 7.3.1 only, this build plan will only run when the target server is booted to the
Intelligent Provisioning service OS available on ProLiant Gen8 or newer servers. Attempts to run this build plan on target
servers prior to Gen8 or on servers that are PXE booted will result in a failure of the build plan with an appropriate
message.
The target server will be booted into the Linux service OS and the SPP firmware update function will be run. Upon
completion of this build plan, the target server will be left in the service OS. If you require the production OS, the build
plan will need to be modified with the appropriate boot steps.
Requirements:
•
HP ProLiant server with iLO
•
IC server provisioning Media Server must contain a SPP
Optional Custom Attributes:
•
SPPversion – SPP version in the form of yyyy.mm.x, for example 2014.02.0 and aligns with the SPP directory
on the media server. “latest” may be specified which will automatically select the latest version on the media
server by sort order. This is the default value.
ProLiant SW – Post Install Network Personalization
This OSBP personalizes network settings of a target server after OS installation. Network setting can be passed using a
custom attribute ‘hpsa_netconfig’ which expects values in JSON format. See Appendix B for information about
hpsa_netconfig and the type of information you can personalize with this build plan. This OSBP can perform an optional
reboot based on another custom attribute named as ‘skip_reboot’. By default, OSBP does not perform a reboot after
network personalization.
This Build Plan can be run manually, but is typically run automatically by the “Configure Network” feature. The Configure
Network feature collects the server personalization information from the user interface, automatically creates the
hpsa_netconfig custom attribute, and then calls this build plan to apply the network configuration. See the on line help
topic about the Configure Network feature for more information.
Requirements:
•
Target server must be booted to either Windows or Linux production OS.
Custom Attributes:
•
hpsa_netconfig – This CA is used to input network settings in a JSON format. hpsa_netconfig is in the Json
format used to provide all the necessary network settings. See Appendix B for information about
hpsa_netconfig and the type of information you can personalize with this build plan.
Skip_reboot – This CA specifies whether to perform a reboot or not. A “yes” value will skip Reboot and “No” will perform
a reboot. Default value is “Yes”. The skip_reboot uses ‘yes’ or ‘no’ option to either skip or perform the reboot after
network personalization. The default value assigned to the build plan is ‘Yes’, however, you can override it by creating a
skip_reboot custom attribute to the server you are personalizing.
ProLiant SW - Validate Media Server Settings
Validates the Media Server configuration and the data entered on the Media Server Settings page. Use this build plan to
validate your Media Server settings or troubleshoot Media Server access problems. All forms of access appropriate to
the particular booted environment are tested. Diagnostic messages are output to the job log.
This Build Plan does not boot the target server. It is meant to be run in whatever environment you are trying to validate
or troubleshoot. To fully test the Media Server, run this build plan on both a Windows and a Linux booted target server.
See the Set Media Source step and Media Server troubleshooting topic in the Troubleshooting section of the online help
for more information about this Build Plan.
Requirements:
48
•
Target server must be booted to a either Windows or Linux, service or production OS. This build plan does not
boot the target server and cannot be run against a target server booted to the ESXi OS, since no agent is
available for that OS.
Custom Attributes: None
Scripts
Summary
The scripts listed in this section are used or were created to be used by the HP-provided build plans. There are some
scripts listed here that are not part of the HP-provided build plans, but are meant to provide extended capabilities when
creating custom build plans.
NOTE: There are also some scripts on your appliance that are not listed in this document. These scripts are part of the
underlying Server Automation installation. They have not been tested with the appliance and are not guaranteed to
work.
Add ESXi Boot Option To UEFI Boot Order
This script adds a new entry to the UEFI boot menu that will point to the just completed installation of ESXi. This script
was added because VMware does not currently modify the UEFI boot menu as part of an ESXi installation, and without
this boot option in the menu, installation problems are likely.
This script is meant to be used immediately after an ESXi installation completes. It will force a target server configured
in UEFI boot mode into the Intelligent Provisioning Linux Service OS. The script will then add an ESXi boot option to the
UEFI boot menu. The disk partition with the “ESXi” label is assumed to be the EFI System Partition and will be used when
creating the ESXi boot option. This script does nothing if the target server is not configured in UEFI boot mode.
Type: OGFS
Parameters:
•
--atLeast=MINUTES The number of minutes to wait before setting a one-time boot to Intelligent Provisioning.
Since a one-time boot cannot be set while a server is going through POST (Power On Self Test), this option can
be used to give the server time to complete POST after it has rebooted. Default is 5 minutes.
•
--atMost=MINUTES The number of minutes to wait for this script to complete after it has configured the
server to one-time boot into Intelligent Provisioning. Default is 45 minutes.
•
--bootOptionName=NAME The name of the boot option that you want added to the UEFI boot menu. Default
is "ESXi".
•
--efiSystemPartitionLabel=PARTITION_LABEL The label assigned by the ESXi installer to the EFI System
Partition. This option should only be used if the ESXi installer assigns a different label to the EFI System
Partition. Default is "ESXi".
Custom Attributes: None
Add ESXi Module
Adds the specified module to the list of modules ESXi will boot.
Places the file or directory specified as an argument to the “-s” into a compressed tar file so that it can be loaded as an
ESXi module when ESXi is booted. The file or directory will be visible in the file system when ESXi boots.
Type: Unix
Parameters:
•
-s file – a file or directory to create a module from
•
-d – create a tar in tar image to get around VMware’s vgz format
•
-a file – alias the file or directory
Custom Attributes: None
49
Add iLO User
Adds an iLO user using the ProLiant Scripting Toolkit hponcfg utility.
Type: OGFS
Required Parameters:
•
--username=USERNAME where USERNAME of the new iLO user.
•
--password=PASSWORD where PASSWORD of the new iLO user
•
--privilege=PRIVILEGE where PRIVILEGE to be given to the new iLO user. Can be specified more than once.
Possible values: ADMIN REMOTE_CONS RESET_SERVER VIRTUAL_MEDIA CONFIG_ILO
Custom Attributes: None
Add Windows Hyper-V Role
Add Windows Multipath IO Feature
Installs the Windows Hyper-V Role or Multipath IO Feature using ServerManagerCmd or PowerShell.
These scripts can be run on a Windows production OS or appended to the end of a Windows installation build plan to add
the specified feature/role. A reboot is required after this script is run.
These scripts can also be used as templates for enabling other roles.
Type: Windows BAT
Parameters: None
Custom Attributes: None
Add Windows Server to Domain
Adds a target server to a Domain.
This script can be run on a Windows production OS or appended to the end of a Windows installation build plan. A reboot
is required after this script is run. This script will fail if the required custom attributes are not defined or if a DNS server
is not configured on the target server.
NOTE: This script uses PowerShell commands. To run on Windows 2008, PowerShell 2.0 and WinRM need to be
installed.
Type: Windows BAT
Requirements: DNS needs to be configured on the target server
Parameters: None
Required Custom Attributes:
•
DomainFQDN – Fully Qualified Domain Name
•
DomainName – NETBIOS name of domain
•
DomainUser – domain user with permissions to join the domain
•
Password, either
o
DomainPassword – text-based domain password to join the domain
OR
o
EncryptedDomainPassword – encrypted domain password. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
o
Key – used to generate the value for EncryptedDomainPassword
Adjust Windows System Disk Number on HP ProLiant Gen8
50
[Note]: starting 7.5.1, this script is deprecated, use “Hide Intelligent Provisioning drives” step instead.
Adjusts the SystemDiskNumber custom attribute on Gen8 servers to account for the Virtual Install Disk.
On ProLiant Gen8 or newer servers equipped with embedded flash drives, the diskpart command may list the Virtual
Install Disk before the system disk. When this situation occurs, the SystemDiskNumber custom attribute needs to be
adjusted so that it references the correct system disk and not the Virtual Install Disk. The server's SystemDiskNumber
custom attribute is updated with the new value.
Type: OGFS
Optional Parameter:
•
--ca="Alternate-Custom-Attribute-Name" Specifies an alternate custom attribute name where the adjusted
system disk number will get saved. The default custom attribute is SystemDiskNumber.
Custom Attributes: SystemDiskNumber
An Empty Template OGFS Script
An Empty Template Python Script
An Empty Template Unix Shell Script
An Empty Template Windows Batch Script
An Empty Template Windows VBScript
These template scripts can be used to create new scripts of specified type. As of IC server provisioning release 7.2.2,
these scripts have been deprecated since creating a new script is now available from the user interface.
Type: OGFS, Python, Unix, Windows .BAT, or Windows VBScript
Parameters: None
Custom Attributes: None
Apply WIM Image
IMPORTANT: This script is no longer used in Windows build plans starting with IC server provisioning 7.3.1. It has been
replaced with the Windows Image Deploy script.
Takes a previously captured Windows imagex WIM image that is saved on the Media Server and installs it on the target
server’s boot disk.
Type: Windows .BAT
Parameters: None
Custom Attributes: None
Boot
Boots a target server into the specified service OS.
This Boot step is used in almost all build plans to put the target server into the appropriate service OS for running the
rest of the steps in the build plan. It first checks the current state of the target server. If the server is already running the
specified service OS, the boot step does nothing and exits with a success code. If a boot is required, the boot step will
contact the target server’s iLO to power off the server, set the one time boot flag, and the power the server back on.
IMPORTANT:
•
The boot step completes as soon as the boot is initiated, and does not wait for a successful boot. For this
reason, the boot step should always be followed by the Wait for SA Agent step. Sometimes the Decommission
Server step can come between Boot and Wait for SA Agent.
•
When checking the current state of the target server, the boot step cannot distinguish between a server that
was booted using PXE or one booted using the embedded service OS. If the build plan requires one specific
context or the other, be sure to specify the –force option in conjunction with the –method= option, which will
cause a server reboot regardless of the current state.
Type: OGFS
51
Required Parameters:
•
--serviceOS=service_os where service_os is the name of the service OS in which to boot. Possible values are
linux, linux64, and winpe64. There is no difference between linux and linux64.
Optional Parameters:
•
•
--method=method_options where method_options are
o
auto – The boot method will be chosen automatically based on the server type. This is the default.
o
embedded – Boots to the embedded service OS. This is supported only for HP ProLiant Gen8 and
newer servers.
o
network – Boots the server using PXE, regardless of the type of server.
--force - Forces a reboot of the server, regardless of the current state or service OS.
Custom Attributes: None
Capture Windows Image
IMPORTANT: This script is no longer used in Windows build plans starting with IC server provisioning 7.3.1. It has been
replaced with the Windows Image Capture script.
Creates a WIM image of the target server using ImageX.
For more information about ImageX, see the following two articles:
•
http://technet.microsoft.com/en-us/library/cc722145
•
http://technet.microsoft.com/en-us/library/cc749447
Type: Windows .BAT
The parameters are specified in order, separated by spaces.
Required Parameters:
•
Full path where the WIM image file will be saved including the file name and .wim extension.
•
Drive to be captured
Optional Parameter:
•
Path to the optional wimscript.ini exclusion file. This file contains a list of files for ImageX to skip while
imaging. The Capture Windows Image script will always add files to the exclusion list to prevent imaging the
Server Automation agent files. In no wimscript.ini file is specified, one will be created just for the agent files.
Example parameters:
•
Z:\media\newWimFile.wim C: Z:\configs\wimscript.ini
Required Custom Attributes: None
Check iLO Service
Checks that the target server’s iLO has been registered properly with the appliance.
There are circumstances where a target server may appear in the appliance interface, but its iLO may not have
completed registering itself. Since the Boot step requires the iLO for its boot control functions, a build plan could
unnecessarily fail if the iLO registration process is still in progress. The Check iLO Service script is added at the head of
most build plans before the Boot step to verify that the target server has a valid iLO registered. If no iLO is registered,
the script will wait some amount of time to allow the iLO to complete its registration. Once the iLO becomes registered,
the step completes and the build plan continues. If no iLO is found before the timeout, the script fails and halts the build
plan.
To deploy to a Virtual Machine target, this script step should be removed.
Type: OGFS
Optional Parameter:
52
•
--atMost=minutes where minutes is the time before timing out. Default is 10 minutes.
Custom Attributes: None
Collect and Store System Data
This script queries properties that pertain to the target server, such as model, UUID, deployment IP address, etc. and
either creates a custom attribute for these properties, where the custom attribute name is the same as the property
name, or writes properties to a text file as tag/value pairs. These properties can then be read by custom scripts to
perform actions based on the property values. Refer to Table 11 for the list of supported properties and their
corresponding keywords.
Table 11: Supported properties and corresponding keywords or custom attributes.
Properties
Keyword or Generated
Custom Attribute
Properties
Keyword or Generated
Custom Attribute
Hardware Model
Model
Enclosure
Enclosure
UUID
UUID
Bay
Bay
Serial Number
Serial
SA Object ID
SA_Object_Id
# of CPUs
CPU
Manufacturer
Manufacturer
Memory
Memory
Number of disks
Num_Disks
Deployment NIC
Name
NIC_Name
Total storage
assigned to server
Disk_Size
Deployment NIC MAC
address
NIC_MAC_Address
Appliance
deployment IP
Appliance_IP
Deployment IP
IP_Address
Media server share
IP
Media_Server_Share_IP
iLO IP address
iLO_IP
HTTP media server
IP
Media_Server_Http_IP
Rack
Rack
Why use this step:
This advanced step is designed to perform actions based on the target server’s characteristics. For example, specific
settings may be used based on the target server model, or may want to partition the disks differently based on the total
size or number of disks. This step eases the task of collecting the various system properties that may be referenced and
makes those properties available via a properties file or custom attributes. Advanced scripts can be written that make
use of these properties to perform functions based on the properties’ values.
Type: OGFS
Required Parameters:
•
--allProps - when specified, the script will create custom attributes or write variables for all the supported
properties listed below. This is typically used when writing properties to a file. If not specified, the properties
will need to be explicitly specified using the --props parameter.
•
--props - “Property1" "Property2" - When specified followed by a list of supported properties, the script will
create custom attributes or write variables only for the properties that were specified. This is typically used
when creating custom attributes, since a large number of custom attributes may not be wanted for each of the
target servers.
•
--varfile "file-name" – When specified, this parameter will cause the requested properties to be written to a file
on the target server as a series of name/value pairs. The file name specified should be fully qualified, for
example C:\ManagementSpace\Attributes.txt for Windows based systems and
/home/management/attributes.txt for Linux based systems. Note that the format of the specified path,
Windows or Linux, is checked against the running OS type. If there is a mismatch, this script step will fail.
53
•
--CA - When specified, this script will create Device level custom attributes associated with the target server
for all of the specified properties.
--allProps and --props are mutually exclusive. When both the arguments are passed, this script step will generate
an error and fail.
Either --varfile or –CA must be specified. Absence of both will result in an error and this script step fails. However,
both the arguments can be passed to the script.
Table 12: Collect and Store System Data sample parameters
Parameters
Description
--allProps --varfile "C:\ManagementSpace\Attributes.txt"
Writes all supported properties to a file on
the target server.
--allProps --CA
Creates custom attributes on the target
server for all supported properties.
--props "NIC_MAC_Address" "Manufacturer" "Appliance_IP"
--varfile "C:\Temp\Attributes.txt"
Writes only selected set of properties onto
the target server.
--props "NIC_MAC_Address" "Manufacturer" "Appliance_IP" –CA
Creates custom attributes on the target
server for a selected set of properties
Custom Attributes: Refer to script description.
Configure Boot From SAN
This script disables the embedded Smart Array and SATA controllers, leaving only the fibre channel controller
enabled. This script can be used on all ProLiant Bladeservers, DL580 Gen8, and all Gen9 or newer servers. Non-blade
G6, G7, and Gen8 servers, with the exception of the DL580Gen8, are not supported and will result in an error.
Type: OGFS
Optional Parameter:
•
--fibre_channel_first - In UEFI mode, moves the fibre channel device to the top of the boot order.
Custom Attributes: None
Configure Fibre Channel HBA Boot Device
Configures a QLogic or Emulex HBA, or Emulex CNA boot device by applying the configuration specified in the
HBA_Config multi-line custom attribute.
Type: Python
Optional Parameter:
•
--displayHbaOnly - Show the HBA or CNAs on the target server, but doesn’t apply the configuration.
Required Custom Attribute:
•
HBA_Config – Required for configuration operations. See How do I Configure the boot device on a Fibre Channel
HBA in the Insight Control Server Provisioning online help for full details about how to set this custom
attribute.
Configure NIC Teaming for RHEL 7
Creates a single or multi NIC teams on target servers with RHEL 7.0 or later. This script parse the information provided in
nic_teaming custom attribute to form NIC teaming. This script deletes any existing NIC teams on target server before
forming new NIC teams based on nic_teaming CA.
Type: Python
Important:
•
54
Do not use deployment NIC for NIC teaming.
•
Minimum two NICs are required to form NIC team.
Required Custom Attribute:
•
nic_teaming – Required to define NIC team name and corresponding Ethernet interfaces. The Ethernet
interface input can be provided either as name of interface or MAC address corresponding to it.
Configure NIC Teaming for Windows
Creates a teamed NIC on target servers with Windows 2012 or later. The step takes a comma separated list of
parameters which specify exactly which NICs will be teamed together.
Type: Windows .BAT
Required Parameters:
•
•
Field Name – lists the NIC characteristic that will be specified in the other parameters. Valid field names are:
•
Name
•
InterfaceDescription
•
ifIndex
•
Status
•
MacAddress
•
LinkSpeed
Values - The value(s) to be checked for that corresponds to the specified Field Name parameter. Note that no
extra spaces should be used when specifying parameters.
Table 13 is an example that represents the NICs on a target server with Table 14 as examples of parameters to
provide to the script.
Table 13: Configure NIC Teaming for Windows sample network adapters on a target server
Name
InterfaceDescription
ifIndex
Status
MacAddress
LinkSpeed
Ethernet
HP NC553i Dual Port FlexFabric 10G
16
Up
18-A9-05-C5-E1-B7
10 Gbps
Ethernet 2
HP NC553i Dual Port FlexFabric 10G...#1
15
Disconnected
18-A9-05-C5-E1-B3
10 Gbps
Ethernet 3
HP NC553i Dual Port FlexFabric 10G...#2
14
Disconnected
18-A9-05-C5-E1-B4
10 Gbps
Table 14: Configure NIC Teaming for Windows sample parameters used for target server with network adapters setup
as provided in Table 13.
Parameters
Description
Status,Up
Teams all NICs that are active
Name,Ethernet,Ethernet 2
Teams the first and second NIC
MacAddress,18-A9-05-C5-E1-B3,18-A9-05-C5-E1-B4
Teams the second and third NICs
Custom Attributes: None
Configure Multiple NIC Teaming for Windows
Creates multi NIC teams on target servers with Windows 2012 or later. This script parses the information provided in
nic_teams custom attribute to form NIC teaming. This script deletes any existing NIC teams on target server before
forming new NIC teams based on nic_teams CA.
Type: Windows .BAT
Important:
•
Do not use deployment NIC for NIC teaming.
55
•
Minimum two NICs are required to form NIC team.
•
Member should not be part of any other team.
Required Custom Attribute:
•
nic_teams – Required to define NIC teamname and corresponding Ethernet interfaces. The Ethernet interface
input can be provided using four filters: Name, MacAddress, InterfaceDescription and ifIndex.
Exceptions for NIC teaming
•
Deployment NIC can be used for NIC team formation with risk of OSBP failing and Agent getting disconnected.
Examples of Custom Attribute:
•
nic_teams = {"Teams": [{"filter": {"Name": ["Ethernet 4", "Ethernet 3"]}, "TeamName": "Team2"},{"filter":
{"Name": ["Ethernet 2", "Ethernet"]}, "TeamName": "Team1"}]}
•
nic_teams = {"Teams": [{"filter": {"MacAddress": ["00-50-56-93-20-BF", "00-50-56-93-54-D6"]}, "TeamName":
"Team2"},{"filter": {"MacAddress": ["00-50-56-93-25-7E", "00-50-56-93-70-34"]}, "TeamName": "Team1"}]}
•
nic_teams = {"Teams": [{"filter": {"InterfaceDescription": ["Intel(R) PRO/1000 MT Network Connection", "Intel(R)
PRO/1000 MT Network Connection #2"]}, "TeamName": "Team2"},{"filter": {"InterfaceDescription": ["Intel(R)
PRO/1000 MT Network Connection #3", "Intel(R) PRO/1000 MT Network Connection #4"]}, "TeamName":
"Team1"}]}
nic_teams = {"Teams": [{"filter": {"ifIndex": ["15", "14"]}, "TeamName": "Team2"},{"filter": {"ifIndex": ["13", "12"]},
"TeamName": "Team1"}]}
Continue SuSE AutoYaST Installation
Causes the SuSE AutoYaST installation to continue after it was stalled for HP SA Agent injection or other tasks before the
reboot into the second phase of the SuSE AutoYaST installation process.
Type: OGFS
Parameters: None
Custom Attributes: None
Control Server Bootmode
Configures the boot mode on a target server that supports UEFI and then powers off the server. If the server is already
configured with the specified boot mode, no action is performed.
Type: OGFS
Requirement:
•
HP ProLiant server with iLO that supports UEFI and is capable of switching between UEFI and Legacy boot
modes.
Required Parameter:
•
--bootmode=mode where mode is one of the following:
o
LEGACY - switch to "Legacy BIOS" boot mode (Not UEFI)
o
UEFI_OPTIMIZED - switch to UEFI mode w/ optimized boot enabled which provides improved boot
time
o
UEFI - switch to UEFI non optimized boot mode. This is needed for certain legacy OS e.g. Windows
2008 SP2 and Windows 2008 R2 SP1
o
UEFI_OPTIMIZED_SECURE - switch to UEFI mode with optimized boot and secure boot mode enabled.
Not supported on ProLiant Gen8 or earlier servers.
The mode must be set. There is no default value if mode is not set.
56
Custom Attributes: None
Copy Boot Media
Copies files needed to boot the installer environment to the stub partition.
This is one of the scripts used to prepare a server for a Linux installation. It should follow the Create Stub Partition script.
If no parameters are given, the script will check the installation media and figure out the files that the installer needs in
order to boot.
Type: Unix
Optional Parameters:
•
base_path_or_img - A directory in the installation media, or a mountable image file. All other files are relative
to this location.
•
"file1" ["file2" ["file3" ...]] - list of files to copy onto the boot partition.
Custom Attributes None
Create Stub Partition
Creates a partition on the local disk to load the Linux build image.
This is one of the scripts used to prepare a server for a Linux installation. By default, the boot disk is identified as the
first disk in /proc/partitions. A single bootable 1 GB primary partition is created with an EXT3 filesystem. The partition is
mounted under /mnt/<device_name>, using the device's /dev/ path but replacing "/dev/" with "/mnt/" for the
mountpoint. For example, this would be "/mnt/cciss/c0d0p1" on an HP ProLiant system. A symlink is created under
/mnt/root so other scripts can alter the root filesystem if needed.
Type: Unix
Requirements:
•
Existing filesystems on the boot disk, if mounted, must be unmountable. This means interactive sessions
cannot have the present working directory beneath the mount point, for example. Any partitions on the boot
disk that are currently mounted will be unmounted.
•
Target server must be running the Linux OGFS Agent. This script uses the following system utilities: mount,
umount, sfdisk, and mkfs.ext3
Parameters: None
Custom Attributes None
Create Windows System Drive
IMPORTANT: This script is no longer used in Windows build plans starting with IC server provisioning 7.3.1. It has been
replaced with the Partition Disk for Windows script.
Creates a temporary partition on the target server hard drive using diskpart to prepare for Windows operating system
deployment. The partition is created within this script versus partitioning within the unattend file for the following
reasons:
•
HP felt it was easier to create or extend custom partitions versus inside the unattend XML format.
•
An error from diskpart may be more intuitive, as well as the build plan will fail at this step without the need to
call Windows Setup and look for the Windows installation logs for an error.
•
The HP-provided OSBPs use this temporary partition to store the extracted driver files. Although it may be
possible to store the driver files on the WinPE X: drive, there is possibility to run out of storage.
If additional partitions are needed, please consider the following options a guideline:
•
Option #1
Make a copy of the Create Windows System Drive script and modify it to create the additional partitions using
the diskpart command. With this method, all the partitioning is still done within the script.
57
•
Option #2
Modify an HP-provided Windows OSBP
1.
Remove the Create Windows System Drive step from the Windows OSBP.
2.
Add the boot disk partitioning to the Windows unattend file following the instructions provided by
Microsoft. Also, modify the <DriverPaths> section to use X:\$oem$. The latter is necessary since
the C: partition will no longer be available with the removal of Create Windows System Drive step.
3.
Remove the HP-provided unattend file from the Windows OSBP and replace with the new unattend
file that contains the disk partitioning.
4.
Update the ProLiant Drivers for Windows XXX OSBP step to use X:\$oem$ as the directory path
parameter. This is necessary since C: partition will no longer be available with the removal of Create
Windows System Drive step.
NOTE: The X: (WinPE) drive is a RAM disk that only exists in memory. It is possible that the combined size
of the drivers may be too large to fit in the available RAM disk space. If this occurs, please consider using
Option #1 above.
Type: Windows .BAT
Parameters: None
Optional Custom Attributes:
•
SystemDrive
•
SystemDiskNumber
Decommission Server
Decommissions the secure agent connection between a target server in production and the appliance to allow for
reprovisioning of the target server.
Target servers provisioned by IC server provisioning contain certificates that uniquely and securely identify the server to
the appliance. The appliance expects to retrieve this information every time the target server boots. This can cause
problems when attempting to reprovision a server or when a server’s hard drive is erased, as the service OS may not be
able to retrieve these certificates. This script decommissions a server, breaking that security bond, and allowing a server
to boot into maintenance without requiring the identification certificates.
If this script is run against a server that does not have an established secure agent connection, the script exits and the
build plan continues without error.
CAUTION: Because of the way this script works, it can only be placed in a build plan after the first Boot step and before
the Wait for SA Agent step. Placing this script anywhere else will likely cause the build plan to fail.
CAUTION: This script breaks the secure agent connection between the target server and the appliance. Only run this
script against a target server if you are certain you will never boot the server back into its production operating system.
Type: OGFS
Parameters: None
Custom Attributes: None
Delete iLO User
Deletes an iLO user using the ProLiant Scripting Toolkit hponcfg utility.
Type: OGFS
Required Parameters:
•
--username=USERNAME - Username of the iLO user to delete.
Custom Attributes: None
58
Deploy Agent
Deploy an SA agent to the target server.
This script is typically used to deploy an agent to the stub partition in preparation for a Linux installation. This agent is
used to communicate with the server during the operating system installation and is not the same agent that is placed
on the production server.
Type: Unix
Required Parameters:
•
-d DEST, --dest=DEST Where to download the agent. This can be a file or a directory, absolute or relative.
Directories will be created if they don't exist. The default is to create a file in the current directory with the
same name. Directories that don't exist will be created, note however that the basename will be considered as
a file.
Optional Parameters:
•
-n NAME, --name=NAME The name of the file to download.
•
-g SERVER, --gateway=SERVER Optional server to download from. If not present the agent config will be used
to determine a valid gateway.
Custom Attributes: None
Display Media Server Settings
Displays the Media Server settings as read in from the Media Server Settings page. This is used for validating Media
Server settings.
Type: OGFS
Parameters: None
Custom Attributes: None
Embed files initrd
Embeds a specified list of files or directories into a new initrd image. This allows for the use of utilities and drivers
during the Linux installation.
Type: Unix
Required Parameters:
•
-s origin_name:destination_name The origin_name is the name of the file, directory, or set of files and
directories to embed and the destination_name is the location to put the file(s) in the initrd image.
origin_name and destination_name are separated by a colon (:). Multiple single files can be specified, but each
requires its own –s parameter. For example, -s file1:distination1 –s file2:destination2 –s file3:destination3
Table 15: Embed files initrd sample parameters
Parameters
Description
-s /tmp/user.ks.cfg:/
Copies /tmp/user.ks.cfg file to /
-s /tmp/opt/opsware/agent:/opt/opsware
Copies /tmp/opt/opsware/agent directory to /opt/opsware
-s /tmp/dud/.:/
Copies the contents of the /tmp/dud directory to /
Custom Attributes: None
Embed Monitoring SA Agent
Embeds the SA installation monitoring agent into the %pre section of the kickstart file along with a prescript to extract
and start it. This script has taken the place of the Deploy Agent script starting with RHEL 7.
Type: Python
59
Requirements:
•
Can only be used on RHEL 6 or later installations
Required Parameters:
•
agent_path: The local path to the agent zip file, for example /tmp/opt/opsware/agent/ogfs-agent.zip
Custom Attributes: None
Erase Server Disk
Erases the partition table on all detected disk drives.
This script is used to clear out a server’s disk drives, usually in preparation for reprovisioning. This script does not
overwrite the entire disk. It only overwrites the partition table.
CAUTION: Running this script causes data loss on all connected disk drives.
Type: Unix
Parameters: None
Custom Attributes: None
Find SD Card on Server
This script searches for the special embedded SD card or USB device on ProLiant target servers. If a card is found, the
custom attribute, boot_disk, is set to the device associated with the card. The boot_disk custom attribute is used in the
Create Stub Partition script step to force the creation of the initial installed OS boot partition on a specific disk. If the user
specified device name is not found, the step will fail.
Type: Python
Optional Parameter:
•
--embeddedDevice=EMBEDDEDDEVICE – Where EMBEDDEDDEVICE is the name of embedded device to be
searched for VMware ESXi 5.X OS deployment. The acceptable device names for EMBEDDEDDEVICE are sd_card
and usb. If not specified, it will search for either embedded sd_card or usb.
Custom Attribute: boot_disk
Get Deployment Interface Details
Retrieves and stores Deployment Interface Network details into the specified file. This is used with Install Windows SPP
script to reset the network after a NIC firmware or driver update.
Type: Python
Required Parameter:
•
absolute_filename – The absolute path to the file to write the network details.
Custom Attributes: None
Prepare Disks on HP ProLiant Gen8
[Note]: starting 7.5.1, this script is deprecated, use “Hide Intelligent Provisioning drives” step instead.
Hide Intelligent Provisioning drives
Prepares disks of an HP ProLiant Gen8 or above target server and sets the target device custom attribute,
SystemDiskDevice.
The embedded flash drives on ProLiant Gen8 and newer servers are sometimes seen by the operating system installers
and are possibly used for the hard drive by the installers. This script attempts to hide those embedded flash drives from
the operating system installer, and also sets a custom attribute to indicate to the installer, exactly which drive to install.
This script is required for Windows operating system deployments on ProLiant Gen8 and newer servers, since these
60
flash drives are displayed when the target server is booted to the Intelligent Provisioning WinPE service OS. Although
not required, this script can be used on ProLiant G6 and G7 servers without consequence.
Type: OGFS
Parameters: None
Custom Attributes: SystemDiskDevice
Inject AutoYaST Personalization Settings
Inject Kickstart Personalization Settings
Inject Kickstart Personalization Settings for ESXi 5
Injects settings for personalization into the appropriate kickstart or AutoYaST answer file.
When a build plan is run and the Configure static network information option is selected through the IC server
provisioning interface, a custom attribute named hpsa_netconfig is automatically created for each target server the
build plan is run against. hpsa_netconfig contains the network settings to be applied to that particular target server.
hpsa_netconfig is not created or set manually by the user.
At run time, these scripts edit the Kickstart or AutoYast files and insert static IP addressing information based on the
contents of the hpsa_netconfig custom attribute. If hpsa_netconfig is not defined, then this script does nothing and
completes successfully.
Type: OGFS
Optional Parameter:
•
--require-netconfig=[true,false] - Specify whether a network configuration is mandatory or not. Defaults to
false. If set to true and the hpsa_netconfig custom attribute is missing, the script will fail. This is useful when
creating a build plan where specifying a network configuration is mandatory.
Optional Custom Attribute: hpsa_netconfig
Inject Multi-NIC Kickstart Personalization Settings
Injects settings for personalization from Matrix Operating Environment into a Linux Kickstart answer file.
The multi-nic-configuration0 through multi-nic-configuration9 custom attributes are set through the Matrix Operating
Environment.
At run time, this script edits the Kickstart file and inserts the static IP addressing information based on the contents of
the multi-nic-configuration custom attributes. If multi-nic-configuration is not defined, then this script does nothing
and completes successfully.
Type: OGFS
Parameters: None
Required Custom Attributes: multi-nic-configuration0 through multi-nic-configuration9
NOTE: This script is to be used with Red Hat Linux 6.0 or higher release Kickstart answer files.
Inject Multi-NIC Personalization Settings
Injects settings for personalization from Matrix Operating Environment into a Windows unattend answer file.
The multi-nic-configuration0 through multi-nic-configuration9 custom attributes are set through the Matrix Operating
Environment.
At run time, this script edits the unattend file and inserts the static IP addressing information based on the contents of
the multi-nic-configuration custom attributes. If multi-nic-configuration is not defined, then this script does nothing
and completes successfully.
Type: OGFS
Parameters: None
Required Custom Attributes: multi-nic-configuration0 through multi-nic-configuration9
61
Inject Multi-NIC Required ESXi 5 Kickstart Settings
Injects required Matrix Operating Environment settings into an ESXi Kickstart answer file. The install NFS directive will
be inserted with the values used at the mount NFS share step. This inject step also checks if an encrypted password was
used, since such a password, cannot be used to automatically manage the hypervisor. The SSH service is also enabled
and started.
At run time, this script edits the Kickstart file and inserts the static IP addressing information based on the contents of
the standard_switch and multi-nic-configuration custom attributes. If standard_switch or multi-nic-configuration are
not defined, then this script will fail with an error.
Type: OGFS
Parameters:
•
accept-encrypted-password – accepts the password to be encrypted
Required Custom Attributes:
•
standard_switch – semicolon separated list of comma separated vlan names from Matrix Operating
Environment to configure ESXi vSwitches.
•
multi-nic-configuration0 through multi-nic-configuration9
Inject Personalization Settings
Injects settings for personalization into a Windows unattend answer file.
When a build plan is run and the Configure static network information option is selected through the IC server
provisioning interface, a custom attribute named hpsa_netconfig is automatically created for each target server the
build plan is run against. hpsa_netconfig contains the network settings to be applied to that particular target server.
hpsa_netconfig is not created or set manually by the user.
At run time, this script edits the unattend file and inserts the static IP addressing information based on the contents of
the hpsa_netconfig custom attribute. If hpsa_netconfig is not defined, then this script does nothing and completes
successfully.
Type: OGFS
Optional Parameter:
•
PATH_TO_FILE where an alternate path to the Unattend.xml, Unattend.txt, or sysprep.inf file may be specified.
This parameter can normally be omitted and the script will use the standard file locations. The following path
locations are checked (in order), and if that file exists, it is updated and no further files are checked.
X/Windows/Temp/Unattend.xml (For Windows 2008 OS Media installs), C/Windows/Panther/unattend.xml (For
Windows 2008 WIM installs).
•
--require-netconfig=[true,false] - Specify whether a network configuration is mandatory or not. Defaults to
false. If set to true and the hpsa_netconfig custom attribute is missing, the script will fail. This is useful when
creating a build plan where specifying a network configuration is mandatory.
Optional Custom Attribute: hpsa_netconfig
Inject Required AutoYaST Settings
This script injects required settings into the autoinst.xml file.
This script modifies the AutoYaST file and adds scripting that will allow IC server provisioning to monitor and control the
operating system installation.
62
•
required pre- chroot- and post- exitpoint scripts.
•
pre-exitpoint to start the agent before the installation starts.
•
chroot-exitpoint to stall the installation before the AutoYaST reboot between
o
the first and second installation phase. This also triggers
o
the integration of the HP SA agent installation executed
o
during the next reboot.
•
post-exitpoint
to write info file that the installation has finished
Type: OGFS
Required Parameter:
•
HP SA Agent Name - The SA agent that needs to be started during installation.
Custom Attributes: None
Inject Required ESXi 5 Kickstart Settings
This script injects required settings into the kickstart answer fill.
This script modifies the Kickstart file and adds scripting that will allow IC server provisioning to monitor and control the
operating system installation.
Type: OGFS
Optional Parameter:
•
accept-encrypted-password - accept the password to be encrypted, which for ESXi is not typically allowed.
Custom Attributes: None
Inject Required ESXi 6.0 U1 Kickstart Settings
This script injects required settings into the kickstart answer file.
This script modifies the Kickstart file and adds scripting that will allow IC server provisioning to monitor and control the
ESXi 6.0 U1 operating system installation.
Type: OGFS
Optional Parameter:
•
accept-encrypted-password - accept the password to be encrypted, which for ESXi is not typically allowed.
Custom Attributes: None
Inject Required Kickstart Settings
This script injects required settings into the kickstart answer file.
It appends code to the %pre section of the kickstart file, to start the agent before the installation starts. It also injects
code into the %post section to prevent the installer from rebooting after the installation is complete. The later gives the
target a chance to integrate the HP SA agent.
Type: OGFS
Parameters: None
Custom Attributes: None
Inject Required Unattend.xml Settings
This script injects required settings into the unattend answer file.
This script modifies the unattend file and adds scripting that will allow IC server provisioning to better monitor and
control the operating system installation.
Type: OGFS
Optional Parameter:
•
PATH_TO_FILE - An alternate path to the Unattend.xml file may be specified. This parameter can normally be
omitted and the script will use the standard file locations. The following path locations are checked (in order),
and if that file exists, it is updated and no further files are checked: X/Windows/Temp/Unattend.xml,
C/Windows/Panther/unattend.xml
Custom Attributes: None
63
Inject Windows Domain or Workgroup Personalization Settings
This script injects Windows Active Directory Domain or Workgroup related configuration into the unattend answer file as
part of a Windows OSBP. Values are read from custom attributes and inserted into the unattend file. Supported for
Windows Server 2008 and later releases.
Type: OGFS
Optional Parameter:
•
path_to_file - the OGFS path or absolute path on the target server to the unattend answer file. If this
parameter is omitted, the script will look for an existing file at X:\Windows\Temp\Unattend.txt.
Required Custom Attributes:
•
DomainName – Fully Qualified Domain Name
•
DomainUser – domain user with permissions to join the domain
•
DomainPassword – plain-text domain password to join the domain
Optional Custom Attribute:
•
Workgroup – workgroup name if joining workgroup and not a domain
Install and boot into local WinPE
This script is used to make sure that the proper version of WinPE is running on the target server. The required version of
WinPE is passed to the script using the winpeVersion parameter. If the version of WinPE running on the target server
does not match the requested version, this script will create a small temporary partition on the target server and will
write the correct version of WinPE to that partition. The script will then reboot the target server from that temporary
partition leaving the target server running the proper version of WinPE. If the target server was already running the
correct version of WinPE or if “any” is specified, this script does nothing.
This script is also used when booting to WinPE on a UEFI capable server that is in Legacy BIOS mode. The Intelligent
Provisioning version of WinPE included with your server always boot into UEFI mode, so when legacy mode is required,
this step will detect the mis-match and reboot into WinPE from the temporary partition using legacy mode.
Why use this step:
Use this step to always make sure your target server is running the correct version of WinPE in the correct mode
regardless of the version it booted via PXE or Intelligent Provisioning. If you do not include this step in your OS
installation Build Plans, you run the risk of having your Build Plans fail due to an incorrect WinPE version or server mode.
Usage notes:
This step does not replace the initial Boot step of a Build Plan. The initial Boot step is still required to bring the target
server from bare metal into the WinPE service OS. This step then checks the running version of WinPE and switches only
if necessary.
IMPORTANT: This step only works on servers that are in maintenance and should never be run from a production OS as it
may overwrite your OS boot partition.
Type: OGFS
Optional Parameters:
64
•
--winpeVersion - WinPE version which is required for this Build Plan. Choices are 3.0, 3.1, 4.1, or “any” 3.0 and
3.1 are equivalent. “any” means that any version of WinPE can be used and the step will only change the
service OS if there is a boot mode mismatch as described above.
•
--force – Forces the step to write and boot into a local WinPE regardless of the current environment.
•
--waitAtLeast=MINUTES – where MINUTES is the number of minutes to wait before actively checking for the
agent; default value is 1 minute.
•
--WaitAtMost=MINUTES – where MINUTES is the maximum number of minutes to wait for the agent to come
back online; default value is 15 minutes
•
--withVID - does not hide the Intelligent Provisioning embedded drives
•
--systemDiskNumber – system disk number where Windows is installed; default disk number is 0
•
--systemDrive – system drive letter where WinPE will be copied
Custom Attributes: None
Install bootloader for ESXi
Installs the ESXi boot loader.
The high level steps are: (1) Writing the EXTLINUX Master Boot Record to the boot disk, (2) Installing the EXTLINUX boot
loader, and (3) Creating the extlinux.conf configuration file. This script does not reboot the target server, but when this
script completes, the target server may be rebooted and the ESXi scripted install will occur. This script comes after the
Create Stub Partition and Copy Boot Media script steps, and expects the following files in /tmp: extlinux, mbr.bin, and
ks.cfg.
Type: Unix
Optional Parameter:
•
--kernel_arguments=’args’ - Pass on kernel arguments
Custom Attributes: None
Install bootloader for RedHat Enterprise Linux Server
Install bootloader for SuSE Linux Enterprise Server
Install bootloader for RedHat Enterprise Linux 7 Server
Installs GRuB (GRand Unified Boot Loader) onto the stub partition
GRuB is placed in the stub partition in order to enable the booting into the appropriate Linux installation image. The high
level steps are: (1) Installing the GRuB boot loader and (2) Configuring GRuB. This script does not reboot the target
server. This script comes after the Create Stub Partition.
Type: Unix
Optional Parameter:
•
kernel_arguments=’value’ - a string of arguments that will be passed to the build images' kernel, for example,
kernel_arguments=mpath used with Red Hat EL 5.8 for multipath support.
Custom Attributes: None
Install Linux SPP
Install Windows SPP
Installs the HP Service Pack for ProLiant (SPP) on the target server.
IMPORTANT: The Install Windows SPP script is no longer used starting with IC server provisioning 7.3.1. It has been
replaced with the following three steps; Install Windows SPP In Background, Wait for HP SA Agent, and Report Windows
SPP Installation Results. See the descriptions of these scripts in the reference section above for complete details.
These scripts install the entire SPP onto the running production target server using the HP SUM utility and specified SPP
version located on the Media Server. This includes agents, drivers, and firmware. If you do not want to install all of these
things, you can control what gets installed using the –hpsum_parameters parameter. See the HP SUM User Guide for
information about what options are available.
This script expects the SPP location on the Media Server to be \Media\spp\yyyy.mm.x where yyyy.mm.x is the
SPP version number, for example 2014.02.0. This script requires that the SPP be available, so it should come after the
Set Media Source script. Since this script uses the HP SUM utility, an SPP should be used in the media server location.
Copying a supplemental package to that location will fail the script since it won’t be able to find HP SUM.
NOTE: In some cases, it is common for a small percentage of the SPP components to fail. Because of this, by default, the
Install xxx SPP script will not report a failure if individual components fail with HP SUM exit code 253. Unfortunately,
there is no way to distinguish between one of these expected failures and an unexpected failure. If you prefer that your
script and build plan fail when a component fails, you can specify the –fail_on_warning flag.
Type: Unix or Windows .BAT
65
Required Parameter:
•
filename=absolute_filename – The absolute file path containing the Deployment Interface details of the
server which can be obtained by running Get Deployment Interface Details script.
Optional Parameters:
•
--spp_version=directory_name - The name of the directory containing the SPP to be installed, such as
2013.02.0. If the value is blank or latest, the script automatically selects the directory with the latest
version as determined by alphabetic sort order.
•
--hpsum_options="option1 option2 option3 ... optionN" - HP SUM utility supported command-line options
that are to be passed to HP SUM. Refer to HP SUM's CLIhelp.txt documentation file for available options.
•
--fail_on_warning - When specified, the script will fail on receiving the error code 253 from HP SUM. When
absent, the script will be successful for the error code 253 from HP SUM
Custom Attributes: None
Install Windows SPP In Background
This script installs the entire SPP onto the running production target server using the HP SUM utility and specified SPP
version located on the Media Server. It works exactly like the Install Windows SPP script, but the execution of HP SUM
happens in the background while the SA agent is disabled. This method eliminates problems caused when a NIC driver or
firmware is updated and the network connection to the appliance resets.
This step must be immediately followed by a Wait for HP SA agent step. The Wait for HP SA agent step will cause the
build plan to wait until the background SPP process completes and the SA agent is turned back on.
Also, because the execution happens while the agent is turned off, an additional step, Report Windows SPP Installation
Results, is required after the Wait for HP SA agent step to collect the results and report the SPP success or failure.
This script expects the SPP location on the Media Server to be \Media\spp\yyyy.mm.x where yyyy.mm.x is the
SPP version number, for example 2014.02.0. This script requires that the SPP be available, so it should come after the
Set Media Source script. Since this script uses the HP SUM utility, an SPP should be used in the media server location.
Copying a supplemental package to that location will fail the script since it won’t be able to find HP SUM.
Type: Python
Optional Parameters:
•
--spp_version=directory_name - The name of the directory containing the SPP to be installed, such as
2013.09.0. If the value is blank or "latest", the script automatically selects the directory with the latest version
as determined by sort order.
•
--hpsum_options="option1 option2 option3 ... optionN” - HP SUM supported command-line options that are to
be passed to HP SUM. Refer to HP SUM's CLIhelp.txt documentation file for available options.
Custom Attributes: None
Integrate HP SA Agent
Sets up the installation of the production SA agent as part of a Windows installation.
The important features it includes are as follows:
•
Downloading the HP SA agent installer
•
Creating a script that will execute the HP SA Agent installer when the final OS first boots.
•
Copying the server's unique MID and cryptographic certificates into place
•
Integrating with Windows setup to schedule a task that will install the HP SA agent when Windows first boots.
For Windows 2008 and newer, this is done by adding the appropriate script commands to the Unattend.xml file
Type: OGFS
Parameters: None
Custom Attributes: None
66
Integrate Linux HP SA Agent
Sets up the installation of the production SA agent as part of a Linux installation.
The agent will install and register at the first target server boot.
Type: OGFS
Optional Parameter:
•
HP SA Agent Name - The name of the HP SA agent to install. The name of the agent doesn't require quotes.
For example, Red Hat Enterprise Linux Server 5.
Custom Attributes: None
Manage iLO Configuration
Captures or sets the target server's iLO configuration using the ProLiant Scripting Toolkit hponcfg utility.
Type: Unix
Required Parameters:
•
To capture: -w output_filename
•
To set: -f input_filename
Manage Smart Array Configuration
Captures or sets the target server's Smart Array configuration using the ProLiant Scripting Toolkit HP SSACLI utility.
This script runs in the Linux service OS and attempts to unmount any partition mounted on the Smart Array. The
partitions are left unmounted (i.e. not remounted). These partitions must not be in use at the time this script is run.
Type: Unix
Required Parameters:
•
To capture: -c output_filename
•
To set: -i input_filename
Optional Parameters:
•
-nofail - indicates if the script should not fail if a Smart Array controller is not found.
•
-internal - limit operation to internal controllers. Is not used with –external parameter.
•
-external - limit operation to external controllers. Is not used with –internal parameter.
•
-reset - removes existing data and overwrites current configuration with new configuration. Use only with –i
parameter.
Manage System Configuration
Captures or sets the target server's BIOS system configuration using the ProLiant Scripting Toolkit conrep utility.
Type: Unix
Required Parameters:
•
To capture: -s output_filename
•
To set: -l input_filename template_filename
Monitor Installation
Monitors an installation by checking the installation log file at specified intervals.
67
This script checks the specified log file at given intervals to see if it has changed. If the log file has not changed after the
maximum number of checks, the script fails and reports a timeout. This means that the script will time out after
number_of_checks multiplied by the timeout in seconds.
Since sometimes packages take too long to install, you can extend the timeout for each package installation by
increasing the number_of_checks parameters to this script in your build plan. This can also be done to handle slower
hardware or networks
Type: OGFS
Required Parameters:
•
log_file - the log file that needs to be monitored
Optional Parameters:
•
number_of_checks - the number of times to check if the log file has changed before failing. This has a default
value of 100 times.
•
timeout - the timeout between checks. This has a default value of 6 seconds.
Custom Attributes: None
Move PXE To The End Of UEFI Boot Order
In UEFI mode, this step moves the PXE boot options to the end of the UEFI boot order. The boot order is not changed if
the server is in Legacy BIOS mode.
Type: OGFS
Parameters: None
Custom Attributes: None
Partition Disk for Windows
Creates a temporary partition on the target server hard drive using diskpart to prepare for Windows operating system
deployment and supports UEFI mode partitioning The partition is created within this script versus partitioning within
the unattend file for the following reasons:
•
HP felt it was easier to create or extend custom partitions this way versus inside the unattend XML format.
•
An error from diskpart may be more intuitive than trying to troubleshoot a partitioning error in setup.exe and
will happen earlier in the build plan.
•
The HP-provided OSBPs use this temporary partition to store the extracted driver files. This helps prevent
running out of disk space on the WinPE RAM drive (X:).
You can modify the HP default partitioning schemes using one of the following methods:
•
Option #1 – Change the HP provided script to meet your needs
Make a copy of the Partition Disk for Windows script and modify it to create the additional partitions using the
diskpart command. With this method, all the partitioning is still done within the script.
•
Option #2 – Remove the HP partitioning script and do partitioning in the unattend file
Modify an HP-provided Windows OSBP
68
1.
Remove the Partition Disk for Windows script step from the Windows OSBP.
2.
Add the boot disk partitioning to the Windows unattend file following the instructions provided by
Microsoft. Also, modify the <DriverPaths> section to use X:\$oem$. The latter is necessary since
the C: partition will no longer be available with the removal of Partition Disk for Windows step.
3.
Remove the HP-provided unattend file from the Windows OSBP and replace with the new unattend
file that contains the disk partitioning.
4.
Update the ProLiant Drivers for Windows XXX OSBP step to use X:\$oem$ as the directory path
parameter. This is necessary since C: partition will no longer be available with the removal of the
Partition Disk for Windows step.
NOTE: The X: (WinPE) drive is a RAM disk that only exists in memory. It is possible that the combined size
of the drivers may be too large to fit in the available RAM disk space. If this occurs, please consider using
Option #1 above.
Type: OGFS
Parameters: None
Optional Custom Attributes:
•
SystemDrive
•
SystemDiskNumber
Personalize Network Settings of Installed System
Personalizes network settings of the server after OS installation using values provided by custom attribute
‘hpsa_netconfig’. See Appendix B for information about hpsa_netconfig and the type of information you can personalize
with this build plan.
This step provides an easy way to configure all of the NICs on a target server once it’s running a production OS. It is the
key component of the “Configure Network” feature and is used in most OS Build Plans to apply a configuration after the
OS is installed. See the on line help for the “Configure Network” feature for more information.
Type: Python
Optional Parameters (Linux only):
•
--systemRoot – specifies the root folder where the configuration will take place. Defaults to "/" on an installed
Linux OS, and /mnt/local_root if the step is run on the service OS.
•
--configureOnly - The new specified configuration will be configured but will only be applied after a reboot. By
default the configuration will be applied if the systemRoot is /(root)
•
--disableWarning Do not show warnings of old hpsa_netconfig format
Important: The connection to the SA agent might be temporarily interrupted. So, not all output from the step will be
visible, but all setting will be applied. A "Wait for HP SA Agent" step is required right after this step to make sure that the
agent is operational before other steps can be executed.
Custom Attributes:
hpsa_netconfig
Prepare Windows for Image Capture
This script prepares a running Windows installation (Windows 2008 and newer) from a Managed server to be captured
using the Sysprep tool.
For more information about the Sysprep tool, refer to the following articles:
•
http://technet.microsoft.com/library/cc766514
•
http://technet.microsoft.com/en-us/library/cc721973
Type: Windows .BAT
Optional Parameter:
•
/unattend:path_to_answer_file – Path to the answer file that is passed to the Sysprep tool.
Custom Attributes: None
Prevent WIM File Overwrite
Checks for the existence of the WIM image file.
69
This ensures that an existing WIM image is not accidentally overwritten if another capture build plan is run that uses the
same WIM file name. The script returns an error if the specified file name exists on the Media Server. Removing this step
from a build plan will allow an existing image file to be overwritten.
Type: Windows .BAT
Required Parameters:
•
WIM_filename The WIM file name and path to be checked if exists.
Custom Attributes: None
Reboot
This script reboots a target server into the production operating system.
This script clears any previous boot configuration for the target server and triggers a reboot so that the target server
will follow its normal boot order and boot from its hard disk into the installed production operating system.
Type: OGFS
Parameters: None
Custom Attributes: None
Reboot to Apply BIOS Changes and Power Off
Completes a BIOS reset by booting the target server and then powering it off.
When a system BIOS is reset to factory settings, the reset does not take effect until the next time the target server is
power cycled. This script performs that power cycle, waits a specified amount of time for the reset to take effect, and
then powers the server off again. The default settings will then have been applied, and the server is ready to have
another build plan run against it.
This script should always be used following the Reset System Configuration script step.
NOTE: After completion of this script, the target server is left powered off. The next build plan run against this server
needs to have a Boot step up front to bring the server back up.
NOTE: This script is based on the Boot script, so it uses some of the same parameters, even though the target server
should never actually complete the booting process. It should be powered off before it completes the power on selftest.
Type OGFS
Required Parameters:
•
--serviceOS='SERVICE_OS' - represents the service OS into which to boot; See the method parameter for the
supported service OSs. The target server should power off before booting to this OS, so what you put here
does not matter.
•
--force - Forces the boot configuration and reboot of the target server. This is required whenever using this
step to force the boot operation to take place.
Optional Parameters:
•
•
--method=‘METHOD’ - This parameter is not required as the target server should power off before the boot
ever begins, but it can be specified without consequences. Possible values:
-
auto - it will behave as embedded or network, depending on the target server
-
embedded - supported only if the IloService is enabled on the target server and this is a HP ProLiant
Gen8. The following service OSs are possible: linux, linux64, or winpe64.
-
network - configures PXE network booting into the selected Service OS if the IloService is enabled on
the target server it will also set the one time boot option to NETWORK. Specifying an ogfs PXEoption as the Service OS is supported.
--wait <time> - Specify a new wait time. Default is 45 seconds.
Custom Attributes: None
70
Remove Custom Attributes From Server
This script removes all or specific Custom Attributes for a target server. This script can also remove just the Custom
Attributes generated by the Collect and Store System Data script. If a Custom Attribute does not exist on the target
server, then the script step will generate an information message and move ahead with the attributes without failing.
Any attribute(s) that is removed from the target server are logged into the job log for future reference.
Why use this step:
There are many reasons why you might want to automatically remove server custom attributes as part of a build plan.
For example, the SystemDiskNumber custom attribute is automatically created in many build plans. Once it’s created, it
will be used for all subsequent OS installation build plans, something that may be undesirable. This step can be added
to the beginning or ending of a build plan to delete that custom attribute and allow it to be set new the next time. The
same is true for network personalization and the hpsa_netconfig custom attribute. If the custom attribute doesn’t get
deleted, all OS installation build plans will use the same network settings. This step can be added to remove that
personalization data after it’s applied. Lastly, if you used the Collect and Store System Data step, that may have created
many custom attributes. This step can be used to remove only the custom attributes that were created by that step,
leaving all others intact.
Type: OGFS
Required Parameters:
•
--all – All of the Custom Attributes associated with that target server are removed.
•
--allGeneratedAttrs – Only Custom Attributes that were set on the target server using the Collect and Store
System Data script step are removed.
•
--custAttrNames “ca1 ca2…” – Just the specified Custom Attributes associated with that target server are
removed.
--all, --allGeneratedAttrs, and –custAttrNames are mutually exclusive. When multiple arguments are passed, the
script step will generate an error and fail.
Custom Attributes: Refer to Collect and Store System Data script description.
Remap Windows Drives
Remaps the volumes to new drive letters, starting with "C". Network drives are not remapped since those drive letters
are explicitly assigned. The "X" drive is reserved for WinPE and is not remapped either.
Type: Python
Optional Parameter:
•
--reservedDriveLetters="letter1 letter2 ... letterN" A space separated list of drive letters that are not to be
assigned during the remapping.
Custom Attributes: None
Report Windows SPP Installation Results
This script works with the "Install Windows SPP In Background" script. It reports the results of the SPP installation, by
collecting the HP SUM return code and log data from a file left behind by the Install Windows SPP In Background step.
Type: Python
Optional Parameter:
•
--fail_on_warning - Causes the build plan step to fail if the HP SUM return code is -3, which means that there
were some components that could not be installed. By default a -3 is recorded as a success.
Custom Attributes: None
Reset System Configuration
Resets the target server's BIOS system configuration to factory default settings using the rbsureset utility.
71
As part of the reset, the date and time on the target server is reset.
NOTE: The system settings are not actually reset until the next server power cycle. Always follow this step with the
Reboot to Apply BIOS Changes and Power Off step which will perform this power cycle.
Type: Unix
Parameters: None
Custom Attributes: None
Run Windows 2008 R2 x64 Setup
Run Windows 2008 x64 Setup
Run Windows 2012 x64 Setup
Run Windows 2012 R2 x64 Setup
Starts the appropriate Windows operating system installation by call the setup.exe specified in the script parameter.
Type: Windows .BAT
Required Parameters:
•
“setup.exe_path_and_file” - Path and filename to the Windows setup.exe program. Parameter should
include the double quotes.
Custom Attributes: None
Sample - Capture Linux Server Image
Sample - Create New Filesystem RHEL
Sample - Create New Filesystem SLES
Sample - Deploy Linux Image
Sample - Fixup RHEL Deployment
Sample - Fixup SLES Deployment
Sample - Mount the RHEL Filesystem
Sample - Mount the SLES Filesystem
Sample - Re-Install RHEL HP SA Agent
Sample - Re-Install SLES HP SA Agent
Sample - Remove RHEL Old Partition
Sample - Unmount RHEL Disk Partition
These scripts are provided as samples to accompany the Insight Control server provisioning Capturing and Installing
Linux System Images Technical white paper. The scripts are copies of the scripts in the white paper and are provided
here as a convenience to avoid copy and paste errors. These scripts are just samples and may require modification to
use with the specific target server hardware or drive configuration.
Set Media Source
Defines the connection from the target server to the Media Server.
The Set Media Source script is where the location of the media to be used for a build plan is specified. The script will do
different things depending on the protocol specified in the URI:
•
SMB – This is the Samba/Windows file share protocol. When this protocol is specified, the Windows file share is
mounted immediately as part of this script.
•
HTTP – When the HTTP protocol is specified, this script writes the media location information to a special place
where it can be read by the Inject Required Settings steps later on. Those steps modify the OS installation
answer file to use the HTTP location specified for the OS installation.
•
NFS – When NFS is specified, the NFS mount happens immediately as part of the script.
Note: The media server cannot be a domain controller.
Type: Python
72
Required Parameters:
•
URI - where URI can be any of the supported schemes:
-
smb from a Windows client:
smb://username:password@server/path/to/media[#X:]
where X is the drive letter to mount. If the mount drive is omitted, the default is Z: If the
media server is part of a domain, the username must be in the form domain\username,
where domain is either the domain of the user account or the computer name if the user
account is a local account. The username can be a maximum length of 20 characters.
-
smb from a Linux client:
smb://username:password@server/path/to/media#/mount/point?noserverino
where /mount/point is the local mount point and no server info is required.
If the media server is part of a domain and the user account is a domain account, the
username must be in the form domain\username, where domain is the domain of the
user account. If the media server is part of a domain and the user account is a local account,
specify just the username, and add the domain=<computername> option to the end of
the command line. The username can be a maximum length of 20 characters.
Special options:
Additional options can be added to the URI by appending them as a comma separated list.
These are passed as options to the mount.cifs command that is used to mount the
media server share. A sample URI with extra options:
smb://mydomain\user:mypassword@myserver.corp.com/media#/mnt?noserverino,sec=ntlmv2
The following are some common options:
sec=securitymode – This option is used to match the security mode of the target server to
the security mode of the media server. The value of 'securitymode' needs to be set based
on the security configuration of your media server. If not specified the default is 'ntlm'. The
table below lists common Windows security policies and the appropriate security mode
setting. See the mount.cifs man page for more information.
Table 16: Windows security policies and ‘securitymode’ valuse
Security policy selected
Allowable choices
for 'securitymode'
(choose only one)
Network security: LAN Manager Authentication level
Send LM & NTLM responses
ntlm,ntlmv2,ntlmv2i
Send LM & NTLM - use NTLMv2 session security, if negotiated
ntlm,ntlmv2,ntlmv2i
Send NTLM response only
ntlm
Send NTLMv2 response only
ntlmv2,ntlm
Send NTLMv2 response only, Refuse LM
ntlmv2,ntlm
Send NTLMv2 response only, Refuse LM & NTLM
ntlmv2
Microsoft network server: Digitally sign communications (always)
ntlmv2i
Microsoft network server: Digitally sign communications (if client
agrees)
ntlm,mtlmv2,ntlmv2i
domain=name – This option is typically not needed. It is only used when the media server is
part of a domain and the username specified in the URI does not contain the domain
information. The value of 'name' will contain either the domain of the username that was
specified, or the computername of the media server, if it is a local user account.
73
-
http:
http://server/path/to/media
-
nfs:
nfs://server/path/to/media[#/path/to/mount/point]
If the mount point is omitted, it defaults to /mnt/media
Custom Attributes: None
Set One Time PXE Boot
This script will set one-time PXE boot. It is intended for servers migrated from IC server deployment/RDP. It uses
hponcfg to set the one-time PXE boot on Windows-based target servers and /sbin/hpbootcfg on Linux-based target
servers. /sbin/hpbootcfg is a utility installed on RDP-deployed target servers.
NOTE: This script will only work on target servers that were provisioned using RDP and migrated to IC server
provisioning.
Type: Unix
Parameters: None
Custom Attributes: None
Shutdown Server
This script powers down a physical server using its iLO. The script first attempts a graceful shutdown of the server using
the iLO Momentary Press function. For ACPI-aware operating systems, this should trigger a graceful shutdown. If after
two minutes, the server is not shut down, a hard power off is performed. This step does not power off VMs.
Type: OGFS
Optional Parameter:
•
--failVM - Causes the build plan step to fail if the target server is a VM. The default behavior is for the step to
exit successfully, even though the VM was not powered off.
Custom Attributes: None
Skip steps based on Custom Attribute
Skips a number of steps based on a Custom Attribute
This step skips a number of steps in a build plan. The number of steps to skip is determined by a parameter, and the skip
will only happen if a custom attribute, also specified as a parameter, evaluates to a positive value (“yes”, “y”, or “1”).
Why use this step:
This step can be used to create a build plan whose behavior changes based on a custom attribute. As a result, you can
create a single generic build plan that can account for multiple scenarios controlled by custom attributes, as opposed to
the alternative of creating one build plan for each scenario.
Type: OGFS
Optional Parameters:
•
--CA - The Name of the custom attribute that will control the flow of the Build Plan.
Ex: --CA='@custom_attribute@'
Valid values: 'yes', 'y', '1', 'no', 'n', '0'
•
--skipSteps - Number of steps that will be skipped if the value of the CA is positive.
Custom Attributes:
•
74
Create a custom attribute with any one of the valid values assigned. The valid values are ‘yes’,’y’,’1’,’no’,’n’,’0’.
The same name should be used in --CA parameter.
Note: If the Custom Attribute is not present or has a null string value, this step will not skip any other steps.
Uninstall HP ProLiant Utilities
Uninstalls HP ProLiant utilities that store system specific information in the registry.
This script is typically used with image capture build plans. There may be problems if a Windows image captured with
these agents and utilities installed is deployed to another server.
Beginning with IC server provisioning 7.3.1, the script name was changed to Uninstall HP ProLiant Utilities, replacing
instances of Uninstall HP Agents and Utilities.
IMPORTANT: The Uninstall HP ProLiant Utilities step only works on English operating systems. The HP utilities will need
to be manually uninstalled from any non-English system before capturing the Windows image. Use the English version
of the script to determine the list of agents and utilities that need to be uninstalled.
Type: Windows .BAT
Parameters: None
Custom Attributes: None
Unmap Network Drive
Unmaps the network drive that is associated with the specified drive letter. If there is no network drive associated with
the specified drive letter, this script still completes successfully.
Type: Python
Required Parameters:
•
--driveLetter - The letter that's associated with the network drive to be unmapped.
Custom Attributes: None
Unmount All Boot Disk Partitions
Unmounts all the partitions belonging to the boot disk. By default, the boot disk is computed as the first hard drive
listed in /proc/partitions.
Type: Unix
Parameters: None
Optional Custom Attributes:
•
boot_disk - The absolute path to the device file for the boot disk. For example, /dev/sda.
Unmount Intelligent Provisioning WinPE Drive
Unmounts the Intelligent Provisioning WinPE volume containing the directory, $WinPEDrivers$ where WinPE drivers are
provided for ProLiant Gen8 servers. This prevents the Windows setup utility from using these drivers for the Windows
installation. This script is currently only used with Windows 2008 SP2 deployments.
Type: Windows .BAT
Parameters: None
Custom Attributes: None
Update Firmware Using SPP
Runs an off-line firmware update on the target server using HP SUM from an SPP on the media server.
IMPORTANT: With IC server provisioning 7.3.1only, this script has been modified so that it will only run when the server
is booted to the Intelligent Provisioning service OS available on ProLiant Gen8 or newer servers. Attempts to run this
script on servers prior to Gen8 or on servers that are PXE booted will result in a failure of the script with an appropriate
message. This issue was resolved with IC server provisioning 7.3.2.
75
This script must be run while booted in the LinuxPE service OS. It uses the HP SUM utility and specified HP Service Pack
for ProLiant (SPP) version. This script expects the SPP location on the Media Server to be \Media\spp\yyyy.mm.x
where yyyy.mm.x is the SPP version number, for example 2014.02.0. This script comes after the Set Media Source
script.
Since this script uses the HP SUM utility, an SPP should be used in the media server location. Copying a supplemental
package to that location will fail the script since it won’t be able to find HP SUM.
The SPP version may have an alpha number after the yyyy.mm.x, for example, 2013.09B.0. Adding this alpha number at
the end will work appropriately to pickup 2013.09B.0 as the latest compared with 2013.09.0 or 2013.09A.0.
Since this is an off-line firmware update, the log files showing what happened will be lost as soon as the server reboots.
If you want to save a copy of the logs on the media server, use the hpsum_logs_dump_dir option as described below.
Type: Unix
Optional Parameters:
•
--spp_version=directory_name - The name of the directory containing the SPP to be installed, such as
2015.10.0 If the value is blank or latest, the script automatically selects the directory with the latest
version as determined by sort order.
•
--hpsum_options="option1 option2 option3 ... optionN" - HP SUM utility supported command-line options
that are to be passed to HP SUM. Refer to HP SUM's CLIhelp.txt documentation file for available options.
•
--hpsum_logs_dump_dir=writable_directory_under_mounted_file_share - Copies the zipped HP SUM log
files to the specified directory. The directory must start with the mount point specified in the Set Media Source
script step. For example, if the file share where the zipped HP SUM log file is to be copied to is mounted on
/mnt/media and the destination directory is "hpsum_logs", then specify
--hpsum_logs_dump_dir=/mnt/media/hpsum_logs.
•
--no_show_log – Do not display the hpsum_log.txt contents in the job log.
Custom Attributes: None
Update Intelligent Provisioning Firmware
Updates the Intelligent Provisioning (IP) firmware on a ProLiant Gen8 or newer target server. This script must be run
while PXE booted in the LinuxPE service OS. PXE booting is required as the IP cannot be flashed while it is actively
booted. It uses the utilities and functions provided in IP Recovery media for update. This script expects the IP location on
the Media Server to be \Media\ip\x.xx where x.xx is the IP version number, for example 1.60 without the period. This
script is run after the Set Media Source script since requires connection to the media server.
Type: Unix
Optional Parameters:
•
--ip_version=directory_name - The name of the directory containing the IP to be installed, such as 1.60. If the
value is blank or ‘latest’, the script automatically selects the directory with the latest version as determined by
sort order.
Custom Attribute: None
Validate Custom Attributes
Validates that the specified custom attributes exist and have values assigned.
This script is used early in a build plan to check that required custom attributes are defined and have non-null values
before proceeding with the rest of the build plan. It validates the custom attributes defined in the parameter field and
fails the build plan if any custom attribute does not have a value associated with it. Indicating no parameters will cause
this script to do nothing and end successfully.
Type: OGFS
Required Parameters:
76
•
--custAttrNames "custAttrName1 custAttrName2 custAttrName3 ... custAttrNameN" The parameter list is a
space-separated list of custom attribute names contained inside double quotes. At least one parameter is
required.
Custom Attributes: None
Validate Gateway Setting for Static Network Configuration
Verifies that a gateway (gw) has been specified when using static network configuration. Some operating systems
require a gateway when doing a static network configuration.
When a build plan is run and the Configure static network information option is selected through the IC server
provisioning interface, a custom attribute named hpsa_netconfig is automatically created for each target server on
which the build plan is run. hpsa_netconfig contains the static network settings that are applied to that particular target
server. hpsa_netconfig is not created or set manually by the user.
This script is used early in the build plan to check if a gateway is defined in hpsa_netconfig before proceeding with the
rest of the steps in the build plan. The build plan will fail if the gateway is not specified. If hpsa_netconfig does not
exist, this script will skip the gateway validation and proceed with the remaining steps in the build plan.
Type: OGFS
Required Parameters: None
Optional Custom Attribute: hpsa_netconfig
Validate ImageX Package Contents
Verifies that the ImageX package contains imagex.exe.
This script is used as a validation step to verify that the imagex utility has been properly uploaded to the appliance. It is
used so that the build plan can check for this, warn the user, and fail early in the build plan, before irreversible changes
are made to the target server. This step should always follow the deploy imagex package step.
On a new appliance, the ImageX zip package contains a dummy file and does not contain the imagex.exe utility.
imagex.exe is one of the things that are uploaded to the appliance when you build and upload WinPE as described in the
installation guide.
This script validates that imagex.exe made it into the ImageX package and has been installed in the
SystemDrive\HPPROVTEMP directory using the Install ZIP Package - ImageX step if the target server is in the
production OS, or in X:\Windows\System32 if the target server is in WinPE service OS where SystemDrive is the
Windows production system drive letter. On the production OS, the SystemDrive\HPPROVTEMP directory is
removed after the contents of the ImageX package have been verified.
Type: Windows .BAT
Parameters: None
Custom Attributes: None
Validate Media Server
Validates the Media Server configuration and the data entered on the Media Server Settings page. Use this to validate
your Media Server settings or troubleshoot Media Server access problems. All forms of access appropriate to the
particular booted environment are tested. Diagnostic messages are output to the job log.
See the Set Media Source step and Media Server troubleshooting topic in the Troubleshooting section of the online help
for more information about troubleshooting the Media Server.
Type: Python
Parameters: None
Custom Attributes: None
77
Validate Windows OS Version
This step verifies that the target server is running a Windows version that is appropriate for the particular Build Plan it’s
in. It does this by comparing the running Windows version against a list of versions provided as a parameter to this step.
If the running OS version does not match one from the parameter list, the step will fail with an appropriate error
message and cause Build Plan execution to halt.
Why use this step:
This script is one of several early error checking steps, and is typically used to check that it is executing on a version of
Windows the Build Plan can support. It allows the Build Plan to fail gracefully before any permanent data loss occurs.
Type: OGFS
Required Parameter:
•
‘--version=<os-short-name>', where <os-short-name> is a comma separated list of Windows versions that the
Build Plan will support. Versions must be specified using the short name abbreviations listed in Table 9. At
last one version must be specified.
Table 9: os-short-name values
Full Qualified Windows OS Name
os-short-name Value
Windows 2008
Win2008
Windows 2008 R2
Win2008R2
Windows 2012
Win2012
Windows 2012 R2
Win2012R2
Windows 7
Win7
Windows 8.1
Win81
Table 10: Check Windows OS Version sample parameters
Parameters
Description
--version ‘Win2012’ ‘Win2012R2’
Verifies OS running on target servers are
either Windows 2012 or Windows 2012 R2.
--version ‘Win7’
Verifies OS running on target servers are
either Windows 7.
--version ‘Win2008’ ‘Win2008R2’
Verifies OS running on target servers are
either Windows 2008 or Windows 2008 R2.
--version ‘Win81’
Verifies OS running on target servers are
either Windows 8.1.
Validate WinPE Version
This script is used as a validation step to verify that the target server is booted into the correct WinPE version.
Beginning with IC server provisioning 7.3.1, WinPE 4.0 or WinPE 3.1 can be used with the product; however, Windows
2008 SP2 and Windows 2008 R2 can only be successfully installed via WinPE 3.1.
NOTE: With Intelligent Provisioning v1.60 or greater, WinPE version is 4.0.
NOTE: Beginning with Insight Control server provisioning version 7.5, multiple versions of WinPE come pre-installed on
the appliance, and a Build Plan with the “Install and Boot to Local WinPE” step can automatically switch to the required
version of WinPE. That new feature make this step obsolete, however, the step will be retained for legacy purposes.
Type: Python
Required Parameter:
•
78
--version=n where n is 3.1, 4.0, a list of versions ("3.1, 4.0"), or any. The version of the booted WinPE is
checked against the parameter specified. If no option is specified, then the option defaults to 3.1.
Custom Attributes: None
Verify Supported Boot Modes
Verifies that the target server is configured in a boot mode that is supported by the build plan. The boot modes that the
build plan supports can be specified using the options listed below. For example, if the build plan installs an operating
system which does not support the UEFI boot mode, then the -uefi=false option should be specified, so that the
build plan execution is stopped before the operating system is attempted to be installed.
Multiple parameters can be used together to list all the boot mode restrictions.
Type: OGFS
Parameters:
•
--legacy={true|false} Specifies whether the build plan can be run on a server whose boot mode is set to
Legacy BIOS mode. Default is “true”.
•
--uefi={true|false} Specifies whether the build plan can be run on a server whose boot mode is set to UEFI
mode. Default is “true”.
•
--optimized={enabled|disabled|any} Specifies whether the build plan can only be run on a server with UEFI
optimization enabled, disabled, or any. The default is "any".
•
--secure={enabled|disabled|any} Specifies whether the build plan can only be run on a server with UEFI secure
boot enabled, disabled, or any. The default is "any".
Custom Attributes: None
Verify server has iLO4 or newer
Verifies that the target server has an iLO4 management processor or newer. If the target server has iLO, iLO2, iLO3, or
no iLO at all, the script will return an error.
There are scenarios where a build plan can only be run on servers with iLO 4 or newer (one example: Intelligent
Provisioning Firmware Update). This step is used in those build plans to ensure that the target server is running iLO 4 or
newer. If not, it will fail early instead of unnecessarily going forward with build plan execution.
Type: OGFS
Parameters:
•
-t MINUTES or --atMost=MINUTES - Wait at most MINUTES number of minutes before timing out. Default is 10
minutes.
Custom Attributes: None
Validate Server Platform
Validates whether the selected target server model is supported for running the Windows or Linux OS Build Plan. This
script compares the value provided in the script parameter with the Hardware Model of the server as stored in the
appliance database. If the target server selected is not supported, this script will fail with error code 2. This script is
used, for example, with the Windows 7 SP1 Professional build plans to only run on Proliant WS460c Gen8 or Gen9
Graphics Server Blades.
Type: OGFS
Required Parameter:
•
--prodname = Comma separated list of server model names that are not case sensitive. If the model names
contain spaces, surround the entire list in double quotes.
Optional Parameter:
•
--exact = Match the server model name exactly as specified in the –prodname parameter. The default behavior
will match partial strings. For example, “ProLiant BL” should match all HP ProLiant Bladeservers.
Custom Attributes: None
79
Wait for ESXi installation
Waits for an ESXi installation to complete.
Since there is no SA Agent available under ESXi, this script is used to verify that the production hypervisor is booted
properly. In the ESXi kickstart file, a few lines of Python script executes under first production boot, sending a ping back
to say that installation is complete and the machine is booted successfully in to production.
Type: OGFS
Parameters: None
Custom Attributes: None
Wait for HP SA Agent
Waits for the HP SA Agent to register or come online before proceeding with future instructions.
This script is used in nearly every build plan. It holds up a build plan’s execution during the time a target server is
booting, and will not allow processing to continue until the target server finishes booting and an agent on that server
registers itself with the appliance. Any Boot or Reboot step must be followed by a Wait for SA Agent step, since the Boot
steps do not wait for boot completion.
Once an agent does register with the appliance, the script will check to make sure the target server was booted into the
proper mode as specified by the parameters listed below.
This step can also be used to re-establish communication with a target server when the running build plan might cause a
network interruption. If a build plan step causes the target server's NIC to go down for any reason, the agent will lose its
connection to the appliance and cause the build plan to fail. Adding the Wait for HP SA Agent step after the step with the
network interruption will cause the build plan to wait for the target server to reestablish a connection.
NOTE: The Decommission Server step is the only step that is allowed to come between Boot and Wait for SA Agent.
Type: OGFS
Optional Parameters:
•
--ogfs, --maintenance Interchangeable parameters that indicate the server is to boot into a service OS. HPprovided build plans do not use --ogfs.
•
--production indicates we are expecting a production agent.
•
--atLeast=MINUTES – where MINUTES is the number of minutes to wait before actively checking for the agent;
default value is 1 minute. This is necessary in some cases, because this script could actually end up polling for
an agent before the target server shuts down. The delay allows the server to shut down and begin its reboot.
•
--atMost=MINUTES – where MINUTES is the maximum number of minutes to wait for the agent to come back
online; default value is 15 minutes. It may be necessary to increase this setting if the target server is slow at
booting and not providing enough time for the agent to connect.
Custom Attributes: None
Windows Image Capture
Creates a WIM image of the target server using ImageX.
For more information about ImageX, see the following two articles:
•
http://technet.microsoft.com/en-us/library/cc722145
•
http://technet.microsoft.com/en-us/library/cc749447
Type: Python
The parameters are specified in order, separated by spaces.
Required Parameters:
•
80
Full path where the WIM image file will be saved including the file name and .wim extension.
•
Drive number to be captured
Optional Parameter:
•
Path to the optional wimscript.ini exclusion file. This file contains a list of files for ImageX to skip while
imaging. The Capture Windows Image script will always add files to the exclusion list to prevent imaging the
Server Automation agent files. In no wimscript.ini file is specified, one will be created just for the agent files.
Example parameters:
•
--wimFilePath="Z:\Images\@WimFileName@" --systemDiskNumber=@SystemDiskNumber:0@
Custom Attributes: None
Configuration Files
Summary
The configuration files listed in this section are used or were created to be used by the HP-provided build plans. There
are configuration files that are not part of the HP-provided build plans, but are meant to be interchanged with
configuration files in the build plans.
Configure Windows Partitioning Scheme for Legacy
Contains diskpart commands which create a BIOS/MBR system partition.
Configure Windows Partitioning Scheme for Uefi
Contains diskpart commands which create a UEFI/GPT system partition.
ESXi 5.0 U1 Kickstart
ESXi 5.0 U2 Kickstart
ESXi 5.0 U3 Kickstart
ESXi 5.1 Kickstart
ESXi 5.1 U1 Kickstart
ESXi 5.1 U2 Kickstart
ESXi 5.1 U3 Kickstart
ESXi 5.5 Kickstart
ESXi 5.5 U1 Kickstart
ESXi 5.5 U2 Kickstart
ESXi 5.5 U3 Kickstart
ESXi 6.0 Kickstart
ESXi 6.0 U1 Kickstart
ESXi 6.0 U2 Kickstart
Sample answer file for the specified operating system.
Refer to the appropriate operating system supplier for answer file details.
NOTE: For ESXi 5.1 and later, ESXi naming has changed to vSphere; however, OSBPs, scripts and configuration files may
continue to state ESXi.
Optional Custom Attributes:
•
encrypted_root_password – root password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
kernel_arguments
•
ProductKey_ESXi50, ProductKey_ESXi51 or ProductKey_ESXi55 depending on which file is used - Requires
editing answer file to remove the comment for the vmserialnum line.
81
iLO Configuration - Set Minimum Password Length
Sets the iLO Minimum Password Length with default as 8.
This is a sample file used as a template for creating custom files. Refer to ProLiant Scripting Toolkit documentation for
hponcfg configuration file details.
Custom Attributes: None
ImageX Configuration - Exclude Boot Directory
Excludes the /Boot directory from the capture process using the imagex.exe /capture option.
This is required for some Windows capture build plans to prevent multiple boot loader entries from being created when
the WIM image is installed, since bcdboot.exe will create a new boot loader entry.
Custom Attributes: None
RHEL 5.9 x64 en_us Kickstart
RHEL 5.10 x64 en_us Kickstart
RHEL 5.11 x64 en_us Kickstart
RHEL 6.3 x64 en_us Kickstart
RHEL 6.4 x64 en_us Kickstart
RHEL 6.4 x64 KVM en_us Kickstart
RHEL 6.5 x64 en_us Kickstart
RHEL 6.5 x64 KVM en_us Kickstart
RHEL 6.6 x64 en_us Kickstart
RHEL 6.6 x64 KVM en_us Kickstart
RHEL 6.7 x64 en_us Kickstart
RHEL 6.7 x64 KVM en_us Kickstart
RHEL 7.0 x64 en_us Kickstart
RHEL 7.0 x64 KVM en_us Kickstart
RHEL 7.1 x64 en_us Kickstart
RHEL 7.1 x64 KVM en_us Kickstart
RHEL 7.2 x64 en_us Kickstart
RHEL 7.2 x64 KVM en_us Kickstart
SLES 11 SP2 x64 en_us Autoyast
SLES 11 SP3 x64 en_us Autoyast
SLES 11 SP4 x64 en_us Autoyast
SLES 12 x64 en_us Autoyast
SLES 12 SP1 x64 en_us Autoyast
Sample answer file for the specified operating system. By default with IC server provisioning 7.2.2 and later releases,
firewall settings are disabled within these answer files to allow SA agent communication on port 1002. Commented
code to enable firewall is also provided that is designed to allow communication on port 1002.
Refer to the appropriate operating system supplier for answer file details.
Optional Custom Attributes:
•
encrypted_root_password– root password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
kernel_arguments
•
boot_disk – describes which disk to install Linux, for example sda, hdc, cciss/c0d1
Ubuntu Server 14.04 preseed
Sample answer file for the specified operating system.
82
Refer to the appropriate operating system supplier for answer file details.
Optional Custom Attributes:
•
encrypted_root_password– root password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
kernel_arguments
Smart Array Configuration - Delete RAID Logical Volumes
Clears the Smart Array configuration.
IMPORTANT: Using this configuration file causes data loss.
This configuration file deletes all logical volumes and arrays on all Smart Array controllers. Refer to ProLiant Scripting
Toolkit documentation for HP SSACLI configuration file details.
Custom Attributes: None
Smart Array Configuration - Set RAID 1
Smart Array Configuration - Set RAID 5
Configures the Smart Array with the specified RAID level
Refer to ProLiant Scripting Toolkit documentation for HP SSACLI configuration file details.
Custom Attributes: None
System ROM Configuration – Enable Boot from SAN
System ROM Configuration - Enable Virtualization
IMPORTANT: The System ROM Configuration – Enable Boot from SAN configuration file is no longer available starting
with IC server provisioning 7.4.0. Refer to the ProLiant HW – System ROM Enable Boot from SAN build plan for more
information.
Enables Boot from SAN on ProLiant Blade Servers or Virtualization BIOS functionality on ProLiant servers. Virtualization
BIOS functionality enables CPU Virtualization or No Execute Memory Protection (NX on AMD processors).
Refer to ProLiant Scripting Toolkit documentation for conrep configuration file details.
Custom Attributes: None
Windows 2008 SP2 DataCenter x64 en_us Unattend
Windows 2008 SP2 Enterprise x64 en_us Unattend
Windows 2008 SP2 Standard x64 en_us Unattend
Windows 2008 SP2 Web Server x64 en_us Unattend
Sample answer file for the specified operating system and edition.
Refer to the appropriate operating system supplier for answer file details.
NOTE: The HP-provided unattend files do not contain any disk partitioning information. The partitioning of the boot disk
is performed in the Partition Disk for Windows OSBP step. Refer to the Partition Disk for Windows script description in
the Scripts section within this document for important information about disk partitioning.
Required Custom Attributes:
•
ProductKey_Win2008-DC-x64, ProductKey_Win2008-Ent-x64, ProductKey_Win2008-Std-x64, or
ProductKey_Win2008-WS-x64
Optional Custom Attributes:
•
ComputerName
83
•
EncryptedAdminPassword– Administrator password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
Custom Attribute.
•
SystemDrive
•
SystemDiskNumber
Windows 2008 R2 SP1 DataCenter x64 en_us Unattend
Windows 2008 R2 SP1 Enterprise x64 en_us Unattend
Windows 2008 R2 SP1 Standard x64 en_us Unattend
Windows 2008 R2 SP1 Web Server x64 en_us Unattend
Sample answer file for the specified operating system and edition.
Refer to the appropriate operating system supplier for answer file details.
NOTE: The HP-provided unattend files do not contain any disk partitioning information. The partitioning of the boot disk
is performed in the Partition Disk for Windows OSBP step. Refer to the Partition Disk for Windows script description in
the Scripts section within this document for important information about disk partitioning.
Required Custom Attributes:
•
ProductKey_Win2008R2-DC-x64, ProductKey_Win2008R2-Ent-x64, ProductKey_Win2008R2-Std-x64, or
ProductKey_Win2008R2-WS-x64
Optional Custom Attributes:
•
ComputerName
•
EncryptedAdminPassword– Administrator password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
Custom Attribute.
•
SystemDrive
•
SystemDiskNumber
Windows 2012 DataCenter x64 en_us Unattend
Windows 2012 Standard x64 en_us Unattend
Sample answer file for the specified operating system and edition.
Refer to the appropriate operating system supplier for answer file details.
NOTE: The HP-provided unattend files do not contain any disk partitioning information. The partitioning of the boot disk
is performed in the Partition Disk for Windows OSBP step. Refer to the Partition Disk for Windows script description in
the Scripts section within this document for important information about disk partitioning.
Required Custom Attributes:
•
ProductKey_Win2012-DC-x64 or ProductKey_Win2012-Std-x64
Optional Custom Attributes:
84
•
ComputerName
•
EncryptedAdminPassword– Administrator password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
SystemDrive
•
SystemDiskNumber
Windows 2012 R2 DataCenter x64 en_us Unattend
Windows 2012 R2 Standard x64 en_us Unattend
Sample answer file for the specified operating system and edition.
Refer to the appropriate operating system supplier for answer file details.
NOTE: The HP-provided unattend files do not contain any disk partitioning information. The partitioning of the boot disk
is performed in the Partition Disk for Windows OSBP step. Refer to the Partition Disk for Windows script description in
the Scripts section within this document for important information about disk partitioning.
Required Custom Attributes:
•
ProductKey_Win2012R2-DC-x64 or ProductKey_Win2012R2-Std-x64
Optional Custom Attributes:
•
ComputerName
•
EncryptedAdminPassword– Administrator password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
SystemDrive
•
SystemDiskNumber
Windows 7 SP1 Professional x64 en_us Unattend
Windows 7 SP1 Enterprise x64 en_us Unattend
Sample answer file for the specified operating system and edition.
Refer to the appropriate operating system supplier for answer file details.
NOTE: The HP-provided unattend files do not contain any disk partitioning information. The partitioning of the boot disk
is performed in the Partition Disk for Windows OSBP step. Refer to the Partition Disk for Windows script description in
the Scripts section within this document for important information about disk partitioning.
Required Custom Attributes:
•
ProductKey_Win7-Pro-x64 or ProductKey_Win7-Ent-x64
Optional Custom Attributes:
•
ComputerName
•
EncryptedAdminPassword– Administrator password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
SystemDrive
•
SystemDiskNumber
Windows 8.1 Pro x64 en_us Unattend
Windows 8.1 Enterprise x64 en_us Unattend
Sample answer file for the specified operating system and edition.
Refer to the appropriate operating system supplier for answer file details.
NOTE: The HP-provided unattend files do not contain any disk partitioning information. The partitioning of the boot disk
is performed in the Partition Disk for Windows OSBP step. Refer to the Partition Disk for Windows script description in
the Scripts section within this document for important information about disk partitioning.
Required Custom Attributes:
•
ProductKey_Win81-Pro-x64 or ProductKey_Win81-Ent-x64
Optional Custom Attributes:
•
ComputerName
85
•
EncryptedAdminPassword– Administrator password in encrypted form. Refer to the HP Insight Control Server
Provisioning online help on how to create an encrypted password.
•
SystemDrive
•
SystemDiskNumber
Packages
Summary
The packages listed in this section are used or were created to be used by the HP-provided build plans. There may be
packages that are not part of the HP-provided build plans, but can be interchanged with packages in the build plans.
There may be packages listed in your appliance that are not listed here. These packages are not used or tested by IC
server provisioning and will not be discussed here. Additionally, there are no packages for ESXi deployments since those
drivers are part of the HP-provided VMWare ESXi operating system distribution.
ESXi Installation Utilities
Contains the boot loader and Master Boot Record needed to boot ESXi.
GRub Boot Loader x86
Contains the grub boot loader that will land on the stub partition.
Even though the name contains x86, it is still used with x64 Linux deployments.
Hponcfg for Windows x64 with One Time PXE Boot
Contains hponcfg and support files to setup the one-time PXE boot.
This package is part of the RDP migration related build plans. It puts hponcfg and support files needed to setup the onetime PXE boot on a target server running a Windows production operating system. The bundled hponcfg.exe only
supports x64 bit architectures
This package should only be used on servers deployed using RDP and then migrated to IC server provisioning
ImageX
The ImageX Microsoft imaging utility.
By default, this package does not contain the imagex.exe utility, but instead, contains a dummy file. The real ImageX
utility is uploaded to the appliance with the WinPE image that gets generated externally and is then uploaded to the
appliance. Using the IC server provisioning WinPE Image Generation utility, which is available for download from the
Settings > DHCP page, a zip package containing WinPE, as well as the required imagex.exe utility is created. When this
zip package is uploaded to the appliance in the Settings > DHCP page, using the Upload file button, the imagex.exe
utility will be automatically inserted into this package.
LinuxPE add-on packages
Contains additional libraries and utilities required in the LinuxPE PXE service OS.
LinuxPE HBA add-on packages
Contains additional libraries and utilities required by the Fibre Channel utilities in the LinuxPE PXE service OS.
86
ProLiant Drivers for RHEL 5.9 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 5.10 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 5.11 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 6.3 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 6.4 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 6.5 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 6.6 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 6.7 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 7.0 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 7.1 x64 - yyyy.mm.x
ProLiant Drivers for RHEL 7.2 x64 - yyyy.mm.x
ProLiant Drivers for SLES 11 SP2 x64 - yyyy.mm.x
ProLiant Drivers for SLES 11 SP3 x64 - yyyy.mm.x
ProLiant Drivers for SLES 11 SP4 x64 - yyyy.mm.x
ProLiant Drivers for SLES 12 x64 - yyyy.mm.x
ProLiant Drivers for SLES 12 SP1 x64 - yyyy.mm.x
ProLiant Drivers for Windows 2008 x64 - yyyy.mm.x
ProLiant Drivers for Windows 2008 R2 x64 - yyyy.mm.x
ProLiant Drivers for Windows 2012 - yyyy.mm.x
ProLiant Drivers for Windows 2012 R2 - yyyy.mm.x
Contains Service Pack for ProLiant (SPP) drivers for the specified operating system. Starting with IC server provisioning
release 7.3.1, the package names include the SPP version, yyyy.mm.x. IC server provisioning 7.2.2 contained packages
with yyyy.mm only. This is to allow multiple SPP driver versions to reside on the appliance.
NOTE: A package may have an older version compared with other packages since the SPP no longer supports all drivers
for that operating system version. For example, ProLiant Drivers for RHEL 6.3 x64 - 2013.09b will be the latest package
provided for Red Hat EL 6.3 support.
NOTE: The Windows 7 SP1 Professional install build plans were added with IC server provisioning 7.4.0 and use the
ProLiant Drivers for Windows 2008 R2 x64 - yyyy.mm.x driver package.
NOTE: The Windows 8.1 Pro install build plans were added with IC server provisioning 7.4.1 and use the ProLiant Drivers
for Windows 2012 R2 - yyyy.mm.x driver package.
ProLiant Scripting Toolkit for Linux x64
Contains the ProLiant Scripting Toolkit 64-bit utilities.
Appendix A – Changes in Build Plans for each release
With each new release of Insight Control server provisioning, the HP provided build plans are updated to provide more
functionality, support more platforms, be more robust, and correct defects. Any build plans you customized in a
previous release may not have the latest changes, since those build plans are copies of the ones HP provided in the older
release. This appendix provides a description of all the build plan changes made for each release so that you can update
your customized build plan to take advantage of the latest features. Some of the changes listed here are optional, while
others are mandatory. Read this section carefully.
Depending on the customizations you make to your build plans and the changes for each release, you may find it easier
to re-customize the latest HP provided build plans rather than go back and change your old ones. For example, if all you
do is change the unattend file, it will be easier to copy a new Windows build plan and replace the unattend file, than it
will be to modify your old build plan to get all the latest changes.
87
New Changes for IC server provisioning Release 7.5.1
Linux Combo Build Plan updated to use RHEL 7.2
The sample Linux combo Build Plan was modified to use RHEL 7.2, and the older Linux combo Build Plan was removed
Modification to Windows Build Plans
Prepare Disks on HP ProLiant Gen8 and Adjust Windows System Disk Number on HP ProLiant Gen8 steps are deprecated
and replaced with Hide Intelligent Provisioning step.
New Changes for IC server provisioning Release 7.5.0
“Install and boot into local WinPE” step now added in all Windows Scripted Install Build Plans to facilitate WinPE
version switching.
To support multiple WinPE versions installed on the appliance and the automatic switching of WinPE versions, the Install
and boot into local WinPE step was added to all Windows scripted OS installation Build Plans, and the --winpeVersion
parameter for the step was added to Build Plans that require a specific WinPE version.
These changes allow Windows Build Plans to automatically switch WinPE versions if a specific version is required but not
currently running. Below is a list of Windows versions and the required WinPE versions:
•
WinPE 3.1 is required for installing Windows 2008, Windows 2008 R2, and Windows 7.
•
WinPE 4 is required for installing Windows 8.1.
•
Windows 2012 and Windows 2012 R2 will work with either version of WinPE.
You should modify any existing Build Plans to take advantage of this new feature. See the HP provided Build Plan that
corresponds to the version of Windows you are installing to see what parameters to use and where to add this step.
All Build Plans check the server boot mode and were updated to reflect support of UEFI Secure Boot mode
In the previous release, the Validate Supported Boot Modes step was added to Build Plans to check that the current boot
mode of the server was supported that Build Plan. This release of Insight Control server provisioning adds support for
UEFI Secure Boot mode at OS installation time, and Build Plans that support UEFI Secure Boot were updated to reflect
that new support.
UEFI Secure Boot Mode is supported for the following operating systems:
RHEL 7.0, RHEL 7.1, RHEL 7.2, SLES 12,SLES 12 SP1, Windows 2012, Windows 2012 R2
You can modify the Validate Supported Boot Modes step in your existing Build Plans to reflect this support by removing
the “--secure=disabled” parameter.
Note that if your system has a Smart Array Controller, only the px4x series of controllers support UEFI Secure Boot
Mode.
Modifications to ProLiant OS - Windows 2008 & Windows 2008 R2 build plans
The parameter in the Validate Supported Boot Modes step was changed to --UEFI=false to fail the OSBP if the target is in
UEFI Mode.
RHEL 6.5 and 6.6 Kickstart files updated with i40e drivers
The Intel i40e driver fails to load on some installations, so a specific callout was added to the HP provided RHEL 6.5 and
6.6 Kickstart files. If your servers need this driver, you may want to add this to your Kickstart files too. The additional
lines look like this:
# Needed to ensure Intel i40e driver installed when required
kmod-hp-i40e
Linux Combo Build Plan updated to use RHEL 7.1
The sample Linux combo Build Plan was modified to use RHEL 7.1, and the older Linux combo Build Plan was removed.
Driver name change in driver packages
ProLiant Drivers for RHEL 6.5 x64 - 2015.06.0
ProLiant Drivers for RHEL 6.6 x64 - 2015.06.0
ProLiant Drivers for RHEL 7.1 x64 - 2015.06.0
88
The name of a driver in above packages has changed from previous versions. In the older package versions, the driver
was named kmod-mlnx-en. In the latest 2015.06.0 packages, it is named kmod-mlnx-ofa_kernel. To use the newer
driver package with an older kickstart file, or an older driver package with the newer kickstart file, the kickstart file will
need to be updated with the appropriate driver name.
New Changes for IC server provisioning Release 7.4.1
Driver packages from IC server provisioning 7.2.1 and 7.2.2 will be deprecated
The following driver packages will not be included in the full appliance database:
•
ProLiant Drivers for RHEL 5.9 x64 - 2013.09b
•
ProLiant Drivers for RHEL 6.4 x64 - 2013.09b
•
ProLiant Drivers for SLES 11 SP2 x64 - 2013.09b
•
ProLiant Drivers for SLES 11 SP3 x64 - 2013.09b
•
ProLiant Drivers for Windows 2008 R2 x64 - 2013.09b
•
ProLiant Drivers for Windows 2008 x64 - 2013.09b
•
ProLiant Drivers for Windows 2012 - 2013.09b
New Build Plan step to validate Windows OS version
The new script Check Windows OS Version was added that verifies the Windows OS version, passed as parameter to the
script, against the Windows OS running on target server. This script is basically used in Windows image capture build
plan to detect the early error. An appropriate error message will be displayed if any non-windows OS image capture
build plan or windows OS image capture build plan with no parameter/invalid parameter is specified.
New Build Plan to do Post Install Network Personalization
The new build plan is added to do the network personalization after installing either Windows or Linux production OS.
The build plan makes use of hpsa_netconfig custom attribute to provide the network settings. The reboot step can be
either skipped or retained based on the option passed in the separate custom attribute. This custom attribute will then
be used in the new step called “Skip steps based on Custom Attribute”.
New Changes for IC server provisioning Release 7.4
New Steps and Build Plans for enabling Boot from SAN
The Build Plan ProLiant HW - System ROM Enable Boot from SAN on Bladeserver and associated configuration file System
ROM Configuration - Enable Boot from SAN have been deprecated and are replaced by the new Build Plan ProLiant HW System ROM Enable Boot from SAN and associated script Configure Boot From SAN.
The introduction of HP ProLiant Gen9 servers changed the way Boot from SAN was implemented in addition to adding
support for non-blade systems.
If you created any custom build plans that included functionality to enable booting from SAN, you will want to update
them to use these new methods.
New Build Plan step to validate server hardware platform support
A new script Validate Server Platform was added that compares the reported hardware model of the target server with a
list of models specified as parameters to the script. If you have any custom Build Plans that are specific to particular
hardware models or VMs, you may wish to add this script to prevent errors caused by running the Build Plans on the
wrong platform.
New RHEL7 specific steps
Some new Build Plan steps were created to account for changes in RHEL 7 installation procedures. There is a new Embed
Monitoring SA Agent, that takes the place of Deploy Agent, and a new Install bootloader for RedHat Enterprise Linux 7
Server is used instead of Install bootloader for RedHat Enterprise Linux Server. No changes to older build plans are
required, but if you are creating custom RHEL 7 Build Plans, be sure to use the HP provided RHEL 7 Build Plan as a
starting point.
89
The Validate Custom Attribute script was updated to require a parameter
The Validate Custom Attribute script must have at least one parameter included with it when used within a build plan.
Driver name change in ProLiant Drivers for RHEL 6.4 x64 – 2014.09.0 and ProLiant Drivers for RHEL 6.5 x64 2014.09.0 driver packages
The name of a driver in ProLiant Drivers for RHEL 6.4 x64 – 2014.09.0 and ProLiant Drivers for RHEL 6.5 x64 – 2014.09.0
packages has changed from previous versions. In the older package versions, the driver was named kmod-mellanoxmlnx-en. In the latest 2014.09.0 packages, it is named kmod-mlnx-en. To use the newer driver package with an older
kickstart file, or an older driver package with the newer kickstart file, the kickstart file will need to be updated with the
appropriate driver name.
New Changes for IC server provisioning Release 7.3.2
The ProLiant SW - Offline Firmware Update build plan was modified for running in LinuxPE PXE service OS
The ProLiant SW - Offline Firmware Update build plan was modified to provide dependencies needed by the HP SUM
utility and the Smart Components when run under LinuxPE PXE service OS.
New Changes for IC server provisioning Release 7.3.1
All Build Plans updated to support Proliant Servers with UEFI Boot Capability
All of the HP-provided build plans now support servers running in UEFI mode as well as "Legacy" BIOS mode. Many of the
changes for this support were made in the back end and will automatically be picked up by older build plans, however,
there are some important changes you will need to make if you want your build plans to remain current and support UEFI
servers. If you are not planning on using any UEFI servers, these changes may not be necessary. The changes are as
follows:
•
Most Build Plans now include the Verify Supported Boot Modes script step which helps make sure the action
being performed by the build plan is supported by the mode the server is in.
•
All Windows Scripted Install and Image Install Build Plans were updated to support UEFI disk partitioning.
The Create Windows System Drive script was replaced by the following three steps in order: Configure Windows
Partitioning Scheme for Legacy, Configure Windows Partitioning Scheme for Uefi, and Partition Disk for
Windows configuration files and script.
•
All Windows Scripted Install Build Plans were updated to support a legacy BIOS mode installation while using
a UEFI server and the Intelligent Provisioning WinPE Service OS. The Install and boot into local Winpe script
was added after the Wait for HP SA Agent step to allow for this special case.
•
All Windows Image Capture Build Plans now use a new capture script. Windows Image Capture is now used
instead of Capture Windows Image. The old script is still provided but is no longer supported.
•
All Windows Image Install Build Plans now use a new image deployment script. Windows Image Deploy is now
used instead of Apply WIM Image. The old script is still provided but is no longer supported.
•
VMware ESXi 5.1u2 and VMware ESXi 5.5 Scripted Install Build Plans were updated to add ESXi to the UEFI
boot menu. The Add ESXi Boot Option To UEFI Boot Order script was added for this purpose.
Windows 2008 SP2 and Windows 2008 R2 SP1 Build Plans updated to check for WinPE Version
The Validate WinPE Version script was added to the Windows 2008 SP2 and Windows 2008 R2 SP1 scripted install build
plans to fail if WinPE 3.0 or 3.1 is not being used. Beginning with IC server provisioning 7.3.1, multiple WinPE PXE
versions are provided. Windows 2008 SP2 and Windows 2008 R2 SP1 may only be installed using WinPE 3.1 PXE version
or Intelligent Provisioning v1.50 or earlier which is based on WinPE 3.0. Adding this step early in the build plan will help
ensure the OS install will not be attempted using the wrong version of WinPE.
Windows unattend answer files now use EncryptedAdminPassword custom attribute instead of the AdminPassword
custom attribute
The old AdminPassword custom attribute was replaced with EncryptedAdminPassword in all of the default Windows
unattend files to help reduce confusion and make it clear to users that the password being provided is expected to be
90
encrypted. Underlying functionality has not changed as the Administrator password was always encrypted in previous
versions. This is an optional change for your old build plans.
Linux and ESXi kickstart and autoyast answer files use encrypted_root_password custom attribute instead of the
root_password custom attribute
The old root_password custom attribute was replaced with encrypted_root_password in all of the default Linux and ESXi
configuration files to help reduce confusion and make it clear to users that the password being provided is expected to
be encrypted. Underlying functionality has not changed as the root password was always encrypted in previous versions.
This is an optional change for your old build plans.
Set Media Source parameter changed from /mnt/ms to /mnt/media in some build plans
In build plans that mount the media server from a Linux OS, the mount point when using Set Media Source is now set to
/mnt/media. Scripts that use this mount point have been updated to recognize /mnt/ms or /mnt/media. Since this is a
parameter defined for each OSBP, it is not necessary update customizable OSBPs.
All Windows image OS build plans - Uninstall HP Agents and Utilities replaced with Uninstall HP ProLiant Utilities
Since the Uninstall HP Agents and Utilities script did not uninstall agent information, the script name was changed to
Uninstall HP ProLiant Utilities to more accurately reflect that only HP utilities are being uninstalled. This script is used
within the Windows Image capture OS Build Plans. Updating customized OS Build Plans is not necessary.
Windows SPP Build Plans – New scripts used to install the SPP and collect results
In build plans that install the Windows SPP, the Install Windows SPP script was replaced by the following three steps;
Install Windows SPP In Background, Wait for HP SA Agent, and Report Windows SPP Installation Results. See the
descriptions of these scripts in the reference section above for complete details.
Also note that HP SUM is now copied from the media server to the target server before executing so that a network
interruption will not interfere with the execution.
New Changes for IC server provisioning Release 7.2.2
Custom Attribute added for several ProLiant HW build plans
A new custom attribute, configuration location was added to the following ProLiant HW build plans:
• ProLiant HW - iLO Capture Configuration
• ProLiant HW - Smart Array Capture Settings
• ProLiant HW - System ROM Capture Settings
This custom attribute is the absolute filename where the captured configuration file is to be stored and it will contain a
default value. The value is considered to be a temporary location where the file will reside until it is consumed by a later
step in the build plan. Adding this custom attribute to any existing build plans is not required unless specific control is
necessary where these temporary files are stored.
Script step added to ESXi build plans for network gateway validation
A new build plan script step was added to the beginning of all ESXi scripted installation build plans. This Validate
Gateway Setting for Static Network Configuration script build plan step verifies that a gateway was specified if static
networking information is provided for the target server. Unlike most other operating systems, ESXi requires that a
gateway be specified when configuring static IP information during an installation. The only purpose of this script is to
do error checking and fail the build plan before the ESXi installation is started. Adding this step to existing ESXi build
plans is recommended as an extra safety check, but is not required.
New ProLiant Driver package naming to include SPP version
For all Windows and Linux scripted install build plans, the ProLiant drivers packages have been named to include the SPP
version with format as ProLiant Drivers for xxxx – yyyy where xxxx is the operating system name and version and yyyy is
91
the SPP version. This new naming convention will allow storage of multiple SPP versions of the ProLiant driver packages
on the appliance. After an upgrade, all HP-provided build plans will use the latest versions of the driver packages. Any
customized build plans will continue to use older versions of the driver packages. To use the latest driver packages for
customized build plans, a build plan modification will be required to replace the older ProLiant drivers package build plan
step with these new ones.
Windows build plans contain comment information regarding disk partitioning in the unattend answer files
Two commented lines have been added to all default Windows unattend answer files regarding the disk partitioning. The
commented lines explain that disk partitioning is done within a script build plan step of the build plan and not within the
unattend answer file. These are just comments and are not necessary for customized build plans.
Linux build plans have firewall disabled in default kickstart or autoyast answer files
The default Linux answer files have the firewall disabled. Commented example lines are provided to enable the firewall,
but still allow communication on port 1002. If configuring a firewall on target servers, make sure port 1002 is open for
agent communication.
Modifications to the Erase Server Disk build plan
A new build plan script step was added to the Erase Server Disk build plan to set the server life-cycle to UNPROVISIONED
and the wait parameter to the Reboot to Apply BIOS Changes and Power Off script build plan step was increased to 180:
--serviceOS=linux64 --force –wait=180
This is a recommended change to customized build plans.
Appendix B – Network Personalization Custom Attribute
Details
Personalize Network Settings
Network personalization is achieved using the `hpsa_netconfig` custom attribute using a simple
[JSON](http://json.org/) syntax to express the network setup to be configured on the target system.
Example
{
"hostname" : "testname",
"domain" : "test.domain.com",
"workgroup" : "someWorkgroup",
"interfaces" : [
{
"macAddress": "11:22:33:44:55:66",
"enabled": true,
"dhcpv4": true,
"ipv6Autoconfig": true,
"provisioning": true,
"dnsServers" : [ "192.168.0.30", "192.168.0.31", "FC00:2::30", "FC00:2::31" ],
"dnsSearch" : [ "test.domain.com", "domain.com" ],
"winsServers" : [ "192.168.0.34" ],
"staticNetworks": [
92
"192.168.0.123/24",
"192.168.0.124/255.255.255.0",
"FC00:2::123/64"
],
"vlanid" : 2,
"ipv4gateway": "192.168.0.1",
"ipv6gateway": "FC00:2::1"
}
],
"virtualInterfaces" : [
{
"interfaceName" : "br0",
<--rest of the fields are similar to “interfaces”-->
}
]
}
Mandatory and Optional Fields
If you do not specify the `hpsa_netconfig` custom attribute, SA automatically determines the interface used by the SA
Agent to communicate with the SA Core when the personalization runs. This interface, also known as the *Provisioning
Interface*, is configured for automatic configuration through DHCP.
If the `hpsa_netconfig` Custom Attribute is present, and contains *interfaces*, the `macAddress` field defaults to the
MAC address of the provisioning interface if not present. Because there is a single provisioning interface, there can only
be one interface definition in `hpsa_netconfig’ that doesn't have a MAC address.
MAC Addresses are needed to uniquely identify the network interfaces of the server. All other fields are optional and
have default value
The `hpsa_netconfig` format does not make any assumptions about how the networks to which the server is joined are
configured. For this reason, only minimal validation is performed. SA does not verify that the settings lead to valid
connectivity between the SA Agent and the SA Core. You should verify that the specified network settings will allow the
SA Agent to connect to the SA Core after they are applied. Other obvious error cases, like disabling the provisioning
interface, are validated.
Description of Individual Fields
enabled
The value handles the state in which the interface will be after the network is configured. If the value is false, the
interface will still be configured as intended but it will be deactivated.
hostname, domain
The host name (also known as computer name) is the name used to identify the node on the network. The domain name
is the DNS registered domain of the server. Together they account for the fully qualified domain name (FQDN) of the
server.
interfaces
A list of the physical network interfaces of the system that are to be configured. Each interface (as identified by the MAC
address) can have a single entry in the list.
93
macAddress
The Media Access Control (MAC) address of the network interface. Multiple formats are accepted, colon or dash
separated, or just a string of hexadecimal numbers.
dhcpv4
Controls the use of the DHCP for acquiring IPv4 network addresses.
ipv6Autoconfig
Controls the use of IPv6 stateless address autoconfiguration (SLAAC) and DHCPv6 simultaneously. The IPv6 router
should be configured to advertise DHCPv6 configuration. If not specified, depending on how the SA Agent is connected to
the SA Core, it will be se to true (IPv6 connection) or false (IPv4 connection).
provisioning
This field is used to explicitly specify the interface to be used for provisioning. Only one provisioning interface is
supported. Use of this field is not recommended outside of complex scenarios. In most cases, SA will be able to (and will)
configure this automatically.
dnsServers, dnsSearch, winsServers
Controls the name resolution settings. The order in which the values are specified will be the order of configuration. The
first DNS nameserver, DNS domain or WINS server in the list will be the primary selection. DNS servers can be a
combination of both IPv4 and IPv6 addresses. For WINS servers only IPv4 addresses are supported.
staticNetworks
A list of static networks to configure on the interface. IPv4 addresses can use the CIDR notation, or IP address / network
mask notation. IPv6 addresses will use the IP address / prefix length notation. The first address in the list will be the first
one to be applied.
ipv4gateway/ipv6gateway
The IP version 4/6 of the default gateway (next hop) address.
vlanid
The VLAN ID used to tag packets for this interface.
virtualInterfaces
Configures the non-physical interfaces. These are not identified by their MAC address but by their interface Name. The
virtual interfaces are configured similar to the physical ones (using fields as dhcpv4, staticNetworks, etc.).
interfaceName
Identifier for the configured virtual interface. This field is not necessary for the physical interfaces which are identified
by their MAC address.
94
For more information
To read more about Insight Control server provisioning, go to www.hpe.com/go/insightcontrol/docs
•
HPE Insight Management Support Matrix
•
HPE Insight Control Server Provisioning Installation Guide
•
HPE Insight Control Server Provisioning Administrator Guide
•
HPE Insight Control Server Provisioning online help
•
HPE Insight Control Release Notes
95
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising