The other day, a trainer was in one of my new demo environments setting up for a demo and told me the time was wrong.  However, if you looked at the server the time was bang on except for the fact that it was using the UTC-0 Timezone, which is common for virtualized cloud server because what timezone you want is really up to you.

I was very surprised that PeopleSoft did NOT seem to acknowledge the servers timezone and adjust accordingly.  So in my case, the demo was in the eastern time zone, so I changed the server timezone to America/Toronto.  To do this, I found was a little less than straight forward:

server1 :>   cd /etc

server1 :>   mv /etc/localtime /etc/localtime.orig

server1 :>   ln -s /usr/share/zoneinfo/America/Toronto localtime

There are hundreds of timezones you can set to but for me that one worked great.  If I need to I can revert back to utc-0 by simply moving the localtime.orig back to localtime filename.  Once the change was made the database booted with the correct time and PeopleSoft worked correctly after that.  I tried to figure out from the support site why UTC-0 was not recognized but found no valid answers anywhere.

Last week while working on a new install of O-SES for a development server, instead of using a dedicated SSL certificate we decided to use a wildcard certificate to reduce headaches.

When trying to build the PTPORTALREGISTRY index it failed with the error showing up in the web server logs:

####<Oct 3, 2014 3:18:25 PM EDT> <Warning> <Security> <OSESDEV> <search_server1> <FlexSecThread-16> <<anonymous>> <> <669085ede0c2399a:-42f78039:148d7454212:-8000-0000000000000031> <1412363905243> <BEA-090504> <Certificate chain received from osesdev.thesmartpanda.com – 111.142.22.208 failed hostname verification check. Certificate contained *.thesmartpanda.com but check expected osesdev.thesmartpanda.com>

Weblogic has a feature that validates the hostname when the web server is acting as a client.  Under the SSL settings for the PIA under the advanced options you can set the “Hostname Verification” to NONE.

After the change, re-ran the initial index builds and everything worked as expected.

Smart Thinking Newsletter

ERP Survey Results: Frustrated Users

How do users really feel about ERP? A recent study by Epicor has revealed some surprises – with the majority of respondents feeling that their ERP systems were basic or adequate, and only 25% having access to ERP systems via Smartphones. Perhaps they needed a SmartPanda to help develop their system!

I got a notice today that my service provider needed to reboot my servers as there was a vulnerability that was exposed on the actual host that could cause problems and the only way to fix it was to reboot the entire host.  So I wanted to ensure that everybody was off the system and cleanly so that there was no  problems because this is rare that my entire server set would be going down at the same time.

On my windows machines I wanted to make sure that nobody was still connected via remote desktop connections.  To do this quickly, from a command prompt I issued the command:

qwinsta

Another option would be to use the SysInternals Suite of Tools which is available from Microsoft, there is one called PSLoggedOn that will give the information you are looking for.

On my RedHat 6.5 servers you can issue the command:

who -a

There is another one called “w”  that will give similar information but for a quick look the who command works great.

During the last upgrade pass I was attempting to apply patches to the upgraded environment and ran into an unusual error when trying to build the change package within Change Assistant.

As it turns out when we build the image, we did not force it to always use the same IP address.  So every time it starts the IP address has a tendency to change.  As it turns out this can cause some problems with the configuration that was done before on previous passes.  Depending on your setup you may find that the Oracle Database Listening will not work, which in turn makes it unavailable for the application server and process scheduler and the database is not listening to requests.  So you will need to change the listening and tnsnames files, as well as the tnsnames file on the server where change assistant is running.

However, the error with building the change packages was caused because the mapped drive for the “pi_home” on the virtual image was mapped as a network drive using the IP address.  Once the mapping was changed and the pi_home was available the change package error was eliminated.