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.

Leave a Reply

Your email address will not be published. Required fields are marked *