Tuesday, December 1, 2009

Installing Oracle Enterprise Manager 10.2 on Windows Server 2008

One would suppose that installing OEM on Windows Server 2008 would be like installing it pretty much in any other Windows environment; Oracle did a pretty good job of making it easy to install and run out-of-the-box under earlier versions of Windows, so it should be easier with the latest version of OEM and Windows, correct?
Wrong. There are a variety of reasons, and we’ll run through them in this exercise, as we install Oracle Enterprise Manager on Windows Server 2008 (NOT R2; this is important!).
As an added bonus, we’ll get the OEM repository database up to 11g.

Make sure you’ve got the right operating system

Start with the OS: Windows Server 2008, 32-bit (OEM is a 32-bit application, and putting it on a 64-bit system is asking for trouble). Windows Server 2008 R2 begins the march to 64-bit only, so make sure you're not installing it.

Install OEM

First, we have to download OEM, as that’s the latest version that is available as something besides an upgrade. You can get that install here: http://www.oracle.com/technology/software/products/oem/index.html. Note that and above are only available as patch installers, rather than as a full installation.
Don’t install OEM, yet.

Install Oracle Database

The database that ships with OEM is v10.1.0.4, which doesn't work on Windows Server 2008. So you have to create the repository database yourself.
If you find yourself installing OEM and getting an error starting the database (installation fails when configuring the database), this is your problem. You’ll also see the following in the application event log:
Faulting application ORACLE.EXE, version
Again, this is because earlier versions of Oracle don't work on Server 2008; make sure you've downloaded the correct version as below.
Installation files for Win 2008 32-bit can be downloaded here. Note that there is a separate installation for Vista and Windows Server 2008; make sure you get that.
Don't create a database as a part of the installation.
After installation, run the Database Configuration Assistant and create a basic database without configuring it for Enterprise Manager console.
Once the database is created, connect to it as sys and run the following commands to prepare the system for OEM. Note that the below commands assume you’re using an spfile. Make sure you’ve created one before running this.
alter system set session_cached_cursors=200 scope=spfile; alter system set aq_tm_processes=1 scope=spfile; alter system set job_queue_processes=10 scope=both; @?/rdbms/admin/dbmspool.sql; shutdown immediate; startup;

Run Net Configuration Assistant

This will create the listener.
Start -> All Programs -> Oracle - OraDb10g_home1 -> Configuration and Management Tools -> Net Configuration Assistant
Net Configuration Assistant won't update your tnsnames.ora file for your database; you'll need to make sure you do that. Net manager will, should you want to use a GUI to get that done. You can, of course, use other net naming methods, as well…

Install OEM with the Option for using an existing database

Tell setup not to check for system prerequisites
Windows Server 2008 didn't exist when was created, so when installing, you've first got to tell it not to check system prerequisites:
setup.exe -IgnoreSysPrereqs
Otherwise, you'll get this error:
Checking operating system version: must be 4.0, 5.0, 5.1 or 5.2. Actual 6.0 Failed <<<<<<<<
Set the TimeZone
This seems silly, but it appears to have been a fatal error in bringing up the agent. If the installation fails at configuring the agent, this might be the problem. Here is the relevant section of the log at c:\oraclehomes\agent10g\sysman\log\emagent.nohup
Tue Nov 17 12:19:39 2009::The agentTZRegion value in C:\OracleHomes\agent10g/sysman/config/emd.properties is not in agreement with what agent thinks it should be. Please verify your environment to make sure that TZ setting has not changed since the last start of the agent.
So open the emd.properties ($OracleHome\agent10g\sysmand\config\emd.properties) file and change the agentTZRegion line from GMT to the appropriate time zone code.
Change the local firewall settings
Open ports 1159, 4889, and 1521 to allow Oracle and OEM to communicate.
Test OEM
Version requires that be working before installing it, so make sure OEM is providing basic functionality before you start with the installation.
Upgrade OEM to
Once is working, run the install to upgrade it to v10.2.0.5. Stop enterprise manager Start -> All Programs -> Oracle application server -> Stop EnterpriseManager
If you don't do this, you'll get the following error:
Management Servers cannot be connected to the management repository during upgrade
They tell you to wait four minutes after stopping the server, and they're not kidding; you really do have to wait. Run setup.exe from the OEM download.
When it asks for the IAS_ADMIN password, this is the password you entered to secure the agent communication.
Once the upgrade to is complete, make sure that OEM still is working. (Browser to your server on port 1159.) Having verified that, we'll start to upgrade the database.

Upgrade the database to 11g

Now that we’ve got OEM up to 10.2.05, we have the option of running the back-end database on 11g. Here’s how to get that: First install 11g on the same system without creating a database into a new Oracle Home. Suggested: c:\oracle\product\11.1.0 use c:\oracle as the Oracle Base location.
Once installation is complete, run the DBUA (DataBase Upgrade Assistant) and select the instance you want to upgrade. Don't move the database files when doing the upgrade unless you had them stored in the oracle_home from 10g. DBUA takes a long time to run.

Re-set the Sys password and parameter

After upgrading to 11g, the agent likely will not be able to connect to the OEM instance anymore. This is pretty easy to fix: in the OEM instance, make sure the following parameter is set:
alter system set remote_login_passwordfile=exclusive scope=spfile;
Then make sure you've got a pwd file:
c:\oracle\product\11.1.0\db_1\dbs\orapwd file=C:\oracle\product\11.1.0\db_1\database\pwdSID.ora password=xxxxxx entries=5
Note that the above command has to be run as administrator (right-click on the cmd icon and select "Run as administrator"). Now log in to OEM and click on Targets -> All Targets. Select the database instance and click the configure button (see below)
Re-set the sys password (making sure it's set to connect as sysdba) and save your changes. Now restart the instance and the agent; you should be good to go.


If installing OEM fails with a "RepManager Create Repository Error = 14" message, then you probably need to get rid of some DB users and objects. The following command will do this (from support doc ID # 358627.1)
repmanager [hostname] 1521 [SID] -action drop
There's another gotcha in that command, though: it has to be run with Windows' administrator privileges. If you see the following when attempting this command, you need to start a command console as administrator.
Enter repository user name : sysman Getting temporary tablespace from database... Found temporary tablespace: TEMP Checking SYS Credentials ... Access is denied. Failed SYS credentials or connect string is invalid.


  1. hi. i'm researching about the oem agent. from what i've read it uses port 3872. this port also happens to be used for our school's web proxy. our network operations director supposes that this could be a potential cause of conflict especially at times when the oracle systems are being used frequently (i.e. for enrollment and the like). i need your opinion. could this really be a source of network traffic? please help me. i'll appreciate it a lot if you did. thanks!

  2. Mohamad,
    My hunch is that this wouldn't present much of a problem for you. That's because while the TCP port (3872) is used by your web proxy, it's only used by Oracle on the database servers and on the Grid Control web server. Since those aren't also your web proxy servers (I'm assuming, but that seems like a safe assumption), you shouldn't have any difficulties with this.
    The port that is used isn't something that affects the kind of traffic that is going over that port (we can tunnel almost anything through the SSL port 22, for instance); we only get into trouble when we have multiple applications trying to listen on the same port on the same server. That is to say: we can use the same TCP port for multiple purposes in our network, so long as we're not trying to have several things listen on the same port on the same server.

    It sounds like, though, your network folks are more concerned with the volume of traffic being transmitted; is that true? I can't speak knowledgeably about the actual numbers in terms of kb/host, but I believe that the diagnostic and performance data generated by the agent and sent to the repository each day must be minuscule when compared to the amount of data transmitted in a busy hour by the applications, themselves. I hope that helps!

  3. Thanks a lot! appreciate it. :) i'll just post another comment if there is something to clarify. thanks for your time and effort. :)


Thanks for leaving a comment!