Agent Update Packs

If you navigate to the 'Managed Software' page in the quick links you'll see a listing of all the tools releases and JDBC drivers that have been uploaded to the management console. These packages, obtained from the Update Center, are used to stage tools releases prior to installing or upgrading them.

You may notice an entry named 'Agent Install Pack 7' of type 'Management Agent Installer Bundle'.

What is this? Well, in a previous post I mentioned that we have two separate downloads for Server Manager for each tools release.

• A large (~1 GB) Installer, and
• A much smaller (< 50 MB) console update
  

The large installer is used the first time you install SM. This includes the J2EE container used to run the web application, the SM management console application, and the corresponding agent install pack. The SM update contains only updated SM management console (and corresponding management agent code). Installing a new SM application and later applying an update is functionally equivalent to initially installing the later release using the installer. Our goal here was to keep updates small and easy to apply.

There's actually a third possible download from the update center: a new agent update pack. This contains items that are rarely going to change with each tools release update. Specifically it contains the platform specific managed home installer for all the platforms we support and the platform specific Oracle Configuration Manager agent that is installed along with the managed home.

These items are rarely updated because

1. The managed home agent installer obtains the actual agent codebase from the management console, thus installing whatever is current with the console application
2. The Oracle Configuration Manager agent will automatically update with the latest version provided by Oracle, therefore not requiring OCM updates with Server Manager

So why the potential separate download for the management agent pack? In the event we need to update either the managed home installer or OCM agent that is initially installed we will create a new management agent pack that can be downloaded from the Update Center. Why would we do this? It won't be typical, but an example in which we might need to update the pack is if we added support for a new platform that isn't currently available or need to deploy code fixes to the managed home installer. As of this posting we have no foreseeable need to update the agent installer pack.

How do I know if I need a new agent installer pack? Should we need to update the agent installer pack we will create and add the package to the Update Center. Navigating to the 'Management Agents' page will tell you if a new agent installer pack is required. For example, assume:

1. We updated the agent install pack with a particular tools release of Server Manager
2. You have applied that SM update to an existing SM installation
3. You want to install a new managed home agent

In this case you will be instructed to download the corresponding agent installer pack and add it to the SM software repository.

What if I delete the existing agent installer pack? This software component is treated just like any other software component; that is you can delete it either through SM or directly from the file system. If you have deleted the agent installer pack and navigate to the 'Management Agents' screen you will be instructed to obtain the installer pack from the Update Center.

Since we have not had the need to rev the installer pack it is not currently available for download from the Update Center. So, in the case you accidentally deleted the existing installer package you may obtain it only by performing a new SM installation and copying/uploading the file from the new install to the existing installation. After doing so you may uninstall the new SM console just installed.

The file will be named something along the lines of agentPackage7.jar and will be located in the directory INSTALL_BASE/components, where INSTALL_BASE refers to the installation path of the SM application.

Starting UNIX Enterprise Servers

Starting and stopping an enterprise servers is an easy task. Start the appropriate service on Windows, run STRNET in the appropriate system library on iSeries, and execute the RunOneWorld.sh script on UNIX based platforms. Simple enough, right? While the first two examples are as easy as they sound configuring the proper environment in order to start the UNIX based servers has become an art form of its own. This article while detail the steps, fixes, and other details on how Server Manager starts the enterprise server on UNIX based platforms.

The various install permutations of apps releases and introduction of the platform pack have resulted in different environments for the UNIX servers. Prior to 8.11SP1 an installer was used to install the enterprise server code. This installer created a script, named .oneworld, in the operating system user's home directory and modified the user's .profile to call this script. The .oneworld script defined several environment variables used by the RunOneWorld.sh and other scripts including the EVRHOME and SYSTEM variables. These environment variables must be properly set in order for the startup scripts to operate properly.

8.11SP1 introduced the platform pack, an improved installation program, used to install the enterprise server and database files. The platform pack did away with the .oneworld script instead favoring a more robust script named enterpriseone.sh located in the $EVRHOME/SharedScripts directory

The $EVRHOME environment variable refers to the installation path of the enterprise server. Underneath this directory would be, among other things, the pathcodes and system directory containing the tools release.

The user's .profile was modified to call the enterpriseone.sh script during login.

Since Server Manager supports all application releases from 8.9 through 8.12 the startup and shutdown logic must accommodate both of these conventions. In all cases the corresponding environment setup script (.oneworld or enterpriseone.sh) must be called prior to calling RunOneWorld.sh or EndOneWorld.sh.

8.97.0.0 Server Manager

The 8.97.0.0 release of Server Manager contained several issues around properly setting up the environment prior to invoking the start/stop scripts. Most of these issues have been addressed by 8.97.0.1 and as such all UNIX based installations should immediately upgrade server manager to 8.97.0.1.

8.97.0.1 Server Manager

Server Manager starts/stops the enterprise server by calling the script startEntServer.sh/stopEntServer.sh located in the $EVRHOME/SharedScripts location. The scripts are dynamically created each time the server is started or stopped. If that directory does not exist (as it may not in 8.9, 8.10, or 8.11) it will be created. The startEntServer.sh and stopEntServer.sh scripts will do the following tasks

• Include the .oneworld or .enterpriseone.sh script, depending on release
• Call the RunOneWorld.sh or EndOneWorld.sh script

Including the appropriate environment scripts resolved most of the startup issues discovered.

There remains one pending issue for IBM UDB users: prior to 8.11SP1 the installation instructions required the user to add a call to the db2profile script used to setup the environment needed for the UDB binaries and environment variables. The documentation instructed the user to add this call to the operating system user's .profile. The startEntServer.sh/stopEntServer.sh scripts did not directly include the db2profile script call, resulting in an enterprise server started using server manager failing to connect to UDB. The jde.log files for the kernel processes that establish a database connection would include numerous errors indicating that libodbc.[sl or so, depending on platform] failed to load.

8.97.0.next Server Manager

The next tools release will include some fixes to address the UDB issue mentioned above. As the startEntServer.sh and stopEntServer.sh files are created, during start or shutdown, the management agent will parse the user's .profile looking for a call to the db2profile script. If found it will add a call to this script thus properly setting up the UDB environment.

If you are using 8.97.0.1 Server Manager in a UDB environment you can easily workaround this issue by adding a call to the db2profile into the .oneworld script rather than the .profile.

Depending on how the user is setup, how the db2profile script is called, and the virtually unlimited permutations we realize that our .profile parsing logic may not always find the db2profile script. There may also be other environment setup that we did not anticipate. Since the startEntServer.sh and stopEntServer.sh scripts are dynamically created it is not possible to modify these files directly. To address this a check for the scripts startExtras.sh or stopExtras.sh has been added to the dynamically created scripts. We do not deliver these scripts, however, if present they will be invoked. This permits the administrator to add any additional setup each time the server is started or stopped. These scripts are located in $EVRHOME/SharedScripts and are available for all apps releases.

The JVM Issue

The 8.96 tools release introduced Java based kernel processes using a bundled JVM for the metadata kernel. 8.97 makes further use of this capability for both the BI Publisher and Server Manager kernel processes. The required JVM is bundled with the tools release (except iSeries where it is built-in to the OS).

The server manager managed home agent also includes a bundled JVM (again, except for iSeries). The 8.12 platform pack (and the included enterpriseone.sh) shell script properly configures the LD_LIBRARY_PATH or SHLIB_PATH (depending on platform) to properly define the directories in which shared libraries should be loaded.

The scripts created by the installers/platform packs prior to 8.12 did not have these additional environment configuration parameters needed to properly startup the enterprise server. With Server Manager the startup scripts are invoked by a Java process (our bundled JVM, based on 1.5). The JVM will modify the LD_LIBRARY_PATH or SHLIB_PATH to include locations specific to the 1.5 based JDK we deliver. This will conflict with the 1.4 JDKs delivered with the enterprise server tools release.

If you installed your enterprise server using the 8.12 or later platform pack stop reading; this issue will not affect you. If you initially registered your enterprise server using the 8.97.0.2 release or later stop reading; we have fixed the issue.

If you installed your enterprise server using 8.11SP1 or earlier AND registered your enterprise server using 8.97.0.1 or earlier server manager you may still have an issue. We modified, during the registration process, the .oneworld or enterpriseone.sh script to properly setup the LD_LIBRARY_PATH/SHLIB_PATH for you. However, there was a flaw that you may have to manually correct. If you look in these files you will see a line that was added by server manager that defines the JVM_LIB environment variable, and the LD_LIBRARY_PATH/SHLIB_PATH are modified to include it. The flaw, however, is in the order added. We appended the JVM_LIB environment variable to the existing LD_LIBRARY_PATH/SHLIB_PATH. Instead it should have been prepended to it.

To resolve this issue edit the appropriate file and ensure that LD_LIBRARY_PATH is redefined to be something like:

LD_LIBRARY_PATH=$SYSTEM/lib:$(JVM_LIB)........:$LD_LIBRARY_PATH

rather than

LD_LIBRARY_PATH=$SYSTEM/lib:......$LD_LIBRARY_PATH:$JVM_LIB

Summary

If you registered your enterprise server using 8.97.0.2 or later server manager don't worry -- all these issues have been resolved.

If you registered your enterprise server using 8.97.0.1 or earlier server manager and your enterprise server was installed using 8.11SP1 or earlier platform pack/installer you may need to modify the LD_LIBRARY_PATH/SHLIB_PATH to move the JVM_LIB definition.

If you use UDB and you are using 8.97.0.1 or earlier server manager and your enterprise server was installed using the 8.11 or earlier installer you may need to add a call to db2profile to the .oneworld shell script.

Installing Server Manager for Non-English Machines

An issue has been discovered that prevents the successful installation of Server Manager when the user that performs the installation is configured for something other than English.  The problem relates around messages that are output by the embedded container.  The installer is looking for particular words, in English, and the container is outputing that text localized.  So even though the installation was successful the installer thinks it failed and begins to uninstall.

A workaround is to change the current user's language, in Windows, back to English and perform the installation.  Also make sure the 'Language for non-Unicode programs' on the advanced tab is configured to English as well.  These settings can be found in the 'Regional and Language Options' control panel option in Windows.

Once the installation is complete you may return to using the desired language of choice.

The Management Kernel

Tools release 8.97 adds two new kernel definitions to the enterprise server: the BI Publisher (XML Publisher) and Server Manager kernels. Like the metadata kernel introduced in 8.96 these new kernels are Java based kernels that start their own JVM instance to run Java code rather than the traditional C based code of kernels past. SM will automatically add and configure these kernels into the JDE.INI when changing the tools release to 8.97. This post will focus on the server manager kernel.

The server manager kernel (number 32 for those keeping count) operates on all platforms and loads a JVM upon startup. This JVM will in turn load the management agent. This is the same codebase as that used by the managed home agent and is used to provide runtime information about the enterprise server to the management console. It uses a couple of INI settings, configured automatically, to provide it with the instance name and managed home location associated with the enterprise server instance. From the managed home location it will read the agent.properties discussed in previous posts to obtain the connection details for the management console. It also follows the same connection logic used to establish communications as outlined in that post.

The management console uses this kernel to obtain all the runtime information about the server such as the active process list. It also uses this agent to expose and provide the log files that are active for the processes that appear in the process list.

This kernel definition is a singleton; that is there may only be a single process active and must be configured to start automatically, again all configured automatically. In fact the management console will not permit configuring more than one process for this kernel. The underlying network communications used by the management agents is different than the JDENET communications used by other kernels. As such the singleton can properly handle any amount of load and introducing additional processes is not necessary and will cause unexpected results.

The SAW Kernel

The Although SAW has been replaced with 8.97 there are still portions of the SAW infrastructure that are used by server manager. On the enterprise server the SAW kernel is still used. The Management Kernel (Java) exposes the runtime information using the JMX standard. It obtains much of this information by sending JDENET messages to the SAW kernel.

It is advisable to continue to run multiple SAW processes. The information exposed by the management kernel is collected periodically, approximately every 30 seconds. After that elapsed time JDENET messages are sent to the SAW kernels to collect the information. Having multiple SAW kernels will ensure that the information update to the management kernel occurs quickly and reduces the likelihood of any of these messages timing out.

Troubleshooting

In reality there is very little that needs to be known about this kernel. That said if the runtime information isn't available for a running enterprise server it may be desirable to investigate the log files for the kernel. There are two sets of log files of interest: the jde/jdedebug.log and the java log files.

The first place to check is the server manager jde.log. Since the process list isn't available (that's what we're troubleshooting) we'll have to randomly go through the log files exposed on the management page for the enterprise server until we find the management kernel. A successful startup is shown below. If there are any errors about starting up the JVM, loading the SM classes, or any other content in this log file this is the first place to look.

If there are no problems indicated in the JDE.LOG you may look at the java based logs. Since this is standard E1 Java code, logging is configured in the jdelog.properties file contained within the system/classes directory. For each log defined in the jdelog.properties you will see a corresponding log file created for each java based kernel process. Since multiple processes can be defined for the other java kernel types (metadata and xml publisher) the process id is added to the filename, as shown below:


Summary

The management kernel provides server manager powerful new monitoring capabilities. The operation of the management kernel can generally be ignored and should only be of concern should runtime information not be available for a particular enterprise server in the management console web application.

Improving Database Connection Pools

Although this isn't a Server Manager specific post the SM tool may provide insight into the database connection pooling behavior. The EnterpriseOne web based servers maintain a pool of connections to a database. When a database connection is required it will be obtained from the connection pool. When no longer used it will be returned to the pool.

The maximum size, initial size, growth increment, and other parameters are configured in the JDBJ Database Configuration -> JDBj Connection Pools configuration parameters. Refer to the Server Manager Guide for information about the particular settings.

For each effective database connection, or connection URL, a pool of connections is created upon first request. What is a connection URL? The actual logic varies based on database type but can be summarized as a combination of the connection information (server, port, SID, etc) appended by the name of the proxy database user. A good way to think of it is evaluating the actual connection details defined by an EnterpriseOne datasource. For example a typical Oracle database based installation will use the same SID for each datasource. Thus regardless of whether the datasource is 'System - 812' or 'Central Objects - PD812' it all boils down to the same database -- the SID. In this case the connection URL will be the concatenation of the SID with the name of the proxy user.

Other databases may use more complex naming conventions for the connection URL. For example SQL Server based datasources will look something like 'jdbc:sqlserver://DENDSQWN01:1433_JDE_DEVELOPMENT_true_JDE'. This URL includes the server name, listening port, physical database name, unicode enabled, and proxy user.

The active database connections may be viewed using Server Manager. Navigate to the HTML server of intesrest and select 'JDBj Connection Caches' from the runtime metrics. You will see all the connection pools that have been established.


In the screen shot above you can see I actually have two sets of 10 database connections to two different connection URLs. The thing is these are the same database differing only by case. This didn't seem like a good thing so I went through my database datasources (F98611) and found I used all upper case there. I then went through the configuration metrics in server manager for my JAS server and found both upper and lower case uses of the Oracle SID. Changing those all to uppercase and restarting my server resulted in a single pool to the database.

Multiple JVMs in OAS

It may be advantageous, performance-wise, to configure multiple JVMs to run a single JAS instance rather than a single, larger JVM. Server Manager has made it easy to configure and utilize multiple JVMs and enhancements in the 8.97 tools release ensure there are no conflicts with log files.

A multi-JVM configuration allows a single URL to be load balanced onto two or more JVM processes for a single OC4J container. The Apache http server will automatically load balance users onto a particular JVM where their session will remain for the duration of their sign-in. A multi-JVM setup is not a failover clustering configuration; that is, if a JVM were to crash all the user sessions on that JVM will also terminate.

The number of simultaneous JVMs is configured at the OC4J container level. To view or modify the JVM count navigate to the management page for the Oracle Application Server within Server Manager. In the middle of the page you will see a section listing each J2EE container (OC4J instance) within the OAS instance.


Listed next to each OC4J instance is the JVM Processes edit and a list of active JVMs if the container is currently running. To modify the JVM processes edit and save the change. Changes will take effect the next time the container is started. Starting or stopping a JAS instance within server manager starts/stops the corresponding container.

Runtime Metrics

Server Manager will automatically detect the multi-JVM configuration and display all the runtime metrics (user sessions, database caches, et. al) separately for each JVM. Each JVM is assigned, by OAS, a unique JVM identifier. This ID is in the format container_name.group_name.index, where container_name is the name of the OC4J instance, group_name is the name of the OAS defined group to which the container belongs, and index is an integer beginning with 1 and incremented for each JVM started.



Shown above is the runtime summary displayed within the management page for a JAS server. It shows the number of active JVMs (2) and the uptime, online users, and login status for each JVM. Selecting a runtime metric, in this case JDBJ Database Caches, will display the metrics separately for each active JVM:


Configuration

Each JVM will utilize the same configuration files. As such it is not necessary to configure items for each JVM. In fact, it is not possible to configure items separately for each JVM.

Log Files

Since each JVM utilizes the same configuration files, including the jdelog.properties file using to configure the E1 logging, creating and writing to the log files would historically conflict in a multi-JVM environment. Tools release 8.97 will now automatically detect a multi-JVM environment and append the JVM ID, described above, into the filename for JVMs with a process index of 2 or greater as shown below:


Compatibility

Multiple JVM configuration is supported only for the EnterpriseOne HTML (JAS) server. Configuring multiple JVMs for the other E1 web products, such as the Transaction Server, PIMSync Server, or Business Services Server is not supported and may cause unpredictable results.

UPDATE:
While playing around with this I discovered that making changes to the JVM count on a running container will take effect immediately. That is if you have a container that is configured for a single JVM and change the value to 3 you will see two more java processes appear (after a few minutes). Changing this back to 1 will shut down the additional JVMs. Note: I do not know if it will shut down JVMs with active users on it.

This is pretty cool and can be used to aid a HTML server that is getting overloaded without having to restart it.

Configuring the HTML Server (JAS) Template Configuration

A powerful feature of Server Manager is the template configurations defined for each server type within a server group. Properly configuring the server group template greatly simplifies the creation of a new HTML server. When the server is created it will copy the configuration defined for the server group selected thus requiring minimal, if any, configuration during deployment.

I've often been asked what individual settings must be configured in order for a new HTML server to be functional immediately. First navigate to the 'Server Groups' page

Next select the 'Configure' icon for the group you wish to modify
Navigate to the 'EnterpriseOne HTML Server' section

Configure the following settings:

• Network Settings -> JDENET Configuration -> Outgoing JDENET Port - Specify the JDENET port used by the enterprise server
  
• Network Settings -> Security Server Configuration -> Primary Security Server - Specify the machine name of the enterprise server to use for security services
• JDBJ Database Configuration -> JDBj Bootstrap Datasource - Configure this section to point to the location of the system tables (e.g. System - 812). You can find these values in the JDE.INI of a development client.
• JDBJ Database Configuration -> JDBC Drivers - If you are using the SQL2005 or DB2/UDB on Itanium you may need to change the default JDBC driver
• JDBJ Database Configuration -> JDBj Bootstrap Session -> Bootstrap Environment - Specify a valid environment that will be used to determine the location of various system tables through OCM
• JDBJ Database Configuration -> Oracle Database Settings -> File Contents - If you are using an Oracle database cut and paste the contents of the TNSNAMES.ORA that the server should use.
• JDBJ Database Configuration -> JDBj Spec Datasource - If you define your serialized objects tables (F989998 and F989999) in a particular datasource rather than using OCM to determine their location complete this section
• Web Runtime -> Web Runtime -> Pathcodes - Specify a single pathcode to use for this server. Note it must be surrounded by parenthesis and single quotes, such as ('DV812')
• Web Runtime -> Web Runtime -> Default Environment - Specify the default environment to display in the login form

There are many other options that may be configured; however, these are the core values I always configure. Properly configuring the server group once significantly simplifies the new creation of servers at a later time.

One last note: when a new server group is created the template configuration is copied from the default server group. Configuring the default server group prior to creating additional server groups means you don't have to reconfigure these items for each new group unless a change to these particular settings is required.

Active Server Manager Users

Here's a real quick one: I was asked today if it is possible to know who all is signed in to the management console. To see this simply navigate to the management console instance (Instance Name: home) and select the 'User Sessions' runtime metric on the left. You'll see a grid containing all the active management console users. Your current session will be highlighted in bold.

Troubleshooting Agent Communications

The managed home agents communicate with the management console using secure JMX connections. Once started the agent will connect with the console, perform some registration tasks, and appear automatically in the management dashboard. This article provides inside to the communication process and steps to troubleshoot the communications.

Agent Communication

The management console is configured with a JMX port used to establish communication between the management agents (both the managed home agent and the embedded agent contained within the server products). This port is specified during the installation wizard and defaults to 14501.

When the agent is installed a configuration file containing the name of the management console and JMX port to use is configured. This is in the file install_location/config/agent.properties.

management.server.name=myserver.mydomain.com
management.server.port=14501

The name of the server may either be a short machine name, a fully qualified domain name, or an IP address depending on how the Java process running the management console was able to resolve the host name.

The agent will use this information to attempt to connect to the management console. If unsuccessful, for example if the console isn't running, the agent will continually re-attempt the connection. This activity is recorded in the agent's log files. Look in the log file e1agent_0.log (the zero will always be the most current log) located within the install_location/logs directory of the managed home. In the log file you will see something along the following, in this case the management server is on denlcmwn5.mlab.jdedwards.com and the JMX port is 18501:

Nov 7, 2007 10:35:37 AM com.jdedwards.mgmt.agent.E1Agent$ManagementServerDaemonThread run

FINER: Attempting to connect to service:jmx:jmxmp://denlcmwn5.mlab.jdedwards.com:18501

If the connection could not be established a corresponding error will appear shortly in the log file.

Tip #1
On the machine the agent was installed attempt to ping the management console using the server name configured in the agent.properties file. If the ping is not successful you may either change the agent.properties file (for example to not use a fully qualified name) or modify host files (e.g. /etc/hosts on unix) as necessary. Either way restart the agent after making any changes.

Tip #2
If the ping was successful you can attempt to telnet to the management console using the same port. For example 'telnet denlcmwn5.mlab.jdedwards.com 18501'. If the connection is successful you know the agent is able to establish a connection to the console. If this fails there may be firewall or other networking issues preventing the connection that need to be resolved. Note: On a successful connection you may ignore any content displayed in the connection; it will not be human readable.

Once that connection has been made the management console will assign a TCP/IP port that the agent should use to listen for incoming connections. The agent will pass in it's machine name and install location, and the console will provide the next unused TCP/IP port starting at the 'Management Agent Starting Port' which was also configured during the installation wizard and defaults to 14502.

In the managed home agents log you will see the port that was assigned, in this case it was 18607:

Nov 7, 2007 10:35:42 AM com.jdedwards.mgmt.agent.Server startListener

INFO: Starting the management agent listener on port '18607'.

Nov 7, 2007 10:35:42 AM com.jdedwards.mgmt.agent.Server startListener

FINE: Attempting to start the local management agent listener on port 18607

Nov 7, 2007 10:35:42 AM com.jdedwards.mgmt.agent.Server startListener

FINE: Succesfully started the management agent listener on port 18607

If the operation was successful, as shown above, you may continue to to the next step. If there are errors indicating the listener could not be started you should make sure no other program is using that same port (and if they are you may change the 'Management Agent Starting Port' to something else in the management console (Select the 'Management Agents' link in the Quick Links. Do not change the 'Management Server JMX Port' setting.

If everything has been successful so far we will now focus our attention on the logs for the management console. You may view these logs using the console application itself. Navigate to the managed home for the management console (the managed home that contains the 'home' instance). On the bottom of that page select the log file home_0.log. The log should contain an entry indicating the initial connection (thus a port of -1) from the managed agent:

FINER: Received heartbeat from the remote management agent on denlcmlx2 listening on port -1 of type 2 in managed home /home/oracleas/oasagent

Next you will see an entry about the calculated port discussed above.

FINER: Determining the port the remote agent 'denlcmlx2' should start listening on.

FINER: Assigning the port 18607 to the remote agent 'denlcmlx2'.

Followed by a "heartbeat" request from that agent:

FINER: Received heartbeat from the remote management agent on denlcmlx2 listening on port 18,607 of type 2 in managed home /home/oracleas/oasagent

Finally the console will attempt to connect to the remote agent on the port assigned. If successful you will see something like:

FINE: Attemping to establish a connection from the management console to the remote agent 'denlcmlx2' on port 18607.

FINE: Successfully established a connection from the management console to the remote agent 'denlcmlx2' on port 18607 with connection id 'jmxmp://10.139.163.53:3213 32330841.

This completes the communication negotiation process and the managed home will soon appear in the dashboard.

Tip #3
If there are errors indicating the connection was not successful follow similar steps as above to troubleshoot the issue:

1. On the management console machine ping the server using the name reported in the log files (in this case denlcmlx2). If not successful ensure the network/dns configuration is correct. Add an entry to the hosts file (\windows\system32\drivers\etc\hosts) for the machine name if necessary.
2. If the ping was successful telnet from the management console to the specified name and port, for example 'telnet denlcmlx2 18607'. If that connection was not successful ensure that there are no firewall or other networking issues preventing the connection.

Nearly all the problems related to the managed agents not appearing in the management dashboard are related to networking and host name resolution issues or firewalls that are in place between the server running the management console and the remote machine.

Tip #4
On the iSeries platforms if there are errors in the logs indicating crypto or encryption related problems (because the connection between agents is fully encrypted) this usually indicates the required JDK (1.5) is not present.

Understanding the Server Manager Downloads

Server Manager is mastered along the standard tools release schedule. That means that for each tools release, maintenance release, and update will include downloads for Server Manager. For each tools release there will be two downloads.

If you are installing SM for the first time I would recommend obtaining the latest installer. This will be a large (1 GB) download that is used to perform the initial installation.

If you have already installed SM you may download a significantly smaller update (around 30-50 MB) and apply that to your existing SM installation (of course using SM to perform the update).

For example installing 8.97.0.0 and then applying the 8.97.0.1 update will be functionally identical to initially installing the 8.97.0.1 release. You may also go backwards, if desired, to an earlier release.

Remember you may always use the latest SM release even if you are managing earlier tools releases of the E1 components. Using the latest SM release ensures you have all the latest bug fixes and functionality available.

Visit us at OpenWorld '07

I and some of my colleagues will be OpenWorld this year. Visit us at the EnterpriseOne Tools and Technology booths at DEMOgrounds and attend Server Manager session on Thursday morning. See you there!

Here we go....

If you can read this it means we have gone GA with the 8.97 tools release.  Download, install, and go crazy with Server Manager.  And stay tuned for more tips, tricks, and detailed information about Server Manager.

Multi-Foundation on UNIX

Today I wanted to setup multi-foundation on the same enterprise server on my Linux based server. I had an existing server that I wanted to "clone" to create two additional installs for testing various tools releases. The primary was installed using platform pack and was already upgraded to 8.97 using SM.

I wanted to take advantage of the multiple instance support in EnterpriseOne that allows multiple instances to run under the same OS user. Typical multi-foundation setups operate each enterprise server install as a different OS user. This works fine, but with the advent of server manager and it's management agents it would require installing and operating a separate managed home for each OS user. This setup works fine, but operating under the same OS user requires only a single agent install which seems like a good idea.

The first think I did was to stop the existing enterprise server using SM. In a shell I performed a recursive copy of the base directory (/u02/jdedwards/e812 in this case) to /u02/jdedwards/port6015 and /u02/jdedwards/port6016). Back in server manager I created two new instances by registering these new installations with unique instance names.

Using SM I went through and modified all the configuration items that were install specific. I went through each configuration category and looked for those settings that referenced the old install path and updated them accordingly. Off the top of my head I had to change the following settings

• Install Path
• Build Area
• XTS Repository
• JDE and JDEDEBUG log configurations
• jdelog.properties log file configurations
• Compiler and associated locations

There are also some settings that are not install location specific that I knew add to be modified. These include

• The JDENET listen and connect ports (set to 6015 and 6016)
• The IPC Start Key (set to unique, non-overlapping values)

Since these new servers were a copy of an existing install I had to modify some of the startup scripts to use the new install paths. These scripts were located in the SharedScripts folder found underneath the base install. This included changing the paths in

• enterpriseone.sh

If you are on a release earlier than 8.11SP1 (and thus prior to the platform pack installer) the settings are instead contained in the .oneworld located in the user's home location.  Since this single file defines paths that would be different for each enterprise server instance it is better to use multiple OS users in this case.

Finally, since I'd be running these servers under the same OS user I had to modify the RunOneWorld.sh and EndOneWorld.sh scripts to set the variable "MULTIPLE_INSTANCE" to 1. This instructs the scripts to be aware that multiple foundations are running under the same OS user. I made this change for all servers, including the original server used as the source.

Back in SM I tried to start all my new servers. The new servers all failed to start. Looking at the SM logs and a little digging later I realized a problem in the logic in the RunOneWorld.sh script that determines if processes are already running. The script makes a series of calls to the ps application and filters based on OS user and the JDENET port. Since my new installs included the JDENET port in the path (6015 and 6016) it was incorrectly thinking the startup script itself was an existing E1 process and failed start the server. I changed the install locations so they didn't include the 6015 and 6016 values in the path and all worked.

Sidenotes
This is probably not a typical setup but once configured it works very well. There are a few notes I'd like to mention.

First, when performing my initial installation plan I had anticipated these additional ports and defined them initially. This is probably not normal, so one would have to modify their original plan to add the new ports. This creates many of the DB records required for the server such as the F965* tables and the package discovery tables (812 and later).

Secondly one must be aware of the changes made to RunOneworld.sh and EndOneWorld.sh to set the MULTIPLE_INSTANCE=1 line. Since these scripts are delivered with the tools release they will be overwritten with each new tools release I upgrade the servers to. I'll have to go back and modify those.

Although this isn't a true step by step guide to configuring multi-foundation I hope it helps the experienced CNCs with some guidance to configuring this sort of configuration.

INI Madness Tamed!

As many might be aware the task of managing the INI files, used to store the configuration of our server based products, can be difficult at best. Server Manager addresses many of these problems in the following ways:

Complete INIs:
Server Manager provides a web based tools release specific mechanism for editing the configuration files of our server based products. Using Server Manager there should be no reason to manually edit the INI files directly. Server Manager provides a web based view/editing of all the configuration files.

Server Manager utilizes metadata about configuration settings that are delivered with each tools release. To accomplish this we performed many searches over the entire codebase to find every configuration item used. Our policy is: if something is configurable via INI it is configurable via Server Manager. This search resulted in the addition of many, some possibly obscure, configuration settings. It also resulted in the removal of many configuration items that have historically been delivered but are no longer relevant.

For existing enterprise servers that are registered with SM many configuration settings that were present in the JDE.INI that are no longer used will remain in the file, if present, but won't appear using the Server Manager GUI. For our web based servers the INIs are created when the instance is created, so will perfectly match the tools release initially used. If a setting is present in these web based INIs and the server is later upgraded to a release that obsoletes a setting that parameter will still remain in the file, but will no longer be viewable through the management console.

It is, of course, possible that we missed a setting. We did our best, but there are a lot of settings to manage. If a setting was missed and is therefore not available through the management console application it may always be edited directly within the file. All settings not known to SM will be maintained during tools release upgrades/downgrades.

Documentation:
Each configuration item is identified using a short, human readable description. An extended description is provided via the online help and bundled documentation. Default values, where applicable, are provided as reference. Many parameters provide a list of values detailing exactly what is allowed for each setting. For reference the documentation provides the INI filename, section, and entry for each setting.

We've also provided a reference document with the product detailing each setting. As of this writing this is over 350 pages. All the information in the documentation is also available in online help. If you are looking for a particular setting and are having trouble locating it using the new descriptions the documentation allows a quick lookup based on the INI entry details.

This reference documentation is current as of the 8.97 tools release. It will be kept current for all future tools releases. The reference may also be of assistance to earlier tools release but be aware that not all settings will be applicable to the earlier releases.

Relevant INIs:
Another task we undertook was to remove the configuration parameters that are not relevant to the product. Historically the JAS.INI and JDBJ.INI used for web servers were simply duplicated for the other web based products (collaborative portal, transaction server, PIMSync server, and the new business services server). We evaluated these products and removed from their configuration parameters that didn't apply. This means that each server has it's own unique set of configuration parameters. We hope this will reduce confusion in not appearing to require configuring parameters that do not apply to the server.

The transaction server (RTE) also previously contained three separate copies of each configuration file, one for each of the EARs that make up the product. This has been removed and only a single set of configuration files are shared among all the EARs.


There's much more to talk about configuration management in Server Manager: server groups, configuration comparison, and audit history. I hope to post on those topics in the future.

Quick History of Me

Here's a quick background of who I am, why I'm blogging, and what I hope to accomplish here.

I have been with JD Edwards/PeopleSoft/Oracle for almost ten years now. The first three or so years were spent on the support organizations SWAT team flying to customer sites to address specific customer issues and provide technical assistance. Life on the road was great; I traveled to more than twelve countries and countless client sites and really enjoyed the work. It came time to stop traveling so much so I settled down in the Denver area and created the Support Assistant diagnostic product. I'm still very proud of SA, and am glad to say that the product is alive and kicking. More on that later.

After working primarily on SA for five or so years I decided to tip my hat into something new. I wanted to apply my experience from the field and support organizations and create something new. The result is Server Manager. Specifically, I wanted to address

• The difficulty in installing and upgrading our server based products
• The difficulties around configuration management; understanding all the configuration parameters and managing the configuration of servers across an E1 installation
• The difficulty in monitoring the activity of E1 servers
• The difficulty associated with troubleshooting servers when something goes wrong

Hopefully you'll see that Server Manager addresses these and many other administration activities that will truly result in a lower cost of ownership.

As someone unbelievably addicted to blogs, generally of a geeky nature, I've been "inspired" by many others to use this forum to publish tips, tricks, knowledge, and general musings on the product of which I'm so proud. I'm particularly inspired by a blog by a co-worker entitled 'The Buttso Blathers' with very insightful posts on all things OAS (Oracle Application Server).

There is one thing this blog does not represent; it is not a support forum or a place to seek help.  So tune in and learn more about the exciting Server Manager product.

Thanks!

Before digging into the product itself I want to express some thanks to the team that worked on Server Manager. At this point I'll let the involved parties remain anonymous. This was a team effort, and I want to express my personal thanks to the development team and quality assurance team that helped create the product.

So, for all those involved in Server Manager, I say thanks.

Welcome!

Welcome to the blog about the Server Manager product for JD Edwards EnterpriseOne.

I'm starting this blog a little early; the formal announcement of the 8.97 tools release and Server Manager is still months away. That said I wanted to have some content ready when we "flip the switch".

Before I continue let me be clear that the rumblings, opinions, and tips contained within are entirely mine and do not necessarily represent those of my employer, Oracle Inc. That said I hope this blog provides insight and tips that ease the adoption and widespread use of the Server Manager product.

Stay tuned for useful tips, troubleshooting, advice, and all things Server Manager.