Well, I have just had my first full exposure to the glory they call Oracle Secure Enterprise Search!  All I can say is damn, that was NOT easy.

The documentation is pretty good that I found, and maybe it is easier on a fresh install but I was doing the setup on an existing environment that I had just upgraded.  The upgrade was for Finance from 8.9 to 9.2.  In the 9.2 application VERITY is no long supported, and the PeopleSoft Search Framework only supports Oracle Secure Enterprise Search (O-SES).  The first trick is to download it from edelivery and in my case I installed the software on my batch processing server.  This install will install a full Oracle database with a webservice that by default runs on port 7777.  There is a bunch of setup that needs to be done to get this working, but the documentation I had for the install was very good for this part.

Some of the next parts I thought were a little difficult to follow, and so the first item is, I used my system start user as my main user, and made sure it had the following roles:

Search Administrator, Search Developer, Search Query Administrator, Search Server

I also have a custom permission list that this user has access to and I made sure that the permission was assigned the search group: PTPORTALREGISTRY.  This appears to be a new security element in the permission lists.

The new Search Framework uses a ton of IB service operations to do all of its work, and one element you need to do is set the Portal Content & Portal URI text fields on the Node for all the local nodes, otherwise the search results will return incorrect content reference paths (extra:  don’t forget the “/” at the end of the URI).

Now, I also inactivated all my integration broker routings for the default local node after the upgrade so no IB would unnecessarily be taking place.  This might have been a bad idea, but old habits are hard to break.  Since O-SES uses the IB for its Search Framework, the following Service Operations need to be active with the routing turned on!

Service: PT_SES – Service Operation: PT_SES_CREF_GET, PT_SES_USERSEC_GET, PT_SES_INIT,

Service: PTSF_META_DATA: Service Operation: PTSF_GET_GROUP_CAT_LBLS, PTSF_GET_SRCH_CAT_DET, PSFT_GET_SRCH_GROUPS

Service: PTSF_SECURITY: Service Operation: PTSF_AUTHENTICATEUSER, PTSF_GETSECATTRVALUES, PTSF_GETUSERROLES, PTSF_POSTPROCESS_FILTER, PTSF_VALIDATESRCHUSER, PTSF_VALIDATEUSERROLE,

Service: PTSF_SES_FEED – Service Operation: PTSF_CRAWLER_CFG, PTSF_SES_CRAWLSTATUS, PTSF_SES_GET_CONTROL_FEED, PTSF_SES_PROCESS_ERRS, PTSF_SES_SCHEDULED_FEED

Service: ADMINSERVICE:  Service Operation: CREATE, CREATEALL, DELETE, DELETEALL, EXPORT, EXPORTALL, GETAPIVERSION, GETSTATE, START, UPDATE, UPDATEALL

Service: PTFP_FEED – Service Operation: PTFP_GETPREPUBFEED  (not 100% sure on this one, but I turned it on along the way).

Make sure you add the PTPORTALREGISTRY to the Home Page Context Type, I added mine and made it default.  I also found that I was getting no returns and then after a day of thinking about things I tried again and everything appeared to be working fine.  I believe that the system was bounced web and app during that time, so if all else fails that might work!

Good Luck!

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.

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

I got a note from a client the other day saying that they were randomly sending out a lot of messages when Integration Broker failed to send a message.

It turned out that they had the Error Notification Integration Broker process turned on, which notifies everybody with the role APP_MSG_ADMINSITRATOR that an error has occurred. However, since this is workflow based if you look at the role under the security area, there is a workflow tab, and by default this role uses a query based workflow routing.  The base routing is Query: _ROLE_APP_MSG_ADMINISTRATOR, and if you dig into this you will find that everybody that has access to a web services (entry on PSAUTHWS table) will get notified.

In order to route the messages strictly to the administrators assigned to the role APP_MSG_ADMINISTRATOR, turn off the use query to route workflow in the role configuration.  PeopleTools -> Security ->Permissions & Roles -> Roles – tab WORKFLOW.

I was working with a client recently and they wanted some help setting up change assistant in order to apply some bundles to their environment. Seems like a pretty straight forward request. While doing a WebEx session we installed the change assistant and setup the agents and download the patches/bundles and then went into the change assistant to apply them. This is where things went weird.

After going through all the prompts to apply the change packages, the second last prompt is to enter the userid/password and accessid/password. Once the password was entered and the next button clicked, I received a Java Platform Platform SE Binary has stopped working. When you clicked on more details it shows that javaw.exe has crashed with a bunch of weird codes.

The versions I was seeing in the error code, made me think that there was some issue with the Java, so I made sure I was using the current version of java. Still no dice. So I tried a newer toolset, and went through the process to upgrade to the latest toolset. Still no dice.

This is when it dawned on me. I had the system administrator entering the accessid password during the remote session, and when I actually saw the password, it was 9 digits in length. I changed the password to an 8 digit password and we were in business.

This is an actual note from PeopleSoft: IMPORTANT NOTE: One thing to remember is that PeopleSoft does not support an Access ID or Access ID password of over 8 Characters. It MUST also start with an alpha character and can not contain any white space, or any of the following characters: ; : & , < > \ / ” ‘ [ ] { } ( )! % * ? – = +

The @ $ # characters will sometimes work, depending on DB platform, but cannot be at the beginning of the password. The Access ID cannot be a restricted word used in the Database either.

So there you go! There is an enhancement request to make the sysadm password handle larger sized passwords but I believe this case 1076084.1 has been open for a considerable time. I can remember being a DBA at one site almost 10 years ago, and they insisted that all administrative password had to be 16 digits. After a long and intense battle all passwords were changed to 16 digits except the accessid password.