Server Manager 9.1 Upgrade

jdel6654

VIP Member
I tried to install SM 9.1 console today. I am not sure if this has been a problem for others, but it seems like each new SM console install is a little more painful than the previous.

1. SM Console 9.1 Update file is downloadable from Update Center but not EDelivery. I think the reason may be because the update doesn't work. It looks like SM update is either a patch to 9.1 or wasn't designed to upgrade SM 8.98.x. When I attempted to "update" SM console, I get an error saying I have to do the full install with "the upgrade option" specified.

2. The full SM console is about 1.7 GB so it will take some time to download. The first time I downloaded it, my session expired after a few hours.

Curious to know others' experiences.
 
[ QUOTE ]

1. SM Console 9.1 Update file is downloadable from Update Center but not EDelivery. I think the reason may be because the update doesn't work. It looks like SM update is either a patch to 9.1 or wasn't designed to upgrade SM 8.98.x. When I attempted to "update" SM console, I get an error saying I have to do the full install with "the upgrade option" specified.

Curious to know others' experiences.

[/ QUOTE ]

We ran into that gotcha as well. Here is the trick. Choose the full install option. (yes scary) When it starts to run, it will recognize that you have an exisiting instance and then give you the option to upgrade it. We pointed out to Oracle that they should update their documentation to reflect that.


- Gregg
 
Just a follow-on comment.

This new version of the Server Manager guide does not appear to be available from within My Oracle Support. I searched forever looking for it. I found it on the standard oracle.com/documentation pages. Go figure.
 
The whole server manager installation reminds me of kamchatka dolls. Every time I think everything is installed, there is some smaller subordinate installation or process to run.

My Server Manager console upgrade is complete. Now the agents. In deploying the agents, you run the agent installer from Windows and it creates a totally new, can't-be-specified folder into the AS400 IFS. It also creates a similarly-named folder into onto my Windows drive. There is now a new instance of my enterprise server in the SM console with a 2nd JDE_HOME.

On the other hand it doesn't because now when I look at the SM agent for my AS400 it says "Agent Update Required". When I run that it doesnt work.

What happened to the simple update solution on the SM agent that worked fine before. Also, it looks as though I will need a 64-bit Java 1.6 installation on my AS400 too.

...oy vay.
 
I understand your pain. The requirement, for 9.1.0.0, to get the full installer to "Upgrade" is necessary because there is an uptake of technology. The underlying OC4J container and JDK are now replaced during the "Upgrade". The container is now 10.1.3.5 and JDK 1.6. Because of this uptake the self update as before will not be possible. So an external process, the installer, must be used.

The process going forward, until another uptake or change to technology is done, will be the same "Update" (Change Component) methodology.

The update of the agent should not be different, the console will issue an update of the code for the agent and update the jdk as a part of that process. If that is not working, a bug should be entered for that.

Hope that helps clarify why this pain is necessary at this release level.
 
One additional note is the agent update for the iSeries, as you know, is different and does not update the jdk. It does require there be a 1.6 version to use on the system. The new script file will point to the 1.6 expected location.
 
Yeah, I got the docs and I get the complexity. That hasnt changed since E1/OW was introduced. Its the messy delivery of 9.1 on Server Manager that I am hung up with. In addition to the other points I have already made:

1. Why isn't the updated SM guide indexed into support.oracle.com? Search for it and you won't find it.

2. The update function on the agent does not work - it doesn't update anything. The only option is to install another SM Agent instance.

3. The upgrade process of SM now requires 2 jde_home directories to be retained. Kind of a maintenance mess.

4. The new OUI processes seem to complify the simple and elegant SM install programs.

If Oracle / JDE wants SM to be the entry point for deploying JDE, they seem to have take a couple of steps backward on the delivery with 9.1
 
I downloaded 9.1.0.0-Deployment-Server_06_99 and now I have to update my E1 9.00 deployment server with TR 9.1.
Which are correct steps?
gg
 
Luigi,

To the best of my knowledge the dep server installation process hasn't changed.

1. Backup
1a. x:\JDEdwards\E900\system
1b. x:\JDEdwards\E900\systemcomp
1c. x:\JDEdwards\E900\OneWorld Client Install
1d. x:\Windows\jde.ini

2. Rename the .par file to .zip.

3. Extract the zip.

4. Run X:\9.1.0.0-Deployment-Server_06_99\Disk 1\ToolsRelease\install\setup.exe

5. Install the co-requisite ESUs for Planner & Tools
 
[ QUOTE ]
Luigi,

To the best of my knowledge the dep server installation process hasn't changed.

1. Backup
1a. x:\JDEdwards\E900\system
1b. x:\JDEdwards\E900\systemcomp
1c. x:\JDEdwards\E900\OneWorld Client Install
1d. x:\Windows\jde.ini

2. Rename the .par file to .zip.

3. Extract the zip.

4. Run X:\9.1.0.0-Deployment-Server_06_99\Disk 1\ToolsRelease\install\setup.exe

5. Install the co-requisite ESUs for Planner & Tools

[/ QUOTE ]

Thanks, only a doubt. When you run setup, it asks home directory. Here I must specify my deployment home folder (for example d:\JDEdwards\E900). Correct?
 
Looks like there may be something new. From the guide:

"

Each Oracle product that is installed on a machine is installed into what is termed an
Oracle Home directory or path. This is a directory that contains most of the files
associated with the product. This path has a name as well. You can specify a name that
is intuitive so you do not have to remember the path.
When you install the Oracle Enterprise Edition (OEE) database engine on the
Deployment Server, by default the Oracle Home path will be:
c:\Oracle\E1Local
The value E1Local cannot be changed, but you may specify another drive and/or
directory instead of c:\Oracle. The Oracle Home name for the OEE database is
E1Local.
When you install the JD Edwards EnterpriseOne Deployment Server, you specify an
Oracle Home and name for that installation as well. For example, you may enter
C:\JDEdwards\E900 as the Oracle Home path and JDE_DEP900_HOME as the
Oracle Home name.
Following the above examples, you would now have two Oracle Homes:
1. The first Oracle Home is the Oracle Home of the database; it has these properties:
a. Oracle Home Path
C:\Oracle\E1Local
b. Oracle Home Name
E1Local
2. The second Oracle Home is the Oracle Home of the Deployment Server; it has
these properties:
a. Oracle Home Path
C:\JDEdwards\E900
b. Oracle Home Name
JDE_DEP900_HOME


"






You might want to read this guide:

http://docs.oracle.com/cd/E24902_01/doc.91/e18836.pdf
 
Hi All,

I'm travelling down the TR 9.1 road and it seems to be filled with nasty gremlins.

As discussed in the thread, the SM upgrade installs a second directory. I would have expected it to incorporate into the existing installation directories. The same applies to the IBM i. This creates two SM agents within Server Manager running on the one IBM i. I went ahead and migrated all the components from the old agent to the new agent (probably not the best thing to do if you have a truck full of registered targets) and then uninstalled the old agent. So far so good. I'm running this on the development IBM i.

The next gremlin is the deployment server. As jdel6654 pointed out above, the installer wants a Oracle Home Path. Assuming that I have the Deployment software installed on D:\JDEdwards\E900, when I try and run the installer and point to that location, the installer tells me that the directory is not empty and that it recommends that an empty directory be used but I can go ahead with the installation. The SM manual cautions one not to use the existing installation directory whereas there is no such caution in the Deployment manual.

Could you please verify that I am understanding it correctly and can go ahead with the existing installation directory?

Thank you in advance for your assistance.

Kind regards,
Misael

Currently testing on E9, TR 8.98.4.5, IBM i V6R1 WAS 7.0
 
Tools 9.1 Documentation

Changed the Subject on this post to make it easier to find.

All the new docs are available here:

http://docs.oracle.com/cd/E24705_01/index.htm
http://docs.oracle.com/cd/E24902_01/index.htm

Specifically you need the following:

Deployment Server Reference Guide for Microsoft Windows Enterprise Systems
Tools Release 9.1 and Applications Release 9.0
E18836-01
http://docs.oracle.com/cd/E24902_01/doc.91/e18836.pdf


You also need:

JD Edwards EnterpriseOne Tools
Server Manager Guide
Release 9.1
E18837-01
http://docs.oracle.com/cd/E24902_01/doc.91/e18837.pdf
 
Tools 9.1 Hints

1. If you are upgrading from a previous tools release to 9.1.X then you DO NOT need to reinstall the SM Agents. Simply update the SM Console and use the normal "Update" two lcikcs to update the agents. If this does not work then something else is incorrect. So overall you do not need a 2nd redundant Oracle HOME which for a net new is required and seems to defeat the purpose of a "Universal Installer".

2. I don't do the updates for the SM console. I just simply stop the services, back it up and reinstall right on top of it. The SM Console doesn't have any important config data and all the config is rediscovered from the actual agents once the SM Console restarts. After the install just copy back the one or 2 SM COnsole config files, JDBC drives BEFORE you do the "Run Once" wizard and you'll avoid the numerous prompts (a service restart is needed after the JDBC drives are put in place. You'll have an extra Windows services for the new and old SM consoles but simply disable the old one or delete it from the registry.

So my Oracle Home from the SM Console is X:\jde_home (screw the empty directory warnings).

3. I have posted links to all the 9.1 Updated documentation already

4. Deployment Server process is similar. Since you are updating much more than a tools release a backup of the planner path code would be recommended in addition to SYSTEM, SYSTEMCOMP, ONEWORLD CLIENT INSTALL

5. Kill the '_1' at the end of everything. I did and now I'm just using standard JDE directory names for EVERYTHING

6. Deployment Server Installl was no problem. Some files were not cleaned up in the ONEWORLD CLIENT INSTALL directory but my Oracle Home for this is X:\JDedwards\E900. (screw the empty directory warnings).

The InstallManager.htm needed for the CLIENT installs was missing some key sample lines. I thankfully was on the Beta for Tools 9.1 so grabbed it from there.

Now since the 'extra" files were not cleaned up I decided to install a client using the OLD JDE installed and.............well works no problem so no worries if you can't or don't want to get the new OUI installer working.

I have both working quite fine. Actually the original InstallManger.htm file that wasn't updated pointed to the old installer so by simply swapping these out you can switch between installers.

****************************************************************

So overall I was able to update 1 AS400 Enterprise Server (V7R1) with 5 Web Instances (AS400 V7R1, WAS 7.0.11) and 3 WEBDEV clients (Windows 7-64) to Tools 9.1, Planner ESU, Tools 9.1 Baseline, Tools 9.1 ASI, plus 250+ additioanl fix current ESUs to 5 path codes in 2 days (additional fix current ESUs special instructions still outstanding).

I'm doing this at a client who is not live and migrating from World A73 to E1 9.0 and was running 8.98.4.5 so I can simply ram this in.

So overall I'd look at this as much simplier than moving from pre-8.97 to post-8.97.

Colin
 
Re: Tools 9.1 Hints

Colin,

Re:
"
1. If you are upgrading from a previous tools release to 9.1.X then you DO NOT need to reinstall the SM Agents. Simply update the SM Console and use the normal "Update" two lcikcs to update the agents. If this does not work then something else is incorrect. So overall you do not need a 2nd redundant Oracle HOME which for a net new is required and seems to defeat the purpose of a "Universal Installer".
"
--Why would Oracle bother to release a new SM Agent if they didn't want you to install it? Have you looked at the folder structure behind the new agent? The agent folder contents are substantially different. I would not recommend going down this path.
--Updating the agent thru SM console does not work. Since you've decided not to install it, can we infer that you haven't actually done this yourself?

Re:
"

2. I don't do the updates for the SM console. I just simply stop the services, back it up and reinstall right on top of it. The SM Console doesn't have any important config data and all the config is rediscovered from the actual agents once the SM Console restarts. After the install just copy back the one or 2 SM COnsole config files, JDBC drives BEFORE you do the "Run Once" wizard and you'll avoid the numerous prompts (a service restart is needed after the JDBC drives are put in place. You'll have an extra Windows services for the new and old SM consoles but simply disable the old one or delete it from the registry.
"
--What's the point of having Oracle documentation of the "upgrade" of SM if it is completely invalid. I agree that the second home may be unnecessary, why should we all go rogue if Oracle doesn't get their own installation documented correctly? I don't think we should be freestyling an installation because of inaccurate Oracle support documents. Oracle should put out reliable documentation.

I doubt anyone has had any major problems with the deployment server binaries installation.

One other thing I have noticed that the new JAS web dev features are not updated properly in the features table. Another thing that has been a recurring problem with Tools updates.
 
Yeah, I think we all got that...

Perhaps you could open an SR with Oracle and encourage them to index those documents into support.oracle.com (?).
 
Back
Top