Category Archives: PeopleTools

WebLogic 12 Unattended Install And Patch Scripts Up

I am back finally with something to contribute to the PeopleSoft community.  The WebLogic unattended installation and patch scripts for WebLogic 12 are up at my GitHub.  You can get the install script here and the patching script here.  Patch automation has been switched to opatch in line with the change to the Fusion Middleware model.  Be warned both scripts are still kind of hot off the press and could use better error handling.  I will get there soon I hope.  I forgot that I didn’t include the response file so I will have to add that later but you can find Oracle’s guide on creating one here, which is pretty helpful.  There’s not too many options.

I’ve also committed a script that does the Windows service installation of the MicroFocus COBOL runtime license service for PeopleSoft.  You can download that script from GitHub here.  Should save some time when setting up new machines since I can never remember the steps to install the service.

Now that we are finally starting to look at an upgrade to Tools 8.54 I’ve kind of been trying to get everything lined up and ready to go so we can have as much of an automated install as possible.  To that end, I’ve been experimenting with shared PS_HOMEs, which is not really a new feature but has supposedly been ironed out quite a bit in 8.54.

The advantage to doing the PS_HOME this way is that instead of having 11(or however many application server) PS_HOMEs to patch each time you apply a bundle or patchset, you patch one and every server in that environment is upgraded automatically at the same time, since they all use the same PS_HOME.  This will be a huge time saver and reduce the amount of places where something can go wrong.

I built a demo environment over the past week or so to test things out and despite Oracle’s claims that a lot of the bugs have been worked out I didn’t really see it that way.  You can read more about the shared PS_HOME process for Windows on Oracle’s site, but the important things to take away are:

  • Make sure your Tuxedo and PeopleSoft services are set to start as a domain service account.  Otherwise, they won’t have access to the network share.
  • You must use a mapped drive to get Tuxedo to work with a shared home, but your actual PS_HOME variable seems to require a UNC path.  I don’t know why this discrepancy exists.
  • Make sure you set your TM_TUXIPC_MAPDRIVER environment variable as a systemwide environment variable.  If you want Tuxedo and your domains to start with no user logged on there is no other way.
  • This might be an error in the way I have things set up (even though the app server and process scheduler domains start correctly), but using the shared homes I cannot get psadmin to work.  It will always show the domain status as not started.  I don’t know if this is because I am not logged on to the service account when running psadmin, but it is going to change the way a lot of our other scripts work if we can’t use psadmin.
  • Be prepared for your domains to take a long time to start.  In my demo environment it takes about 7 minutes to bring a single app server domain and process scheduler domain up.  Your Windows service will say it timed out but it is really still loading in the background.
  • You will want to seriously consider using Server 2012R2 file servers with SMB 3 in a cluster for your file server so you get a highly available file share.  I shut the file server down once just to see what would happen and it crashes the PeopleSoft environment.
  • Make sure your PS_CFG_HOME is on a local drive.  You don’t want to be writing logs back to the network location.  Also, make sure your service account running Tuxedo and PeopleSoft has write access to PS_CFG_HOME or your domains won’t start.

I am still ironing out the kinks in the shared PS_HOME, but the ease of patching and the disk space savings are well worth the time it takes to figure it out.

One last thing – to readers who asked how the license key was specified in the unattended installation of PeopleTools.  I told you it was only needed to determine which database type was used, but that information might be wrong.  There appears to be a step during the database configuration where the key is required in order to be added to a particular table. I’m guessing this may be why unattended installation of Tools is not supported.  So close, yet so far away.  It may be possible to fix this, but I am not willing to push it because it may violate a license agreement and I don’t want Oracle after me – I can’t afford that.  Sorry to have misled people, but together we can make Oracle support unattended installs if we push them hard enough.

PeopleTools 8.54 Initial Impressions

I had a chance to play with PeopleTools 8.54 the other day in my virtual environment.  Just trying to see what the upgrade process will look like for us when we go forward.  A few initial thoughts:

  • The installer.properties format for 8.54 hasn’t changed from 8.53, so you can still use the installer file I posted a while back.  Good news for automated installs!
  • Bad news for automated installs – I can’t seem to get the installer to run silently from a network location.  Seems like some sort of signed executable issue on Windows Server 2012 R2.  I will need to look at this to figure out a way around it.  The wrapper scripts might need work.
  • WebLogic 12 has moved to the Fusion Middleware model and as such, all the WebLogic install wrappers and PSU update wrappers I wrote for 10.3.6 don’t work at all anymore and will need a rewrite.  Patching is now done using opatch instead of bsu.
  • Tuxedo 12 works just like before, so good news there.  Saves some work.
  • I have been reading through the install documentation and can’t figure out if they have moved search to Secure Enterprise Search finally or if you still need Verity.  Verity isn’t listed in the documentation, but it’s part of the Campus Solutions package download from Oracle’s E-Delivery site.  Any readers know the situation here?

I’m glad I took some time to try this out as the start of the upgrade process would have been a bad time to find out the automated installers didn’t work anymore.

If and when I end up rewriting the wrappers I’ll put them up on GitHub and let everyone know.

Automated PeopleTools Installation – And More!

Ever got the go-ahead for an upgrade or installation of PeopleTools, looked at all your application and web servers, and thought “Man, if only there was some way to automate all these installs”?  Me too.

Sadly, Oracle does not make this easy to do.  The “installer.properties” files written by the install processes are usually incomplete and can’t actually be used to reproduce an installation.  Fortunately, through the magic of Java decompilers, InstallShield 2013, and hard work, I’m here to share working installer.properties files for not only things that come with Oracle-generated examples, but PeopleTools itself.

I think the most obscure automated installation is PeopleTools, so I’ll start there.  You can find the PeopleTools installer.properties file you can use to structure your own installation on my GitHub. Just look at some of those names – USER_INPUT_RESULT_14?  Way to make it easy.  Edit that file to reflect your environment and database type, then just use “setup.exe -f installer.properties” to silently and automatically install PeopleTools.  Of course, why stop there?  I’ve also written PowerShell wrappers for both installing a new Tools environment and upgrading an existing install to a point release.  These scripts handle your error checking during the process and the upgrade script will automatically update your PIA installer files on a file share while preserving your custom installer.properties for your PIA automatic installs.

Speaking of PIA automatic installs, some people know that Oracle provides a skeleton installer.properties for PIA in the \scripts directory of PsMpInstall.  For those that didn’t, you can find a usable installer.properties for PIA here.  I have a PowerShell wrapper for the PIA install, but it’s a fairly simple process to call the PIA executable with the file.  Nicholas Gasparotto did a nice write-up  – although he is on Linux the basic steps are the same.

We’ve now got our PeopleTools and PIA silent installs covered, but how can we do the prerequisites too?  We need to install Tuxedo on the application servers and WebLogic on the PIA servers.  Never fear though…

Oracle has a write-up on unattended Tuxedo installs on their site.  Maybe I’m slow but I didn’t find it too easy to follow right off the bat.  So, grab your Tuxedo installer.properties file here and make it easy on yourself by just having to customize for your environment.  Then, just follow Oracle’s instructions to call the installer with your file.

But what about Tuxedo Rolling Patches?  We don’t want to move on without those, right? I have a nice PowerShell wrapper for the process of installing an RP that takes care of all the steps in that procedure, including uninstall, cleanup, error handling, etc.  Easy, and better, automated.

WebLogic is another product Oracle wrote a guide for silent installation for.  But if you don’t want to read all that and write your silent.xml, get yours here! Oh, and there’s also another PowerShell wrapper for the install process.  It’s not as involved as the others though.

Again, what about WebLogic Patch Set Updates? Grab your PSU PowerShell wrapper and automate those installs away.

I left out JDK automated installs because that process is fairly well documented in my opinion.  I do have a PowerShell wrapper for that as well that takes care of uninstalls, error handling, and other minor stuff – if anyone wants it leave a comment and it can be another post.

Want to take all that to the next level?  Set up a file share, get all your properties and XML files in line, then convert those scripts to SCCM packages.  Now, you can deploy installs or upgrades to site collections and never even have to log in to a machine.

If something gets confusing let me know and I’ll try to help if I can.  Converting all these steps to SCCM packages has really changed the way I handle upgrades and installs for our PeopleTools environments.