I have a site setup that requires SSL in order to show all the functionality of my demo PeopleSoft environments.  However, I have several other requirements for SSL, so I have a WildCard SSL certificate.

According to PeopleSoft wildcard certificates are unsupported however, I have had no problem using them with Weblogic 10.3.0.1 or higher.  I have not tried it with earlier versions, but I really don’t see why they wouldn’t work.

On my first environment I create a CSR (Certificate Signing Request) using the pskeymanager tool.  Next I submit that CSR into my provider (in my case GoDaddy), and I generate a signed certificate which I import using the pskeymanager tool.

Next I go into the console and turn the SSL on and set it to use the custom identity custom trust settings and enter the alias and my vault passwords.  After committing the changes the certificate should be working correctly.

On my next system I install my PIA as per normal, but before I start things up, I copy the pskey file from server 1 to server 2.  This file is located in the <webserver_home>/<domain>/piaconfig/keystore folder.  Now I start the server up and go into the console and setup the SSL exactly the same as I did on server 1.

I have not found a clean way to export the signed certificate out of one vault and import it into a second vault.  But this procedure works like a charm.

I was reading case notes earlier today and found this note:  638613.1 which explains how PeopleSoft gets datetime.

Prior to PeopleTools 8.46 we had an issue with the way %DateTime retrieved the datetime value. The information below is not a direct solution to the behavior described above. This is an explanation of how the
%DateTime function worked prior to PeopleTools 8.46, and how/why it was changed.

When the Process Scheduler or Application Server is started, the host server’s system time and the time from the database is retrieved.  The difference between the server’s system time and the time from the database is stored as permanent value.  From this moment forward, whenever the Date/Time/or DateTime is requested we get the system time from the host server, and apply the difference that was originally calculated between the system time and the database time. The was done to avoid the overhead of going to the database for every request. The problem with this approach was that over time the clocks on the database and the process scheduler/appserver might not be ticking at the exact same rate.  If your process scheduler and/or appserver have not been rebooted for a long time, you could possibly see a difference of up to 5 minutes or more between the database time and the server’s system time.

The change that was made in PeopleTools 8.46 was to call a function that will retrieve and save the time from the database. When the function is called (it is called whenever someone logs on through PIA or a new batch process starts), and it has not issued the SQL to get the time from the database for over 20 minutes, the process scheduler and/or appserver will issue the SQL to retrieve the time from the database. If it has been less than 20 minutes, then a calculation similar to the one described above is used.

When creating a windows server that is going to run application and process servers for PeopleSoft I find a great way to automate the starting and stopping of services.  PeopleSoft delivers a method of installing a service to stop/start the services, which I have seen many people use, but I personally think it is a little buggy. I have experienced weird issues with the services not stopping properly, or if you have multiples and one has a problem you either effect all of them or you have to manually go to psadmin to administer the problem domain. I have also found that having non-administers trying to use the service/psadmin to be tricky.

As a solution to this problem, I have always liked using Windows Scheduled Tasks.  Scheduled tasks can be setup in advanced and you can run either a batch program (script) or the psadmin.exe utility.  When you scheduled a task you also set what user it will run as regardless of who runs it thus allowing a developer to run the script without being the administrator.

The only problem I have had with this is with the introduction of ps_cfg_home and ps_app_home variables.  Typically these can vary for every environment in which case I will create a batch program that sets the variables and then call psadmin in the script.  Then I schedule the task to run the batch program.  In order to run psadmin correctly after 8.50 you have to make sure the ps_cfg_home is set before running psadmin, otherwise it won’t know where the domains are.

For example on my environment I have an environment variable for the ps_cfg_home=c:\oracle\psoft\pt852cfg and my scheduled task is setup to run c:\oracle\psoft\pt852\appserv\psadmin.exe -p stop -d HRDEMO.  This basically tells the system where the HRDEMO domain is stored and to stop the process scheduler.

Other commands:

Application Server Start:  psadmin.exe -c boot -d {Domain}

Application Server Stop: psadmin.exe -c shutdown -d {Domain}   (to “force” down use shutdown! <-note exclamation point)

Process Server Start: psadmin.exe -p start -d {Domain}

Process Server Stop: psadmin.exe -p stop -d {Domain}

The other day I had to install an old 8.1 version of Tuxedo on a RHEL 4 machine and I ran into a problem after I tried to run the install.sh script.  It was reporting that the included VM could not be uncompressed.

Since this machine was brand new it turned out the the /usr/bin/uncompress utility was not there.  The Tuxedo installer needs this utility to uncompress the setup files.  It typically is located in the /usr/bin directory, and this path should be included in your PATH variables.

In my case there was no /usr/bin in the path and there was no uncompress utility.  There are various RPMs that will install an uncompress utility, however it is actually pretty old now and has been replaced with gzip.  So I added the path to my path variable and since I actually had gunzip already on the machine in /usr/bin, I created a symbolic link to gunzip for uncompress:

ln -s gunzip uncompress

I re-executed the install.sh script again and the install worked without a problem.

The other day I was stuck trying to cleanup a license manager for Cobol on a new virtual machine that was cloned from another machine. There was a series of licenses in the database that could not be removed.  In the end I decided that the easiest way to solve this problem was to delete the database and install a new clean database.

These instructions are for a linux based system, when dealing with peoplesoft, you will have a COBDIR where the server express software is installed.