It's all about the answers!

Ask a question

Setting up IHS on top of single server CLM installation

Karen Steele (1.2k1133131) | asked Apr 16 '19, 3:17 p.m.
retagged May 06 '19, 2:36 p.m. by Ken Tessier (84117)

This also refers to the my question 262130 in this forum. 

We have a single server installation of full CLM - it has a Public URI - and is an existing working installation.  We have to move off this current server to a new one in a different domain.  Initially we would like to be able to at least move it to the new server and add IHS using Liberty Profiles to provided a reverse proxy in front retaining the single server model - near long term is distributed, but we have to get single working first. 

We have found at least 3 or 4 articles (and have been provided links to the same) on how to do this.  We've followed this step by step but still have questions as the documentation merely stops at "test http://reverse proxy server" .. if we get the splash screen (presuming this means the notation that the service is running) - which we do that its a done deal.  

If we call out the application using the IHS server name, the application loads at the project areas space, but we cannot get to a project dashboard as it returns an error as its referencing the public URI we have (so its not resolving). If we navigate away to say RQM or DoorsNG then it attempts to find the application using its public URI - which it cannot resolve to either, unless we're going to the https://reverse proxy server:port/rqm/web for example

There seems to be pieces missing on what to do once you've confirmed that the IHS is actually running (or as best  we can tell running) given the other errors above. 

We're on a timeline to get this moved due to some site restrictions and looking for help - we do not have access to Websphere so it has to be liberty plugins using IHS.  

All assistance greatly appreciated. 

Preston Berkeley commented Apr 16 '19, 3:41 p.m.

@nerack What do you mean by splash screen?  Do you mean an IBM HTTP Server page, with icons like "Administration," "Information Center," "Support," and "Release Notes?"

If this is where you are getting, have you created the plugin-cfg.xml file, and put it in the correct location on the Reverse Proxy Server? Something like IBM\Websphere\Plugins\config\serverName

Have you also used ikeyman.bat to create the keystore? 

Ralph Schoon commented Apr 17 '19, 5:30 a.m.

There is no workable information in the question. No version, no app server. No references to what articles you refer to etc. This basic information is key in a forum. 

Karen Steele commented Apr 17 '19, 5:35 a.m.
All the articles you mention here Ralph are the ones you gave us previously so those are the articles

CLM 6.0.4
IHS Archived version as also indicated in the above articles.

Karen Steele commented Apr 17 '19, 5:40 a.m.
Preston .. same comments as replied to Ralph .... following the article mentioned by Ralph ... followed it to the letter ... when we run http://ihsservername we get a splash screen on the browser of "permission denied" followed by IBM HTTP Server 9.0x listening on port 80 ... when we run the same for https, we get the same message but listening on port 443 ... which is the indication that its running.

We follow thru by using the same URL and expanding it to include for example https://ihsservername:9447/jts/admin or ccm/admin or ccm/web etc ... which does load CLM at the required page.  But the minute we select a project area (if running the command ccm/web) we get a cannot load dashboard as "clmweb.test.local" is not known .. this is the public URI in our standalone configured (working) version without IHS on top of it.

Karen Steele commented Apr 17 '19, 8:59 a.m. | edited Apr 17 '19, 9:22 a.m.
Ralph / Preston ... so I think I got a little further, however, I still have an issue .. so to elaborate further :

Single server installation of CLM 6.0.4 with a public uri of clmweb.test.local sitting currently on a server and being access directly by the url https://clmweb.test.local:9447/x

Can't move between project areas using the IHS server URL it's trying to resolve to my public URI which has not changed ?

3 answers

permanent link
Ralph Schoon (62.7k33643) | answered Apr 17 '19, 10:08 a.m.
edited Apr 17 '19, 10:29 a.m.

 To understand how to setup using IHS, I would suggest to look into the interactive install or upgrade guides. They usually contain the information needed.

The Deployment Wiki can provide additional information. Especially see . Note the hostmanes and URI's of the servers. Also see: 

In general the key here is, that the IHS hosts the Public URI. E.g. Assume Public URI  root so public URIs ,

Assume two servers server one is IHS configured as . This is the IHS server that hosts the public URI. Note the port and host name must be from the public URI root. 

Server two is The CLM is setup to be accessible at say and . Different ports and different host names. However it knows itself as, that is the Public URI that is set.

IHS maps 

This step is the Plugin stuff in IHS.

If you don't get the redirection right, you can reach IHS, but no application.

Summary: the IHS hosts the public URI. The clem servers are installed on systems where the do not know the name of. They always talk to the IHS on the public URI which redirects to the applications. This way you can move the servers around, provided IHS stays where it is.

permanent link
Rosa Naranjo (2.9k11523) | answered May 07 '19, 2:38 p.m.
I also recommend reviewing the section 'What a reverse proxy will and will not do' in
to make sure that you are not trying to somehow go down a path where a reverse proxy introduced after the public uri is set will not help.

Without a server rename, the CLM applications will always want to be called by either a client like a browser or by a forwarded request from a reverse proxy by its original public URI.

permanent link
Karen Steele (1.2k1133131) | answered May 07 '19, 6:31 p.m.

thank you for all your input - we have got IHS to work with our new distributed environment after some trials and errors but we got it now.

Rosa Naranjo commented May 07 '19, 8:30 p.m.
That's great! can you share what resolved the issue? Is there anything missing from the articles you referenced? Continuous Improvement is key!

Karen Steele commented May 10 '19, 12:31 p.m.

I'll be honest, we had a lot of great materials given to us. The issue we had with those materials is that there was some underlying assumptions made on all of them either that you had WebSphere, that you were single server, default application installs and different ways of creating the IHS server certificates or key databases - all of which led to some confusion.  We had to bind together the references to pull from one and then from another to get what we needed.  I'll be documenting exactly what we did and referring to these articles.

Your answer

Register or to post your answer.