nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

IWMIGRATE: Beating a dead horse

Bjorn

First off, I have read the docs and nearly every thread on devnet. I only say that to head off any RTFM comments.

I want to know if the following is possible using IWMIGRATE. We'd be using 6.5 on a Windows box.

1 - Create a new backing store from an existing backing store.
2 - Take another backing store and add that store to the newly created backing store.

Basically, we want to take 2 different, very large stores on 2 different servers and merge them into one single (extra large)store, obviously on a single server. Each store has many branches/subbranches.

Sample tree:

store
___level1aof5
______level2aof200
______level2bof200
_________level3aof5
____________workarea
_______________dirs
_______________files

I've read so many different posts I'm not sure what to think. Any ideas or thoughts would be appreciated.

I <i>have</i> RTFM.

Find more posts tagged with

Comments

Adam Stoller

First things that come to mind...

Are all of your users defined centrally, rather than using local disk accounts on the TeamSite server?
Are all your groups defined centrally, rather than using local disk groups on the TeamSite server?
(this would impact the ownership of files and directories because SIDs for local users and local groups on different servers would be different)

Are the branches *completely* different (besides 'main') or are, at least, the common branches "empty" branches (i.e. just contain sub-branches, no content)?
(iwmigrate will not, I believe, be able to handle "merge" issues)
(it's very difficult to tell from your post which branches came from which store)

Aside from the licensing issue that might surround the use of MultiStore functionality ...In theory, I believe that this should work - but the best way to tell would be through impirical evidence - i.e., backup your existing store (the one you will be migrating *into*) and try it.

I'm assuming that both servers are running 6.5 and both servers are running Windows (preferably the same version of Windows)

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Bjorn

Thanks for responding, fish.

All accounts and groups are domain based. So yes, centrally defined. That may alleviate some of the permission issues of which you were thinking.

In regards to the structure, both servers would have the path --> main/foo/clients, but the branches below "clients" are completely different between the 2 different stores.

We have been testing this on a dev server as you suggest, but are getting some inconsistent results, when we get results at all. We've tested it at 5.5.2, 6.1 and now 6.5 (all at different points in time over the past while). We get different types of errors when running it. It's never completed.

But I want to get a grasp if others have done someting similar before we'd continue on with it. The size of the stores makes it a time consuming test.

I <i>have</i> RTFM.

Bryant

Have you ever got this to work? I am trying on teamsite 552 in preparation to migration to 6x but I get permission problems with the files migrated and some files are not copied at all.

Thanks

gzevin

I'd just add a few comments/ Iwmigrate/imconvert work IMO only if the users have been following a strandard IWOV practice of content management - i.e. workareas in a branch are reflecting each other and are not pruned at all (this is the case in many situations, BTW). If this is not the case, one would have either files missing, or too many files...

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Migrateduser

Hi Bjorn,

I have done this successfully with both 6.1 and 6.5. The two gotchas have already been mentioned: permissions and branch structure. As long as any necessary iwidmapping is done and all the branches have unique names you should be fine. And, as iwmigrate has already nagged you about, make sure to use the latest version of iwmigrate. If you're running into issues I suggest opening a support case.

Viking

Adam Stoller

You forgot the other rule - make sure editions are created for those branches - as iwmigrate / iwconvert operate on editions.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

gzevin

This I considered as a default fact Smiley Happy

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU

Adam Stoller

It doesn't hurt to state the default facts either - as I've encountered a number of customers in the 5.x and pre-5.x days who didn't create editions because (a) they didn't understand their purpose, (b) thought they took up too much space in the backing store, and/or (c) were concerned about having too many editions on a branch [a real problem pre-5.5.2] and so instead of having a monthly edition or something that would be unlikely to hit the problematic limits - they didn't cut any editons.

Then you go to do their upgrade / migration / conversion and find that most of the files don't get transferred and/or you get tons of error messages because of the lack of editions.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

gzevin

in that case I would not bother with iwconvert/migrate at all. Just tar and tarnsfer the workareas....

another thing - IMO iwconvert should have taken into account 2 versioning models that exist in TeamSite .. so while playing editions, these tools should be able to transfer individual files' versions.....

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU