User management in Confluence Server stage/test environments (exporting/importing users)

[Joel Ponce]

Hello,

We are working on streamlining our deployment process with Confluence servers. We're managing a highly customized Confluence installation (lots of custom macros, themes, etc). As such, we've been testing content and site updates on a staging environment that we then backup and use to upgrade our prod environment.

The issue is keeping our user accounts during every upgrade. Every time we restore from backup, user accounts appear to be recreated/overwritten (stage overwrite prod). We want to allow user creation on the prod site and only update content, themes, etc from staging to prod without overwriting users.

Is there a way to do this? Perhaps only to export/import user accounts from Confluence?

[Shannon S]

Hi Joel,

Users will always be overwritten when completing a full site restore.

All content replaced. Importing a site will replace all your content and users. Back up your database before you start.

If you do not wish your users to be overwritten, you can import each space individually instead, or migrate your users to an external authentication provider.

Let me know if you have any questions about that.

Regards,

Shannon

[Joel Ponce]

Hi Shannon,

Thank you for your response. Exporting/importing individual spaces will likely not be sustainable for our situation. What are our options for an external authentication provider? Atlassian Crowd?

Edit: Moreover, will an external directory keep track of user settings, profile edits, etc as well?

Joel

[Shannon S]

Hi Joel,

Yes, you could use Crowd, LDAP, AD, etc.

Have a look here:

• Configuring User Directories

Once you configure your instance to an external directory, the users should sync over.

Then, upon restoring your site export, it will only overwrite the users in the Confluence database. It will ignore the external directory.

At this point, you will need to reconnect to the external user management.

I would advise that you try this out first on a staging instance. Make sure to create a full site backup prior to this as well just to ensure there isn't any data loss.

As for your 2nd question, the user settings, profile edits, etc. are in the database, and are not migrated with a site import. To avoid those being removed, then the space import is the better option.

Do let me know if you have any questions!

Regards,

Shannon

[Joel Ponce]

Hi Shannon,

It looks like Crowd and space imports won't be a complete solution for us then. In our staging environment, we often test out new add-ons, custom macros, and other content settings. Is there a way for us to roll out/"deploy" these changes to our prod environment without overwriting our user tables?

Replicating our installation (as described here) will not help us either since we'd need to recreate the database as well. Please let me know if you have further suggestions.

Joel

[Joel Ponce]

Another update:

I'm looking at the Production Backup Strategy documentation. I'm wondering if I can directly copy the Confluence Home folder content to the prod server and copy our bandana table from stage to prod as well (to transfer user macros, etc). I'm trying to find a sure-fire way to copy all content data between deployments but am unsure if this will break other site data, table relationships, etc.

Maybe there's a way to copy only user settings from one database to the other and continue do site restores for everything else (with Crowd for user authentication, etc)?

[Shannon S]

Hi Joel,

I'm sorry to hear that the external user management setup won't work for you either.

Unfortunately I have no further suggestions. Your solution to copy the home folder and BANDANA table unfortunately would only cause further issues for you. For example you would get a lot of foreign key constraints. I do not recommend modifying the database in this way to get around the issue.

Hopefully some other users in the Community might have a solution for you.

Take care,

Shannon