HPE Insight Control
Server Provisioning 7.6
Build Plans Reference
Guide
HPE Part Number: 5200-2444
Published: November 2016
Edition: 1
1
© Copyright 2012, 2016 Hewlett Packard Enterprise Development LP
The information contained herein is subject to change without notice. The only warranties for Hewlett Packard Enterprise
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. Hewlett Packard Enterprise shall not be liable for technical
or editorial errors or omissions contained herein.
Confidential computer software. Valid license from Hewlett Packard Enterprise 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.
Links to third-party websites take you outside the Hewlett Packard Enterprise website. Hewlett Packard Enterprise has no
control over and is not responsible for information outside the Hewlett Packard Enterprise website.
Acknowledgments
Microsoft® and Windows® are either registered trademarks or trademarks of Microsoft Corporation in the United States
and/or other countries.
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.
Adobe® and Acrobat® are trademarks of Adobe Systems Incorporated.
For access to applicable source code for the open source software used by HPE Insight Control server provisioning, see the
website www.hpe.com/software/opensource
2
Contents
Table of contents
Summary
10
OS Build Plans
ProLiant Hardware
ProLiant Operating System
ProLiant Software
ProLiant Combination
10
10
10
10
10
OS Build Plan Steps
Run Script
OGFS
Python
Unix
Windows BAT
Windows VBScript
Powershell
Deploy Package
Deploy Configuration File
Capture Configuration File
11
11
11
11
11
11
11
11
11
11
12
Working with OS Build Plans
Modifying Configuration Files
Adding Scripts
Modifying Build Plan Step Parameters
Combining Build Plans
12
12
12
12
13
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
13
13
17
20
22
25
28
29
30
32
32
Build Plan and Build Plan Steps Reference
OS Build Plans
Summary
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
33
33
33
33
34
34
34
35
35
35
35
35
36
36
36
36
36
36
37
37
37
37
38
38
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
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 6.8 x64 Scripted Install
ProLiant OS - RHEL 6.8 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 2016 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 2016 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 2016 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
38
38
39
39
39
39
39
39
39
39
39
39
39
39
39
39
39
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
40
41
41
41
41
41
41
41
41
42
42
42
42
42
42
42
43
43
43
43
43
43
43
43
43
44
4
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
ProLiant SW - Validate Media Server Settings
Scripts
Summary
Add ESXi Boot Option To UEFI Boot Order
Add ESXi Boot Option to UEFI Boot Order in PXE
Add ESXi Module
Add iLO User
Add 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
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 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
44
44
44
45
45
45
46
46
46
46
47
47
47
48
48
48
48
49
49
49
49
49
49
49
50
50
50
52
52
52
52
53
54
54
54
55
55
56
56
56
57
57
57
58
58
58
58
59
59
59
59
59
59
60
60
61
61
61
61
62
62
63
63
63
63
63
63
Install Linux HPSUT
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
Run Windows 2016 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
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 Boot to Service OS
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
64
64
64
64
65
65
65
65
66
66
67
67
67
67
68
69
69
69
69
69
69
69
69
70
70
70
70
70
70
70
70
70
70
70
70
70
71
72
72
72
73
73
73
73
74
74
75
75
75
76
76
77
77
77
78
78
78
79
79
79
79
79
80
80
80
80
80
6
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
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 6.8 x64 en_us Kickstart
RHEL 6.8 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 2016 DataCenter x64 en_us Unattend
Windows 2016 Standard x64 en_us Unattend
Windows 2012 R2 DataCenter x64 en_us Unattend
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
80
80
80
80
80
80
80
80
80
80
80
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
81
82
82
82
82
82
82
82
82
82
82
82
82
83
83
83
83
84
84
84
84
84
84
85
85
85
85
85
85
85
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 6.8 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 Drivers for Windows 2016 - 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.6
Improved Error handling in install HPSUT scripts
Suppressed bening error
Linux Servce OS Change
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
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
85
86
86
86
86
86
86
86
86
86
86
86
86
86
86
86
86
86
86
86
86
86
86
86
86
87
87
87
87
87
87
87
87
87
88
88
88
88
88
88
88
88
89
89
89
89
89
89
89
89
89
89
89
90
90
90
90
90
91
91
8
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
Linux build plans have firewall disabled in default kickstart or autoyast answer files
Modifications to the Erase Server Disk build plan
91
91
91
91
91
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
93
93
93
93
94
94
94
94
94
94
For more information
95
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 HPE Insight Control Server Provisioning Installation Guide. IC
server provisioning documentation can be found at www.hpe.com/info/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.
10
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 HPE provides
or entirely from scratch.
IC server provisioning supports the following script types:
OGFS
OGFS scripts control the HPE 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. HPE 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 post-installation 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 HPE.
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 HPE
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. HPE provides many sample configurations. You can
use these or create your own.
11
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 HPE-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 HPE-provided build plans will work without modification, it is
highly unlikely the HPE-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 HPE-provided configuration file to be modified and make a copy using Actions > Save as.
2.
Modify the new configuration file.
3.
Open the HPE-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 HPE 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 HPE 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.
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 HPE-provided scripts, a summary of parameters for
that script are listed in the script’s description field.
12
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. HPE 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 HPE-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 HPE 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
Step Name
Step Type
Step Parameters
Validate Custom Attributes
OGFS
1
--custAttrNames "ProductKey_Win2012-Std-x64"
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
2
3
--secure=disabled
Boot
OGFS
4
--serviceOS=winpe64
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
5
6
--maintenance --atLeast=3 --atMost=20
Hide Intelligent Provisioning drives
OGFS
7
13
Install and boot into local WinPE
8
OGFS
--systemDiskNumber=@SystemDiskNumber:0@ -systemDrive=@SystemDrive:c@
Set Media Source
9
Python
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSWMedia-WinPath@#z
Configure Windows Partitioning Scheme for Legacy
Deploy configuration file
10
x:\Windows\Temp\diskpart_legacy.txt
Configure Windows Partitioning Scheme for Uefi
Deploy configuration file
11
x:\Windows\Temp\diskpart_uefi.txt
Partition Disk for Windows
Python
12
--systemDiskNumber=@SystemDiskNumber:0@
Windows 2012 Standard x64 en_us Unattend
Deploy configuration file
13
x:\Windows\Temp\Unattend.xml
Inject Required Unattend.xml Settings
OGFS
Inject Personalization Settings
OGFS
ProLiant Drivers for Windows 2012
Deploy package
14
15
16
@SystemDrive:c@:\$oem$
Run Windows 2012 x64 Setup
Windows .BAT
17
"z:\Media\win2012-x64-en_us\setup.exe"
Integrate HP SA Agent
OGFS
Reboot
OGFS
Wait for HP SA Agent
OGFS
18
19
20
--production --atLeast=3 --atMost=30
21
22
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 HPEprovided 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.

14
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 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 HPE 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 reprovisioned. 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 – HPE 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 HPE 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.
15
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 HPE-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.
16

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
HPE-provided unattend file to the target server’s ram drive. It is recommended to replace this step
with a customized unattend file using the HPE-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.

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 HPE 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
Note: User profile for a computer running Windows 2012 or 2012 R2 when customized (for example,
background desktop, desktop shortcuts, screensaver, files and so on), they are not part of windows image
install OS Build Plan. Refer to the Microsoft KB (https://support.microsoft.com/en-in/kb/2101557) for more
information.
Table 2 – ProLiant OS – Windows 2012 Standard x64 Image Capture build plan sample
Step
Number
1
Step Name
Step Type
Step Parameters
Validate Windows OS
Version
--version=Win2012
Validate Custom Attributes
OGFS
OGFS
2
--custAttrNames "WimFileName"
Check iLO Service
OGFS
3
17
Verify Supported Boot Modes
OGFS
4
--secure=disabled
Unmap Network Drive
Python
5
--driveLetter=Z
Set Media Source
6
Python
@__OPSW-Media-WinUser@@__OPSW-MediaWinPassword@@__OPSW-Media-WinPath@#z
Prevent WIM File Overwrite
Windows .BAT
7
"Z:\Images\@WimFileName@"
ImageX
Deploy package
8
%SystemDrive%\HPPROVTEMP
Validate ImageX Package Contents
Windows .BAT
Uninstall HP ProLiant Utilities
Windows VBScript
Prepare Windows for Image Capture
Windows .BAT
Boot
OGFS
9
10
11
12
--serviceOS=winpe64
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
13
14
--maintenance --atLeast=3 --atMost=20
Hide Intelligent Provisioning drives
OGFS
Remap Windows Drives
Python
ImageX
Deploy package
15
16
17
X:\Windows\System32
Validate ImageX Package Contents
Windows .BAT
Unmap Network Drive
Python
18
19
--driveLetter=Z
Set Media Source
20
Python
@__OPSW-Media-WinUser@@__OPSW-MediaWinPassword@@__OPSW-Media-WinPath@#z
ImageX Configuration - Exclusion List
21
x:\wimscript.ini
18
Deploy configuration File
Windows Image Capture
22
Python
--wimFilePath="Z:\Images\@WimFileName@"
--systemDiskNumber=@SystemDiskNumber:0@
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 HPE 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.
19
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 HPE ProLiant Gen8 servers.

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
Step Name
Step Type
Step Parameters
Validate Custom Attributes
OGFS
1
--custAttrNames "WimFileName ProductKey_Win2012-Std-x64"
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
2
3
--secure=disabled
Boot
OGFS
4
--serviceOS=winpe64
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
5
6
--maintenance --atLeast=3 --atMost=20
Hide Intelligent Provisioning drives
OGFS
Configure Windows Partitioning Scheme for Legacy
Deploy configuration file
7
8
20
x:\Windows\Temp\diskpart_legacy.txt
Configure Windows Partitioning Scheme for Uefi
Deploy configuration file
9
x:\Windows\Temp\diskpart_uefi.txt
Partition Disk for Windows
Python
10
--systemDiskNumber=@SystemDiskNumber:0@
Set Media Source
11
Python
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSWMedia-WinPath@#z
ImageX
Deploy package
12
X:\Windows\System32
Validate ImageX Package Contents
Windows .BAT
Windows Image Deploy
Python
13
14
--wimFilePath="Z:\images\@WimFileName@" -systemDiskNumber=@SystemDiskNumber:0@
Windows 2012 Standard x64 en_us Unattend
Deploy configuration file
15
@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
16
17
18
19
20
21
22
--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.
21
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 HPE 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 HPE 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
Step Name
Step Type
Step Parameters
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
1
2
--secure=disabled
3
22
Boot
OGFS
--serviceOS=linux64
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
4
5
--maintenance --atLeast=3 --atMost=20
Set Media Source
Python
6
@__OPSW-Media-LinURI@/rhel63-x64
RHEL 6.3 x64 en_us Kickstart
Deploy configuration file
7
/tmp/user.ks.cfg
Inject Required Kickstart Settings
OGFS
8
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
9
10
11
12
13
14
-d /tmp/opt/opsware/agent/ogfs-agent.zip –u
Embed files initrd
Unix
15
-s /tmp/user.ks.cfg:/ -s /tmp/opt/opsware/agent:/opt/opsware/ -s /tmp/dud/.:/
Install bootloader for RedHat Enterprise Linux Server
Unix
16
--kernel_arguments="@kernel_arguments@"
Reboot
OGFS
Wait for HP SA Agent
OGFS
17
18
--maintenance --atLeast=3 --atMost=20
Monitor Installation
OGFS
19
tmp/anaconda.log
Integrate Linux HP SA Agent
OGFS
Reboot
OGFS
20
21
23
Wait for HP SA Agent
OGFS
22
--production --atLeast=3 --atMost=30
Personalize Network Settings of Installed System
Python
23
Wait for HP SA Agent
OGFS
24
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.
24

RHEL 6.3 x64 en_us Kickstart – This is a deploy configuration file step. It writes the HPE-provided
kickstart file to the target server’s ram drive. It is recommended to replace this step with a customized
kickstart file using the HPE-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.

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 HPE 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 6.0 U2 Scripted Install build plan sample
Step
Number
1
Step Name
Step Type
Step Parameters
Validate Gateway Setting for Static Network Configuration
OGFS
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
2
3
--secure=disabled
Boot
OGFS
4
--serviceOS=linux64
5
Decommission Server
OGFS
25
Wait for HP SA Agent
OGFS
6
--maintenance --atLeast=3 --atMost=20
Set Media Source
Python
7
@__OPSW-Media-LinURI@/esxi51
ESXi 5.1 Kickstart
Deploy configuration file
8
/tmp/user.ks.cfg
Inject Required ESXi 5 Kickstart Settings
OGFS
9
--accept-encrypted-password
Inject Kickstart Personalization Settings for ESXi 5
OGFS
Create Stub Partition
Unix
Copy Boot Media
Unix
ESXi Installation Utilities
Deploy package
Deploy Agent
Unix
10
11
12
13
14
-d /tmp/opt/opsware/agent/ogfs-agent.zip –p “Red Hat Enterprise Linux Server 5 X86_64” –u
Add ESXi Module
Unix
-s /opt/hpsa_agent –d
15
Add ESXi Module
16
Unix
-s /tmp/user.ks.cfg –a ks.cfg
Install bootloader for ESXi
Unix
17
--kernel_arguments=”@kernel_arguments@”
Reboot
OGFS
Add ESXi Boot Option To UEFI Boot Order
OGFS
18
19
--atLeast=1
Wait for ESXi installation
20
--atLeast=1 --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.
26
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.
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 HPE-provided kickstart file to
the target server’s ram drive. It is recommended to replace this step with a customized kickstart file
using the HPE-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 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 20 – 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.

Add ESXi Boot Option to UEFI Boot Order - On servers configured in UEFI boot mode, this script will
force the server into the Intelligent Provisioning Linux Service OS after the ESXi installation has
completed, where it will add an ESXi boot option to the UEFI boot menu. The disk partition with the
27
"ESXi" label is assumed to be the EFI System Partition and will be used when creating the ESXi boot
option.

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
Step Name
Step Type
Step Parameters
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
1
2
--secure=disabled
Boot
OGFS
3
--serviceOS=linux64
Wait for HP SA Agent
OGFS
4
--maintenance --atLeast=3 --atMost=20
Configure Boot From SAN
OGFS
Shutdown Server
OGFS
Boot
OGFS
5
6
7
--servicesOS=linux64 --force
Wait for HP SA Agent
OGFS
8
--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.

28
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.
Sample Build Plan: ProLiant Software Install
Table 7 – ProLiant SW – Offline Firmware Update build plan sample
Step
Number
Step Name
Step Type
Step Parameters
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
1
2
--secure=disabled
Boot
OGFS
3
--serviceOS=linux64
Wait for HP SA Agent
OGFS
4
--maintenance --atLeast=3 --atMost=20
Set Media Source
5
Python
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSW-MediaWinPath@#/mnt/media?noserverino
LinuxPE add-on packages
Deploy package
6
/
LinuxPE HBA add-on packages
Deploy package
Update Firmware Using SPP
Unix
7
8
--spp_version=@SPPversion:latest@
Boot
OGFS
9
--servicesOS=linux64 --force
Wait for HP SA Agent
OGFS
10
--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.
29
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.

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 neccessary 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 HPE 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 SPPversion 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
Step Name
Step Type
Step Parameters
Validate Custom Attributes
OGFS
1
--custAttrNames "ProductKey_Win2012-Std-x64"
Check iLO Service
OGFS
Verify Supported Boot Modes
OGFS
2
3
--secure=disabled
Boot
OGFS
4
--serviceOS=winpe64
30
Decommission Server
OGFS
Wait for HP SA Agent
OGFS
5
6
--maintenance --atLeast=3 --atMost=20
Configure Boot From SAN
OGFS
Shutdown Server
OGFS
Boot
OGFS
7
8
9
--serviceOS=winpe64
Wait for HP SA Agent
OGFS
10
--maintenance --atLeast=3 --atMost=20
Install and boot into local WinPE
11
--systemDiskNumber=@SystemDiskNumber:0@ -systemDrive=@SystemDrive:C@
Set Media Source
12
OGFS
Python
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSWMedia-WinPath@#z
Hide Intelligent Provisioning drives
OGFS
Configure Windows Partitioning Scheme for Legacy
Deploy configuration file
13
14
x:\Windows\Temp\diskpart_legacy.txt
Configure Windows Partitioning Scheme for Uefi
Deploy configuration file
15
x:\Windows\Temp\diskpart_uefi.txt
Partition Disk for Windows
Python
16
--systemDiskNumber=@SystemDiskNumber:0@
Windows 2012 R2 Standard x64 en_us Unattend
Deploy configuration file
17
x:\Windows\Temp\Unattend.xml
Inject Required Unattend.xml Settings
OGFS
18
--WindowsPartitionID=Autodetect
Inject Personalization Settings
OGFS
19
--require-netconfig=@require_netconfig:false@
ProLiant Drivers for Windows 2012 R2 – yyyy.mm
Install ZIP
20
@SystemDrive:c@:\$oem$
Run Windows 2012 R2 x64 Setup
Windows .BAT
21
"z:\Media\win2012-x64-en_us\setup.exe"
22
Integrate HP SA Agent
OGFS
31
Reboot
OGFS
Wait for HP SA Agent
OGFS
23
24
--production --atLeast=3 --atMost=30
Personalize Network Settings of Installed System
Python
25
Wait for HP SA Agent
26
--production
Set Media Source
27
OGFS
Python
@__OPSW-Media-WinUser@@__OPSW-Media-WinPassword@@__OPSWMedia-WinPath@#z
Install Windows SPP In Background
Python
28
--spp_version=@SPPversion:latest@
Wait for HP SA Agent
OGFS
29
--production --atLeast=2 --atMost=60
Report Windows SPP Installation Results
Python
Reboot
OGFS
Wait for HP SA Agent
OGFS
30
31
32
--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.
32
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.
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 HPE-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
33
Pack for ProLiant (SPP) on the Windows operating system. For the BFS functionality, this build plan may be
run on any supported HPE 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:

HPE 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 HPE 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 HPE 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:

HPE 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.
34
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 one-time 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.

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: Synergy or 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: Synergy or 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:

Synergy or 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.
35
Requirements: Synergy or 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 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: 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: Synergy or 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 HPE 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: Synergy or 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 HPE 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 HPE 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: Synergy or 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.
36
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: Synergy or ProLiant server with iLO
Custom Attributes: None
ProLiant HW - Smart Array Capture Settings
Captures the HPE 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 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: Synergy or 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 HPE 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: Synergy or ProLiant server with iLO and a Smart Array controller
Custom Attributes: None
ProLiant HW - Smart Array Set RAID 1
Sets the HPE 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: Synergy or 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 Synergy or 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:

Synergy or ProLiant server with iLO that supports UEFI and is capable of switching between UEFI and
Legacy boot modes.
Custom Attributes: None
37
ProLiant HW - Switch to UEFI boot mode and Power Off
Switches the Synergy or 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:

Synergy or 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 HPE System ROM scripting utility and may be used as input for
the Manage System ROM Configuration script.
Requirements: Synergy or 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 HPE 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 Synergy or 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 SAN for information on how to move the fibre channel controller to the top of the boot order as
part of this Build Plan.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: Synergy or 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: HPE ProLiant BladeSystem with iLO and fibre channel controller
Custom Attributes: None
38
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: Synergy or ProLiant Server with iLO
Custom Attributes: None
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:

Synergy or 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 HPE 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
39
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 6.8 x64 Scripted Install
ProLiant OS - RHEL 6.8 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.
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 virtmanager 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:

Synergy or 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 HPE 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.
40
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:

Synergy or 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 HPE 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, you are required to use linux based media server. To setup a linux based
media server, follow the instruction given in IC server provisioning Administrator guide, at
http://www.hpe.com/info/insightcontrol/docs.

To copy Ubuntu iso image to windows media server, Please follow the below instructions:
Make sure the file name extensions in the md5sum file matches the files that are extracted. To match
the file names, Hewlett Packard Enterprise recommends that you use Linux machine to extract the ISO
image instead of Windows utilities.
To extract Ubuntu ISO image using Linux machine:
1.
Copy the Ubuntu ISO image into root directory.
2.
Create a folder under root with the name Ubuntu_mount.
3.
Run mount -o loop –t iso9660 /*isoname* /Ubuntu_mount
The ISO file is mounted to /Ubuntu_mount. Now, copy these files to Windows Media Server
Requirements:

HPE ProLiant server with iLO

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 HPE 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 2016 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.
41
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:

Synergy or ProLiant server with iLO must be powered on and running the Windows OS to be captured.

Media Server share must be writeable.
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 2016 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.
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:

Synergy or ProLiant server with iLO and similar hardware as the reference server.

A previously captured WIM image on Media Server.
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:
42

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 2016 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:

Synergy or 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.

EncryptedAdminPassword – Administrator password in encrypted form. Refer to the HPE 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:

Synergy or 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.
43
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:

Synergy or ProLiant server with iLO running a Windows 2012 or later production OS
Required Custom Attribute:

nic_teaming
Note: Refer to section Scripts > Configure NIC Teaming for Windows > Examples of Custom Attribute
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 Smart Update Manager 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:

Synergy or ProLiant server with iLO and running a production operating system

Media Server must contain a SPP
Custom Attributes: None
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 Smart Update Tools on Linux and Windows
managed nodes respectively. IC server provisioning installs SUT and runs it in Auto Stage mode. In this mode,
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:


Synergy or 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 2016, Windows 2012, Windows Server 2012, and Windows Server 2012 R2

Red Hat Enterprise Linux 6 (x86–64)

Red Hat Enterprise Linux 7

SUSE Linux Enterprise Server 11 (AMD64/EM64T)

SUSE Linux Enterprise Server 12
HPSUT folder exists in Media Server and contains SUT installer files.
NOTE: If HPSUT folder does not exist in Media Server, follow the below steps to setup Media server for HPSUT:


44
Create folder Media/HPSUT
Download and place SUT from http://hpe.com/info/hpsut to /Media/HPSUT folder.
Custom Attributes:

HPSUT_Linux – Linux SUT filename

HPSUT_Windows – Windows SUT 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:

Synergy or ProLiant Gen8 server or newer

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.
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:

Synergy or 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.
45
Requirements:

Target server must be booted to either Windows or Linux production OS.
Custom Attributes:

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 – specifies whether to perform a reboot or not. 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:

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 HPE-provided build plans. There
are some scripts listed here that are not part of the HPE-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:

46
--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 Boot Option to UEFI Boot Order in PXE
This script adds a new entry to the UEFI boot menu that points 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 expected.
Prior to running this script the target server must boot to PXE service OS after completing the ESXi installation.
You must use “Set One Time Boot to Service OS” script to boot target server to PXE service OS immediately
after completing the ESXi installation. The script, then adds 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 is used when creating the
ESXi boot option. This script must be used only on target servers configured in UEFI boot mode.
Type: Python
Parameters:

--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
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
47
Add Hyper-V Role
Add Windows Multipath IO Feature
Note: Add Windows Hyper-V Role is deprecated
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 HPE 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
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
48
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
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 HPE ProLiant
Gen8 and newer servers.
o
network – Boots the server using PXE, regardless of the type of server.
49

--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:

--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.
50
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.

--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
51
--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:

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.
52
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
ifInde
x
Status
MacAddress
LinkSpe
ed
Ethernet
HP NC553i Dual Port FlexFabric 10G
16
Up
18-A9-05-C5-E1B7
10 Gbps
Ethernet 2
HP NC553i Dual Port FlexFabric
10G...#1
15
Disconnecte
d
18-A9-05-C5-E1B3
10 Gbps
Ethernet 3
HP NC553i Dual Port FlexFabric
10G...#2
14
Disconnecte
d
18-A9-05-C5-E1B4
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.

Minimum two NICs are required to form NIC team.

Member should not be part of any other team.
Required Custom Attribute:
53

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 HPE 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:

Synergy or 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.
Custom Attributes: None
Copy Boot Media
Copies files needed to boot the installer environment to the stub partition.
54
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 HPE 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:

HPE 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 HPE-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.

Option #2
Modify an HPE-provided Windows OSBP
1.
Remove the Create Windows System Drive step from the Windows OSBP.
55
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 re-provisioning 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 re-provision 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
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.
56
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
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
57
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 re-provisioning. 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 HPE 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 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
58
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_customization0 through multi_nic_customization9 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_customization custom attributes. If multi_nic_customization is not defined, then this
script does nothing and completes successfully.
Type: OGFS
Parameters: None
Required Custom Attributes: multi_nic_customization0 through multi_nic_customization9
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_customization0 through multi_nic_customization9 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_customization custom attributes. If multi_nic_customization is not defined, then this
script does nothing and completes successfully.
Type: OGFS
Parameters: None
Required Custom Attributes: multi_nic_customization0 through multi_nic_customization9
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_customization custom attributes. If standard_switch or
multi_nic_customization are not defined, then this script will fail with an error.
59
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 vSwitchs.

multi_nic_customization0 through multi_nic_customization9
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.

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 HPE SA agent installation executed
o
during the next reboot.
post-exitpoint
to write info file that the installation has finished
Type: OGFS
Required Parameter:

HPE SA Agent Name - The SA agent that needs to be started during installation.
Custom Attributes: None
60
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 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 HPE 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
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
61
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:

--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
62
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
Install Windows SPP In Background
Installs the HPE 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.
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 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.
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 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 , Windows .BAT or 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.
63

--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.

--fail_on_warning - When specified, the script will fail on receiving the error code 253 from SUM.
When absent, the script will be successful for the error code 253 from SUM
Custom Attributes: None
Install Linux HPSUT
Install Windows HPSUT
Installs the HPE Smart Update Tools(SUT) for Linux x64 or Windows x64 on a Linux production target server or
Windows production target server respectively.
Type: Unix or Windows.BAT
Requirements:
* Custom Attribute HPSUT_Linux exist with Linux HPSUT filename.
Or
* Custom Attribute HPSUT_Windows exist with HPSUT filename.
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 HPE SA agent installer

Creating a script that will execute the HPE 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 HPE 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
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:

64
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 HPE 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.
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: None
Optional Parameters:
- -log=LOG the log file that will be monitored
--count=COUNT the number of times it counts before timing out, default is 100.
--delay=DELAY the delay in seconds between every log check, default is 6.
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.
65
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:

HPE 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 HPE-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 HPE default partitioning schemes using one of the following methods:

Option #1 – Change the HPE 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 HPE partitioning script and do partitioning in the unattend file
Modify an HPE-provided Windows OSBP
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 HPE-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
66
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.
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.
67
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 self-test.
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 PXE-option as the Service OS is supported.
--wait=<time> - Specify a new wait time. Default is 45 seconds.
Custom Attributes: None
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:
68

--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"
be assigned during the remapping.
A space separated list of drive letters that are not to
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 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 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.
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
Run Windows 2016 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.
include the double quotes.
Parameter should
Custom Attributes: None
69
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
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 noserverino 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:
70
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:[email protected]/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.
-
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 Boot to Service OS
This script is used to set one time boot option of target server into the specified service OS.
This script can be used in any build plan to set one time boot option to either Intelligent provisioning based or
PXE based service OS. The target server then loads user specified service OS in the next reboot.
IMPORTANT:

The Set One Time Boot to Service OS step does not reboot the target server and it is intended to use
in ESXi OSBP to add ESXi boot option to UEFI boot order. This script sets one time boot option during
71
ESXi installation. Once ESXi installation is completed then target server boots to user specified service
OS. Hence, this step should be followed by the Wait for SA Agent step.
Type: OGFS
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 Synergy or
ProLiant Gen8 and newer servers.
o
network – Boots the server using PXE, regardless of the type of server.

--ipv6: Boots into an IPv6 Service OS

--disableWarning: Do not show warnings of old hpsa_netconfig format
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 Linuxbased 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.
72
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:

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 HPE 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 HPE
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.
73
Type: Windows .BAT
Parameters: None
Custom Attributes: None
Update Firmware Using SPP
Runs an off-line firmware update on the target server using 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.
This script must be run while booted in the LinuxPE service OS. It uses the SUM utility and specified 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 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 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" - SUM utility supported command-line options
that are to be passed to SUM. Refer to SUM's CLIhelp.txt documentation file for available options.

--hpsum_logs_dump_dir=writable_directory_under_mounted_file_share - Copies the zipped 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 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
74
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:

--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
75
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
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
76
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 preinstalled 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:

--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
77
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 HPE ProLiant
Bladeservers.
Custom Attributes: None
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 HPE 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:
78

--ogfs, --maintenance Interchangeable parameters that indicate the server is to boot into a service OS.
HPE-provided 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:

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 HPE-provided build
plans. There are configuration files that are not part of the HPE-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.
79
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 HPE Insight Control Server
Provisioning online help on how to create an encrypted password.

kernel_arguments

Productkey_ESXiZZ (depending on which kickstart file is used) - To use this custom attribute, the
%firstboot section containing the 'vim-cmd vimsvc/license' command must be uncommented in the
answer file.
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
80
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 6.8 x64 en_us Kickstart
RHEL 6.8 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 HPE 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.
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 HPE 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 HPE SSACLI configuration file details.
81
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 HPE 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 HPE-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

EncryptedAdminPassword– Administrator password in encrypted form. Refer to the HPE 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.
82
NOTE: The HPE-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 HPE 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 HPE-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:

ComputerName

EncryptedAdminPassword– Administrator password in encrypted form. Refer to the HPE Insight
Control Server Provisioning online help on how to create an encrypted password.

SystemDrive

SystemDiskNumber
Windows 2016 DataCenter x64 en_us Unattend
Windows 2016 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 HPE-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_Win2016-DC-x64 or ProductKey_Win2016-Std-x64
Optional Custom Attributes:

ComputerName

EncryptedAdminPassword– Administrator password in encrypted form. Refer to the HPE Insight
Control Server Provisioning online help on how to create an encrypted password.

SystemDrive
83

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 HPE-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 HPE 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 HPE-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 HPE 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 HPE-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:

84
ComputerName

EncryptedAdminPassword– Administrator password in encrypted form. Refer to the HPE 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 HPE-provided build plans. There
may be packages that are not part of the HPE-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 HPE-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 one-time 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.
85
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 6.8 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 Drivers for Windows 2016 - 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 HPE 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 HPE 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 HPE 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.
86
New Changes for IC server provisioning Release 7.6
Improved Error handling in install HPSUT scripts
Improved Error Handling on Install Linux HPSUT and Install Windows HPSUT scripts:
Improved Custom attribute validation.

Suppressed benign standard error while reinstalling SUT
Suppressed bening error
Updated Install Linux SPP script to suppress benign standard error logs on top of SLES OS.
Linux Servce OS Change
Starting with 7.6 ICsp Linux PXE service OS are updated to CentOS 6.7 and 7.2 instead of RHEL 6.6 and 7.1
respectively.
Following Scripts are updated to Support New Service OS.

Update Firmware Using SPP

LinuxPE HBA add-on packages
Modification to ProLiant HW - Erase Server Build Plans
Updated the wait time to --wait=300 in STEP:’ Reboot to Apply BIOS Changes and Power Off' parameter.
Which will provide fair time to complete POST on the target server.
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 HPE 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.
87
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 HPE 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
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
88
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 HPE 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 HPE
provided RHEL 7 Build Plan as a starting point.
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-mellanox-mlnx-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
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 HPE-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
89
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 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 HPE utilities are being uninstalled.
90
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 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 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 HPE-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.
91
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": [
"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”-->
}
92
]
}
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.
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.
93
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
© Copyright 2016 Hewlett Packard Enterprise Development LP. The information contained herein is subject to
change without notice. The only warranties for Hewlett Packard Enterprise 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. Hewlett Packard Enterprise shall not be liable for technical or editorial errors or
omissions contained herein.
This document contains confidential and/or legally privileged information. It is intended for Hewlett Packard
Enterprise and Channel Partner Internal Use only. If you are not an intended recipient as identified on the front
cover of this document, you are strictly prohibited from reviewing, redistributing, disseminating, or in any other way
using or relying on the contents of this document.
5200-2444, November 2016