Demantra setup.exe does nothing on Windows 7

Last evening, Mukhtiar called me to assist in Demantra installation on Windows. By the time we got on screen share, he had already downloaded patch 2195481 and installed JDK 1.8.0_77. However, when he clicked setup.exe, nothing happened.  We tried these :

1. Right click on setup.exe > Click Properties > Compatibility Tab > Run this program in compatibility mode for Windows XP
2. Run the program as Administrator
3. Tried changing registy settings as per some microsoft technotes

However nothing worked.

We located a file called setup.lax that was a configuration file for the installer and switched on stderr=console

However it showed a command window that used to disappear in a flash.

We tried uninstalling JDK 1.8.0_77 and installing JDK 1.7

Setting environment variable JAVA_HOME as described Demantra installation guide on https://docs.oracle.com/cd/E26401_01/doc.122/e22516/T573380T574948.htm

JAVA_HOME System Environment Variable

If the client machine does not have JDK version 1.6 or 1.7 installed, the Installer prompts you to download and install it. After installation, set JAVA_HOME to the JDK installation directory (for example, C:\Program Files\Java\jdk1.6.0_16).

Nothing worked.

Mukhtiar located a blog that advised setting java heap size to 512m by setting this environment variable:

_JAVA_OPTIONS = -Xmx512M

The Java Virtual Machine takes two command line arguments which set the initial and maximum heap sizes: -Xms and -Xmx. You can add a system environment variable named _JAVA_OPTIONS, and set the heap size values there

As soon as this environment variable was set, setup.exe finally launched.  All this time it was erroring out as the default 256MB was insufficient for starting the installer.

There was information about Out of Memory error on the installation guide too, but we had missed that:

Out of Memory Error Message

Verify memory settings:

1. From the Windows Start menu, choose Settings, Control Panel, and then Java. The Java Control Panel dialog box appears.
2. Click the Java Tab.
3. From the Java Applet Runtime Settings section, click View.
4. Verify that the value of the field Java Runtime Parameters is at least -Xmx256M and is based on the client machine hardware/RAM capacity. Oracle recommends value -Xmx512M for heavy-duty client side use.

Presenting in Collaborate 2016

I am presenting in OAUG Collaborate 2016 about our experiences with running E-Business Suite on Engineered Systems - Exadata, Exalogic, ZFS and PCA.  Session Details:

https://collaborate.zerista.com/event/member/223628

Please attend, if you are coming to OAUG Collaborate.

Extranet login redirects to intranet URL

For an old 11.5.10.2 ERP, we are moving from the architecture of "EBS application server in DMZ" to the architecture of "Reverse Proxy in DMZ and EBS application server in intranet".  After doing all configurations, we hit the classic issue where, you login through extranet url visible on public internet which redirects to intranet url.

So https://extranet.example.com asks for SSO details and after keying in SSO username and password goes to http://intranet.example.com.

The support.oracle.com article DMZ Configuration with Oracle E-Business Suite 11i (Doc ID 287176.1) has listed 4 checks which could be the reason for this issue:

H6: Redirection to an Incorrect Server During Login

If you are getting redirected to an incorrect server during the login process, check the following:

• Whether the hirearchy type of the profile options mentioned in Section 5.1 is set to SERVRESP .

select PROFILE_OPTION_NAME,HIERARCHY_TYPE from fnd_profile_options where profile_option_name in 
('APPS_WEB_AGENT','APPS_SERVLET_AGENT','APPS_JSP_AGENT','APPS_FRAMEWORK_AGENT' ,'ICX_FORMS_LAUNCHER','ICX_DISCOVERER_LAUNCHER','ICX_DISCOVERER_VIEWER_LAUNCHER','HELP_WEB_AGENT','APPS_PORTAL','CZ_UIMGR_URL','ASO_CONFIGURATOR_URL','QP_PRICING_ENGINE_URL','TCF:HOST');

PROFILE_OPTION_NAME                               HIERARCHY_TYPE
----------------------------------------                               --------------------------------
APPS_FRAMEWORK_AGENT                         SERVRESP
APPS_JSP_AGENT                                         SERVRESP
APPS_PORTAL                                         SERVRESP
APPS_SERVLET_AGENT                                 SERVRESP
APPS_WEB_AGENT                                         SERVRESP
ASO_CONFIGURATOR_URL                         SERVRESP
CZ_UIMGR_URL                                         SERVRESP
HELP_WEB_AGENT                                         SERVRESP
ICX_DISCOVERER_LAUNCHER                 SERVRESP
ICX_DISCOVERER_VIEWER_LAUNCHER SERVRESP
ICX_FORMS_LAUNCHER                         SERVRESP
QP_PRICING_ENGINE_URL                         SERVRESP
TCF:HOST                                                 SERVRESP


All good on this point


• Whether the profile option values for the fnd profile options (APPS_FRAMEWORK_AGENT, APPS_WEB_AGENT, APPS_JSP_AGENT, APPS_SERVLET_AGENT) are pointing to the correct node. Replace the node_id with the node_id of the external and internal web tier. For example:

select fnd_profile.value_specific('APPS_FRAMEWORK_AGENT',null,null,null,null,) from dual;

This query returned https://extranet.example.com


• Whether the dbc file pointed to by the JVM parameter (JTFDBCFILE) in jserv.properties exists.

wrapper.bin.parameters=-DJTFDBCFILE=

This was incorrect.  It was pointing to the intranet jdbc file location.


• Whether the value of the parameter APPL_SERVER_ID set in the dbc file for the node is the same as the value of the server_id in the fnd_nodes table.

  select node_name,node_id,server_id from fnd_nodes;

  This was overwritten in the dbc file, with appl_server_id of intranet when autoconfig was done on intranet and overwritten with appl_server_id of extranet when autoconfig was done on extranet, as the DBC file location and name were same for both intranet and extranet.

I asked the DBA team to manually correct the dbc file name inside $IAS_CONFIG_HOME/Apache/Apache/Jserv/etc/jserv.properties

and create a file of that name in $FND_SECURE/$CONTEXT_NAME.dbc on the extranet node and bounce services.  Once that was done, we tested and it worked. No more redirection to intranet URL.

Then I asked them to correct the s_dbc_file_name variable in the context file of extranet node. Run autoconfig on extranet, verify the value of dbcfile in jserv.properties DJTFDBCFILE parameter, verify that the DBC file had the server_id of the extranet node.  Restart all services.

Checked again, and it worked again.

So apart from checking the values of context file variables like s_webentryhost, s_webentrydomain, s_active_port, you also need to check the value of s_dbc_file while verifying the setups for extranet configuration. This can happen in 11i , R12.1 and R12.2 also.