BI4.1SP1 Web Tier Install - "either the remote CMS cannot be reached or the logon credentials are incorrect INS00013"

[Former Member]

I have installed the BI platform as a full install on server A and on server B I am trying to install the Web Tier. I get to the point where I have to enter the CMS information however I get the error "Error: either the remote CMS cannot be reached or the logon credentials are incorrect INS00013".

Now I can log into the CMC and Launchpad with these credentials on server B and all of the servers are started and running within the SIA on server A. The CMS name is the only thing I can think of that's incorrect however this is the same name thats used in the 'System' field when logging in to the CMC (minus the port detail).

As I can ping server A from server B and log in to the WEB components which will have to call server A I cannot see why its throwing this error? If it helps server B is in a DMZ.

Any help anyone can provide will be very much appreciated.

Thanks

[Former Member · Accepted solution]

This issue has now been resolved with the below steps from SAP.

1. Manually bound the CMS with the servers hostname

2. Ran the setup install with 'Run as Administrator' privileges

The user I was installing with originally should have had admin rights but apparently they didnt. The install has now completed successfully however I can only access the web apps via the local host address as opposed to the IP address or Domain Name, I assume a change to tomcat is required for this?

[Former Member · Accepted solution]

Hi Matthew

Please could you further describe "Manually bound the CMS with the servers hostname"?

I think I may be facing the same issue.

Thanks

Al.

[Former Member · Accepted solution]

Hi Al,

Apologies for the delay I have been away. You need to locate the Central Management Server within the CMC server list. Right click to open the properties and scroll down until you see the hostname field. Update this with the name of the server and see if that helps.

[Former Member · Accepted solution]

Just wanted to say thanks for the post!

Implementing step 1 of your resolution allowed me to get past the INS00013 error during installation of IPS 4.1 SP5 on a RHEL 6.5 server that needed to connect to our BI 4.1 SP6 CMS on a separate RHEL 6.7 server.

Now I just need to install DS 4.2 SP5, and get everything talking to each other...

[Former Member · Accepted solution]

this solution didnt work with SAP Explorer, although I was getting the same error.

v4.1 sp1

[javier_almillategui]

Hi Matthew,

The issue is with the dynamic port the cms service chooses for comunication.

by default is random, this can cause issues. Please set it to an static value (like 6701 or the like) in CMC -> Server list -> rigth click on CMS service -> select properties -> common settings -> request port.

Best,

Javier

[Former Member]

Thanks Javier, Already covered - see my very first reply.

[Former Member]

Thanks Javier, as Berend said we have already tried this.

I have also tried applying notes 1682451 and 1669226 however STILL have the problem. I did see another suggestion surround the password and special characters however that didnt resolve the problem either.

Do you have any other suggestions?

[javier_almillategui]

Hi Matthew, Berent,

Did you guys put the server name in the hosts file (in Linux and UNIX is in /etc/hosts and in windows is in C:\windows\system32\drivers\etc\hosts)?

I had the same issue and I had to put the name in the host file and fix the request port in order to install.

best,

[Former Member]

Hi Berend,

i think i am facing similar issue as Posted by Mathew. i don't want to deviate the flow in this thread:)..

so request you give your suggestions asked in the thread- http://scn.sap.com/thread/3471366

Regards,

Santosh Kumar S

[Former Member]

Can I just confirm that the 'CMS Name' it refers to is effectively the node name and not the CMS database name? I am looking at the log and seeing things like this

13:31:41.590 | Property: shared.tp.aurora.sybase.sqlanywhere.props-4.0-core$SQLAnywhereAdminUser = dba

13:31:41.590 | Property: shared.tp.aurora.sybase.sqlanywhere.props-4.0-core$SQLAnywhereDatabaseAudit = BI4_Audit

13:31:41.590 | Property: shared.tp.aurora.sybase.sqlanywhere.props-4.0-core$SQLAnywhereDatabaseCMS = BI4_CMS

13:31:41.590 | Property: shared.tp.aurora.sybase.sqlanywhere.props-4.0-core$SQLAnywhereDSNAudit = BI4_Audit_DSN

13:31:41.590 | Property: shared.tp.aurora.sybase.sqlanywhere.props-4.0-core$SQLAnywhereDSNCMS = BI4_CMS_DSN

13:31:41.590 | Property: shared.tp.aurora.sybase.sqlanywhere.props-4.0-core$SQLAnywherePort = 2638

13:31:41.590 | Property: shared.tp.aurora.sybase.sqlanywhere.props-4.0-core$SQLAnywhereServerName = BI4

13:31:41.590 | Property: shared.tp.aurora.sybase.sqlanywhere.props-4.0-core$SQLAnywhereServiceName = SQLAnywhereForBI

13:31:41.590 | Property: shared.tp.aurora.sybase.sqlanywhere.props-4.0-core$SQLAnywhereUniqueID =

which are making me doubt it.

[Former Member]

The CMS Name during the installation process is by default the name of the server, hwich can be replaced by the IP address if necessary.

All the entries in the log are about the system database on Sybase. Different thing.

[Former Member]

Thanks for that confirmation. The CMS name wasn't changed so that will be what I am expecting it to be. Looks like I am back to square one. I am doing a re-run of the whole install including the unzipping process in the hope that triggers something. I'm totally stumped at the moment.

[denis_konovalov]

you do not need to re-install. it is network issue between A and B. Your network admin is not telling you the whole picture.

Run processes explorer on server B to see on which port and address it tries to access CMS.

You can also try installing BI4 client tools on server B and make connection from them to CMS, I'm sure you'll have similar issue.

[Former Member]

Thanks Denis.

I did try to run process explorer on server B but could not see any service that were related to BOBJ. The setup.exe file didn't have anything in the TCPIP properties either.

[Former Member]

You need to run it on serverA where the CMS is running, find the SIA and underneath that the CMS. open the properties and find the TCP/IP tab. There you should see that the CMS has connection to serverB. Can you see that?

[Former Member]

I have found that as per the screen shot below but at no point does it show that the CMS has a connection to server B. All of the rows are from A to A. I have had to block out the exact address for security reasons.

The point I am not sure about is WHEN B should appear in that list during in install phase of the web tier on A. Should it only be when I hit OK to validate the CMS details in the install screen on B or should it always be there?

[Former Member]

It's only there when you have an active connection (and a short time after that) so when you try to logon, and you see the error message, do you see a connection to serverB? You can run the Process Explorer on both machines at that stage. Guess on machine B you would need to look at the Windows Installer process that will start a subprocess (which will then be listed immediately below that, that's why I live the Process Explorer tool) which will want to connect to the CMS on machine A.

[Former Member]

No nothing appears at any point in the process explorer on A when I click the button to validate the CMS details on B. Does this suggest its being blocked somehow at B?

On B when I click the button I can see a java.exe process start as well as a conhost.exe process however they close again so quickly I cannot view the properties of them.

[Former Member]

Yes, I would say something is blocking communication between serverA and serverB.

Have you checked the Windows application event log on both servers - maybe something is showing up there?

[Former Member]

Nothing is showing up in the event logs either unfortunately.I think im just going to have to raise it to SAP support and hope they have some other diagnostic tools they can run.

[Former Member]

OK. Sorry we could not help more. Once you have made progress can you come back here and let us know what the solution was?

[Former Member]

You have been most helpful even if we didnt get to a solution. I will make sure to update the topic once I have a resolution to help any others that may run into this error.

Thanks again, and to Denis for his suggestions.

[Former Member]

DMZ? That means proper-firewall stuff. Make sure the CMS is running with a hardcoded requestport (CMC>Servers>Servers List>CMS>Properties> Request Port > Enter a valid port number here (for example: 6401) and make sure that both 6400 and 6401 are open on the firewall between serverA and serverB.

You could try doing a telnet command from server B to server A. You can ping, that's good, but can you access the CMS service? So do a "telnet serverA.domain.com 6400" and replace serverA.doamin.com with the FQDN of server A.

If this doesnt work, it confirms what you are seeing.

Tricky bit is that telnet is not always installed by default anymore, so in those cases I'd use process explorer as an alternative.

The other thing you could do is use the serverA IP address in stead of the system name.

[Former Member]

Thanks Berend.

Whilst testing this the firewall is currently OFF between the two servers with traffic allowed on all ports. I have made the change to the hard-coded request port but this has had no effect.

The network tests are being carried out by someone else but I can certainly pass these on. So far they have managed to test that a session is being created on port 6400 from server B to server A, all firewalls are off and traffic allowed. I tried substituting the name for the IP address in the CMS box and this had no effect either.

Do you have any other suggestions? I was under the impression that if the firewall was OFF between the two then it should have no problem at all as all traffic would get through?

[Former Member]

OK, if the ports are open you can verify that by running that Process Explorer tool, expand the services on the left, find the CMS.exe, open the properties and find the TCP/IP tab. There you should see that the CMS has connection to serverB. Can you see that?

Also, what you could try is have a look at the log so far. The details for the install log are noted here: http://service.sap.com/sap/support/notes/1801736.

Long shot: could it be you're installing from a share and not from a drive letter? Then have a look at http://service.sap.com/sap/support/notes/1915795.

[denis_konovalov]

Berend is correct, if you are able to login into CMC on machine A, and the only problem is from machine B, it's your network. Something is bloking access to CMS ports or name/IP is not resolving into correct address.

[Former Member]

I should be running the process explorer on server A? I cannot see any reference to server B in the properties. The local address and remoteaddress are all server A.

The setup.exe file is being run on a local disk so that rules out one of those points above.

Thanks again.

[Former Member]

Hi Denis,

I can access the CMC and Launchpad from Server B as well as A. I just cannot install the Web Tier on server B.

Does that suggest anything else?

[denis_konovalov]

this means install on A is fine (assuming you can login as well access CMC/BILP).

CMC and Launchpad when viewed on B access A over HTTP port 8080 (default) , but when you run install it connects over corba to CMS server process and needs open ports which most likely are blocked....

one other possibility is - do you by any chance using Egde version of BI4.x ?

[Former Member]

I am using Edge 4.1 yes. Is that going to be the cause?

A is perfectly fine and running as expected. Its just B thats the problem area.

[denis_konovalov]

See, Edge version meant to be a single server install. I'm not sure, but its possible it won't allow even web tier to be installed on another machine.

You can try installing normal tomcat on B, then  do war files predeploy on A (wdeploy tomcat7 predeployall) and copy BOE webapps to tomcat on B....

That part might work. (see Web applications deployment guide for details on that process)...