Possible to force AGS to use non-default ORACLE_HOME?

[ChrisBeaudette]

I realize that this is not an ArcSDE or geodatabase question, but I thought some Oracle types might know the answer.  Note that I also posted this question to the ArcGIS Server v10 group...

We have ArcGIS Server v10.0 SP5 (32 bit) and Latitude Geographics' Geocortex Essentials (64 bit) installed on the same server (Windows Server 2008 R2). We're using a 64-bit Oracle client since we have Oracle datalinks in GTX Essentials. We also want to start using query layers in ArcGIS Server, but we have to use a 32-bit Oracle client to do so. We can configure the MXD successfully but when we publish to ArcGIS Server and attempt to start the service, we get a 'server library could not be loaded' error, most likely because AGS is 32-bit and cannot be used w/ a 64-bit Oracle client.

We installed the 32-bit client as well so now both it and the 64-bit Oracle clients are on the same server with different ORACLE_HOMEs. I tried creating a logon script for the ArcGISSOC user account that sets the ORACLE_HOME environment variable and pre-pends the PATH env var with the 32-bit ORACLE_HOME/bin directory, but I'm still getting the 'server library could not be loaded' error when starting the ArcGIS Server service. Our ArcGIS REST service app pool uses the 'ApplicationPoolIdentity' which is a virtual account. I can set the app pool 'Load User Profile' setting to True for ApplicationPoolIdentity (or some new Identity that I create) and potentially set the ORACLE_HOME and PATH variables there to see if that fixes it. But this is a production environment so I want to be fairly certain that this will work before making a potentially intrusive change. (And I don't have another server with a similar setup to test it on).

Is it possible to force ArcGIS Server to use the 32-bit ORACLE_HOME when all other apps on the server are using a different (64-bit) ORACLE_HOME? If so, how can this be done?

[VinceAngelo]

This is more like a fundamental flaw in Windows.  The easiest way to deal with 32-bit/64-bit
issues is to not put them both on the same host.  AGS 10.1 is 64-bit, so that's your fastest
route to an all 64-bit environment.

If you can't move to 10.1 Server, you might be able to skirt the problem by running AGS as
a service account user which overrides the system PATH variable, to place the 32-bit homes
before 64-bit (I thought I had this working for a while, but then the system registry became
hopelessly corrupted and I had to have the host re-imaged, so I'm not as fond of this technique
as I had been previously).

I haven't tried this, but you may be able to use a simple C/C++ wrapper to replace the binary
run at service start, and have this app change the environment and run the normal binary.
Even though it should work, I've had issues with using putenv(), so I'd recommend you try
using SetEnvironmentVariable instead.

- V