When installing the runtime license for Server Express 5.x, you will most likely encounter an error reporting that psauto64.int is in an unsupported format. This unsupported format error is caused by a failure to read the file from the nfs mounted file system. By explicitly setting the path in the psauto64 (or psauto32) script to a file reference the script will execute correctly.

Simply open the psauto64 or psauto32 script with vi and change the follwing:

From:  $COBDIR/bin/cobrun psauto64.int verbose
To:        $COBDIR/bin/cobrun ./psauto64.int verbose

Happy installing! 🙂

I was moving one of my database servers to a new cloud, and I could not find the product key that I used to install the SQL Server install.  So I did some google action and found a bunch of folks that had little to no clue on how to get the real product code.  I found a dude named Laser on the gearbox software website, that is a genius, and this worked for both my 2008 and 2012 versions of SQL Server.

In the registry I navigated to the key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\100\DTS\Setup] – DigitalProductID, for SQL Server 2012 it will be in the “110” entries, and it might not be actually under this entry, I found it several spots so if you don’t see it there look around a bit.

Now I did find the the 2012 tag was actually the actual 16 2-digit hex values I was looking for where the 2008 tag was 164 2-digit hex values.  In the case of the 164 code, you need to 53rd pair to 69th pair to get your 16 2-digit hex value.

Next you need to take that value and reverse the entry, so for example,

01,02,03,04,05,06,07,08,09,10,11,12,13,14,15,16 becomes:  16,15,14,13,12,11,10,09,08,07,06,05,04,03,02,01

Now remove the commas and take your 32 digit code and put it into a Radix 16 to 24 converter, I found a calculator to do it.

Lastly, for Microsoft codes you need to take your results and do one last conversion:

0 ==> B,  1 ==> C,  2 ==> D,  3 ==> F,  4 ==> G,  5 ==> H,  6 ==> J,  7 ==> K,  8 ==> M,

9 ==> P,  A ==> Q,  B ==> R,  C ==> T,  D ==> V,  E ==> W,  F ==> X,  G ==> Y,  H ==> 2,

I ==> 3,  J ==> 4,  K ==> 6,  L ==> 7,  M ==> 8,  N ==> 9

Yep, it sounds crazy, but it works!  To be totally honest, I have never worked with radix based number systems before, and I am not about to start, and honestly, I get freaked out by hex values in the registry, but those codes cost a lot of money, so if you are like me and either forget to write it down because that would be easy, or inherit a system that was installed by somebody that didn’t write it down, this might just save you!

Just working on another upgrade today and ran into one of those gotcha’s that can make you scratch your head for hours.  The upgrade job failed trying to do a datamover script:

PeopleTools 8.53.05 – Data Mover
Copyright (c) 2013 PeopleSoft, Inc.
All Rights Reserved
Message Set Number: 0
Message Number: 0
Message Reason: Invalid User ID and password for signon. (0,0)
PSDMTX Error: signon

Funny thing is I can log into Application Designer, and I have the application server and process schedulers all running with the same user.  I check to make sure that my connect id still has the correct access and make sure that no accounts are locked, and everything looks great.  I even have PeopleSoft Administrator as one of my roles and still no dice.

If you have ever ventured to look at the PeopleTools Tab in the Permission List Component, you will see there is an option for Data Mover Access.  Make sure you have a permission list with this option turned on.  I have a custom permission list just for the upgrade and I added it to that, and bingo I was back in business.

Today, I was working on a PeopleTools upgrade for a client from 8.51 to 8.53.08 and ran into a failure when doing the Coverting PeopleTools Objects step of the upgrade.  When running the PeopleTools Data Conversion process I got a strange series of errors and then an error messaging that looked like UPGPTHASH failed. The messages appeared to be orphaned Application Engine PeopleCode, but the failure appeared to be with the Hashing.  I ran UPGPTHASH from the command line and it completed successfully but interestingly enough reported the invalid objects just like when PTUPGCONVERT ran it.

I decided to run a sysaudit on the database and found that I had PeopleCode-1, PeopleCode-2, PeopleCode-3, PeopleCode-6 and PeopleCode-7 errors in the database.  I will work on figuring out why they were there tomorrow but for today, I executed the steps from the data integrity guide from PeopleBooks to delete the invalid entries:

PeopleCode-1:

DELETE FROM PSPCMNAME WHERE NOT EXISTS (SELECT ‘X’FROM PSPCMPROG B WHERE B.OBJECTID1 = PSPCMNAME.OBJECTID1 AND B.OBJECTVALUE1 = PSPCMNAME.OBJECTVALUE1 AND B.OBJECTID2 = PSPCMNAME.OBJECTID2 AND B.OBJECTVALUE2 = PSPCMNAME.OBJECTVALUE2 AND B.OBJECTID3 = PSPCMNAME.OBJECTID3 AND B.OBJECTVALUE3 = PSPCMNAME.OBJECTVALUE3 AND B.OBJECTID4 = PSPCMNAME.OBJECTID4 AND B.OBJECTVALUE4 = PSPCMNAME.OBJECTVALUE4 AND B.OBJECTID5 = PSPCMNAME.OBJECTID5 AND B.OBJECTVALUE5 = PSPCMNAME.OBJECTVALUE5 AND B.OBJECTID6 = PSPCMNAME.OBJECTID6 AND B.OBJECTVALUE6 = PSPCMNAME.OBJECTVALUE6)

PeopleCode-2:

DELETE FROM PSPCMPROG WHERE NAMECOUNT <> 0 AND NOT EXISTS (SELECT ‘X’FROM PSPCMNAME B WHERE PSPCMPROG.OBJECTID1 = B.OBJECTID1 AND PSPCMPROG.OBJECTVALUE1 = B.OBJECTVALUE1 AND PSPCMPROG.OBJECTID2 = B.OBJECTID2 AND PSPCMPROG.OBJECTVALUE2 = B.OBJECTVALUE2 AND PSPCMPROG.OBJECTID3 = B.OBJECTID3 AND PSPCMPROG.OBJECTVALUE3 = B.OBJECTVALUE3 AND PSPCMPROG.OBJECTID4 = B.OBJECTID4 AND PSPCMPROG.OBJECTVALUE4 = B.OBJECTVALUE4 AND PSPCMPROG.OBJECTID5 = B.OBJECTID5 AND PSPCMPROG.OBJECTVALUE5 = B.OBJECTVALUE5 AND PSPCMPROG.OBJECTID6 = B.OBJECTID6 AND PSPCMPROG.OBJECTVALUE6 = B.OBJECTVALUE6)

PeopleCode-3:

UPDATE PSPCMPROG SET NAMECOUNT = (SELECT COUNT(*) FROM PSPCMNAME C WHERE C.OBJECTID1 = PSPCMPROG.OBJECTID1 AND C.OBJECTVALUE1 = PSPCMPROG.OBJECTVALUE1 AND C.OBJECTID2 = PSPCMPROG.OBJECTID2 AND C.OBJECTVALUE2 = PSPCMPROG.OBJECTVALUE2 AND C.OBJECTID3 = PSPCMPROG.OBJECTID3 AND C.OBJECTVALUE3 = PSPCMPROG.OBJECTVALUE3 AND C.OBJECTID4 = PSPCMPROG.OBJECTID4 AND C.OBJECTVALUE4 = PSPCMPROG.OBJECTVALUE4 AND C.OBJECTID5 = PSPCMPROG.OBJECTID5 AND C.OBJECTVALUE5 = PSPCMPROG.OBJECTVALUE5 AND C.OBJECTID6 = PSPCMPROG.OBJECTID6 AND C.OBJECTVALUE6 = PSPCMPROG.OBJECTVALUE6)

PeopleCode-4, PeopleCode-5, PeopleCode-6:

Open the PeopleCode program in Application Designer and correct the invalid reference

PeopleCode-7:

DELETE FROM PSPCMPROG WHERE OBJECTID1 = 104 AND OBJECTID2 = 107 AND OBJECTVALUE2 NOT IN (SELECT APPCLASSID FROM PSAPPCLASSDEFN P WHERE P.PACKAGEROOT = OBJECTVALUE1 AND P.APPCLASSID = OBJECTVALUE2)

Restarted the PTUPGCONVERT Step (F9) and the Conversion process ran without issue.

I also found several cases where it reported that UPGPTHASH will fail where the conversion process will fail because of a license code issue.  I can’t remember when PeopleSoft made the switch over but now when you install the software you are to use the license codes from PeopleSoft License Code Page. Often if your database has been around awhile the license code stored on PSOPTIONS.LICENSE_CODE will be different then whats on the License Code Page.  You can update the license code on PSOPTIONS, using SQL:  just note that the license code should be in lower case, no spaces, and no dashes.

I have to admit I struggle to understand why SSL is one of the weirdest and most difficult things I get stuck configuring about 2 or 3 times a year.  Today I was trying to see a private key as I had a REN server that would not boot properly after a new SSL certificate was installed and I wanted to compare the key that was getting loaded by REN with what I had in my certificate.

It turns out that I had done something very similar a few weeks ago, but in reverse, and I posted this blog on it.

This time in order to see the private key, you have to take the jks keystore and convert it to a p12 keystore, and then export the private key. Again nothing ever is easy with SSL, so this requires two tools:  keytool and openssl.  You can get openssl from the great folks at sourceforge – click here.

First the conversion from jks to p12:

keytool -v -importkeystore -srckeystore keystore.jks -srcalias certificatekey -destkeystore myp12file.p12 -deststoretype PKCS12

Secondly, now that you have the p12 keystore you can extract the private key:

openssl pkcs12 -in myp12file.p12 -out private.pem