PeopleTools on Vista


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_USERSOFTWAREODBCODBC.INIHCM89, and then when that fails it is trying to read from HKEY_LOCAL_MACHINEWow6432NodeSOFTWAREODBCODBC.INIHCM89.

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_MACHINESOFTWAREODBCODBC.INIHCM89, and there are no entries in HKEY_LOCAL_MACHINEWow6432NodeSOFTWAREODBCODBC.INIHCM89.

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


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: , , , ,