“The best laid plans of mice and men often go awry.”
I’m working on writing my paper for Collaborate 09, and for some reason, this phrase keeps coming back to me. I actually looked up this quote and it is often misquoted, including in my opening sentence. The quote is actually from a poem by Robert Burns, called “To a Mouse” and the quote is actually, “The best laid schemes o’ mice an’ men, Gang aft a-gley.” Burns, incidentally, also wrote Auld Lang Syne. My best laid plans included actually having my white paper and presentation completed for Collaborate 09 before they were due. This year my presentation is “Implementing the PeopleSoft Enterprise Environment Management Plug-in for Oracle Enterprise Manager.” I did get an early start, but have been working on this for about six months and have been unable to complete the project.
Issues started almost immediately with the installation process. We are an HP-UX shop running on Itanium CPUs. The installation of the plug-in to the Oracle Enterprise Manager Management Service failed with a password issue. After several weeks, Oracle determined that the installer was having issues on Itanium. They created a patch for the installer that allowed me to install the plug-in and I was finally on my way. You will have to wait for my paper and presentation for the details of the installation and setup, but I did run into a few more road blocks that fed into the “Best Laid Plans” theme.
One thing that got me was that I had installed the Oracle Management Agent on my PeopleSoft servers before starting to do the research for the PeopleSoft plug-in. Big mistake! I was hoping to monitor the up/down status of the hardware and the available space for the file systems. This worked well, but then I found out that the installation of the agent for the plug-in is required to be owned by, or at least in the same group as, the user that owns the PeopleSoft installation. So after several uninstalls and reinstalls, I was ready to go again. Of course then there was the issue of what user to use when discovering the PeopleSoft targets. The documentation is unclear and I tried several options. Bottom-line is that while the Management Agent can run as a centralized user that shares the group with the PeopleSoft installation, the discovery has to be done by the actual software owner. This was an issue only because we have several environments hosted on the same server in our non-production environments. That was a long paragraph and hopefully makes some sense. If not, I wrote it much better in the paper so you can check it out at Collaborate.
My next challenge had to do with how PeopleSoft identifies its databases. This is something I had no clue about and caught me off-guard. I went through and, with the help of the PeopleSoft Administrators, added all the non-production PeopleSoft targets. One of the cool features of the plug-in is that it allows you to create a system for each environment and a service to measure the login time and make sure the web site is available. When I started to create systems for each environment, Enterprise Manager tried to connect all the components to one database. After further research I found that PeopleSoft stores a GUID in the PSOPTIONS table that needs to be unique for every environment. Since we refresh our test environments with production, all the GUID fields were the same, thus the reason that Enterprise Manager tied everything together. The fix for that is to shut down the application server, set the GUID to a single space in PSOPTIONS, and then restart the application server. The application server then assigns a new GUID and all is wonderful… Unfortunately, the developers, testers, and PeopleSoft administrators are not that happy to give up the environments for outages. Plus, I had to delete all the targets that had been previously discovered and go through the discovery process all over.
At this point I am almost ready to add the production targets to the Enterprise Manager repository and really start using it like it is meant to be used. And of course, I found one more issue. We refreshed one of our non-production environments the other day. Part of the service monitoring includes a user in the PeopleSoft system that only has rights to log in and nothing else. Of course, we decided to use a different password that we could standardize for all non-prod environments, but it is different than what we used the first time. I cannot for the life of me, figure out where to change that password to make the service check work again. I ended up creating a Service Request with Oracle and apparently, they don’t know either. It has been a week and they haven’t given me a response.
Well, I better actually get to finishing the paper. I have not been able to find a lot of information about people using the plug-in so if you are, please drop me a line and let me know. I would love to trade war stories! Also, if you are not already planning on attending Collaborate 09 in Orlando in May, make sure you check it out. It is hard to beat the amount of technical content and the networking opportunities that exist at this one conference.
Until next time, and as always… stay clean!
Subscribe to:
Post Comments (Atom)
Todd, I was not able to attend Collaborate this year, but I am running into the same issue you noted above regarding "the discovery has to be done by the actual software owner". How did you overcome this when having 2+ different ps_homes on an app server running as different owners?
ReplyDeleteTHanks