OD Migration

I reviewed the product documentation and forum, but wasn't able to find any info on OD migration (just installs and upgrades), so here goes...

We have a new install of OD 6.1.1 running on Linux and now need to bring over the user roles and deployment authorizations from the old server (OD 6.1.1 on Solaris). Sure we can manually re-add users to the server and reassign access to specific deployments, but geeez it would take forever and a day and be very error prone.

Any ideas or suggestions on programmatically migrating user access info from OD server A to B?

TIA

Find more posts tagged with

Comments

Adam Stoller

I reviewed the product documentation and forum, but wasn't able to find any info on OD migration (just installs and upgrades), so here goes...

We have a new install of OD 6.1.1 running on Linux and now need to bring over the user roles and deployment authorizations from the old server (OD 6.1.1 on Solaris). Sure we can manually re-add users to the server and reassign access to specific deployments, but geeez it would take forever and a day and be very error prone.

Any ideas or suggestions on programmatically migrating user access info from OD server A to B?

TIA

iwodauthorize should at least help with the user / role definitions as I believe it will allow you to dump a list of users in any role.

Getting the access for individual deployments could also probably be done this way, but I don't think there's anything that lists all of the deployments which were configured, so you'd have to do it by memory.

Seems like source for a good feature request - although a better one would be a means of dumping the entire thing into some format that could be read by the same utility on a different machine. I'm not aware of any such utility - though since the information is supposedly stored in some DB / DBfile - it should be possible.

Have you checked with Support on this?

LooseCannon

If Support doesn't have a utility or a better approach then writing some Perl around iwodauthorize looks like the next best thing.

Adam Stoller

If Support doesn't have a utility or a better approach then writing some Perl around iwodauthorize looks like the next best thing.

Unfortunately, as I believe I mentioned, iwodauthorize doesn't provide a way to list all the deployments which have been specifically authorized - neither does it seem to provide a way to list all the users for a specific deployment - but I think you might be able to cycle through all the configuration files and directories and do something like an 'add' for a non-existent user and retrieve the list of users for that deployment - either that or add and remove a real user. Definitely not a good API... you should file a case with Support if you need this.

LooseCannon

Unfortunately, as I believe I mentioned, iwodauthorize doesn't provide a way to list all the deployments which have been specifically authorized - neither does it seem to provide a way to list all the users for a specific deployment - but I think you might be able to cycle through all the configuration files and directories and do something like an 'add' for a non-existent user and retrieve the list of users for that deployment - either that or add and remove a real user. Definitely not a good API... you should file a case with Support if you need this.

Support suggests using iwodauthorize as well.

I haven't tried this *yet* but I think the following approach will do what I need and migrate the user role and deployment access to the fresh install (looks good on paper anyway Smiley Happy

).

Current server:

Get a list of users in od-user role (write list to txt file)
iwodauthorize -r list od-user
Get a list of deployments foreach user (write list to txt file)
iwodauthorize -d list INTERWOVEN\\bill

New server:

Add users the od-user role (read from txt file)
iwodauthorize -r add od-user INTERWOVEN\\bill
Grant deployment authorization to users (read from txt file)
iwodauthorize -d add INTERWOVEN\\bill deploy1 deploy2

Adam Stoller

Hmm - yeah, I guess since you have to be an od-user to be given explicit rights to a deployment the '-d list' option (which, I admit, I missed seeing) can certainly be used to help generate sufficient information to re-create it.

However, it still looks like a good feature request for something a bit less hackish to perform this kind of operation...