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 errors 2410

HKN1104

Hi
Recently we moved from 6.7.1 sp1 - 7.3.1 Windows environment.

When we ran iwmigrate. We got this error.

ERROR [err=2410], AddPermissionEntry failed for /default/main/**Branch**. Continuing.

Any Faced this issue.

Is this becoz of iwidmap.

Any pointers would be helpful

Thanks

Find more posts tagged with

Comments

mart2001

What's the command line arguments that you used to run iwmigrate?

HKN1104

What's the command line arguments that you used to run iwmigrate?

Hi Mart2001

Thanks for reply, this is the command i used to iwmigrate.
iwmigrate -o E:\new-iw-store -b /default/main -g > migration_log.txt 2>&1

Thanks

HKN1104

Anyone any idea about it.

Thanks

ISCBorisB

Hi Mart2001

Thanks for reply, this is the command i used to iwmigrate.
iwmigrate -o E:\new-iw-store -b /default/main -g > migration_log.txt 2>&1

Thanks

Have you run it as "Administrator"?
Was Target Store Inactaive?

HKN1104

Have you run it as "Administrator"?
Was Target Store Inactaive?

Thanks ISCBorisB for reply

Yes, ran it as an Admin
Created a New Folder and renamed it iw-stor-migrate and pointed it.

Thanks

ISCBorisB

Thanks ISCBorisB for reply

Yes, ran it as an Admin
Created a New Folder and renamed it iw-stor-migrate and pointed it.

Thanks

Ok, I'll try one more time....

You should have run iwmigrate Command as Windows local user named "Administrator",
not just any member of "Administrators" Group. Have you?

Command's Target Store should have been inactive, not just frozen. Has it been?

HKN1104

Ok, I'll try one more time....

You should have run iwmigrate Command as Windows local user named "Administrator",
not just any member of "Administrators" Group. Have you?

Command's Target Store should have been inactive, not just frozen. Has it been?

Thanks ISCBorisB for reply

Yes, Ran it as Windows local user named "Administrator" and target Node is not frozen.

Thanks

Adam Stoller

Thanks ISCBorisB for reply

Yes, Ran it as Windows local user named "Administrator" and target Node is not frozen.

Thanks

Target node is not frozen - but is inactive too? (e.g.: either entire TeamSite service is stopped, or the particular backing store was deactivated with iwstoreadm -d) - yes?

(just trying to clarify)

Adam Stoller

Hi Mart2001

Thanks for reply, this is the command i used to iwmigrate.
iwmigrate -o E:\new-iw-store -b /default/main -g > migration_log.txt 2>&1

Thanks

I'm not entirely sure where /default/main's backing store is located and what (if anything) is in E:/new-iw-store, but from my past experiences, where I have a copy of an older-version-of-TeamSite backing store (e.g.: "6.5" - "active") mounted on a newer-version-of-TeamSite server ("inactive"), the command I tend to use is:

iwmigrate -g -b /65/main/branch-name -o E:/new-iw-store/default -d

The '-d' flag prevents recursing through the entire source backing store - as doing so can cause disk space issues since iwmigrate causes lots of duplicate data to be written to the target store - and thus you need to run iwfsshrink after doing iwmigrate and you may need to do several rounds of one-and-then-the-other depending on how many versions of how much content in how many branches you are migrating.

The argument for the '-b' flag is the vpath of the source of content to be migrated.

The argument for the '-o' flag is the file system path of the specific archive's backing store location. So, even if you decide to leave off the specific branch name in the '-b' flag and omit the '-d' flag - you still need to fix the argument for the '-o' flag.

HKN1104

Target node is not frozen - but is inactive too? (e.g.: either entire TeamSite service is stopped, or the particular backing store was deactivated with iwstoreadm -d) - yes?

(just trying to clarify)

Thanks Ghoti

Store is not deactivated nor frozen.

These are the steps that i used for iwmigrate:
Just to make sure, these are correct steps or something was missing.

1) Created New Empty folder (xyz New iw-store).

2) Ran command iwmigrate -o E:\New-iw-store -b /default/main -g > migration.txt 2>&1 with Windows Local Administrator.

After 19 hours, I saw migration.txt file with
Iwmigrate succeeded.

ERROR err(2410): AddPermissionEntry failed for /default/main/**Branch**. Continuing.

So pointed new-iw-store and checked, branches were not seen, when i pointed out new-iw-store.

If Pointed to Old Store, I see all branches, Workareas and everything.

When i see error codes for 2410, It says: psx_ENOGROUP No such group" .

Thanks

HKN1104

I'm not entirely sure where /default/main's backing store is located and what (if anything) is in E:/new-iw-store, but from my past experiences, where I have a copy of an older-version-of-TeamSite backing store (e.g.: "6.5" - "active") mounted on a newer-version-of-TeamSite server ("inactive"), the command I tend to use is:
iwmigrate -g -b /65/main/branch-name -o E:/new-iw-store/default -d
The '-d' flag prevents recursing through the entire source backing store - as doing so can cause disk space issues since iwmigrate causes lots of duplicate data to be written to the target store - and thus you need to run iwfsshrink after doing iwmigrate and you may need to do several rounds of one-and-then-the-other depending on how many versions of how much content in how many branches you are migrating.

The argument for the '-b' flag is the vpath of the source of content to be migrated.

The argument for the '-o' flag is the file system path of the specific archive's backing store location. So, even if you decide to leave off the specific branch name in the '-b' flag and omit the '-d' flag - you still need to fix the argument for the '-o' flag.

Oh...WOW....Awesome...

It worked...Thanks a lot Ghoti...

Ghoti ++

Thanks

HKN1104

I'm not entirely sure where /default/main's backing store is located and what (if anything) is in E:/new-iw-store, but from my past experiences, where I have a copy of an older-version-of-TeamSite backing store (e.g.: "6.5" - "active") mounted on a newer-version-of-TeamSite server ("inactive"), the command I tend to use is:
iwmigrate -g -b /65/main/branch-name -o E:/new-iw-store/default -d
The '-d' flag prevents recursing through the entire source backing store - as doing so can cause disk space issues since iwmigrate causes lots of duplicate data to be written to the target store - and thus you need to run iwfsshrink after doing iwmigrate and you may need to do several rounds of one-and-then-the-other depending on how many versions of how much content in how many branches you are migrating.

The argument for the '-b' flag is the vpath of the source of content to be migrated.

The argument for the '-o' flag is the file system path of the specific archive's backing store location. So, even if you decide to leave off the specific branch name in the '-b' flag and omit the '-d' flag - you still need to fix the argument for the '-o' flag.

Thanks a lot Ghoti for explaining it in brief.

Thanks

HKN1104

I'm not entirely sure where /default/main's backing store is located and what (if anything) is in E:/new-iw-store, but from my past experiences, where I have a copy of an older-version-of-TeamSite backing store (e.g.: "6.5" - "active") mounted on a newer-version-of-TeamSite server ("inactive"), the command I tend to use is:
iwmigrate -g -b /65/main/branch-name -o E:/new-iw-store/default -d
The '-d' flag prevents recursing through the entire source backing store - as doing so can cause disk space issues since iwmigrate causes lots of duplicate data to be written to the target store - and thus you need to run iwfsshrink after doing iwmigrate and you may need to do several rounds of one-and-then-the-other depending on how many versions of how much content in how many branches you are migrating.

The argument for the '-b' flag is the vpath of the source of content to be migrated.

The argument for the '-o' flag is the file system path of the specific archive's backing store location. So, even if you decide to leave off the specific branch name in the '-b' flag and omit the '-d' flag - you still need to fix the argument for the '-o' flag.

Hi Ghoti

After using this command, iwmigrate -g -b /65/main/branch-name -o E:/new-iw-store/default -d

It successfully created branches and all sub branches. It is did not copy all the files in branches. It is creating folders and all stuff.. For fewer branches, i see, its creating with temporary_workarea with empty directory with no files copied.

Any Idea about it.

Any pointers would be helpful

Thanks

Adam Stoller

Hi Ghoti

After using this command, iwmigrate -g -b /65/main/branch-name -o E:/new-iw-store/default -d

It successfully created branches and all sub branches. It is did not copy all the files in branches. It is creating folders and all stuff.. For fewer branches, i see, its creating with temporary_workarea with empty directory with no files copied.

Any Idea about it.

Any pointers would be helpful

Thanks

The temp_workarea is used by iwmigrate to perform all of its actions and maintain state for incremental migrations performed later (as part of a multi-day cut-over strategy) - do NOT touch the temporary workarea.

The reason you might get empty workareas and/or empty directories in the workareas is usually due to having not submitted files on those branches or in those directories in those branches and/or not having created named editions on those branches prior to running iwmigrate.

If you are going to do a series of incremental migrations (i.e.: you migrate the store to a new server and test things out there while folks are still using the original server) - remember to make a backup of the new backing store BEFORE you make any changes to any files within it - as you will need that point-in-time copy of the backing store in order to perform the incremental migration. Once you modify the target store, you will no longer be able to run another migration for whatever branch you modified - until / unless you restore the point-in-time copy of the store from just after the previous migration.

Also make sure to capture ALL output from the migration process into a log file (or series of log files, one per branch) so that you can review the output to figure out if something prevented it from performing the migration.

Additionally, it is recommended that you run iwfsck on the original store before you copy it to the new server; run iwfsck on the copy of the store on the new server after you mount it but before you migrate from it; and run iwfsck (as well as iwfsshrink) on the target store after you perform the migration - to make sure that there are no problems with the backing store before or after the migration process.