Got "Set up step error" after going back a step

[Steinar Bang]

I am in the process of moving an existing Confluence installation to have the users managed by crowd.

To avoid doing my testing in the production environment I've installed an evaluation Confluence where I planned to import two spaces and existing users.

However I've run into a "Set up step error" in the setup with seemingly no way to get out of it.

I got to the step "Load Content" and selected "Restore from backup" and tried to install the space I had exported from the existing Confluence, and was told that at this stage I could only import a complete backup.

And there was no abort button or back button and no way forward, so I tried the back button on the browser.

When I was back in "Load content" I tried pressing "Empty site" but was greeted with "Set up step error".

I tried back button in the browser again, and then "Example site" but got a "Set up step error" again.

Is there a way out of this other than scrubbing the installation and starting fresh?

[Adrian Wyssmann]

Same problem here. Accidentially clicked "Restore from backup", then as there was no abort button or back button I clicked the back button on the browser. Since then for any option I click in the "Load content" menu gets me an "Set up step error".

No error messages on the screen, nor in atlassian-confluence.log

[Shannon S]

Hi Adrian,

To get around this, you'll need to use step # 10 from the Spring Application Context error documentation:

1. Stop Confluence.
2. Delete the <confluence-home>/confluence.cfg.xml file.
3. Start Confluence.
4. Access the Base URL in your browser to start the Setup Wizard from the beginning.
5. During the database configuration step, choose "Continue and overwrite existing data" if prompted.
6. Make sure all the steps are completed successfully.

I was able to break my instance in the same way and repair it with the above steps.

I have also created a feature request to add an option to go back in case you accidentally click Restore from Backup:

• CONFSERVER-55050

Please feel free to vote on that and comment with your feedback.

Thank you!

Kind regards,

Shannon

[Adrian Wyssmann]

Thanks

[Shelly Beckwith]

I followed these steps.  However, "continue and overwrite existing data" on the database contains existing confluence data warning screen does not continue.  The button visually clicks, but no action is taken.

[Shannon S]

Hi Steinar,

The option to Load Content while setting up a new Confluence instance should be a full site export.

If you are attempting to import the Space at this step, it will not work. You want to completely make sure that Confluence is up and running as expected, then you can run through the Restoring a Space documentation.

Could you give that a try and let us know how that goes?

Regards,

Shannon

[Steinar Bang]

Hi Shannon,

I was in a bit of rush so I ended up just doing the transition to crowd in the production Confluence, without doing any testing in a separate system.

The thing I wanted to check before switching to crowd for user management, was that the user and group membership would be correct, as log as the usernames and group names in crowd were the same as the original group names and user names.

We did a bulk rename of users with Confluence usernames that didn't match that person's AD username before doing the switch, and I wanted to be assured that this worked.

The crowd directory used was a "delegated directory" that got its initial sync of a user from AD, but then let the users edit their information in crowd and just doing password checks against AD.

For the curious: ownership was retained: the Confluence pages showed up as owned by the correct person.

I decided to switch off the old Confluence internal directory to avoid confusion about ownership and password logins, since there was a name overlap between the crowd users groups and the Confluence internal users and groups.

(Unfortunately this means that if crowd or AD goes down there is no way to get into Confluence to fix stuff)

[AnnWorley]

Hi Steiner,

Thanks for letting us know how you migrated user management to Crowd while ensuring that Confluence "saw" the users as the same users.

I am curious how you bulk renamed the Confluence users you mentioned.

I understand you disabled the internal Confluence directory and are concerned about accessing Confluence when the external user directory is unavailable. There are a couple of approaches, depending on the version of Confluence. If you are running a version higher than 6.5.0 you may use recovery mode as described in Restore Passwords To Recover Admin User Rights 

Another option when the external user directory is not working as expected, is to re-enable the Confluence Internal directory by setting it as active in the Confluence database. Please refer to the queries on Step 3. Put the Internal Directory in First Position to see how to re-enable the Internal Confluence directory so you can access Confluence with an admin from that user directory.

You didn't mention SSO, but If you are using Crowd for single sign on between applications, and have changed the authenticator in <Confluence_Install>/confluence/WEB-INF/classes/seraph-config.xml, that change will need to be reversed before Confluence will authenticate via the Internal directory.

I look forward to hearing whether you are running a version of Confluence that supports the (easier) recovery mode feature.

Thanks,

Ann

[Steinar Bang]

Hi Ann, and thanks for the information,

To take the last question first: The Confluence version is 5.10.2, so the suggested recovery method is not available, unfortunately.

(Side note: we do use SSO, so I would have had to make the change to the seraph config mentioned)

As for the mentioned bulk rename, here's what we had and what we did:

The existing Confluence installation used the built-in directory with self-service user creation and no connection to the active directory. We were going to introduce JIRA to replace bugzilla, we wanted AD authentication and we wanted SSO between JIRA and Confluence. And we wanted the Confluence users to retain ownership to existing pages.

We did the following:

1. Installed crowd, using PostgreSQL as the database
2. Imported the existing Confluence users into a crowd directory
3. Imported the AD users into a crowd directory
4. Made a copy of the PostgreSQL database and used SQL queries to identify the active Confluence users that had a username different to the AD username (I can dig up the queries I used if that is of interest)
5. As Confluence admin renamed the usernames of the active Confluence users that had usernames different to their AD usernames (not actually a bulk rename) and emailed them that the username had changed to match their AD username but that they should continue to use the old password and not the AD password
6. Set up JIRA to use a delegated crowd directory, groups in this directory were maintained in crowd, and this crowd directory was set up to handle nested groups
7. Connected Confluence to crowd and set up SSO for crowd, JIRA and Confluence (sent a new email to all Confluence users that they should now use their AD username and password in both JIRA and Confluence)

User ownership to pages was retained for the renamed users. I.e. the users who previously had a different username than their AD username has successfully retained ownership to the pages they cretated with the old username.  The users who had the same username as their AD username saw the password change as the only change.

[AnnWorley]

Bravo!

I cannot convert your reply to an answer (so I could accept it and send it to the top of the thread) but for posterity, please review @Steinar Bang's method.