Properties and provisioning

Provisioning uses three types of system objects — devices, system packages, and data store instances. In addition, a provisioned device is represented as a sever object. Like other system objects in BMC Server Automation, these system objects have properties. 

To use properties with provisioning, see the following topics:

Device properties

Every device inherits its properties from the built-in Device class in the Property Dictionary. You cannot edit values for the properties included by default in the Device class. They are intrinsic properties, meaning they are derived from the nature and configuration of a device, such as its MAC address and serial number. However, you can add properties to the Device class in the Property Dictionary. Any property you add applies to every device. 

Server properties

You can use the PROVSERVER class of properties to assign property values to servers during the provisioning process. You can use this feature for predefined server properties that are marked editable and for custom server properties. 

The PROVSERVER class is a subclass of the Server class of properties. The PROVSERVER class has exactly the same set of properties as the Server class. To use PROVSERVER properties to automate server property assignments, you must create an instance of the PROVSERVER class and assign values to the properties in the instance. Then, in a Provision Job, you select the instance you want and the properties in that instance. When the Provision Job executes, it assigns the value in the selected PROVSERVER property to the property of the same name in the Server class, for each of the target servers.

To provision server properties

1. To open the property dictionary, select Configuration > Property Dictionary View.
2. To create a custom property in the Server class, expand Built-in Property Classes, navigate to the Server class, and click Add . Then click OK.  
   For example, create a property named Site.
3. To verify that the new property (created in the Server class) appears automatically in the PROVSERVER subclass, expand PROVSERVER in the left panel and scroll to find the new property. 
   For example, notice the Site property in the PROVSERVER subclass.
4. To create an instance of the PROVSERVER subclass, ensure that you have the PROVSERVER subclass selected in the left panel, and click the Instances tab in the right panel. Then click Add and complete the dialog boxes to create the new instance. 
   For example, create an instance named Austin_Windows_Servers.

5. To populate the new instance with property values, select a property, click Edit, and type the value. 
   For example, select the Site property, click Edit, and type Austin as the property value. Then, select MS_OFFICE_INSTALL_USERNAME, click Edit, and type a username that you plan to create on the servers. Similarly, select and populate MS_OFFICE_INSTALL_PSW.

   Note

   You can select and populate only those properties that are marked as editable in the Server class.

6. To set up a Provision Job to assign these values to all of the target servers in the Job, open or create the Provision Job. On the Server Settings panel, navigate to a PROVSERVER instance and select the properties whose values you want to assign to all target servers. 
   For example, select the Austin_Windows_Servers instance, and then select the Site and the MS_OFFICE properties that you populated with values.
7. Execute the Provision Job.
8. To verify that the server property values are provisioned, in the Servers folder, select one of the target servers that you just provisioned and browse the Properties tab. 
   For example, all of the target servers in the Provision Job have a value of Austin in their Site property.

System package properties

Unlike properties for many other system objects, properties defined for the system package built-in class in the Property Dictionary cannot be changed. To add properties, define them in the Local Properties of the system package.  

Like other system objects, system packages inherit properties defined for a built-in class in the Property Dictionary. However, you cannot change the properties defined for the system package built-in class in the Property Dictionary, the way you can for many other system objects. (In fact, the built-in class for system package is hidden from display within the Property Dictionary.) Instead, to add a property to a system package, you add it to the individual system package itself, using the Local Properties panel for that system package.

Using parameters that refer to properties can be very useful when provisioning.

• For information about how to use a property to refer to a script, see Inserting a script in a system package.
• For information about how to insert a parameter into a system package, see Inserting a parameter into a system package.
• For an example of how to use parameters to refer to system package properties, see Example - How to use parameters to refer to system package properties.

Inserting a script in a system package

To insert a script in a system package, you can create a local property to reference the script. You can create a local property that contains a script, and then insert a parameter that refers to this property in the system package. 

To use a local property to insert a script in a system package, complete the following steps:

1. Create the local property:
   1. Click the Local Properties tab.
   2. Click Add , and for Type, select Simple > Long Text.
   3. To the right of the Default value field, click Browse ()
      to open a text window.
   4. Type your script in the text window.
   5. Click OK and then save the system package. Your property appears on the Local Properties tab.
2. In the relevant system package field, insert a parameter that refers to the newly created script property. Enclose the property name with double question marks. 
   For example, suppose you created a long text script property called PARTITION_SOLARIS_8. In the script field on the Disk Partition panel, you could either type in:
   ??PARTITION_SOLARIS_8??
   or you could click Select Property and select PARTITION_SOLARIS_8 from the drop-down menu of available properties. (When you use the Select Property icon, the double question marks are filled in automatically.)

Inserting a parameter into a system package

Using parameters that refer to properties can be very useful when provisioning. You can insert properties, including parameterized properties, in many fields in system package definitions.

You can generalize a system package using a parameterized property. For example, you can define a system package that uses a parameter to represent the path to a network driver. Later, when this system package is being used to provision a device, a user can insert the value for the network driver path that is applicable to the device being provisioned.

To insert a parameterized reference to a property in a system package field, in the field where you want to insert the reference to the property, do either of the following:

• Click Select Property to display a drop-down menu of available properties. Then click the property you want to insert.
• You can also type the name of the property directly into the system package field. Be sure to delimit the property with two question marks, such as ??NIC_DRIVER_PATH??.

For an example of how to use a parameterized property reference in a system package field, see the following section.

Example - How to use parameters to refer to system package properties

This example shows how set up a field in the provisioning wizard so that it displays a drop-down menu of valid choices for that field. This frees the provisioning operator from needing to know the exact syntax required for the field.

To set up a field in the provisioning wizard so that it displays a menu of choices:

• Add a local property to the system package. 
• Insert a parameter that refers to this property in the system package definition. 
• Run the wizard and view the resulting drop down menu for the field.

Suppose you are creating a system package for a Red Hat system, and you want the Kickstart network device field in the provisioning wizard to include a drop-down menu of available choices. (The Kickstart network device field is one of the Basic Configuration settings.) To accomplish this, you can:

1. Create your Red Hat system package.

2. On the Local Properties panel, add a local property called ACTIVE_NIC_PORTto your system package. Make this property a String enumeration that contains the following name/value pairs:

   Name	Value
   Port 0	eth0
   Port 1	eth1
   Port 2	eth2
   Port 3	eth3

3. On the Basic Configuration panel for your Red Hat system package, type the following into the Kickstart network device field:
   ??ACTIVE_NIC_PORT??
4. Create a Provision Job to provision a device with your Red Hat package. When the provisioning wizard displays the Basic Configuration panel, note that the Kickstart network device field displays a drop-down menu with the choices Port 0, Port 1, Port 2, and Port 3.
   The provisioning operator can simply select one of the available choices without worrying about the underlying syntax, which you specified when you defined the system package.

Data store instance properties

A data store instance has properties that point to the location of a data store, which is where you store sets of installation files that are used for provisioning operating systems. 

You can create multiple data stores throughout your network, and then choose the most appropriate one for provisioning a specific device. You can create data store instances that point to different physical machines on your network, different directories on a machine, or the same configuration setting in different ways (for example, host name vs. IP address).

In the Provision Job, you choose the appropriate data store instance for the machines that you are provisioning. The following examples illustrate this flexible provisioning feature. 

Efficient provisioning over the network

If you are provisioning servers in different LANs, you might improve network and provisioning efficiency by setting up two instances of the data store, one for each LAN. For example, consider the following network topology:

The example shows two data store instances:

• VLAN1 Data Store — points to data store 1 on VLAN 1
• VLAN2 Data Store — points to data store 2 on VLAN 2
  To provision target 1, you specify the VLAN1 Data Store instance in the Provision Job. Similarly, to provision target 2, you specify the VLAN2 Data Store.

Data stores for different operating systems

You can create data store instances to store the files for provisioning different operating systems. For example, consider the following topology. To provision one Linux machine on VLAN 1 and a second Windows machine, also on VLAN1, you can create two data store instances:

• Linux Data Store VLAN1
• Windows Data Store VLAN1
  

Both of these data stores can reside on the same physical machine — in this example on machine 1.

• The Linux Data Store VLAN1 instance points to the directory on machine 1 that contains the Linux installation files. Because Linux targets require the data store property LOCATION to be set to the data store's IP address, you must set LOCATION to machine 1's IP address.
• The Windows Data Store VLAN1 instance points to the directory on machine 1 that contains the Windows installation files. Because Windows targets require the data store property LOCATION to be set to the data store's host name, you must set LOCATION to machine 1's host name.

Where to go from here

Setting up provisioning jobs and post-provisioning jobs