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 woes

SueHernandez

We have copied a backing store from OLD_SERVER (TeamSite 6.0.0 Build 24951) to NEW_SERVER (TeamSite 6.7.1.0 Build 60750 - clean install).

While the backing store "just works," without any changes, and has kept both Version History and Extended Attributes, we have read time and again, run iwmigrate, just in case.

So we try to do just that, and we can't get it to work. I have added a local user "administrator" and added that user to the administrators group; I have added the account I'm using to log in to NEW_SERVER as a master. However, the latest and greatest errors are as follows:

=== Command Line: ===

\TeamSite\bin>iwmigrate -m Y:/default -o E:\migrated-iw-store -b /default/main -g > E:\migration_log.txt 2>&1

=== Log Excerpt: ===

iwmigrate: 6.7.1 Build 60732 Interwoven 20061006
***************************************************************
***************************************************************
Before running this command, please ensure that:

1) You have obtained the latest version of iwmigrate from
   support.interwoven.com.
***************************************************************
***************************************************************
Command line: iwmigrate -m Y:/default -o E:\migrated-iw-store -b /default/main -g 
[Mon Mar 19 15:07:39 2007] No locale specified, using native locale for this system
[Mon Mar 19 15:07:39 2007] Converted backing store location is E:\migrated-iw-store
[Mon Mar 19 15:07:39 2007] Configured backing store on system is E:\iw-store
[Mon Mar 19 15:07:39 2007] Starting backing store environment
[Mon Mar 19 15:07:42 2007] Converting branch /default/main
[Mon Mar 19 15:07:42 2007] Begin replay branch /default/main from first edition (INITIAL) to most recent (Pre_iwmigrate)
[Mon Mar 19 15:07:42 2007] Creating branches needed for /default/main
[Mon Mar 19 15:07:42 2007] Verifying chain of editions to be replayed.
[Mon Mar 19 15:07:42 2007] Check edition 0x00002010000000000000011a
[Mon Mar 19 15:07:42 2007] Found edition INITIAL 0x00002010000000000000011a in input backing store
[Mon Mar 19 15:07:42 2007] Edition INITIAL already exists in output backing store
[Mon Mar 19 15:07:42 2007] Skipping this edition.
[Mon Mar 19 15:07:42 2007] Check edition 0x0000201000000000003f43e7
[Mon Mar 19 15:07:42 2007] Found edition Pre_iwmigrate 0x0000201000000000003f43e7 in input backing store
[Mon Mar 19 15:07:42 2007] Verification of edition chain successful.
[Mon Mar 19 15:07:42 2007] Created temporary workarea /main/WORKAREA/temp_workarea
[Mon Mar 19 15:07:42 2007] Begin replay of editions
[Mon Mar 19 15:07:42 2007] Found edition Pre_iwmigrate 0x0000201000000000003f43e7
[Mon Mar 19 15:07:42 2007] Found previous edition in output backing store
[Mon Mar 19 15:07:42 2007] REPLAY EDITION Pre_iwmigrate 0x0000201000000000003f43e7
[Mon Mar 19 15:07:42 2007] Begin submit event replay for Pre_iwmigrate 0x0000201000000000003f43e7
[Mon Mar 19 15:07:42 2007] End Submit event replay for Pre_iwmigrate 0x0000201000000000003f43e7
[Mon Mar 19 15:07:42 2007] 1 submit events were found
[Mon Mar 19 15:07:42 2007] PUBLISHED WORKAREA TO EDITION Pre_iwmigrate
[Mon Mar 19 15:07:42 2007] Replay of edition Pre_iwmigrate complete
[Mon Mar 19 15:07:42 2007] Done with replay of editions
[Mon Mar 19 15:07:42 2007] Edition replay complete for INITIAL to Pre_iwmigrate
[Mon Mar 19 15:07:42 2007] Converting branch /default/main/test
[Mon Mar 19 15:07:42 2007] Begin replay branch /default/main/test from first edition (INITIAL) to most recent (Pre_iwmigrate)
[Mon Mar 19 15:07:42 2007] Creating branches needed for /default/main/test
[Mon Mar 19 15:07:42 2007] Found branch /main/test in input backing store
[Mon Mar 19 15:07:42 2007] Branch /main/test is not found in output backing store, will create
[Mon Mar 19 15:07:42 2007] Created branch /main/test in output backing store
[Mon Mar 19 15:07:42 2007] Verifying chain of editions to be replayed.
[Mon Mar 19 15:07:42 2007] Check edition 0x000020100000000000000135
[Mon Mar 19 15:07:42 2007] Found edition INITIAL 0x000020100000000000000135 in input backing store
[Mon Mar 19 15:07:42 2007] Check edition 0x000020100000000000000627
[Mon Mar 19 15:07:42 2007] Found edition ed_0001 0x000020100000000000000627 in input backing store
[Mon Mar 19 15:07:42 2007] Check edition 0x0000201000000000000c5b02
[Mon Mar 19 15:07:42 2007] Found edition Pre_iwmigrate 0x0000201000000000000c5b02 in input backing store
[Mon Mar 19 15:07:42 2007] Verification of edition chain successful.
[Mon Mar 19 15:07:42 2007] Created temporary workarea /main/test/WORKAREA/temp_workarea
[Mon Mar 19 15:07:42 2007] Begin replay of editions
[Mon Mar 19 15:07:42 2007] Found edition INITIAL 0x000020100000000000000135
[Mon Mar 19 15:07:42 2007] REPLAY EDITION INITIAL 0x000020100000000000000135
[Mon Mar 19 15:07:42 2007] Begin submit event replay for INITIAL 0x000020100000000000000135
[Mon Mar 19 15:07:42 2007] End Submit event replay for INITIAL 0x000020100000000000000135
[Mon Mar 19 15:07:42 2007] 1 submit events were found
[Mon Mar 19 15:07:42 2007] PUBLISHED WORKAREA TO EDITION INITIAL
[Mon Mar 19 15:07:42 2007] Replay of edition INITIAL complete
[Mon Mar 19 15:07:42 2007] Found edition ed_0001 0x000020100000000000000627
[Mon Mar 19 15:07:42 2007] REPLAY EDITION ed_0001 0x000020100000000000000627
[Mon Mar 19 15:07:42 2007] Begin submit event replay for ed_0001 0x000020100000000000000627
[Mon Mar 19 15:07:43 2007] Error opening file Y:\default\.raw\0x000010080000062700000623
Permission denied
[Mon Mar 19 15:07:43 2007] Warning, incomplete copy for file /main/test/EDITION/ed_0001/folder_1/test1.html
[Mon Mar 19 15:07:44 2007] Status: 100 files + 345730 bytes copied
GUI cloned 100 bytes 345730 errors 1 warnings 0
[Mon Mar 19 15:07:45 2007] Status: 200 files + 653697 bytes copied
GUI cloned 200 bytes 653697 errors 1 warnings 0
[Mon Mar 19 15:07:46 2007] Status: 300 files + 915180 bytes copied
GUI cloned 300 bytes 915180 errors 1 warnings 0
[Mon Mar 19 15:07:47 2007] Status: 400 files + 1277220 bytes copied
GUI cloned 400 bytes 1277220 errors 1 warnings 0
[Mon Mar 19 15:07:48 2007] Error opening file Y:\default\.raw\0x000010080000062700000623
Permission denied
[Mon Mar 19 15:07:48 2007] Warning, incomplete copy for file /main/test/EDITION/ed_0001/folder_1/test1.html
[Mon Mar 19 15:07:48 2007] End Submit event replay for ed_0001 0x000020100000000000000627
[Mon Mar 19 15:07:48 2007] 16 submit events were found
[Mon Mar 19 15:07:48 2007] PUBLISHED WORKAREA TO EDITION ed_0001
[Mon Mar 19 15:07:48 2007] Replay of edition ed_0001 complete

Basically we have "Permission denied" all the way down just about every single branch.

(1) Can anyone point me to the next step of what to check for permissions or requirements such that iwmigrate will actually run;

-and-

(2) We ran a tool provided by tech support called chkfatdir.ipl, and it analyzed our backing store. It said we were under the "threshold" and "didn't need to run iwmigrate." Does anyone have comments on this? Anyone run into this and regret not running iwmigrate later?

Thanks in advance for any comments and suggestions.
Susan H

Find more posts tagged with

Comments

Adam Stoller

We have copied a backing store from OLD_SERVER (TeamSite 6.0.0 Build 24951) to NEW_SERVER (TeamSite 6.7.1.0 Build 60750 - clean install).

While the backing store "just works," without any changes, and has kept both Version History and Extended Attributes, we have read time and again, run iwmigrate, just in case.

This was the recommendation from Support after they started noticing some problems from customers who followed their earlier advice about just copying the store over and letting the TeamSite server "upgrade" the backing store by itself.

So we try to do just that, and we can't get it to work. I have added a local user "administrator" and added that user to the administrators group; I have added the account I'm using to log in to NEW_SERVER as a master. However, the latest and greatest errors are as follows:
[...]

When you say you added a local user "administrator" - do you mean you added a real, full-fledged Administrator account on the system, or you added a user account which just happens to have the name "administrator"?

A real, full-fledged Administrator account should work I'd think - as long as you were logged in with that account when you attempted to perform the migration.

Basically we have "Permission denied" all the way down just about every single branch.

(1) Can anyone point me to the next step of what to check for permissions or requirements such that iwmigrate will actually run;

-and-

(2) We ran a tool provided by tech support called chkfatdir.ipl, and it analyzed our backing store. It said we were under the "threshold" and "didn't need to run iwmigrate." Does anyone have comments on this? Anyone run into this and regret not running iwmigrate later?

Thanks in advance for any comments and suggestions.
Susan H

I'd check with Support regarding both those questions. I haven't done an iwmigrate on Windows in a while, so its possible I'm forgetting some "trick" but it basically looks right as long as you're running as [the real-deal] Administrator. With regard to the chkfatdir.ipl - I have a feeling that may be a different issue and not the same as the issue about whether or not you need to run iwmigrate for an upgrade of a pre-existing backing store.

CRB

did you check the permissions on that branch?

i did iwmigrate to 6.5... but i run iwidmap first, then i run iwmigrate and i had no problems.. based on interwoven support and since you are moving from different server, i think you should run iwusermigrate / iwaccessmigrate / iwidmap before you do iwmigrate...

SueHernandez

When you say you added a local user "administrator" - do you mean you added a real, full-fledged Administrator account on the system, or you added a user account which just happens to have the name "administrator"?

A real, full-fledged Administrator account should work I'd think - as long as you were [highlight]logged in with that account[/highlight] when you attempted to perform the migration.I'd check with Support regarding both those questions. I haven't done an iwmigrate on Windows in a while, so its possible I'm forgetting some "trick" but it basically looks right as long as you're running as [the real-deal] Administrator.

Well, we started off not having any account called "administrator." Because of earlier problems running iwmigrate (something like couldn't connect to store, if I remember), we added an account on the box, NEW_SERVER\administrator. Then I added that user to the NEW_SERVER\Administrators group.

However, I logged in using MYDOMAIN\MyDomainAccount which is a member of the NEW_SERVER\Administrators group. Duh, I didn't even think of trying to log in using the administrator account.

Will try that and report back (server is down right now). Thanks so much for the very quick response.

I think you should run iwusermigrate / iwaccessmigrate / [highlight]iwidmap[/highlight] before you do iwmigrate...

Successfully ran iwusermigrate and iwaccessmigrate; however we did not yet run iwidmap, although I've heard of it. Thanks for the advice, and I'll check on that too.

I know for a fact my domain account does not have permissions on every branch, but I thought that because I was in the Masters role, it would be OK.

-- Sue

Adam Stoller

Well, we started off not having any account called "administrator." Because of earlier problems running iwmigrate (something like couldn't connect to store, if I remember), we added an account on the box, NEW_SERVER\administrator. Then I added that user to the NEW_SERVER\Administrators group.

However, I logged in using MYDOMAIN\MyDomainAccount which is a member of the NEW_SERVER\Administrators group. Duh, I didn't even think of trying to log in using the administrator account.

Will try that and report back (server is down right now). Thanks so much for the very quick response.

Successfully ran iwusermigrate and iwaccessmigrate; however we did not yet run iwidmap, although I've heard of it. Thanks for the advice, and I'll check on that too.

I know for a fact my domain account does not have permissions on every branch, but I thought that because I was in the Masters role, it would be OK.

-- Sue

master role applies to TS activities, access rights applies to file system activities. In cases of iwmigrate you generally want to make sure that you have both covered.

Migrateduser

Thats correct. For iwmigrate, being master itself is not sufficient. You will need to have access via the file system as well. One way to accomplish this is to add the user account under which you are running iwmigrate to the Teamsite Web Preview group.

SueHernandez

Thats correct. For iwmigrate, being master itself is not sufficient. You will need to have access via the file system as well. One way to accomplish this is to add the user account under which you are running iwmigrate to the Teamsite Web Preview group.

Oh my gosh, it looks like this is getting me somewhere. So far, I have not had the 1 gazillion permission denied errors. Now let's see if it completes nicely. Thanks so much for the tip.

So what I did was (1) log in as administrator; (2) run iwidmap to fix the permissions for things like Local Admin on the old server; (3) add administrator to the local Teamsite Web Preview group.

Thanks to all who offered advice.

SueHernandez

Well, after ages of trials, still no success. I have finally gotten iwmigrate working to some extent, thanks to all the suggestions here, but there's still errors, and I can't seem to activate the new store.

Here's a simple question - let's say your original store is called E:\iw-store, and you migrated to E:\migrated-iw-store. How do you then activate the new store? I thought you had to only shut down the teamsite service, rename iw-store to something like iw-store-old, and rename migrated-iw-store to iw-store, then restart the service.

When I do that, I get the following errors in

\TeamSite\local\logs\iw-trace.log:

[Fri Apr 06 09:35:16 2007] Initialized store 0x1 at "E:\iw-store\workflow" (version=300008, next id=0x200).
[Fri Apr 06 09:35:16 2007] ERROR: Invalid workflow registry.
[Fri Apr 06 09:35:16 2007] Failed to start store manager.

The service then shuts itself down. Anyone want to take a stab at this?

Thanks again.
Sue

Adam Stoller

Well, after ages of trials, still no success. I have finally gotten iwmigrate working to some extent, thanks to all the suggestions here, but there's still errors, and I can't seem to activate the new store.

Here's a simple question - let's say your original store is called E:\iw-store, and you migrated to E:\migrated-iw-store. How do you then activate the new store? I thought you had to only shut down the teamsite service, rename iw-store to something like iw-store-old, and rename migrated-iw-store to iw-store, then restart the service.

When I do that, I get the following errors in \TeamSite\local\logs\iw-trace.log:
[Fri Apr 06 09:35:16 2007] Initialized store 0x1 at "E:\iw-store\workflow" (version=300008, next id=0x200).
[Fri Apr 06 09:35:16 2007] ERROR: Invalid workflow registry.
[Fri Apr 06 09:35:16 2007] Failed to start store manager.
The service then shuts itself down. Anyone want to take a stab at this?

Thanks again.
Sue

If you do a directory listing of E:\iw-store-old (what was iw-store) - what do you see? If you do a directory listing of E:\iw-store (what was migrated-iw-store) what do you see?

It's possible that you may be off a directory level somewhere and that you may be needing to move e:\iw-store\default aside and move e:\migrated-iw-store to e:\iw-store\default -- or something like that)

SueHernandez

If you do a directory listing of E:\iw-store-old (what was iw-store) - what do you see? If you do a directory listing of E:\iw-store (what was migrated-iw-store) what do you see?

It's possible that you may be off a directory level somewhere and that you may be needing to move e:\iw-store\default aside and move e:\migrated-iw-store to e:\iw-store\default -- or something like that)

As always, thanks for your quick reply. My directories look like this:

iw-store (the original, pre-migrated store)


  default  (dir)
  events  (dir)
  iwadmin (dir)
  iwserver (dir)
  workflow (dir)
  STOREID (file)
  STOREID_ (file)
  StoreRegistry (file)
  TSMigrateAccess (file)
  TSRunning (file)

migrated-iw-store


  d0 (dir)
  default (dir)
  events (dir)
  FORMAT (dir)
  inodes (dir)
  iwadmin (dir)
  iwserver (dir)
  workflow (dir)
  ... a bunch of files, more than other:
    BATCHJOBS; BKGJOBS; BRANCHES; groupidtoken; ID; LOCKFILE.......etc

Wait a minut, this is strange: inside the E:\migrated-iw-store\default directory, there is a d0 directory, but that only has another d0 directory, which has a d1 subdirectory, which has nothing in it whatsoever. The d0 directory in the root path is the one with everything.

So, wierd - did iwmigrate move the files into the wrong path? I guess I'm going to try copying the d0 directory in. Thanks for the tip.

SueHernandez

Wait a minute, there's nothing in the workflow folder on the migrated folder. There's a folder called d0, which has a subfolder d0, which has a subfolder d1, but that has nothing in it.

I wonder what's supposed to be in here. Same copy as the stuff in Default?

Adam Stoller

As always, thanks for your quick reply. My directories look like this:

iw-store (the original, pre-migrated store)
  default  (dir)
  events  (dir)
  iwadmin (dir)
  iwserver (dir)
  workflow (dir)
  STOREID (file)
  STOREID_ (file)
  StoreRegistry (file)
  TSMigrateAccess (file)
  TSRunning (file)
migrated-iw-store
  d0 (dir)
  default (dir)
  events (dir)
  FORMAT (dir)
  inodes (dir)
  iwadmin (dir)
  iwserver (dir)
  workflow (dir)
  ... a bunch of files, more than other:
    BATCHJOBS; BKGJOBS; BRANCHES; groupidtoken; ID; LOCKFILE.......etc
Wait a minut, this is strange: inside the E:\migrated-iw-store\default directory, there is a d0 directory, but that only has another d0 directory, which has a d1 subdirectory, which has nothing in it whatsoever. The d0 directory in the root path is the one with everything.

So, wierd - did iwmigrate move the files into the wrong path? I guess I'm going to try copying the d0 directory in. Thanks for the tip.

Is this one of those migrations where the wrong path arguments were used the first time or two before iwmigrate actually seemed to work?
If so - you should have cleaned out the target area before running it each time.

Pretty much everything you see in migrated-iw-store belongs inside iw-store/default - so you probably need to do something like:

There may be some more steps too - but frankly, you'd be better off (IMO) if you wiped e:\migrated-iw-store and re-did the migration again...

CRB

if you are going to redo the migration this is the cmd i run and it works perfect for me...

Iwmigrate –m Y:/default –o X: /new-iw-store/default –b /default/main –g > migration_log.txt 2>$1

this migrates from my

\iw-store\default and creates new store in X: /new-iw-store\default and it maintains everything under default.

then i shutdown teamsite and rename iw-store to iw-store_old and bring the new-iw-store over and rename it iw-store...

Corey_Null

Sorry to HiJack.
Can someone tell me what the -g does? I can't find it in the 6.5 or 6.7 Command-Line Tools guide, and a search of "iwmigrate -g" brings up several returns (this being the first).

SueHernandez

if you are going to redo the migration this is the cmd i run and it works perfect for me...

Iwmigrate –m Y:/default –o X: /new-iw-store/default –b /default/main –g > migration_log.txt 2>$1

this migrates from my \iw-store\default and creates new store in X: /new-iw-store\default and it maintains everything under default.

then i shutdown teamsite and rename iw-store to iw-store_old and bring the new-iw-store over and rename it iw-store...

Thanks to everyone for the tips. I, also, incidentally don't know what the -g does.

I am going to try using this command line.

*** NOTE TO ALL: We thought we could get away with not running iwmigrate; however almost once every other day, team site Service is "experiencing a problem and shutting down" and we're not even in production with this yet.

Will post results.

Corey_Null

I, also, incidentally don't know what the -g does.

Someone from IW support told a coworker that it causes iwmigrate to be silent and not ask any "Are you sure" questions.

nipper

Someone from IW support told a coworker that it causes iwmigrate to be silent and not ask any "Are you sure" questions.

Well that is really freaking intuitive.

CRB

yeah, i heard that too when i used it... but i actually tried to run it without the -g, it didnt/doesnt print anything in the log file and it doesnt create the new-iw-store (i guess migration is not happening?).. when i use -g i see the new store being created immediatly and i see info in the log file (the migration is happening)

Adam Stoller

Sorry to HiJack.
Can someone tell me what the -g does? I can't find it in the 6.5 or 6.7 Command-Line Tools guide, and a search of "iwmigrate -g" brings up several returns (this being the first).

It stands for GUI-mode (as opposed to the default command-line mode) - as they didn't want the script outputting a command-line prompt if the program was being run from within a CGI.

SueHernandez

IT WORKED!!!!!!!!!

Thanks to all the great tips and help here.

So to summarize for anyone who is doing the same thing, I'll list my steps here. These are the steps necessary for me, and may be different for you. Again, I was going from a TeamSite 6.0 version on Server A to a brand new installation of TeamSite 6.7 version on Server B.


(1)  On Server B, install IIS.  I didn't know this at first - it's where
     it hosts the "iwmount" or Y virtual drive.  If you have it installed 
     BEFORE you install TeamSite, it configures it for you.
(2)  Pick a weekend and shut down your production system, on server A, 
     by shutting down the TeamSite service.  Copy the entire iw-store 
     directory from your production system A over to your new server B.
(3)  Obviously, restart your production system after you're done copying 
     :-).  Optionally, like in my case where we're doing lots of testing, 
     we also took another copy of the store BEFORE we started fiddling with
     it, in case we needed to "revert" after yet another trial of iwmigrate.
(4)  Move your newly copied store on Server B to the location you will 
     want it in permanently.  Example, E:\iw-store
(5)  Create a License directory at your "iw-home" - the location where 
     you're going to install TeamSite.  For example, \TeamSite would be
     iw-home.  Create a \TeamSite\etc directory.  Move your TS.lic file
     in there.  (This is the license file for TeamSite, and if you don't 
     have one, there's instructions in the installation routine which 
     explains how to generate one on-line.)
(6)  Install TeamSite 6.7 on Server B.  Note, since you already have the 
     store there, it doesn't create a default store for you.  As previously
     mentioned, if you have installed IIS, it prompts you to configure it 
     for you.
(7)  Install OpenDeploy on Server B
(8)  On Server B, believe it or not, create an Administrator account, 
     named - no really - Administrator.  Add Administrator to the Local 
     Group called TeamSite Web Preview.
(8)  Copy over the *.uid files from iw-home\conf\roles into the same 
     directory in server B.  Run the command line tool iwusermigrate.  This
     will add your authors, editors, etc. as logins into the TeamSite server.  
(9)  Copy your files in iw-home\local\config\wft.  These are your workflow 
     files. You may have them in a \solutions subdirectory.  We also copied 
     available_templates.cfg just as-is.
(10) At this point, we had to "fix up" submit.cfg.  I forget where this is,
     and I'm not familiar with what it's used for, but it hindered the 
     iwmigrate. We had to ensure that no users were listed in that file that
     didn't exist.
(11) Copied OpenDeploy *.xml files from od-home\conf over to Server B.
(12) Modified od-home\etc odbase.xml file and odnodes.xml file to reference
     Server B and not server A
(13) Went to server on which OpenDeploy Receiver was installed.  Our 
     version is 5.x.  Modified odrcvr.xml file to add the "node" and 
     "allowedDirectories" elements for Server B, so OpenDeploy would allow
     traffic from the new server
(14) Ran iwidmap for BOTH users and groups to updated any necessary user 
     IDs that didn't map correctly.
(15) Published an edition on every single branch.  To help this, I wrote 
     a simple C# program to "walk" the directory tree on the Y drive, and 
     created a text script.  I then used as a batch file to do this. 
     Syntax is:
       iwpublish -g /default/main/branch STAGING "Before IWMigrate"
       iwpublish -g /default/main/branch/sub-branch STAGING "Before IWMigrate"
       etc
(15) Using the Administrator account, ran the following command 
     line for iwmigrate NOTE this is a bit different than KB 55358 states:
       iwmigrate -m Y:/default -o E:\migrated-iw-store\default -b 
       /default/main -g > E:\migration_log.txt 2>&1
(16) Stopped TeamSite service on Server B, renamed iw-store to iw-store-ORIG,
     and renamed migrated-iw-store to iw-store.  Restarted service.

There you go. I hope this helps someone. Incidentally, our store was around 50 GB and it only took 15 hours to run iwmigrate. Also, there's a command line tool called iwaccessmigrate that creates tons of custom groups for you based on your permissions already set on the file system.

nipper

Well, congratulations are in order. Only 15 steps. Joy. Smiley Very Happy