Administration groups greatly simplify the process of setting up targets for management in Enterprise Manager by automating the application of management settings such as monitoring settings or compliance standards. Typically, these settings are manually applied to individual target, or perhaps semi-automatically using custom scripts. However, by defining administration groups, Enterprise Manager uses specific target properties to direct the target to the appropriate administration group and then automatically apply the requisite monitoring and management settings. Any change to the monitoring setting will be automatically applied to the appropriate targets in the administration group. This level of automation simplifies the target setup process and also enables a datacenter to easily scale as new targets are added to Enterprise Manager for management.
This chapter covers the following topics:
For a video tutorials on using administration groups and template collections, see:
Administration groups are a special type of group used to fully automate application of monitoring and other management settings targets upon joining the group. When a target is added to the group, Enterprise Manager applies these settings using a template collection consisting of monitoring templates, compliance standards, and cloud policies. This completely eliminates the need for administrator intervention. The following illustration demonstrates the typical administration group workflow:
The first step involves setting a target's Lifecycle Status property when a target is first added to Enterprise Manager for monitoring. At that time, you determine where in the prioritization hierarchy that target belongs; the highest level being "mission critical" and the lowest being "development."Target Lifecycle Status prioritization consists of the following levels:
Mission Critical (highest priority)
Development (lowest priority)
As shown in step two of the illustration, once Lifecycle Status is set, Enterprise Manger uses it to determine which administration group the target belongs.
In order to prevent different monitoring settings to be applied to the same target, administration groups were designed to be mutually exclusive with other administration groups in terms of group membership. Administration groups can also be used for hierarchically classifying targets in an organization, meaning a target can belong to at most one administration group. This also means you can only have one administration group hierarchy in your Enterprise Manager deployment.
For example, in the previous illustration, you have an administration group hierarchy consisting of two subgroups: Production targets and Test targets, with each subgroup having its own template collections. In this example, the Production group inherits monitoring settings from monitoring template A while targets in the Test subgroup inherit monitoring settings from monitoring template B.
In order to create an administration group, you must have both Full Any Target and Create Privilege Propagating Group target privileges.
Developing an administration group is performed in two phases:
Plan your administration group hierarchy by creating a group hierarchy in a way reflects how you monitor your targets.
Plan the management settings associated with the administration groups in the hierarchy.
Management settings: Monitoring settings, Compliance standard settings, Cloud policy settings
For Monitoring settings, you can have additional metric settings or override metric settings lower in your hierarchy
For Compliance standards or Cloud policies, additional rules/policies lower in the hierarchy are additive
Enter the group hierarchy definition and management settings in Enterprise Manager.
Create the administration group hierarchy.
Create the monitoring templates, compliance standards, cloud policies and add these to template collections.
Associate template collections with administration groups.
Add targets to the administration group by assigning the appropriate values to the target properties such that Enterprise Manager automatically adds them to the appropriate administration group.
As with any management decision, the key to effective implementation is planning and preparation. The same holds true for administration groups.
You can only have one administration group hierarchy in your Enterprise Manager deployment, thus ensuring that administration group member targets can only directly belong to one administration group. This prevents monitoring conflicts from occurring as a result of having a target join multiple administration groups with different associated monitoring settings.
To define the hierarchy, you want to think about the highest (root) level as consisting of all targets that have been added to Enterprise Manager. Next, think about how you want to divide your targets along the lines of how they are monitored, where targets that are monitored in one way are in one group, and targets that are monitored in another way are part of another group. For example, Production targets might be monitored one way and Test targets might be monitored in another way. You can further divide individual groups if there are further differences in monitoring. For example, your Production targets might be further divided based on the line of business they support because they might have additional metrics that need to be monitored for that line of business. Eventually, you will end up with a hierarchy of groups under a root node.
The attributes used to define each level of grouping and thus the administration group membership criteria are based on global target properties as well as user-defined target properties. These target properties are attributes of every target and specify operational information within the organization. For example, location, line of business to which it belongs, and lifecycle status. The global target properties that can be used in the definition of administration groups are:
Lifecycle Status target property is of particular importance because it denotes a target's operational status. Lifecycle Status can be any of the following: Mission Critical, Production, Staging, Test, or Development.
Line of Business
Customer Support Identifier
Target Type (Allowed but not a global target property.)
You can create custom user-defined target properties using the EM CLI verbs add_target_property and set_target_property_value. See the Oracle Enterprise Manager Command Line Interface Guide for more information.
You cannot manually add targets to an administration group. Instead, you set the target properties of the target (prospective group member) to match the membership criteria defined for the administration group. Once the target properties are set, Enterprise Manager automatically adds the target to the appropriate administration group.
Target Properties Master List
To be used with administration group (and dynamic groups), target properties must be specified in a uniformly consistent way by all users in your managed environment. In addition, you may want to limit the list of target property values that can be defined for a given target property value. To accomplish this, Enterprise Manager lets you define a target properties master list. When a master list is defined for a specific target type, a drop-down menu containing the predefined property values appears in place of a text entry field on a target's target properties page. You use the following EM CLI verbs to manage the master properties list:
use_master_list: Enable or disable a master list used for a specified target a property.
add_to_property_master_list: Add target property values to the master list for a specified property.
delete_from_property_master_list: Delete values from the master list for specified property.
list_property_values: List the values for a property's master list
list_targets_having_property_value: Lists all targets with the specified property value for this specified property name.
rename_targets_property_value: Changes the value of a property for all targets.
For more information about the master list verbs, see the Oracle Enterprise Manager Command Line Interface Guide. Note: You must have Super Administrator privileges in order to define/maintain the target properties master list.
Enterprise Manager Administrators and Target Properties
When creating an Enterprise Manager administrator, you can associate properties such as Contact, Location, and Description. However, there are additional resource allocation properties that can be associated with their profile. These properties are:
Line of Business
It is important to note that these properties are persistent--when associated with an administrator, the properties (which mirror, in part, the target properties listed above) are automatically passed to any targets that are discovered or created by the administrator.
In the following administration group hierarchy, two administration groups are created under the node Root Administration Group, Production and Test, because monitoring settings for production targets will differ from the monitoring settings for test targets.
In this example, the group membership criteria are based on the Lifecycle Status target property. Targets whose Lifecycle Status is 'Production' join the Production group and targets whose Lifecycle Status is 'Test' join the Test group. For this reason, Lifecycle Status is the target property that determines the first level in the administration group hierarchy. The values of Lifecycle Status property determine the membership criteria of the administration groups in the first level: Production group has membership criteria of "Lifecycle Status = Production" and Test group has membership criteria of "Lifecycle Status = Test' membership criteria.
Additional levels in the administration group hierarchy can be added based on other target properties. Typically, additional levels are added if there are additional monitoring (or management) settings that need to be applied and these could be different for different subsets of targets in the administration group. For example, in the Production group, there could be additional monitoring settings for targets in Finance line of business that are different from targets in Sales line of business. In this case, an additional level based on Line of Business target property level would be added.
The end result of this hierarchy planning exercise is summarized in the following table.
|Root Level (First Row)||Level 1 target property (second row)Lifecycle Status||Level 2 target property (third row)Line of Business|
|Root Administration Group||Production or Mission Critical||Finance|
|Staging or Test or Development||Finance|
Each cell of the table represents a group. The values in each cell represent the values of the target property that define membership criteria for the group.
It is possible to have the group membership criteria be based on more than one target property value. In that case, any target whose target property matches any of the values will be added to the group. For example, in the case of the Production group, if the Lifecycle Status of a target is either Production or Mission Critical, then it will be added to the Production group.
It is also important to remember that group membership criteria is cumulative. For example, for the Finance group under Production or Mission Critical group, a target must have its Lifecycle Status set to Production or Mission Critical AND its Line of Business set to Finance before it can join the group. If the target has its Lifecycle Status set to Production but does not have its Line of Business set to Finance or Sales, then it does not join any administration group.
For this planning example, the resulting administration group hierarchy would appear as shown in the following graphic.
It is important to note that a target can become part of hierarchy if and only if its property values match criteria at both the levels. A target possessing matching values for lifecycle status cannot become member of the administration group at the first level. Also, all targets in the administration group hierarchy will belong to the lowest level groups.
Step 2: Assign Target Properties
After establishing the desired administration group hierarchy, you must make sure properties are set correctly for each target to ensure they join the correct administration group. Using target properties, Enterprise Manager automatically places targets into the appropriate administration group without user intervention. For targets that have already been added to Enterprise Manager, you can also set the target properties via the console or using the EM CLI verb set_target_property_value, See the Oracle Enterprise Manager Command Line Interface Guide for more information. Note that when running set_target_property_value, any prior values of the target property are overwritten. If you set target properties before hierarchy creation, it will join the group after it is created. The targets whose properties are set using EM CLI will automatically join their appropriate administration groups. Target properties can, however, be set after the administration group hierarchy is created.
For small numbers of targets, you can change target properties directly from the Enterprise Manager console.
On the Target Properties page, click Edit to change the property values.
To help you specify the appropriate target property values used as administration group criteria, pay attention to the instructional verbiage at the top of the page.
Once you have set the target properties, click OK.
For large numbers of targets, it is best to use the Enterprise Manager Command Line Interface (EM CLI)
set_target_property_value verb to perform a mass update. For more information about this EM CLI verb, see the Enterprise Manager Command Line Interface guide.
Administration groups are privilege-propagating: Any privilege that you grant on the administration group to a user (or role) automatically applies to all members of the administration group. For example, if you grant Operator privilege on the Production administration group to a user or role, then the user or role automatically has Operator privileges on all targets in the administration group. Because administration groups are always privilege propagating, any aggregate target that is added to an administration group must also be privilege propagating.
An aggregate target is a target containing other member targets. For example, a Cluster Database (RAC) is an aggregate target has RAC instances.
A good example of aggregate target is the Privilege Propagating Group. See "Managing Groups" for more information.
At any time, you can use the All Targets page to view properties across all targets. To view target properties:
From the Targets menu, select All Targets to display the All Targets page.
From the View menu, select Columns, then select Show All.
Alternatively, if you are interested in specific target properties, choose Columns and then select Show More Columns.
Step 3: Prepare for Creating Template Collections
Template collections contain the monitoring settings and other management settings that are meant to be applied to targets as they join the administration group. Monitoring settings for targets are defined in monitoring templates. Monitoring templates are defined on a per target type basis, so you will need to create monitoring templates for each of the different target types in your administration group. You will most likely create multiple monitoring templates to define the appropriate monitoring settings for an administration group. For example, you might create a database Monitoring template containing the metric settings for your production databases and a separate monitoring template containing the settings for your non-production databases. Other management settings that can be added to a template collection include Compliance Standards and Cloud Policies. Ensure all of these entities that you want to add to your template collection are correctly defined in Enterprise Manager before adding them to template collections.
If you have an administration group hierarchy defined with more than two levels, such as the hierarchy shown in the following figure, it is important to understand how management settings are applied to the targets in the administration group.
Each group in the administration group hierarchy can be associated with a template collection (containing monitoring templates, compliance standards, and cloud policies). If you associate a template collection containing monitoring settings with the Production group, then the monitoring settings will apply to the Finance and Sales subgroup under Production. If the Finance group under Production has additional monitoring settings, then you can create a monitoring template with only those additional monitoring settings. (Later, this monitoring template should be added to another template collection and associated with the Finance group). The monitoring settings from the Finance Template Collection will be logically combined with the monitoring settings from the Production Template Collection. In case there are duplicate metric settings in both template collections, then the metric settings from the Finance Template Collection takes precedence and will be applied to the targets in the Finance group. This precedence rule only applies to the case of metric settings. In the case of compliance standard rules and cloud policies, even if there are duplicate compliance standard rules and cloud policies in both template collections, they will be all applied to the targets in the Finance group.
Once you have completed all the planning and preparation steps, you are ready to begin creating an administration group.
With the preparatory work complete, you are ready to begin the four step process of creating an administration group hierarchy and template collections. The administration group user interface is organized to guide you through the creation process, with each tab containing the requisite operations to perform each step.
This process involves:
Creating the administration group hierarchy.
Create monitoring templates.
Creating template collections.
Associating template collections to administration group.
Synchronizing the targets with the selected items.
The following graphic shows a completed administration group hierarchy with associated template collections. It illustrates how Enterprise Manager uses this to automate the application of target monitoring settings.
The following four primary tasks summarize the administration group creation process. These tasks are conveniently arranged in sequence via tabbed pages.
In order to create the administration group hierarchy, you must have both Full Any Target and Create Privilege Propagating Group target privileges.
Task 1: Access the Administration Group and Template Collections page.
Task 2: Define the hierarchy.
From the Hierarchy tab, you define the administration group hierarchy that matches the way you manage your targets. See Defining the Hierarchy.
Task 3: Define the Template Collections.
From the Template Collections tab, you define the monitoring and management settings you want applied to targets. See Defining Template Collections.
Task 4: Associate the Template Collections with the Administration Group.
From the Associations tab, you tie the monitoring and management settings to the appropriate administration group. See Associating Template Collections with Administration Groups.
All administration group operations are performed from the Administration Groups home page.
Read the relevant information on the Getting Started page. The information contained in this page summarizes the steps outlined in this chapter. For your convenience, links are provided that take you to appropriate administration group functions, as well as the Enterprise Manager All Targets page where you can view target properties.
On the left side of the page are two tables: Hierarchy Levels and Hierarchy Nodes.
The Hierarchy Levels table allows you to add the target properties that define administration group hierarchy. The Hierarchy Nodes table allows you to define the values associated with the target properties in the Hierarchy Levels table. When you select a target property, the related property values are made available in the Hierarchy Nodes table, where you can add/remove/merge/split the values. In the Hierarchy Nodes table, each row corresponds to a single administration group. The Short Value column displays abbreviated value names that are used to auto-generate group names.
The Hierarchy Levels table allows you to add the target properties that define each level in the administration group hierarchy. The Hierarchy Nodes table allows you to define the values associated with the target properties in the Hierarchy Levels table. Each row in the Hierarchy Nodes table will correspond to a node or group in the administration group hierarchy for that level. When you select a target property in the Hierarchy Levels table, the related property values are made available in the Hierarchy Nodes table, where you can add/remove/merge/split the values. Merge two or more values if either value should be used as membership criteria for the corresponding administration group. The Short Value column displays abbreviated value names that are used to auto-generate group names.
Adding a Hierarchy Level
On the Administration Group page, click the Hierarchy tab.
From the Hierarchy Levels table, click Add and choose one of the available target properties. You should add one property/level at a time instead of all properties at once.
With the target property selected in the Hierarchy Levels table, review the list of values shown in the Hierarchy Nodes table. The values of the target property in the Hierarchy Nodes table.
Enterprise Manager finds all existing values of the target property across all targets and displays them in the Hierarchy Nodes table. For some target properties, such as Lifecycle Status, predefined property values already exist and are automatically displayed in the Hierarchy Nodes table. You can select and remove target property values that will not be used as membership criteria in any administration group. However, property values that are not yet available but will be used as administration group membership criteria, will need to be added.
The next step shows you how to add property values.
Extending Administration Group Hierarchy Maximum Limits
There is a default maximum for the number of values that can be supported for a target property as administration group criteria. If you see a warning message indicating that you have reached this maximum value, you can extend it using the OMS property admin_groups_width_limit. Specify the maximum number of values that should be supported for a target property. For example, to support up to 30 values for a target property that will be used in administration group criteria, set the admin_groups_width_limit as follows (using the OMS
emctl set property -name admin_groups_width_limit -value 30 -module emoms
You can also add up to four levels after the root node of an administration group hierarchy. If there is a need to add additional level, you will first need to change the OMS admin_groups_height_limit property to the maximum height limit. For example, if you want to create to administration group hierarchy consisting of five levels after the root node, set the admin_groups_height_limit property as follows (using the OMS emctl utility):
emctl set property -name admin_groups_height_limit -value 5 -module emoms
This is a global property and only needs to be set once using the emctl utility of any OMS. This is also a dynamic property and does not require a stop/restart of the OMS in order to take effect.
Under certain circumstances, it may be useful to treat multiple property values as one: Targets may have different target property values, but should belong to the same administration group because they have same monitoring profile/settings. For example, if a combination of values is needed, such as Production or Mission Critical for the Lifecycle Status property, they need to be merged (combined into a single node).
To merge property values:
Select a target property from the list of chosen properties in the Hierarchy Levels table. The associated property values are displayed.
Select two or more property values by holding down the Shift key and clicking on the desired values.
Continue adding hierarchy levels until the group hierarchy is complete. The Preview pane dynamically displays any changes you make to your administration group hierarchy.
Set the time zone for the group.
Click on the group name. The Administration Group Details dialog displays allowing you to select the appropriate time zone.
The administration group time zone is used for displaying group charts and also for scheduling operations on the group. Because this is also the default time zone for all subgroups that may be created under this group, you should specify the time zone at the highest level group in the administration group hierarchy before the subgroups are created. Note that the parent group time zone will be used when creating any child subgroups, but user can always select a child subgroup and change its time zone.
The auto-generated name can also be changed.
Click Create to define the hierarchy.
Review and define the complete hierarchy before clicking Create.
Click Update to save your changes.
A template collection is an assemblage of monitoring/management settings to be applied to targets in the administration group. Multiple monitoring templates can be added to a template collection that in turn is associated with an administration group. However, you can only have one monitoring template of a particular target type in the template collection. The monitoring template should contain the complete set of metric settings for the target in the administration group. You should create one monitoring template for each type of target in the administration group. For example, you can have a template collection containing a template for database and a template for listener, but you cannot have a template collection containing two templates for databases. When members targets are added to an administration group, the template monitoring and management settings are automatically applied. A template will completely replace all metric settings in the target. This means applying the template copies over metric settings (thresholds, corrective actions, collection schedule) to the target, removes the thresholds of the metrics that are present in the target, but not included in the template. Removing of thresholds disables alert functionality for these metrics. Metric data will continue to be collected.
Template collections may consist of three types of monitoring/management setting categories:
Monitoring Templates (monitoring settings)
Compliance Standards (compliance policy rules)
Cloud Policies (cloud policies such as determining when to start virtual machines or scale out clusters).
When creating a template collection, you can use the default monitoring templates, compliance standards, or cloud templates supplied with Enterprise Manager or you can create your own. For more information, see Using Monitoring Templates.
To create a template collection:
When editing existing template collections, you can back out of any changes made during the editing session by clicking Cancel. This restores the template collection to its state when it was last saved.
To create a template collection, you must have the Create Template Collection resource privilege. To include a monitoring template into a template collection, you need at least View privilege on the specific monitoring template or View Any Monitoring Template privilege, which allows you to view any monitoring template and add it to the template collection. The following table summarizes privilege requirements for all Enterprise Manager operations related to template collection creation.
|Enterprise Manager Operation||Minimum Privilege Requirement|
Create administration group hierarchy.
Full Any Target
Create Privilege Propagating Group
Create monitoring templates.
Create Monitoring Template
Create template collection.
Create template collection (resource privilege).
VIEW on the monitoring template to be added to the template collection
View any monitoring template (resource privilege).
Create compliance standards.
Create Compliance Entity
No privileges are required to view compliance standards.
Create cloud policies.
Create Any Policy
View Cloud Policy
Associate template collection with administration group.
VIEW on the specific template collection.
Manage Target Metrics on the group.
Perform on-demand synchronization.
OPERATOR on the group or Manage Target Metrics.
Define global synchronization schedule.
Enterprise Manager Super Administrator privileges.
Set the value of target properties for a target (allows the target to "join" an administration group).
Configure Target on the specific target
Delete an administration group hierarchy.
Full Any Target
A corrective action is an automated task that is executed in response to a metric alert. When a corrective action is part of a monitoring template/template collection, the credentials required to execute the corrective action will vary depending on how the template is applied.
The two situations below illustrate the different credential requirements.
The corrective action is part of a monitoring template that is manually applied to a target.
When the corrective action runs, it can use one of the following:
The preferred credentials of the user who is applying the template
The user-specified named credentials.
The user selects the desired credential option during the template apply operation.
The corrective action is part of a monitoring template within a template collection that is associated with an administration group.
When the corrective action runs, the preferred credentials of the user who is associating the template collection with the administration group is used.
Once you have defined one or more template collections, you need to associate them to administration groups in the hierarchy. You can associate a template collection with one or more administration groups. As a rule, you should associate the template collection with the applicable administration group residing at the highest level in the hierarchy as the template collection will also be applied to targets joining any subgroup.
The Associations page displays the current administration group hierarchy diagram. Each administration group in the hierarchy can only be associated with one template collection.
For users that do not have View privilege on all administration groups, you can also perform the association/disassociation operation from the Groups page (from the Targets menu, select Groups).
All sub-nodes in the hierarchy will inherit the selected template collection.
The target privileges of the administrator who performs the association will be used when Enterprise Manager applies the template to the group. The administrator needs at least Manage Target Metrics privileges on the group.
Settings from monitoring templates applied at lower levels in the hierarchy override settings inherited from higher levels. This does not apply to compliance standards or cloud policies.
While the administration group UI is easy to navigate, there may be cases where the administration group hierarchy is inordinately large, thus making it difficult to find individual groups. At the upper right corner of the Associations page is a search function that greatly simplifies finding groups in a large hierarchy.
Figure 6-1 Administration Group Search Dialog
To search for a specific administration group:
As shown in the graphic, the search results display a list of administration groups that match the search criteria. You can then choose an administration group from the list by double-clicking on the entry. The administration group hierarchy will then display a vertical slice (subset) of the administration group hierarchy from the root node to the group you selected.
Figure 6-2 Administration Group Search: Graphical Display
To restore the full administration group hierarchy, click Clear.
Group Names and Searches
In order to perform effective searches for specific administration groups, it is helpful to know how Enterprise Manager constructs an administration group name: Enterprise Manger uses the administration group criteria to generate names. For example, you have an administration group with the following criteria:
Lifecycle Status: Development or Mission Critical
Line of Business: Finance or HR
Enterprise Manager assembles a group name based on truncated abbreviations. In this example, the generated administration group name is DC-DEV-FH-Bang-Grp
As you are building the hierarchy, you can change the abbreviation associated with each value (this is the Short Value column next to the property value in the Hierarchy Nodes table. Hence, you can specify a short value and Enterprise Manager will use that value when constructing new names for any subgroups created.
During the design phase of an administration group, you have the option of specifying a custom name. However, if there is large number of groups, it is easier to allow Enterprise Manager to generate unique names.
In order to apply the template collection/administration group association, you must set up a global synchronization schedule. This schedule is used to perform synchronization operations, such as applying templates to targets in administration groups. If no synchronization schedule is set up, when a target joins an administration group, Enterprise Manager will auto-apply the associated template. However, if there are changes to the template later on, then Enterprise Manager will only apply these based on synchronization schedule, otherwise these operations are pending.When there are any pending synchronization operations, they will be scheduled on the next available date based on the synchronization schedule.
You must set the synchronization schedule as there is no default setting. You can specify a non-peak time such as weekends.
To set up the synchronization schedule:
You can specify a start date for synchronization operations and interval in days. Whenever there are any pending sync operations, then they will be scheduled on the next available date based on this schedule.
The following table summarizes when Template Collection Synchronization operations (such as apply operations) occur on targets in administration groups.
|Action||When Synchronization Occurs|
Target is added to an administration group (by setting its target properties)
Immediate upon joining the administration group.
Template collection is associated with the administration group.
Targets in an administration group will be synchronized based on next scheduled date in global Synchronization Schedule.
Changes are made to any of the templates in the template collection.
Targets in an administration group will be synchronized based on the next scheduled date in global Synchronization Schedule.
Target is removed from an administration group (by changing its target properties).
No change in target's monitoring settings.
Compliance Standards and Cloud Policies will be disassociated with the target.
Immediate synchronization operation occurs.
Template collection is disassociated with administration group.
No change in target's monitoring settings for all the targets in the administration group.Compliance Standards and Cloud Policies will be disassociated with the target.
Targets under the administration group will be synchronized based on next schedule date in Global Synchronization Schedule.
User performs an on-demand synchronization by clicking on the Start Synchronization button in the Synchronization Status region in the administration group's homepage.
Immediate synchronization operation occurs.
You can check the current synchronization status for a specific administration group directly from the group's homepage.
You can initiate an immediate synchronization by clicking Start Synchronization.
There are two types of administration group member targets: Direct and Indirect
Direct Members: Group members whose target properties match the administration group criteria. Monitoring settings, compliance standards, cloud policies from the associated template collection are applied to direct members.
Indirect Members: Indirect members are targets whose target properties DO NOT match administration group criteria. However, they have been added to the administration group because their parent target are direct members of the administration group. These targets are categorized as aggregate targets because they have other member targets. When such targets are added to a group (administration group or other types of groups), all members of the aggregate target are also added to the group. An example of an aggregate target is Oracle WebLogic Server. If that is added to a group, then all Application Deployment targets on it are also pulled into the group. Indirect group members will NOT be part of any template apply/sync operations.
Only direct members are represented in the targets count in the Synchronization Status region.
From the hierarchy diagram, click on a group name to access the group's home page. You can also access this information from All Targets groups page.
From the Group menu, select Members. The Members page displays.
If a system target gets added to an administration group because it matches group criteria, then the system target and its constituent members are also added. However, for template apply purposes, it will only operate on the direct members that also match the administration group criteria. Template apply operations will not occur on member targets whose target properties do not match administration group criteria. All other group operations, such as jobs and blackouts, will apply on all members, both direct and indirect.
To disassociate a template collection from an administration group.
The template collection is immediately removed. See "When Template Collection Synchronization Occurs" in Defining the Hierarchy for more information.
For any administration group, you can easily view what template collection components (monitoring templates, compliance standards, and/or cloud policies) are associated with individual group members.
For monitoring templates, the settings for a target could be a union of two or more monitoring templates from different template collections.
The Administration Group Details page displays.
This page displays all aggregate settings for monitoring templates, compliance standards and cloud policies that will be applied to members of the selected administration group (listed by target type). The page also displays the synchronization status of group members.
To can change the display to show a different branch of the administration group hierarchy, click Select Branch at the upper-right area of the page. This function lets you display hierarchy branches by choosing different target property values
Like regular groups, each administration group has an associated group homepage providing a comprehensive overview of group member status and/or activity such as synchronization status, details of the Associated Template Collection for the group selected in hierarchy viewer, job activity, or critical patch advisories. To view administration group home pages:
Alternatively, from the Enterprise Manger Targets menu, choose Groups. From the table, you can expand the group hierarchy.
From the Associations page, you can determine which targets do not belong to any administration group by generating an Unassigned Targets Report.
The Non-Privilege Propagating Aggregate column indicates whether a target is a non-privilege propagating aggregate. This type of target cannot be added to an administration group, which are by design privilege propagating. For this reason, any aggregate target added to administration group must also be privilege propagating. To make an aggregate target privilege propagating, use the EM CLI verb modify_system with -privilege_propagation=true option.
On this page, you can review the list to see if there any targets that need to be added to the administration group. Click on the target names shown in this page to access the target's Edit Target Properties page where you can change the target property values. After making the requisite changes and clicking OK, you are returned to the Unassigned Targets page.
For information on changing target properties, see "Planning an Administrative Group".
Organizations are rarely static--new lines of business may be added or perhaps groups are reorganized due to organizational expansion. To accommodate these changes, you may need to make changes to the existing administration group hierarchy.
Beginning with Enterprise Manager 12c Release 188.8.131.52, you can change the administration group hierarchy without having to rebuild the entire hierarchy. You can easily perform administration group alterations such as adding more groups to each hierarchy level, merging two or more groups, or adding/deleting entire hierarchy levels. All of these operations can be performed from the Hierarchy page.
After making any change to the administration group hierarchy, click Update to save your changes.
Adding a new hierarchy level equates to adding a new target property to the administration group criteria. For this reason, you must set the value of this target property for all your targets in order for them to continue to be part of the administration group hierarchy. Any new target property added/hierarchy level added will always be added as the bottom-most level of the hierarchy. You cannot insert a new level between levels.
To insert a hierarchy level, you must remove a hierarchy level, then add the levels you want. Think carefully before removing a hierarchy level as removing a level will result in the deletion of groups corresponding to that hierarchy level.
See "Adding a Hierarchy Level" in Defining the Hierarchy for step-by-step instructions on adding a new level.
Removing a hierarchy level equates to deleting a target property, which in turn causes groups at that level to be deleted. For this reason, think carefully about the groups that will be removed when you remove the hierarchy level, especially if those groups are used in other functional areas of Enterprise Manager.
To remove a hierarchy level:
If any of those groups have an associated template collection, then the monitoring settings of the subgroups of the deleted group will be impacted since the subgroups obtained monitoring settings from the associated template collection. You may need to review the remaining template collections and re-associate the template collection with the appropriate administration group.
If you want to merge two or more administration groups, you merge their corresponding target property criteria in the administration group hierarchy definition. The group merge operation consists of retaining one of the groups to be merged and then moving over the targets from the other groups into the group that is retained. Once the targets have been moved, the other groups will be deleted.
You choose which group is retained by choosing its corresponding target property value. The group(s) containing the selected target property value as part of its criteria is retained. If the retained target property criteria corresponds to multiple groups, i.e. group containing subgroups, the movement of targets will actually occur at the lowest level administration groups since the targets only reside in the lowest level administration groups. The upper-level administration groups' criteria will be updated to include the criteria of the other groups that have been merged into it.
To merge groups:
For example, let us assume you want to merge <Devt-Group> with <Test or Stage Group>. In the hierarchy, this corresponds to target property Lifecycle Status. The associated property values are displayed.
The Merge Values dialog displays.
Again, by merging membership criteria (target properties), you are merging administration groups and their respective subgroups. You choose the administration group to be retained. The other groups will be merged into that group.
When deciding which group to retain, consider choosing the group that is used in most group operations such as incident rule sets, system dashboard, or roles. These groups will be retained and the members of the other merged groups will join the retained groups. After the merge, group operations on the retained groups will also now apply to the members from the other merged groups. Doing so minimizes the impact of the merge.
Your administration group consists of the following:
Line of Business
Mission Critical or Production
Staging or Test
Line of Business
The following graphic shows the administration group hierarchy.
You decide that you want to merge the Mission Critical or Production group with the Staging or Test group because they have the same monitoring settings.
Choose Lifecycle Status from the Hierarchy Levels table.
From the Hierarchy Nodes table, choose both Mission Critical or Production and Staging or Test.
Select Merge from the Hierarchy Nodes menu.
The Merge Values dialog displays. In this case, you want to keep original name (Mission Critical or Production) of the retained group.
After clicking OK to complete the merge, the resulting administration group hierarchy is displayed. All targets from Test-Sales group moved to the Prod-Sales group. The Test-Sales group was deleted. All targets from the Test-Finance group moved to the Prod-Finance group. The Test-Finance group got deleted.
Click Update to save the changes.
You can completely remove an administration group hierarchy or just individual administration groups from the hierarchy. Deleting an administration group will not delete targets or template collections, but it will remove associations. Any stored membership criteria is removed. When you delete an administration group, any stored membership criteria is removed.
To remove the entire administration group hierarchy:
From the Setup menu, select Add Target, then select Administration Groups.
Click on the Hierarchy tab.
To remove individual administration groups from the hierarchy: