Tuesday, November 26, 2013

Peoplesoft on Windows 2012 : Peopletools 8.53 install

After having installed Oracle and middleware on Windows 2012, time for the Peopletools.

Note, Peopletools 8.53 is certified on Windows 2012.
However, as soon as we start the installer, something is going wrong:
PTOOLS853_W2012_TOOLS85300_002
PTOOLS853_W2012_TOOLS85300_003
PTOOLS853_W2012_TOOLS85300_004
It does not seem to like the user interface working onto Windows 2012. As far as I remember of my previous installation on Windows 2008, there was no such problem.
So, the only work around is the use of command line, enforcing the console mode:
PTOOLS853_W2012_TOOLS85300_005
As of now, it will follow all the steps you can already see when installing Peopletools onto a Unix/Linux server :
PTOOLS853_W2012_TOOLS85300_006
PTOOLS853_W2012_TOOLS85300_008
PTOOLS853_W2012_TOOLS85300_010
PTOOLS853_W2012_TOOLS85300_012
PTOOLS853_W2012_TOOLS85300_013
Surprisingly, in the end of the process a reboot is triggered.   I wouldn’t expect this to happen ! Especially without notice. 
PTOOLS853_W2012_TOOLS85300_020 

The Peopletools 8.53 patch 4 does not have such problems as described above.
The GUI works perfectly fine, and it does not reboot the server in the end:
PTOOLS853_W2012_TOOLS85304_001
PTOOLS853_W2012_TOOLS85304_002
PTOOLS853_W2012_TOOLS85304_003
<…snipped…>
PTOOLS853_W2012_TOOLS85304_014   

And finally, the psadmin menu:
PTOOLS853_W2012_TOOLS85304_015

And if I change the settings for PS_CFG_ HOME:

PTOOLS853_W2012_TOOLS85304_017
PTOOLS853_W2012_TOOLS85304_018
PTOOLS853_W2012_TOOLS85304_019
PTOOLS853_W2012_TOOLS85304_020
PTOOLS853_W2012_TOOLS85304_021     

Nicolas.

Wednesday, November 13, 2013

How to shutdown Peoplesoft OVA after init

The Peoplesoft team continues to provide the PUM images on schedule. Great work. The last image HCM 9.2.003 has been released about two-three weeks ago.
I’m still using VMWare ESXi vSphere Hypervisor 5.1 and my workaround to move these OVA to VMWare is still working fine, find out more about this workaround I wrote about few months ago here.

There’re few changes though. The number of updates required in the ovf file have been dramatically dropped down. Right now, we’ve only have two parts to modify:
From
<     <OperatingSystemSection ovf:id="109">
<       <Description>Oracle_64</Description>
<       <vbox:OSType ovf:required="false">Oracle_64</vbox:OSType>
To
>     <OperatingSystemSection ovf:id="101">
>       <Description>oracleLinux64Guest</Description>
>       <vbox:OSType ovf:required="false">oracleLinux64Guest</vbox:OSType>
And From
<         <vssd:VirtualSystemType>virtualbox-2.2</vssd:VirtualSystemType>
To
>         <vssd:VirtualSystemType>vmx-07</vssd:VirtualSystemType>
Apart from that, other changes in the file are no longer necessary.
Note that the sound card tag is not there anymore as many of the others which caused incompatibilities with VMWare.

Then I deployed the OVA with ovftool (the link points to the latest version 3.5, but I’m still using the previous version 3.0.1, it probably does not make any difference for this case):
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCMDB-85307-PI003_OVA]# ls -la
total 16223832
drwxrwxrwx 2 root root       4096 Nov  8 13:16 .
drwxrwxrwx 7 root root       4096 Oct 31 15:13 ..
-rw------- 1 root root 1235787776 Oct 10 11:36 HCMDB-853-07-disk1.vmdk
-rw------- 1 root root 2931841536 Oct 10 11:39 HCMDB-853-07-disk2.vmdk
-rw------- 1 root root 4845944320 Oct 10 11:46 HCMDB-853-07-disk3.vmdk
-rw------- 1 root root 7583338496 Oct 10 11:54 HCMDB-853-07-disk4.vmdk
-rw------- 1 root root      13757 Nov  8 09:37 HCMDB-853-07.ovf
-rw------- 1 root root      13747 Nov  7 08:32 HCMDB-853-07.ovf.orig
-rw-r--r-- 1 root root        103 Nov  8 12:03 .ovftool
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCMDB-85307-PI003_OVA]# more .ovftool
lax
datastore=vm
skipManifestCheck
overwrite
powerOffTarget
net:HostOnly=VM Network 2
name=HCM92003
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCMDB-85307-PI003_OVA]# ovftool HCMDB-853-07.ovf vi://root:<mypwd>@192.168.1.10:443
Opening OVF source: HCMDB-853-07.ovf
Opening VI target: vi://root@192.168.1.10:443/
Deploying to VI: vi://root@192.168.1.10:443/
Transfer Completed
Completed successfully
[root@omsa:/nfs/software/PeopleSoftCD/OVA/HCMDB-85307-PI003_OVA]#

Of course, if you’re working on VirtualBox you don’t have any of these above problems.

And finally booting the VM from the console works like a charm:
HCM92003_boot_002

In the end of this boot, and as expected, we are prompted for the Terms of Use, root password, network properties, database name…
HCM92003_boot_003

HCM92003_boot_005 
etc.
Then, last screen, the setup is completed. We are now ready to go to the front-end:
HCM92003_boot_006
Note that all these actions above are done from within the console, you don’t actually have other choice for the configuration (vm-template init script triggered on 1st VM’s boot).
!!! For the sake of my article I deliberately leave the console like this, not touching the keyboard anymore from here, do not press any key !!!

We can really appreciate all the effort done by the Peoplesoft team. It has never been simpler to deploy a working environment. Now, login page:
HCM92003_boot_007
HCM92003_boot_008
So far, so good. All works as expected.

Now the heck, and I’m coming on the subject of the article.

Not long after setting up this new VM, I wanted to shutdown my host server for some maintenance reason. I have had to shutdown this VM first. How to do it ? Should I go to the console ? Or can I do it through putty (I know the IP, so why not) ?

CASE 1: shutting down the VM when connected through Putty
Note that at this very moment the console is still pending with the message (Will continue in 1800 seconds…) whilst I’m shutting down the VM as root connected to the VM through Putty (most of the time I don’t use the console to work on the VM):
HCM92003_boot_010
Now nothing wrong to want to restart the VM. Let’s see:
HCM92003_boot_011 
And here we go to the nowhere:
HCM92003_boot_012
For some reason, we are going to reinit the VM ! What’s the heck ?!?!? I don’t even want do go any further, I’m too scared about the VM stability now.
For the record, here are the last lines of /var/log/oraclevm-template.log
[LOG]  Nov 12 09:12:04 S96psft-abw: Started PIA Domain peoplesoft
[LOG]  Nov 12 09:12:04 oraclevm-template: ==> 2013-11-12 09:12:04: oraclevm-template --config <==
[LOG]  Nov 12 09:12:04 oraclevm-template: Running oraclevm-template --config
[LOG]  Nov 12 09:12:04 oraclevm-template: Loading parameters from config file: /etc/sysconfig/oraclevm-template
[LOG]  Nov 12 09:12:04 oraclevm-template: Reconfiguring OS
[INFO] Nov 12 09:12:06 oraclevm-template: Regenerating SSH host keys.
[LOG]  Nov 12 09:12:08 oraclevm-template: calling /opt/oracle/psft/vm/oraclevm-template.sh
[LOG]  Nov 12 09:12:08 oraclevm-template.sh: Creating Virtual Environment. Date: Tue Nov 12 09:12:08 UTC 2013

We can really see that the configuration is recalled…
And before rebooting:
[root@hcm92003 ~]# more /etc/sysconfig/oraclevm-template
#
# Template configuration
#

#
# Allow configuration of the template when the service is enabled
#
RUN_TEMPLATE_CONF=YES

According to this, this is very logic that it returns to a pre-config state.

CASE 2: shutting down the VM when connected through the VM console
Restarting from scratch, but now instead of going to shutdown the VM with Putty, we do that from within the VM console itself. Let’s see how it is behave.
HCM92003_boot_014  
On that screen which was still pending for the 1800 seconds, I finally press a key (actually “Enter”). Please note the message “Template configuration disabled”, I’m sure it plays a role somewhere.
Now restarting the same VM:
HCM92003_boot_015 
Much better, now everything looks to work fine, and actually does:
HCM92003_boot_016
As of now, no matter how/where we are shutting down the VM, it will always work.
And the log file is pretty clear, all looks ok now:

[LOG]  Nov 12 08:56:52 oraclevm-template: ==> 2013-11-12 08:56:51: oraclevm-template --disable <==
[LOG]  Nov 12 08:56:52 oraclevm-template: Running oraclevm-template --disable
[LOG]  Nov 12 08:56:53 oraclevm-template: Changed RUN_TEMPLATE_CONF=NO in /etc/sysconfig/oraclevm-template
[INFO] Nov 12 08:56:53 oraclevm-template: Template configuration disabled.

And the config file:
[root@hcm92003 log]# more /etc/sysconfig/oraclevm-template
#
# Template configuration
#

#
# Allow configuration of the template when the service is enabled
#
RUN_TEMPLATE_CONF=NO
This time, no doubt, it won’t reconfigure the VM.

HOW DOES IT ALL WORK ?
After a little digging on oraclevm-template scripts triggered on the boot, I think I found why this behavior.
In order to understand, I’ll try to go step by step:

1. In the very beginning, the first script to be called on the VM boot is /etc/rc.d/init.d/oraclevm-template.
In this script, we can see a configuration file CONFFILE=/etc/sysconfig/oraclevm-template… the same as shown above, which contains whether the VM has to be set or not (RUN_TEMPLATE_CONF=YES).
If the VM has to be configured, it calls an other script with the flag “-config”, as following: “/usr/sbin/oraclevm-template –config”. And eventually disable the template, calling the same script with the flag “–disable” which set RUN_TEMPLATE_CONF=NO.
Here we go (just an extract):
CONFFILE=/etc/sysconfig/oraclevm-template
...
                . $CONFFILE
                case "$RUN_TEMPLATE_CONF" in
                    YES|yes|Yes|1)
                        doconfig=1
...
        if [ $forceconfig -eq 1 ] || [ $doconfig -eq 1 ]; then
               /usr/sbin/oraclevm-template --config
                ret=$?
...
            # Just disable no matter firstboot reconfig succeeds or not.
            /usr/sbin/oraclevm-template –disable

2. If the VM has to be configured (RUN_TEMPLATE_CONF=YES), we can see that the script /usr/sbin/oraclevm-template is launched with flag “config”. A function is called, “do_config”. It goes through every single step to initialize the VM, including a call an other script /opt/oracle/psft/vm/oraclevm-template.sh which will run all the necessary.
When this script /usr/sbin/oraclevm-template is called with config flag, it is ending by running the function “ovm_press_anykey 1800”.

3. This last function can be found in /usr/lib/oraclevm-template/functions:
function ovm_press_anykey
{
    local to=0
    [ -n "$1" ] && to=$1 || to=$DEFAULT_TIMEOUT
    echo
    stty -echo
    if [ $to -eq 0 ]; then
      read -n 1 -p "Press any key to continue..."
    else
      read -t $to -n 1 -p "Will continue in $to seconds, or press any key to continue..."
    fi
    echo
    stty echo
}
We find here the last message when the console is pending as I showed in the screenshots above.

To make it short: in the end of the first VM configuration, it will wait for 1800 seconds or that a key is pressed (step 3, function ovm_press_anykey) to continue (step 2, exit from the script /usr/sbin/oraclevm-template)  and do so to disable the template (step 1, /etc/rc.d/init.d/oraclevm-template) with the command “/usr/sbin/oraclevm-template –disable”…
If you don’t press enter or do not wait for 1800 seconds before doing a shutdown from outside the console, then the template is never going to be disabled…

CONCLUSION:
To my point of view, it’s a mistake. This is a template deployment script bug. It should turn RUN_TEMPLATE_CONF to NO as soon as we finished the configuration as stated in the console screen “The setup of the Peoplesoft Virtual Machine is completed” and not after we press a key or wait for 1800 seconds… Probably not an easy fix though since a lot interaction between different scripts is involved here.
Maybe disabling the template immediately after configuration would be the simplest way ? At the step 2, the “config” function should trigger the “disable” function (as it does at step 1) before any pending action.

What should we do now ?
Awaiting a fix, after the very first boot and configuration of the VM, always, always press enter from within the console !!! No matter what you will do later on, press a key ! Then and only then, you can close the console.

Thanks and enjoy the appliances !

Nicolas.

Monday, September 23, 2013

Peoplesoft report re-send content

Deploying the latest Peoplesoft image (HCM92002, Peopletools 8.53.06), and you’ll see a lot of reports not posted:
HCM92002_016
Well, fine, they’re probably not that important, but it can be fixed quite easily especially since they are not posted for one single reason, the process scheduler was started before the PIA during the deployment.

More generally, if you have a bunch of reports which have a non-posted content for a problem you fixed, you may want to avoid to go in every single process just to click “re-send Content” as below:
HCM92002_017 

Going to all and every process is tedious, so let’s try to do it with back-end statements.

First, what this “Re-send Content” is doing ? Set the AppServer in trace mode (Trace SQL=7), and we’ll see all what we need to know:
<…>
PSAPPSRV.12845 (17)      1-1286   12.04.39    0.000045 Cur#2.12845.HR92DM02 RC=0 Dur=0.000018 COM Stmt=UPDATE PSPRCSRQST SET DISTSTATUS = :1 WHERE PRCSINSTANCE = :2
PSAPPSRV.12845 (17)      1-1287   12.04.39    0.000005 Cur#2.12845.HR92DM02 RC=0 Dur=0.000000 Bind-1 type=2 length=1 value=7
PSAPPSRV.12845 (17)      1-1288   12.04.39    0.000003 Cur#2.12845.HR92DM02 RC=0 Dur=0.000000 Bind-2 type=8 length=4 value=2563
PSAPPSRV.12845 (17)      1-1289   12.04.39    0.000879 Cur#2.12845.HR92DM02 RC=0 Dur=0.000019 COM Stmt=UPDATE PSPRCSQUE SET DISTSTATUS = :1 WHERE PRCSINSTANCE = :2
PSAPPSRV.12845 (17)      1-1290   12.04.39    0.000005 Cur#2.12845.HR92DM02 RC=0 Dur=0.000001 Bind-1 type=2 length=1 value=7
PSAPPSRV.12845 (17)      1-1291   12.04.39    0.000003 Cur#2.12845.HR92DM02 RC=0 Dur=0.000000 Bind-2 type=8 length=4 value=2563
PSAPPSRV.12845 (17)      1-1292   12.04.39    0.000321 Cur#2.12845.HR92DM02 RC=0 Dur=0.000022 COM Stmt=UPDATE PS_CDM_LIST SET DISTSTATUS = '8',TRANSFERINSTANCE = 0 WHERE PRCSINSTANCE = :1 AND DISTSTATUS NOT in ('5', '9')
PSAPPSRV.12845 (17)      1-1293   12.04.39    0.000004 Cur#2.12845.HR92DM02 RC=0 Dur=0.000001 Bind-1 type=8 length=4 value=2563
PSAPPSRV.12845 (17)      1-1294   12.04.39    0.010821 Cur#2.12845.HR92DM02 RC=0 Dur=0.009838 Commit
PSAPPSRV.12845 (17)      1-1295   12.04.39    0.000032 Cur#2.12845.HR92DM02 RC=0 Dur=0.000020 Disconnect
PSAPPSRV.12845 (17)      1-1296   12.04.39    0.000819 Cur#1.12845.HR92DM02 RC=0 Dur=0.000000 Commit
PSAPPSRV.12845 (17)      1-1297   12.04.39    0.000007 Cur#1.12845.HR92DM02 RC=0 Dur=0.000004 Disconnect
PSAPPSRV.12845 (17)      1-1298   12.04.39    0.004512 Cur#1.12845.notSamTran RC=0 Dur=0.000033 Open Cursor Handle=0000000002429BE0
<…>

Actually 3 tables are involved: PSPRCSRQST, PSPRCSQUE and PS_CDM_LIST. We just have to update them properly as indicated in the trace file above to make the process scheduler a try to repost.

From the given below screenshot, 9 reports are not posted:
HCM92002_027 

And from the back-end, the same:
SQL> select PRCSINSTANCE from PSPRCSQUE where DISTSTATUS=4 order by 1 desc;

PRCSINSTANCE
------------
        2561
        2560
        2559
        2558
        2557
        2556
        2550
        2549
        2548

9 rows selected.

SQL> select PRCSINSTANCE from PS_CDM_LIST where DISTSTATUS NOT in ('5', '9');

PRCSINSTANCE
------------
        2548
        2550
        2549
        2556
        2557
        2558
        2559
        2560
        2561

9 rows selected.

SQL> select PRCSINSTANCE from PS_CDM_LIST where DISTSTATUS NOT in ('5', '9') order by 1 desc;

PRCSINSTANCE
------------
        2561
        2560
        2559
        2558
        2557
        2556
        2550
        2549
        2548

9 rows selected.

SQL>

Then update these tables:
SQL> UPDATE PSPRCSRQST SET DISTSTATUS = 7 where DISTSTATUS=4 ;

9 rows updated.

SQL> UPDATE PSPRCSQUE SET DISTSTATUS = 7 WHERE DISTSTATUS=4 ;

9 rows updated.

SQL> UPDATE PS_CDM_LIST SET DISTSTATUS = '8',TRANSFERINSTANCE = 0 WHERE DISTSTATUS NOT in ('5', '9');

9 rows updated.

SQL> commit;

Commit complete.

SQL>

And finally, from the front-end, all are now “posted”:

HCM92002_028

And the reports are all reachable:
HCM92002_029
HCM92002_030
HCM92002_031

Of course, it won’t solve a posting problem if there is, it just tries to repost. But in such a case, useful to keep it in mind.

Nicolas.

Friday, September 20, 2013

Oracle Listener details on Peoplesoft Demo Image

If you ever wonder how to reach the databases hosted on a Peoplesoft Demo Images from a remote client…
Here from within the Image FSCM92000 (FSCMDB-SES-85302d).

For some reason, the listener has not been configured on the default and standard port 1521. The listener port is 1522 (listener name is listener1).
Moreover, whether you can choose the name of the database during the VM deployment, the service name is always appended with .us.oracle.com.
You should keep in mind those two things for your remote client connection.

[oracle@fscm92000 ~]$ export ORACLE_SID=EP92DM00
[oracle@fscm92000 ~]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.3.0 Production on Fri Sep 20 11:11:50 2013

Copyright (c) 1982, 2011, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning and Oracle Label Security options

SQL> show parameter local_listener
NAME            TYPE     VALUE
--------------- -------- -----------------------------------------------------------------
local_listener  string   (ADDRESS = (PROTOCOL=TCP)(HOST=fscm92000.phoenix.nga)(PORT=1522))
SQL> quit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning and Oracle Label Security options

[oracle@fscm92000 ~]$ lsnrctl status listener1

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 20-SEP-2013 11:12:27

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=fscm92000.phoenix.nga)(PORT=1522)))
STATUS of the LISTENER
------------------------
Alias                     listener1
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date                20-SEP-2013 10:47:53
Uptime                    0 days 0 hr. 24 min. 34 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/11.2.0.x/db_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/product/11.2.0.x/db_1/log/diag/tnslsnr/fscm92000/listener1/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=fscm92000.phoenix.nga)(PORT=1522)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1522)))
Services Summary...
Service "EP92DM00.us.oracle.com" has 1 instance(s).
  Instance "EP92DM00", status READY, has 1 handler(s) for this service...
Service "XDB.us.oracle.com" has 1 instance(s).
  Instance "EP92DM00", status READY, has 1 handler(s) for this service...
The command completed successfully
[oracle@fscm92000 ~]$

In the end, your client tnsnames.ora file should look like this:
EP92DM00 =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.1.21)(PORT = 1522))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = EP92DM00.us.oracle.com)
    )
  )

Just a little annoying but need to be kept it in mind.

Nicolas.

Addendum (23-Sept 2013):
Note there’s no consistency across images versions, for instance, the last one for HCM (HCM92002) has an other listener name, but still on port 1522:
[oracle@hcm92002 ~]$ cd $ORACLE_HOME/network/admin/
[oracle@hcm92002 admin]$ more listener.ora
# listener.ora Network Configuration File: /u01/app/oracle/product/11.2.0.x/db_1/network/admin/listener.ora
# Generated by Oracle configuration tools.

psft_listener =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = hcm92002.phoenix.nga)(PORT = 1522))
      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1522))
    )
  )

[oracle@hcm92002 admin]$ lsnrctl status psft_listener

LSNRCTL for Linux: Version 11.2.0.3.0 - Production on 23-SEP-2013 11:11:49

Copyright (c) 1991, 2011, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=hcm92002.phoenix.nga)(PORT=1522)))
STATUS of the LISTENER
------------------------
Alias                     psft_listener
Version                   TNSLSNR for Linux: Version 11.2.0.3.0 - Production
Start Date                23-SEP-2013 08:30:21
Uptime                    0 days 2 hr. 41 min. 28 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /u01/app/oracle/product/11.2.0.x/db_1/network/admin/listener.ora
Listener Log File         /u01/app/oracle/product/11.2.0.x/db_1/log/diag/tnslsnr/hcm92002/psft_listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=hcm92002.phoenix.nga)(PORT=1522)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1522)))
Services Summary...
Service "HR92DM02.us.oracle.com" has 1 instance(s).
  Instance "HR92DM02", status READY, has 1 handler(s) for this service...
Service "XDB.us.oracle.com" has 1 instance(s).
  Instance "HR92DM02", status READY, has 1 handler(s) for this service...
The command completed successfully
[oracle@hcm92002 admin]$

Thursday, August 29, 2013

Peoplesoft on Windows 2012 : Middleware

After installing Windows 2012 and Oracle database software, time to move on with Peoplesoft software.
Note that Peopletools 8.53 is now certified on Windows 2012 (check the certification matrix on My Oracle Support).

Before hands, we’ll first install the required software JDK, Tuxedo and Weblogic.

1. JDK
I downloaded the one available on edelivery, Oracle JDK 7 Update 9 for Microsoft Windows x64 (64-bit), part number V35015-01. After unzipping the file, run it. Nothing special here, straight forward, click, click and click. Done. Here we go:
PTOOLS853_W2012_JDK_001
PTOOLS853_W2012_JDK_002
PTOOLS853_W2012_JDK_003
PTOOLS853_W2012_JDK_004
PTOOLS853_W2012_JDK_005
PTOOLS853_W2012_JDK_006
Nothing is required for the JDK, no patch to apply afterwards.     

2. Weblogic
I download the software from edelivery, Oracle WebLogic Server 11gR1 (10.3.6) Generic and Coherence, part number V29856-01.
Now the install, straing from the command line (despite we can see “Powershell windows, I ran a “cmd” first):
PTOOLS853_W2012_WEB_001
Except this command line we should take care of, it’s again a “click'” installation:
PTOOLS853_W2012_WEB_002
PTOOLS853_W2012_WEB_003
The directory I specified is not empty because it is also used for Tuxedo and JDK binaries, nothing wrong to continue:
PTOOLS853_W2012_WEB_004
Again this uninformed question:
PTOOLS853_W2012_WEB_005
PTOOLS853_W2012_WEB_006
PTOOLS853_W2012_WEB_007
The installer retrieve the JDK binaries by itself:
PTOOLS853_W2012_WEB_008
PTOOLS853_W2012_WEB_009
PTOOLS853_W2012_WEB_010
PTOOLS853_W2012_WEB_011
PTOOLS853_W2012_WEB_012

3. Tuxedo
Last part of the middleware, Tuxedo.
Again, I download the software available on edelivery, Oracle Tuxedo 11gR1 (11.1.1.2.0) for Microsoft Windows Server 2008 (64-bit) with MS Visual Studio 2010, part number V28471-01. And again, there’s nothing special here, straight foward:

PTOOLS853_W2012_TUX_001
PTOOLS853_W2012_TUX_002
PTOOLS853_W2012_TUX_003
Choose the full install:
PTOOLS853_W2012_TUX_004
PTOOLS853_W2012_TUX_005
PTOOLS853_W2012_TUX_006
PTOOLS853_W2012_TUX_007
PTOOLS853_W2012_TUX_008
PTOOLS853_W2012_TUX_009
PTOOLS853_W2012_TUX_010
PTOOLS853_W2012_TUX_011
PTOOLS853_W2012_TUX_012
PTOOLS853_W2012_TUX_013
Now, we can check the Tuxedo group installed:
PTOOLS853_W2012_TUX_014        
   

That’s it. Nothing really exciting here, but mandatory steps anyway in order to use Peoplesoft. Note that there’s no big change (none?) from the previous version, and Windows 2012 does not cause any troubles.

Next step, the Peopletools.

Nicolas.