Os Build Plans - Hpe Support Center

Transcript

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