Two installs of Confluence, leading to confusion...

[Thomas Murray]

I was finally able to get a PostgreSQL DB setup for Confluence.  But due to the fact that I had to reinstall Confluence, and assign a different port, I now have the complication of the old "demo/trial" version being there.  When I open the link to Confluence, it often resolves to the old port 8090 (bringing me into the old Confluence using the build in DB).

How can I rid myself of this old install so that I don't run into any issues that that kind of confusion might cause?  

This is going to be a KB for my Jira Service Desk, and when I link them in Jira Service Desk, it links (I THINK to the old DB over 8090, not 8096).

Thank you very much for any and all suggestions.

I have since originally posting this, found that ther are two services for Confluence in Windows, and when I shut the one down, the old 8090 Confluence DB is gone.  My issue now is trying to link the second install of Confluence to this Jira SD.  But when I try to choose Confluemce in "Project Settings" of the SD project, it says "We're having trouble communicating with the application.  Wait a minute and try again."  but waiting does nothing.  I'm assuming it's looking for the application on the original port 8090.  I'm looking around for documentation on how to change the default ports for my second installation of Confluence (while stopping the original trial versions service).

Moved it along I think.  This is what I'm showing right now, and I'm wondering how to make this right.  

[Andy Heinzer · Accepted solution]

Hello Thomas,

I understand that you have Jira Service Desk server and are looking to setup the Knowledgebase integration with Confluence.   It looks like you have already gotten past potential complications of another confluence site, but that you are still having problems getting this to work.

I would recommend taking a closer look at the KB Guide to link Knowledge Base to JIRA Service Desk for unlicensed user.  It is a pretty comprehensive guide to setting up this kind of integration for our server platform products.

The most common caveat I have seen in regards to this integration has been the need to make sure that both Jira and Confluence have a shared userbase.  This feature was designed in our Atlassian Cloud platform, where both Jira and Confluence always have the same userbase.  We understand that isn't always the case in Server.  But for this integration to work correctly, the application link between Jira and Confluence needs to be setup to use the setting 'OAuth with Impersonation'.  This is really only viable when both Jira and Confluence have the same set of users in both applications. This is noted in the KB I reference above:

Things to Know:

This feature was originally built for the Cloud environment which has a shared user base directory (i.e. using the same user directory or has the same sets of users). If you are running server versions of JIRA Service Desk & Confluence, you will need to make sure that users (including Service Desk Customers) exist in both JIRA and Confluence by using of one of the following approaches:

• Have the same user base in both Jira & Confluence e.g. both JIRA and Confluence integrated with the same external directory. Briefly speaking, each Service Desk customers has a user account in both JIRA and Confluence but not consuming any licenses.

This setting has to be changed from both sides (meaning within both applications).  Only after this is done, can you then complete this integration from within the project settings of Jira Service Desk.   It is unfortunate that the error message in Service Desk is not more verbose to explain this error, but I'm betting this is the problem here.

Try this and let me know the results.

Andy

[Thomas Murray]

Andy, thank you for taking the time to respond, and thank you for the valuable information.  It's just those types of caveats and hints I am looking for when posting questions.  Using the documentation, and figuring a few things out, I now have them integrated, and working properly.  Luckily, yes, I did see the shared user base, and have that working.  Without "Crowd" the user does have to (the first time through if they save their password) log in to Confluence to reach a KB article.  But there forward, it just goes to the linked articles without reprompting for the password.  My biggest worry was that the additional old demo/trial version would be active and mess with things, but there are two seperate server services for each install, and I stopped and disabled the service that ran the first (trial) Confluence instance.  Everything works properly, and I know that is totally turned off, and can't possibly get in the way.  I leave these words for anyone else trying to do the same process.  Thank you again for the hand, it is greatly appreciated.