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?
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?
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)
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.
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:
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.
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
To get around this, you'll need to use step # 10 from the Spring Application Context error documentation:
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:
Please feel free to vote on that and comment with your feedback.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG