I've recently been using Vista a lot more as a client machine lately (I know - just in time for Windows 7 to come out I finally start using Vista on a regular basis :-) I hit an interesting problem when running an older version of PeopleTools on Vista though. Resolving the issue ended up using some of the techniques that we have shown in our "Troubleshooting PeopleSoft" presentations, so I figured it would be a good blog entry.

We're connecting to a PeopleTools 8.46 environment running SQL Server. PeopleTools is being run from a network server.


So far, so good. Putting in a password and clicking OK triggers the invalid user/password dialog.

I know that I have a valid access ID and password entered via Configuration Manager. Let's check out our ODBC data source info in Control Panel to be sure that we defined that properly.






That looks good. We've verified database connectivity, but we get kicked out very early in the login process for PeopleTools. I've skipped showing it here, but if you run a SQL trace for PeopleTools right now, you'll see that the error message is correct; it's the initial login to the database that PeopleTools is attempting that is failing.

At this point I fired up Process Monitor to see what was happening. Process Monitor is one of suite of freely available tools from Microsoft that can provide some good low level info about what is happening on Windows. It's not the same Process Monitor that is part of the PeopleSoft Process Scheduler.

After closing Application Designer, I launched Process Monitor, then restarted Application Designer and tried to login. As soon as I got the login error, I switched back to Process Monitor and had it stop capturing activity.



Stopping the capture is important because Process Monitor captures large volumes of detail. If you look at the bottom left of the screenshot above, you'll see that in just the amount of time it took me to try logging in to PeopleSoft, Process Monitor captured over 300,000 different events.



Thankfully Process Monitor has a very cool filter feature. Here we've told Process Monitor to filter the events captured by process name so that we can just see what is happening with pside.exe, and not all of the background processes that are running in Vista.



Filtering just the pside.exe activity still left us with over 8000 events to go through, so we need to do some more filtering. We're suspicious of the database connectivity, and those ODBC entries are stored in the registry, so in the screenshot above we have filtered by operation and limited it to operations starting with "Reg" so that we pick up the registry activity that pside.exe is doing.



That still leaves us with over 1800 events though. That's quite a bit of registry activity being done by Application Designer! Since we were trying to connect to the HCM89 database, we'll do a little bit more filtering. For events like registry and file system access, Process Monitor lets you filter by path as well.

By limiting the registry access events to only include cases where the path references HCM89, we've gotten our original 300,000 events down to just 73. We can see several NAME NOT FOUND errors in reference to ODBC entries for HCM89, so we may be on to something.

A closer examination of those and we discover that PeopleTools tries reading the ODBC entries from HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\HCM89, and then when that fails it is trying to read from HKEY_LOCAL_MACHINE\Wow6432Node\SOFTWARE\ODBC\ODBC.INI\HCM89.

What is Wow6432Node? Microsoft's Knowledge Base has a document on this. The purpose of this is to keep 32 bit programs and 64 bit programs to keep from stepping on each other.

Did I forget to mention that I'm running 64 bit Vista? (sneaky users - never tell the support people key info until after the fact :-)

A quick check with regedit to see what values are actually in the registry reveals that the ODBC entries that were created with the Control Panel applet are in the registry in HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\HCM89, and there are no entries in HKEY_LOCAL_MACHINE\Wow6432Node\SOFTWARE\ODBC\ODBC.INI\HCM89.

So I copied the HCM89 entries into the correct Wow6432Node, then launched Application Designer.


Bingo!

The next step from here would be to investigate how to make this work without requiring manual registry edits, but that will have to wait for another blog post.

Labels: 2009, Support, Sysadmin, Vista, Windows

We wrote awhile ago about how to enforce password protected screensavers in Windows. Password protected screensavers that automatically kick in are nice because they secure the users' desktop when they walk away, which protects their email, local documents, etc. in addition to their PeopleSoft sessions. Lots of customers that use our Desktop Single Signon for PeopleSoft product have implemented this.

In some cases though, locking the current session isn't the desired behavior. In kiosk environments or other types of shared workstations, you want someone else to be able to login, so having the workstation locked to the last user isn't good.

It turns out that Microsoft has a screensaver, winexit.scr, that will log the user out when the screensaver activates. The screensaver is part of the Windows Resource Kits; here's the download for the Windows Server 2003/Windows XP Resource Kit. There are lots of writeups out there about using winexit.scr, but the best one that I found was from David Carlin at Case Western Reserve University. His blog post describes his experience implementing this at one of the computer labs there.

There is at least one commercial product out there (ActiveExit XP) that handles similar requirements, although we don't have any experience with it.

Labels: 2009, Security, Sysadmin, Windows

Well, the Chrome browser's been out for about a day now, so I thought I'd give it a whirl using PeopleSoft.

You see, browser testing has always been a bit of a challenge with PeopleSoft, since each one handles javascript and other things just differently enough to cause issues. Now, many folks may be wondering why even bother test it (other than sheer geekdom), since corporations probably won't be deploying it internally any time soon. However, as we've seen with recent discussions with our ERP firewall product, there are many organizations who are deploying PeopleSoft outside the corporate firewall, like manager self service, open enrollment, and student registration.

What I've found so far

From a couple of hours of testing, here's what I've found

• The frame for the portal navigation does not display the scrollbar (this is a bug that also exists for FireFox)
• REN Server does not work. The JavaScript that catches the browser type issues an error message that the Ren Server is not supported for Safari. This may be a good use for the GoogleTalk integration we've posted in another blog entry.
• Downloading Query Results in Excel cause a corrupt excel file to be sent (Excel tries to fix it, but the formatting is lost).
• Buttons that should be at bottom of Tree Manager and Tree Viewer are rendered in the middle of the page (this doesn't seem to occur for other pages, such as the Journal Entry Page or Report Manager, though... it may have something to do with rendering HTML areas).

All in All, I'm pretty impressed with how much I can do with PeopleSoft on Chrome out of the box, though (I did my testing on Financials 8.9, running PeopleTools 8.46).

Labels: Browser, Microsoft, Windows

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

We've had a couple of situations recently where a customer didn't have easy access to the machine where their process scheduler server was running. The process scheduler was installed as a Windows Service and running under an account that the PeopleSoft team did not have access to.

So when something is not working properly, and an environment issued is suspected, how do you figure out what the environment even looks like? You can a) open a trouble ticket with whoever manages the technical environment and wait for a response or b) run a program under the process scheduler that will show you the environment information. We'll focus on option b for the rest of this blog entry :-)

In order to figure out this info, we created a simple App Engine program that does 3 things.

1. List the environment variables for processes started via the process scheduler. This is accomplished by grabbing the output of the set command that the Windows command shell (cmd.exe) supports. There is a PeopleCode function to check environment variables, but it does not support listing all known variables. Besides, we want to see what Windows says the environment variables are, since that is what our spawned processes end up with.
   
2. List all .cfg files that are found in the appserv directory and it's children. For psappsrv.cfg and psprcs.cfg files, we put the contents of those into our output. These files are what actually hold the values that you typed in when you were setting up process schedulers and application servers with psadmin.
   
3. Get the Windows security information for the files. This is mainly useful for troubleshooting things like a process not being able to save files when running.
   

The attached project has the App Engine code and a process definition for it. The process definition gives access to the ALLPAGES and TLSALL process security groups, but you can adjust that as needed. Since there is no online page for configuring the values fed into the process, the process definition just puts it into the System Process Requests page (PeopleTools -> Process Scheduler -> System Process Requests). The name of the process that will show up on that page is Environment Information.

I mentioned that there is no online page for configuring this, but there are a few minor tweaks that you can make in the code itself. At the top of the PeopleCode, there are 3 boolean variables that control whether or not to run each of the 3 steps listed above. These default to True, but if you didn't want to run the list of the file system security, you could just change that variable to False.

The other configurable part of the code is for picking which directory to use as a base. By default it will use the PS_HOME environment variable as a starting point (which will pick up everything underneath that), but if you need to look at a different directory you can change that to something else.

As for the output, there will be 3 files that you can view from Process Monitor. One is called gs_environment_info.txt. That contains the list of environment variables and should be self-explanatory.

The next file is called gs_appservprocsched_cfg.txt. At the top is the list of all .cfg files that it finds (the same as what you would see if you typed dir *.cfg /s at a command prompt from PS_HOME). After that it lists the name and then the contents of each psappsrv.cfg and psprcs.cfg file that it finds. If you only have one domain setup, then there would likely be one of each, but that will depend on your environment.

The last one should have been called gs_cacls.txt, but it turns out the cacls command (which ships with Windows and will list file permissions) does not like to have it's output re-directed. So we just let the process scheduler pick up the output and dump it into the Message Log file. Note that the Message Log file is different from the "regular" Message Log. The Message Log file is visible from the View Log/Trace page in the Process Detail page in Process Monitor. The "regular" Message Log is the list of messages that the process wrote to the database. The quick way to tell the difference is that the Message Log file is just a plain text file, while the other Message Log page is a regular PeopleSoft page with a grid on it.

In order to make sense of the file permissions that are listed in output, you'll want to read the Remarks section of this document from Microsoft that explains it (or take a look at this writeup that has what I think is a more clear explanation). Neither one makes it super easy to make sense of the output, but it's better than nothing. A future enhancement to this program might be to parse the output and display it in a more human readable fashion.

Aside from fixing up the display of the permissions and offering a page to launch this from that let you pick which options that you want, a few other nice enhancements to this would be :

• Make it work properly in Unix/Linux environments (I've just been building out an Oracle Linux environment for PeopleSoft. Fun!)
• Make these into callable functions and deliver an iScript that calls them so that they can run in locations where there isn't a process scheduler installed.
  
• Support using cacls to change permissions (might require the ability to run the command as a different user)
• Support listing out the contents of other commonly used PeopleSoft configuration files (e.g. pssqr.ini)

Of course, what would really be nice would be to feed the process instance of a process that died for some reason and have it go figure out why. That is (as they say) left as an exercise for the reader.

Labels: 2007, AppEngine, PeopleSoft, Windows