How to keep your middleware domains up to date

Do you wonder why your WebLogic domain is not refreshed, or do you see a lot of old applications and targets? Have you tried to refresh your domain?

You know that it is possible to enable auto refresh by clicking a field?

Just press the date field, and a new pop-up will appear:

Now your WebLogic domains will be automatically refreshed every day.

Oracle Enterprise Manager User Management, part 2

In a previous topic, Oracle Enterprise Manager User Management, part 1, I described how to create new users and even connect your EM installation to Active Directory. Let's now see how you can limit access for different users. The prerequisite is that you already have created at least one Group. I have already created a Group that contains all my WebLogic servers.

If you already have created an Administrator (user) you will see that it is possible to set access and privileges to both users and roles. I would recommend to use roles to make maintenance and access provisioning easier over time. Let's start out by creating a new role:

Let's call the role MWADMIN.

Another tip is to fill out the Description field because describing the intention of the role here will later save you for a lot of clicking to see what this role is actually doing.

Next, don't select any of the existing roles, we will create a new one that is not an aggregate of other Roles.

Step 3 is where the magic is going to happen.

The list that you see on the Target Privileges page are general privileges applicable to all targets. Generic access for all managed targets in Enterprise Manager is set here. If you want to modify any generic settings, then do that with a separate generic role.


Unselect [View any Target] and Scroll down to the bottom and press [Add]

A new pop-up window will appear with the possibility to select target types.

In this case let us select [Group] and then select, or filter, on your WebLogic Group.
(PS: You need to already have created the WebLogic Group for it to show up in the list)

The pop-up window will now close and your group is available for detail settings of privileges. Note that default Target Privilege is View access only.

Press the pencil button, and you will be able to specify the privileges that the MWADMIN role should have on all WebLogic servers in the WeblogicServer Group.

Since we are creating the MWADMIN role, select [Group Administration] and [Full]. This will give full access to both the Group and Middleware targets as Administrator.

Press [Continue] and then [Next]

Enterprise Manager resources and operations specific to the MWADMIN role is done through [Resource Privileges]. For target specific roles, newer change these settings. If you want to limit or change access, do it in a separate EM role instead and try to keep your Role's simple. As seen in the first step, a user can have several roles and a role can inherit privileges from other roles.

Next step gives the possibility to specify which users should have the privileges of our newly created role. Set it in this view, or instead afterwards go into specific users and add the new role.

We are now at the final review stage of the process.

Press [Finish] and we have successfully created a new Role.

If you apply the MWADMIN role as the only role to a user, this user will only have access to the WebLogic servers in Enterprise Manager. All other targets such as database listeners etc. will be hidden and not even visible in the summary page.

Middleware Admins should of course have read access to all targets. A role called [EM_ALL_ADMINISTRATORS] is already there, and should be applied to your middleware admins.

If you want to give your DBA´s read access to your WebLogic group, create a new role called  DBADMIN, and just give the role [View] privilieges to your WeblogicServers group. This way you know that your WebLogic servers are safe.

With the right priveleges set, it is good practice to create developer roles to view status and even be able to download log files from your production environments. All without security risk.

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.

Oracle Enterprise Manager User Management, part 1

One of the first things that should be done in Enterprise Manager is to create users other than the super user sysman. You should only use this for what it is created for, namely system maintenance, and the password should only known by a few people in your organization. Now how do you create new users? Do I have to create users?

For your administrators you should create users directly in Enterprise Manager:

The WebLogic server that Enterprise Manager runs on top of has the ability to use several authentication sources such as Active Directory and LDAP servers. Although users being cached, the catch is that these authentication sources needs to be reachable for the user to log into Enterprise Manager. If your AD is up 100% and you can guarantee that you never ever will experience network outages or other issues, then by all means go ahead and use AD for everything but I like to have the option to be able to log into my system even with all network cables disconnected. That's why you should create at least some of your admin users locally in Enterprise Manager, and you need them to be able to set privileges to your AD users too.

Just to get started, there is a perfectly simple recipe here on how to configure EMCC with AD.



Afterwards you should look into groups; normal groups, dynamic groups and admin groups.