Why you will love Groups in EM

As a Middleware Administrator you are probably wondering how to convince your DBA to get access to Enterprise Manager. The reason is that those guys will not be happy to give you access to their precious databases. And of course maybe you shouldn't have write access to them either. Vice versa they should not have write/change access to your middleware. The answer lies in two things:

• User/Role privileges
• Groups

In the next topic, Oracle Enterprise Manager User Management part 2, I will go through how you connect Users/Roles to groups but for now let's just focus on the different Groups that are available to you and how this can help you both to get access, monitor, patch, configure and get incident notifications for your targets.

To create new Groups, the easiest access is through the [Targets] menu:

Inside, just [create] new Group:

As you may see, there are three different groups available to you:

• Group
• Dynamic Group
• Administration Group

The help text provided states the following:

Groups allow users to monitor and manage many targets as one. Group membership is defined either by explicitly adding targets as members or, in the case of Dynamic Groups or Administration Groups, by defining their membership criteria. Targets that match the membership criteria are automatically added to the appropriate Dynamic Group or Administration Group. Administration Groups are a special type of group meant to automatically deploy management settings to targets as they join the group.

Now, to clarify this in another way groups are a collection of entities. And I will try to explain the differences:

• Group
  Standard groups are created by you. They can contain entities(targets) of the same type or not. This is all up to you. Sometimes I will create a group of all WebLogic servers in all domains so that I can give special access to these servers for the Middleware Administrators. Another useful benefit of a group is that in the dashboard you will be able to see which patches that are available for the targets in the group, any incidents or status as a whole. Another advanced topic I will cover later is of course compliance status. Groups are probably the most used of the three. Even though you now are able to create parent and child groups I rarely do so.
• Dynamic Group
  Dynamic groups are a bit different than normal groups in that it uses some properties to define if a target is inside or outside. The properties used are the ones you can fill in during target discovery, but you can change them later by using the drop down menu for a target and select
  [Target Setup->Properites]. Dynamic Groups work the same way as standard groups in that you can select what types of targets that should participate in a dynamic group, but membership will dynamically change according to the target properties below. 

• Administration Group
  Administration Groups are something I find different from the Group and Dynamic Group concept. Administration Groups are in most cases used for a different purpose than access and control. They are instead used for monitoring purposes such as applying monitoring templates, incident notifications and compliance rules for whole environments. Administration groups are hierarchical in nature, but be aware that the deeper you make them, the more strict you need to be when applying the target properties shown above, or else your targets will not fall into any category. So in the example below, if you have a lifecycle status set to Testing, those targets will not be part of any groups. It is always the bottom level that will have targets and where you can apply rules (Template Collections).

So why are Groups so important to master? Well to put it simple, your life as an Administrator will be easier. You can even propagate privileges down, so by giving someone view access to a group, they will be able to view all targets in that group. If you give them deployment, start or stop privileges they will be able to start/stop and deploy applications to the WebLogic servers in the group.

Just to give a quick idea on how you can set up your environment here are my suggestions:

1. Create an Administration Group with hierarchic environment division such as Production, Development, Testing etc. and apply Monitoring templates that I will cover in a later blog. This is also where you configure your incident management and rule sets.
2. Create a Group for all your WebLogic servers and give privileges to your WebLogic admin
3. Create a Group for all of your databases so that your DBA(s) can have the same experience.
4. Create Dynamic group(s) for your development environment(s). This way all new targets with Lifecycle put to Development will automatically be available to the developers and project team.
5. Create separate standard Groups for other environment such as testing and production. These groups should contain both middleware and database targets.

By using different Groups developers could have access to server start/stop in development, but just read access in production. Yes, you can give different roles/users different access to Groups depending on what they should have access to. Did you also know that developers can have access to download the log files from a production environment without having access to the OS or the machine? It is all functionality made available through the Group concept in Enterprise Manager.