HP Data Center Automation Appliance

Transcription

1 HP Data Center Automation Appliance Blog: Migrating from Windows Server 2003 using HP DCAA Software Version: 1.00 Release Date: April 2015

2 Legal Notices Warranty 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. The information contained herein is subject to change without notice. Restricted Rights Legend Confidential computer software. Valid license from HP required for possession, use or copying. Consistent with FAR and , 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. Copyright Notice Copyright 2015 Hewlett-Packard Development Company, L.P. Trademark Notices Adobe is a trademark of Adobe Systems Incorporated. Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation. UNIX is a registered trademark of The Open Group. The OpenStack Word Mark and the Square O Design, together or apart, are trademarks or registered trademarks marks of OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. Adobe is a trademark of Adobe Systems Incorporated. Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation. The OpenStack Word Mark and the Square O Design, together or apart, are trademarks or registered trademarks marks of OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. Oracle, Solaris, and Java are registered trademarks of Oracle and/or its affiliates. RED HAT READY Logo and RED HAT CERTIFIED PARTNER Logo are trademarks of Red Hat, Inc. This product includes an interface of the 'zlib' general purpose compression library, which is Copyright Jean-loup Gailly and Mark Adler. 2

3 Documentation Updates The title page of this document contains the following identifying information: Software Version number, which indicates the software version. Document Release Date, which changes each time the document is updated. Software Release Date, which indicates the release date of this version of the software. To check for recent updates or to verify that you are using the most recent edition of a document, go to: This site requires that you register for an HP Passport and sign in. To register for an HP Passport ID, go to: Or click the New users - please register link on the HP Passport login page. You will also receive updated or new editions if you subscribe to the appropriate product support service. Contact your HP sales representative for details. 3

4 Support Visit the HP Software Support Online web site at: This web site provides contact information and details about the products, services, and support that HP Software offers. HP Software online support provides customer self-solve capabilities. It provides a fast and efficient way to access interactive technical support tools needed to manage your business. As a valued support customer, you can benefit by using the support web site to: Search for knowledge documents of interest Submit and track support cases and enhancement requests Download software patches Manage support contracts Look up HP support contacts Review information about available services Enter into discussions with other software customers Research and register for software training Most of the support areas require that you register as an HP Passport user and sign in. Many also require a support contract. To register for an HP Passport ID, go to: To find more information about access levels, go to: HP Software Solutions Now accesses the HPSW Solution and Integration Portal Web site. This site enables you to explore HP Product Solutions to meet your business needs, includes a full list of Integrations between HP Products, as well as a listing of ITIL Processes. The URL for this Web site is 4

5 Migrating from Windows Server 2003 using HP DCAA Contents Introduction... 6 Key issues... 6 Migration... 6 Technology shift... 6 Action plan and how HP Data Center Automation Appliance (DCAA) can help... 6 Inventory... 7 Deploy new servers Deploy new hypervisors Deploy new virtual machines Using SA without the virtualization feature Using SA with the virtualization feature through the DCAA IT Operator portal Deploy applications SA OO Deploy configurations Upgrade server firmware Decommission old servers Call to action References

6 Introduction Extended support for Microsoft Windows Server 2003 end on July 14, Standard support was terminated in Many companies still use servers running Windows Server 2003, according to IDC (see References). When extended support ends, bug fixes stop. Security vulnerabilities are no longer addressed. Servers running Windows Server 2003 become a security risk post-july 14, Key issues Migration Customers need to migrate to a newer version of Windows Server. Existing applications may not be compatible with newer OS versions. Application upgrades may require additional data migration Technology shift Traditional data center way of working impacted by demands for: cloud big data social and mobile Action plan and how HP Data Center Automation Appliance (DCAA) can help Before any migration decision is taken, you'll have to get a view of the current state of your server estate. Whatever migration decision is taken after analysis, at some point operating systems (OS) and applications need to be deployed and configured. Deployment can occur in various configurations, in a traditional data centers, private, hybrid or public clouds. In the end, someone somewhere has to deploy a server OS and add some applications on top. If you are responsible for any of these deployments, then DCAA is the tool of choice as the premier management solution for day 1 and 2 management operations in such environments. In order to handle this challenge in the most efficient way you need to involve automation, and even more orchestrate this from within the organization Change Management process. Automating this kind of a process means invoking automation from an RFC, coming through the organization ITSM system, which will start migration. 6

7 DCAA as a solution provides you coverage for all of these aspects using HP Operations Orchestration to provide the orchestration layer and integrate with your ITSM tool, and using HP Server Automation to perform the actual implementation (while still able to leverage OO for the implantation as well). For example let s say the ITSM system in use is HP ServiceAnywhere. HP SAW has a built in integration to HP OO which allows you to embed invocation of OO flow inside the Change Process. Read more on automating Change Fulfillment from HP SAW here. But you can eventually use any ITSM tool you wish. The flow which will be invoked can trigger some pre steps like making sure the RFC was indeed approved and the time window is aligned (see OO content for HP SAW here), and then can trigger the deployment and migration. Obviously you can do also various post actions. Using HP OO, as part of HP DCAA, for this also enable tractability on the whole process. The rest of this post describes how you can do the migration from Windows 2003 outside of an automated change process. The same actions can be done from OO flow by invoking the relevant service offering request from within the flow. This will be described later. Let's see what typical tasks you may have to perform: Collect server data: hardware, firmware and software Deploy new servers, physical and or virtual Deploy and configure new hypervisors Deploy applications Sync application configurations and control drift Decommission servers Inventory When? Before the start of any migration, before and during the planning phase an accurate inventory is indispensable. Key to any migration is knowing what's installed. Using DCAA, you can perform a hardware and software inventory of your servers. HP Server Automation (SA) is included with DCAA. SA has powerful hardware, firmware and software inventory capabilities. SA requires the presence of the SA Agent on the target server. Once the SA Agent is present, you can remotely manage the server. Therefore the first action item is to install the SA Agent on the servers. SA in DCAA contain various ways to install the SA Agent, they are documented in the SA User Guide for Server Automation available here for SA used in DCAA: /facetsearch/document/km , chapters 5 and 16. 7

8 An easy way to get SA Agents installed onto servers is to network scan for a ranger of IP addresses, or better if you have the list, have SA scan specific IP addresses for server details to prepare for SA Agent installation: Click the Scan button and wait util the process completes: Now you can install the SA Agent by right-clicking and selecting Install SA Agent: 8

9 There are many options to choose from in the next dialogue, but there is just one mandatory configuration item, namely userid and password of an administrative user. The server type, Windows, or Linux is discovered automatically. In the below dialog window shown, two advanced options (there are a lot more) that you can use to perform an immediate hardware and software registration: Click Start Job and wait for the process to complete. You can view the installation progress during the execution. 9

10 You can view the results via the Devices, Managed Servers view. 10

11 Now that you've gotten this far, it's time to checkout additional features such as: Exploring servers and device groups: SA User Guide for Server Automation, chapter 4. Deploy new servers When? You decide to move (a subset of your) applications to a new set of physical servers. These servers require an OS to be installed. DCAA SA has a feature called PXE discovery. It exists since SA and allows a server that performs a network boot (also called PXE booting) to automatically come up into an SA service OS. It will then proceed to register the server with SA and if the server is an HP ProLiant, SA will discover and register the ilo with an auto-generated userid/password combination. This works only for servers that have no preexisting server record on SA. Once a server record exists for a given server, SA will not bring up the server in an SA service OS during PXE boot unless explicitly instructed by a Boot step in an OS build plan or if a record with boot information was pre-created using MBC. The use-case we cover is the following: the customer has free rackspace and/or enclosures the customer buys blades the customer inserts the blades and powers them on One prerequisite: blades must PXE boot into a VLAN that has DCAA plus full DHCP running, or where the existing DHCP server points to the DCAA instance. the blade powers on, PXE boots, contacts the DCAA SA instance this is a new server, there is no preexisting server record SA instructs the server to download and boot SA service OS RedHat Linux 6.x x64 You can set another default service OS by configuration the OPSWpxeboot_default custom attribute at the facility level. In 99% of the cases, the Linux default is perfectly fine. Build plans can contain a Boot step to boot the server into the correct SA service OS for the subsequent OS deployment. 11

12 The server comes up in the SA service OS, then: registers with SA, a server record is created if it's an HP ProLiant: the ilo is added and linked to the server record ; a userid called hp_automatic_integration_user with a strong random password is created on the ilo for management purposes. The server is now ready to be deployed to. You can now run one or more build plans to configure the server hardware/firmware and ultimately deploy an operating system (OS). Let's deploy RedHat 7 (with or without KVM that's up to you), select the build plan "Red Hat Enterprise Linux Server 7 X86_64 Install" or "Red Hat Enterprise Linux Server 7 X86_64 with KVM Install" located under /Opsware/Tools/Build Plans/SAVA/Non-ProLiant/Linux. Take a copy of this build plan, you can place it under /Home/CommonCustomerBuildPlans/Non-ProLiant/Linux. For a default install you must only edit step #2 "Set Media Source" to point to the OS media on your media server: "nfs://osprovmedia.mycompany.com/media/linux/rhel7.0-server-x86_64" The contents of the media directory for RedHat 7 is a copy of the DVD you would use to install it manually. total 352 dr-xr-xr-x. 3 root root 4096 Feb 19 10:02 EFI -r--r--r--. 1 root root 8266 Feb 19 10:02 EULA -r--r--r--. 1 root root Feb 19 10:02 GPL dr-xr-xr-x. 2 root root 4096 Feb 19 10:02 LiveOS dr-xr-xr-x. 2 root root Feb 19 10:03 Packages -r--r--r--. 1 root root 3375 Feb 19 10:03 RPM-GPG-KEY-redhat-beta -r--r--r--. 1 root root 3211 Feb 19 10:03 RPM-GPG-KEY-redhat-release -r--r--r--. 1 root root 1568 Feb 19 10:03 TRANS.TBL dr-xr-xr-x. 4 root root 4096 Feb 19 10:02 addons dr-xr-xr-x. 3 root root 4096 Feb 19 10:02 images dr-xr-xr-x. 2 root root 4096 May 12 13:17 isolinux -r--r--r--. 1 root root 108 Feb 19 10:02 media.repo dr-xr-xr-x. 24 root root 4096 Feb 19 10:03 release-notes dr-xr-xr-x. 2 root root 4096 Feb 19 10:03 repodata 12

13 Select step #2 and in the Parameters field, change the value to match your OS media server configuration. In this example, we're using NFS but HTTP-based installation for Linux OSes is also supported (except for Ubuntu). Save and close the build plan. That's it we're now ready to deploy. Select the new server under Devices, then Unprovisioned servers Select the server, right-click and select the Run OS Build Plan option Select the build plan you've just edited, click Next Select the server(s) you want to deploy to and click Start The deployment job will start, you can monitor the job progress in the dialog window or via the Jobs and Sessions UI. On the target server, after some configuration of the local installer, a reboot is performed and the installation starts: After about 5 minutes (on a default OOTB install), the deployment is complete and the RedHat 7 login prompt appears: 13

14 You have successfully deployed RedHat 7 Enterprise Linux! You've performed this task as the DCAA Administrator. The IT Operator can perform exactly the same task. Make sure the Provision Servers offering is published into a catalog that the IT Operator has access to. When the IT Operator logs into to DCAA, the Provision Servers offering can be used to perform the same action. Prerequisites: The DCAA Administrator has configured the Redhat 7 build plan and tested that the deployment works. The IT Operator has been informed of what servers require which OS deployed. The servers are network-booted and available for deployment in SA. In this case, the DCAA Administrator has provided a new copy of the build plan named "RHEL7 deploy for Windows Server 2003 migration prep". To do this, the admin: Right-clicked in the build plan list and selected New. Chose a name for the build plan, in this case "RHEL7 deploy for Windows Server 2003 migration prep". The location for this build plan (if not ProLiant-specific) should be /Home/CommonCustomerBuildPlans/Non-ProLiant/Linux. In the build plan steps list, selected Copy From Chose the "Red Hat Enterprise Linux Server 7 X86_64 Install" build plan and copied all the steps from it. Verified that the Set Media Source step has the correct configuration. Verified that the custom attributes on the build plan are set correctly. For DCAA the following custom attributes need to be set, otherwise the build plan will not be shown in the IT Operator's view: ApplicableServerType HPSAPXEImage VMwareGuestOsName Now the IT Operator can perform the requested task. After a login to select the Provision Server offering from the visible catalogs. 14

15 Click on the Provision Servers offering. Select an unprovisioned server and the purpose-built build plan. A range of options for setting a hostname prefix, additional software, device groups and notification are available. Click checkout, then click Submit. The deployment will start. The DCAA IT Operator UI will instruct SA via OO to run the build plan against the target server. From this point onwards, the process behind the scenes is the same as the DCAA Administrator-started deployment. When complete, the managed server name will either start with the name prefix given, or if not an autogenerated name, as in the example shown below: 15

16 Deploy new hypervisors When? You decide to move (a subset of your) applications to your private cloud and you require extra raw capacity on the form of a couple new VMware ESXi hypervisor instances. In the previous use-case, we've seen deployment of RedHat 7 Enterprise Linux on a new physical machine. DCAA comes with a number of build plans to deploy hypervisor or OS with included hypervisors: VMware ESXi ESXi 4.1 Default Install ESXi 5 Default Install 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.5 Scripted Install ProLiant OS - ESXi 5.5 U1 Scripted Install ProLiant OS - ESXi 5.5 U2 Scripted Install KVM ProLiant OS - RHEL 6.4 x64 KVM Scripted Install ProLiant OS - RHEL 6.5 x64 KVM Scripted Install ProLiant OS - RHEL 7.0 x64 KVM Scripted Install Red Hat Enterprise Linux Server 7 X86_64 with KVM Install Hyper-V Windows 2008 R2 x64 Hyper-V Default Install Windows 2012 R2 x64 Hyper-V Install Windows 2012 x64 Hyper-V Install The execution of these build plans is similar to the bare metal server use-case that we just reviewed. Please refer to that. You will need to provide a different media set if you select the ESXi or Hyper-V build plan. For RedHat the same OS media can be used for the regular OS deployment and a deployment including KVM. The major difference (for example for RedHat) is in the Kickstart file, where additional parameters indicate the installation of additional packages. See the "Configure Red Hat 7 Default ks.cfg with KVM" step in the build plan. #kvm userspace packages (kvm is installed @virtualization-tools For actual KVM configuration, please refer to for detail on how to configure KVM either during or post-deployment. Post-deployment you can use either SA and/or OO to deploy configuration updates to the newly installed hypervisor. 16

17 For VMware ESXi, other than installing the hypervisor itself, the build plans have a step that is used to add the newly installed hypervisor to a VMware vcenter so it can be managed using the vcenter. This step is called "Add to Virtualization Manager". Pass it the reference of an SA V12N managed VMware vcenter or Microsoft SCVMM management instance and your hypervisor can be registered to be managed. This step is included by default in ESXi and Hyper-V installation build plans as a no-op by virtue of the --pass parameter. Prerequisite for Add to Virtualization Manager: SA virtualization service enabled with registered VMware vcenter or Microsoft SCVMM management consoles. Deploy new virtual machines When? You decide to move (a subset of your) applications to a virtualized environment and you need to create new virtual machine instances. Using SA without the virtualization feature Deploying to a new physical server or deploying to a new virtual machine is largely similar. DCAA comes with a set of non-proliant generic OS build plans for use on other hardware, physical or virtual. Newly created virtual machines can be easily network booted (PXE booted) so that an unprovisioned server instance is available in SA. The default service OS that is booted is RedHat Linux 6.5 x64 (in SA 10.20). This may not be the right service OS if you want to deploy Windows 2012 R2. Depending on what your use-case is it will be better to edit the build plan and add in the beginning: Boot step, parameters: --serviceos=linux64 _or_ parameters: --serviceos=winpe64 (optional) Decommission Server Wait for HP SA Agent, parameters: --maintenance --atleast=3 --atmost=20 That way you can keep booting the default service OS (Linux) and then in the beginning boot into the right one depending on what OS to deploy: --serviceos=linux64 for Linux --serviceos=winpe64 for Windows The Boot step is clever enough to boot either the embedded SOS on ProLiant Gen8 (and newer) or PXE on pre-gen8, virtual machines and non-hp hardware. The Decommission step is optional, but if you add it then it will take care of the reprovisioning use-case as well. All the ProLiant build plans have this Boot, Decommission and Wait for HP SA Agent step sequence already applied. 17

18 Once the build plan is configured as described above (or if you did not do this and have booted the virtual machine into the correct SA service OS), any additional configuration of the OS build plan and the series of actions to start and monitor the installation is exactly the same as for a physical machine. Using SA with the virtualization feature through the DCAA IT Operator portal Currently only supported for VMware vcenter 2008 (R2) and any hypervisors supported by this vcenter version. Please check the DCAA platform compatibility matrix for more details. Prerequisite: you will have provided VMware vcenter information when you configured the DCAA application so that the SA virtualization service is initialized. If you have not yet done this, then refer to the DCAA Installation and Administration Guide and read the section on "Adding vcenters Manually". To provision one or more virtual servers, the IT Operator selects the Provision Servers offering from catalog. Once the offering is loaded, scroll down and select the New Virtual Servers option. Then enter the hypervisor, number of and details of the virtual machines that you want to create. 18

19 There are more options than shown in the above screenshot. Once the IT Operator is done with the selections and configuration, click on Cart, Checkout and create subscription services to launch the virtual machine deployment jobs. The IT Operator UI will use OO to start the deployment jobs in SA. SA itself will create the virtual machines and deploy the OS as specified by the selected build plan. Deploy applications When? Your servers with an up-to-date OS are up and running, now the time has come to deploy your application(s). Application deployment and configuration is a key feature of DCAA. From the IT Operator portal the IT Operator can deploy various application policies, applications and scripts. The DCAA Administrator can use SA and OO to perform complex application deployment and management use-cases. SA Whatever application needs to be deployed, SA supports various application types, installation methods and platforms. Application types/methods are: AIX Licence Program Product ZIP files Chef Cookbooks 19

20 DEBian packages Executables and shell scripts HP-UX depots RPMs Solaris IPS archives Solaris packages Solaris patches Solaris patch clusters Windows MSI Let's review a Windows MSI package as an example. The use-case is the installation of the Apache web server. For a Windows MSI package you can configure: Install parameters: Installation flags Reboot behavior Install scripts Pre- and post-install scripts Uninstall parameters Uninstall flags Reboot behavior Uninstall scripts Pre- and post-install scripts Let's publish and deploy a typical MSI package: In the SA UI, select Library, Packages and then the platform, for example Windows 2008 R2 x64. In the right pane, right-click and select Import Software. In the dialog window, select Windows MSI, let's select Apache web server, for example httpd win32-x86-openssl-0.9.8o.msi. Select a target location in the SA Library and click Import. The package(s) are imported. At this point, you can already deploy the package. As part of the import, SA has extracted important information from the MSI package: 20

21 To install with minimal fuss: click the package, right-click and select Install Software. In the dialog, select server from the Managed Servers section and click Next. Click Start Job. The software will be installed on the target managed server. Read on while it installs. Doing it this way is far from ideal, and works really well, but only for a few servers. SA has the following constructs to help you: device groups (dynamic based on criteria, or statically created) software policies (can contain 1 to n software packages that can be managed as a single integrated unit) It's should be clear that applying more than one software package at once (use: software policies) on more than one server at one (use: device groups) is a much better deal than the previous single package to single server use-case. In the meantime, our single package to single server use-case will have completed, you can check both the target server and the job status: 21

22 Before we jump into software policies and device groups, let's uninstall the software we just installed: In the Devices view, Managed Servers, select the server, right-click and select Uninstall software. Select the software package to uninstall (yes this seems a bit counter-intuitive with the green plus sign...) Click Start Job The software will now be uninstalled from the target server: and then Now let's add this software package to a software policy, so that you increase your deployment and management capabilities: In the SA Library, select Software Policies, then the platform. 22

23 In the right pane that lists the software policies, right-click, then select New... In the Name field type 'Apache Web Server' Click Policy Items on the left Click the large green plus, click Package and select Apache HTTP Server Click File Save. Click Close. OK so we've created a software policy. This software policy can be associated with a device group (or if you really want also with a single server). Let's assign it to a dynamic device group that comes out-of-the-box with SA in DCAA: select the Apache Web Server software policy and right-click select Attach in Device groups, navigate to Public. Select the Windows device group Select Attache, then Software policy Select the Apache Web Server software policy Leave the Remediate Servers Immediately checkbox checked Click Attach, the Remediate dialog appears Remediate is SA-speak for processing of install, uninstall and update of software and patch policies on managed servers. Click Start Job SA will start Remediation on the device group Windows which is a dynamic group that contains all Windows servers. The software will be installed on the target managed server. 23

24 OO Starting from the an enormous amount of OO content is available to use in DCAA to drive OO from new offerings that you can create in the IT Operator portal, or to exercise OO flows directly from the OO console. Check out the OO content catalog here: Deploy configurations When? You decide to have all web server configuration deployed and monitored. Let's add twist to the use-case of deploying the Apache web server, in the form of a centrally managed web server configuration. 24

25 In the SA Library, select Application Configuration, then Templates, then platform Windos 2008 R2 x64. In the right pane, right-click and select Create Configuration Template from File Select an httpd.conf template from an local Apache installation that will serve as the default configuration for all deployed instances. In Properties, change the name to httpd.conf.tpl. Under CML, edit the CML content and add 3 lines in the beginning: # # MANAGED by DCAA # Under Advanced options, check the "Replace the entire configuration file on target servers with this template (full template)" option. Click File Save. Close the window. OK, we've created a template. Before this can be deployed through a policy, let's add it to a configuration. In the SA Library, select Application Configuration, then Configurations, then platform Windos 2008 R2 x64. In the right pane, right-click and select New The Configuration dialog opens. In Properties Name type Windows Apache web server In Configuration values, click on the green plus and add the httpd.conf.tpl template Click File Sava. Then close the Window. Now we have a deployable application configuration. This can be linked to a software policy, in our case the Apache Web Server policy. In the SA Library, select Software policies, then the platform, then double-click the Apache Web Server software policy. In Policy Items, click the large green plus sign From Application Configuration, select Windows Apache web server and add it to the software policy by clicking select. Once the items is added to the software policy you will see the up and down arrows activate. This is how you can influence the installation order of individual items in a software policy. Click File Save, then close the Window. When this software policy is remediated on a target server, the configuration file changes will be applied. Remediate this policy on a device group of all Windows or why not all Apache servers and all the servers will have the same Apache web server configuration. In the Devices view, select either a device group or a managed server and remediate the Apache Web Server policy (Windows). Click Start Job. By default a lot more policies will be listed, you can select them all using shift-click and then click the red minus sign to leave only the Apache Web Server policy. (Or you can leave all of them, remediate will take longer, that's all.) 25

26 Click Start Job You'll notice that Apache web server itself will not be reinstalled, SA figures out that's already done, so it moves on to the application configuration. When the job completes, head over to the managed server and check the httpd.conf file. Great! We now have a centrally managed deployed instance of Apache web server including a centrally managed web server configuration. Next steps here can be to: Stop/start the Apache web server on a configuration file change Rendering the configuration file contents dynamic by injecting values taken from configuration items present in SA. Refer to the SA User Guide: Application Configuration: /facetsearch/document/km for more detail. 26

27 Upgrade server firmware When? Some of your servers could support Windows Server 2012 or RedHat Enterprise Linux 7 if only they had upgraded firmware. And you've got 800 of those... This section is specific to HP ProLiant but generally speaking, the process is as follows: Prepare a media server with tools and content that can perform a server firmware upgrade. Prepare (or use) a build plan that: Reboots a server in a service OS (for offline firmware upgrade) Maps the media server update firmware content location Runs the tools to upgrade the firmware Uploads any results to a central location for reporting purposes Reboots the server back into the production OS SA in DCAA comes with all the ProLiant content from Insight Control server provisioning 7.4. Let's discuss a sample ProLiant Offline firmware update build plan. Content taken from the ICsp build plan reference documentation: Updates the firmware using the Service Pack for ProLiant (SPP). IMPORTANT: 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 Attribute: SPPversion SPP version in the form of yyyy.mm.x, for example 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. STEP NUMBER STEP NAME AND PARAMETERS STEP TYPE 1 Check ilo Service OGFS 2 Verify Supported Boot Modes OGFS --secure=disabled 27

28 3 Boot OGFS --serviceos=linux64 4 Wait for HP SA Agent OGFS --maintenance --atleast=3 --atmost=20 5 Set Media Source OPSW-Media-WinUser@@ OPSW-Media- WinPassword@@ OPSW-Media-WinPath@#/mnt/media?noserverino 6 LinuxPE add-on packages Deploy package / 7 Update Firmware Using SPP Unix --spp_version=@sppversion:latest@ 8 Boot OGFS --servicesos=linux64 force 9 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. 28

29 Steps 5 and 6 Prepare for firmware update These steps perform the work of setting up for firmware update on the target server by connecting to the Media Server where the SPP files are located and landing appropriate libraries needed in the service OS environment. Set Media Source This is the step that points the build plan to the SPP bundle on the Media Server. The parameter for this step is made up of three custom attributes all strung together. These are custom attributes that contain the media server configuration. 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/sharename#mount_point?noserverino where username:password are the credentials for the media server, and mount_point is the share that will be mounted. Optionally, all three custom attributes can be replaced with customized values as long as it conforms to URI specification above. Note that the noserverino option is neccessary when mounting a Windows share using the Linux service OS Samba client. LinuxPE add-on packages This is a zip file containing additional libraries and utilities required in the LinuxPE PXE service OS. Steps 7 to 9 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 SPPversion custom attribute name to assign a specific SPP version or it ll use the latest in the Media Server. This script expects the SPP location on the Media Server to be /Media/SPP/yyyy.mm.x where yyyy.mm.x is the SPP version number. This path cannot be easily changed. Boot Reboots the target server back into the service OS to force the ProLiant Scripting Toolkit utility changes to be available at next reboot. Wait for HP SA Agent This is the same step as before, but this time it is waiting for the agent to register in production mode. Really, the only thing left to do is to set up the contents on the media server. The ProLiant SW - Install Windows SPP requires following setup: Media server with a share that is mapped via Set Media Source using parameter such as smb://spp:deployment123@<ip>/spp#x: On this share the SPP including HPSUM needs to reside in the following subdirectory, an example of a full URL including the share name: \\<IP>\spp\Media\spp SPP packs have a name named after year+date such as , so the full path is: \\<IP>\spp\Media\spp\ The relative path to the actual SPP if you map X: to \\<IP>\spp is X:\Media\spp\

30 The Install Windows SPP in background step assumes Z is mapped which is the case if you omit the #X: part on the SMB share. If not then you need to add the following parameter to this step: --media_server_drive_letter=x You do not need the media_server_drive_letter parameter if you omitted the #X: part on the Set Media Source step. You can leave the spp_version parameter, so the full parameter on the install step in this with X: case is: --spp_version=@sppversion:latest@ --media_server_drive_letter=x The step will figure out what the latest version of the SPP is: Step 2 of 6: Run Server Script 'Install Windows SPP In Background' SPP version is 'latest' Latest SPP version is ' ' Once the media server is populated with the SPP content and the Set Media Source step in the build plan points to this content, then it is a simple matter of running the build plan on a server to upgrade the firmware. Decommission old servers When? OK, some servers really won't cut it no more, so let's get rid of them. But before doing that, you have to make sure no important data remains on them. Before possibly physically decommissioning the actual server, the server data can be erased. This includes deletion of disk data, clearing of the Smart Array configuration (if one is present) and resetting of the BIOS to factory defaults including the BIOS date/time. In DCAA, this can be done by running an OS build plan. There are two build plans, one generic and one specific to HP ProLiant servers: Erase All Server Disks: Cleans the partition tables of all target server disks. ** THIS WILL CAUSE DATA LOSS ** ProLiant HW - Erase Server: Erases the target server. Deletes disk data, clears Smart Array configuration (if one is present), and resets the BIOS to factory defaults including the BIOS date/time. ** THIS WILL CAUSE DATA LOSS ** If only the clearing of the SmartArry configuration is needed, then the following build plan can be used: ProLiant HW - Smart Array Erase: Clears the HP Smart Array configuration. Deletes all the logical volumes and arrays on the controller. ** THIS WILL CAUSE DATA LOSS ** 30

31 The above build plans perform distruptive actions on the servers' disks, controllers and BIOS configuration. The build plans boot the server into the SA Linux service OS, and then call a variety of scripts and tools (such as HPSSACLI) to perform the requested actions. The server is also decommissioned (for SA) as part of the build plan execution. At the end, when the server configuration is cleared and the server itself is decommissioned, the server is rebooted fresh into the same SA Linux service OS and is ready for deployment Call to action Download DCAA now from Don't get caught out with an unsupported OS platform! References 31