AdminServer on VMWare

vinod_home

Member
We had a server that was running Progress 9.1e02 and 10.2a, that we converted to VMWare. Progress AdminServer 10.2a works fine, but I cannot connect to 9.1e02 using progress explorer and none of the databases configured within it started automatically (like it normally does). Has anyone experienced this before. I did see a progress knowledgebase on this issue and tried commenting the three configurations that they suggested, but it didnt help.

The service starts fine, when I start the progress explorer it gives a 8336 error.

TIA
Vinod
 

RealHeavyDude

Well-Known Member
Just guessing: The AdminServer's default port is 20931 and the one for the NameServer is 5162. If you run two different versions of Progress/OpenEdge you need to change the default ports for one of the installations.

Plus, to be able to connect with the Progress Explorer to an AdminServer the version of Progress/OpenEdge need to match to the patch level.

Heavy Regards, RealHeavyDude.
 

vinod_home

Member
Yes, the ports are configured different. For the Progress 9.1e02, I have the default 20931. I also have stopped the OpenEdge AdminServer.
I only have one installation of Progress 9.1e02 on that server and I am running the Progress Explorer on the same server, so the version should match to the patch level.

Thanks
 

Stefan

Well-Known Member
You cannot connect to the AdminServer and none of the databases are automatically started. Are you sure your AdminServer is running at all? You should be looking at the AdminServer log file (admserv.log in the Progress work directory).
 

vinod_home

Member
The AdminServer starts from within the Services but the "admserv.log" is not created within the Progress Work Directory. The only log that gets created within the Progress Work directory is "admclnt.log" when I try to connect the Progress explorer (no errors within that).

I do see admsrv process running on the server. When I try to check the status "proadsv -query" from proenv, all it does is show the Progress version. I figure the problem is that the adminserver is not starting correctly, but how can I fix it. I have tried to re-install progress and that hasnt helped either.

TIA
 

RealHeavyDude

Well-Known Member
You can check your working directory in the Windows registry: You will find it under:
HKEY_LOCAL_MACHINE\SOFTWARE\PSC\PROGRESS\<your-version>WorkPath
You can also have a look at the
HKEY_LOCAL_MACHINE\SOFTWARE\PSC\AdminService\<your-version>\StartupCmd
where you can see the settings with which the Admin Service is started.

Heavy Regards, RealHeavyDude.
 

vinod_home

Member
I have checked both these registry values and both look fine and no changes from how it used to be when it was working. Still no luck,

TIA
 

Stefan

Well-Known Member
Are DLC environment variables set (setting them in a multi-progress installation is asking for trouble)?
Is JAVA ok?
Can you start AdminService from proenv using proadsv -start?

I am very confused by the admclnt.log being created - if the AdminServer is not listening for client requests, why should anything bother writing the admclnt.log...

Are both installations pointing to the same working directory?
 

vinod_home

Member
No DLC variables in the environment set. If I try to run any proadsv commands from proenv, all it does is display the progress version.. nothing more.

I am guessing its to do with JAVA, but nothing has changed, I have looked through all the registry setting under "HKEY_LOCAL_MACHINE\SOFTWARE\PSC\Progress\9.1E\JAVA" and it all points to the correct places.

Code:
proenv>proadsv -start
PROGRESS Version 9.1E02 as of Sat Jul 30 00:56:43 EDT 2005

proenv>proadsv -query
PROGRESS Version 9.1E02 as of Sat Jul 30 00:56:43 EDT 2005

proenv>proadsv -stop
PROGRESS Version 9.1E02 as of Sat Jul 30 00:56:43 EDT 2005

proenv>

In the admclnt.log all it does is (I checked it on a local install, it does write to this log if the AdminService is not running, doesnt write anything if the Service is running)
Code:
[11/10/10 1:19:39 PM]=== Start logging. Local time: 11/10/10 1:19:39 PM. ===
[11/10/10 1:19:39 PM] 
[11/10/10 1:19:39 PM] [1] [ProgressExplorer]      Inside of Chimera. (7445)

Each progress install has its own working directory.

Note: This was working perfectly fine when it was a physical server, all we did was change it to a Virtual Server (VMWare).

TIA
 

Stefan

Well-Known Member
Strange... just grasping at straws here:

1. was the server converted using the VMWare physical to virtual tool? Or was it built from the ground up to resemble the old server?
2. are there any other environment variables that are funny? (see %DLC%\bin\proadsv.bat for how the AdminServer is started from proenv)

CLASSPATH is one that has bitten me in the past after setting it as environment variable for some other java experiment.
 

vinod_home

Member
Thanks for all the help.. I think I finally got it fixed. Will monitor it for the next few days and will see how things work out.

Code:
Progress error 8336 when attempting to connect Explorer tool to Adminserver.
Solution ID: qad55794
Usage:	1
Status:	Unverified
Last Modified:	01/31/2008
Fact:	Progress 9.1X
Fact:	Progress Open Edge 10.X
Fact:	Windows 2003 Service Pack 1
Fact:	Windows XP Service Pack 2
Fact:	Progress Explorer
Fact:	Progress Adminserver
Symptom:	Cannot connect to Adminserver with Progress Explorer
Symptom:	Progress error 8336
Symptom:	Unable to connect to Adminserver. Ensure Adminserver is running. (8336)
Symptom:	Adminserver is started in Windows Services.
Symptom:	Running a 'proadsv -query' returns to command prompt with no message.
Symptom:	No Java processes in Task Manager.
Symptom:	No Adminserver log files created.
Symptom:	Windows Data Execution Prevention error for java.exe on bootup of server.
Cause:	Microsoft's Data Execution Prevention (DEP) is preventing Java from launching. The Adminserver runs under a Java process. If Java can not start, the Adminserver will not start. If the Adminserver is set to Autostart in Services (as is the default), it will try to launch java.exe on bootup and the error will occur.
Fix:	Turn off DEP for the Java process. This will allow Java to start, which will allow the Adminserver to start. There is an option in the pop-up message on Windows reboot to change settings for DEP to allow java.exe to run. If the pop-up window is no longer displayed, you can access the DEP setting by right-clicking on My Computer => Properties => Performance => Data Execution Prevention and select 'Turn on DEP for essentional Windows programs and services only.' This will allow Java to start and allow the Adminserver to start.
 

Stefan

Well-Known Member
Good!

However, if the server was converted from physical to virtual - how did DEP magically come into play?
 

vinod_home

Member
Could have changed from the default during the process of physical to virtual by VMWare or by the SysAdmin. The good thing is its working, the bad thing is I dont have a server that I can go check what the default is. On my XP the default is "Turn on DEP for essential Windows Programs and services only".

Thank you,
 
Top