If you run PeopleSoft applications on Windows, then you've probably been annoyed at one time or another by the way that the services are setup. Not the web layer so much as the application server and process scheduler. I know I have gotten annoyed with it :-)
There's a few problems with the way it works out of the box.
The first problem is that when you setup the services (option 3 in psadmin - "Services Setup"), you have to choose which application server domains and process scheduler databases that you want to be started. There's no way to separate multiple application server domains or even keep an application server and a process scheduler. It all gets installed as one Windows service called "PeopleSoft c:\pt848" (or wherever your PS_HOME was installed).
Why would you want them separated? Well, it's nice to be able to bounce things independently. Suppose you change some process scheduler configuration and you need to restart the process scheduler. You don't want to annoy all of your online users. Or maybe you have application server domains that serve different purposes. When we install
our software at customer sites, we almost always see shops with DEV, QA, UAT, etc. installed in a single PS_HOME directory. If your developers need to bounce an appserver, then you don't want them interfering with your testers. Most people do keep production domains separated from the rest though.
Of course, even with the services setup, you can still go into psadmin (
or can you?) and bring domains up and down, but lots of places don't want non-administrators to be able to reconfigure anything. Unfortunately psadmin does not have a mode where you can grant access to start and stop a domain, but not change the configuration of it.
With separate services, you can not only start and stop them independently, you can also use tools like
sc (downloadable from Microsoft as part of the
Windows Server 2003 Resource Kit). Then you could allow your remote developers the ability to reboot their dev domain with out granting them access directly to the server at all.
Another problem is that the psntsrv.exe process that launches psadmin to start or stop a domain does not integrate well with either the Windows Services APIs or with psadmin itself. If a domain takes a long time to boot for some reason, you'll end up getting an error about the service failing to start, even though psadmin is still starting things.
As long the domain ends up starting properly, this isn't such a big deal, but if the domain fails to boot for some reason after Windows thinks that it has failed to start, then there's no
automatic corrective action that can be taken. Also, psntsrv.exe relies purely on the exit status of psadmin.exe to decide whether a domain started or not. Unfortunately, this is not 100% reliable. Of course, if you can't trust the service status when the service is just a single domain, you certainly can't trust it when it is managing multiple app server domains and process schedulers under a single service definition.
Another nice thing that you can do with separate services and service
statuses that you can trust is take advantage of Windows service dependendencies. David Kurtz
explains this well over on his weblog (including some caveats about when not to use them).
An example use might be having your DEV appserver domain wait to start until your DEV database service available. That particular example presumes that you have the appserver and database server on the same physical box and that you're running a database engine that will create separate services for each database (such as Oracle), but you get the idea.
Rather than sit around complaining, we at Grey Sparling went ahead and built something that addresses these issues(1). The Grey Sparling Services Manager solves these problems as well as providing a few other handy features.
- Create separate Windows service definitions for each application server domain and process scheduler domain that you have.
- Sane service names so that you can script them with things like "net start" or sc, and have the script make sense. An example service name would be something like HCM9_appserv_c_pt848 (domain name _ domain type _ directory name)
- Watches domain status and will set service status accordingly. So if someone goes in and shuts down a domain manually with psadmin, the service status will change to reflect that. This means that you restart the domain remotely utilizing the service management tools described above even when the domain was stopped manually.
- Logging directly to the Windows Event Log. Each time a domain is started and stopped, the output from psadmin is captured and saved to the Event Log. This is also useful for remote administration.
- Nice graphical installer that guides you through the process of creating (or removing) service definitions (there's also a command line interface for doing this if for some reason you are managing lots and lots of domains)
- Enables tighter integration of PeopleSoft applications with enterprise management tools such as Oracle Enterprise Manager, Microsoft Operations Manager, etc.
We have a Flash demo of the
Services Manager in action, you can take a look at a short Flash demo here.
If you'd like to get a copy, we're making it available free to all Grey Sparling customers. If you're not a Grey Sparling customer yet (and why aren't you?) and you'd like to take it for a test spin, we can have an evaluation version up and running in your environment in about 5 minutes. It's really that straightforward. Just
shoot us an email or give us a call.
1) We actually built this a few months back, but this posting has been sitting in the queue for a bit.
Labels: 2007, Sysadmin, Windows
Subscribe Now!
