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; } } }

Branch migration issue

System

I have recently undertaken a migration of a specific branch using the iwmigrate CLT from Server A (TeamSite 6.7.1) to Server B (TeamSite 7.1).

It all seemed to work well, no errors were reported and logging in to CC-Pro on Server B I can see that the new branch is in the right place and all the content is available. Forms publishing, Tagging etc.. all seems to work as expected through the UI.

However, when I view the branch through the IFS (Y: drive), things get a little wierd. The Workarea shows up as a 0 byte size file and I can;t browse any further (event though I can browse the workarea and all content, subfolders, files etc.. through CC-Pro).

Likewise, the contents of the STAGING area and EDITIONS when browsed through IFS also look strange .. what should be folders also appear as 0 byte size files and all have odd windows file attributes associated with them (R, C, O etc..).

As I said, everything seemed to go well with the iwmigrate so I don't understand why I'm seeing such results in the IFS. Has anyone else had a similar experience with a scenario such as this?

thanks in advance

Find more posts tagged with

Comments

Adam Stoller

You migrated the content - but did you migrate the users/roles/access information?

You probably need to go through an iwidmap run or two (see the manual and Support KB articles for more information)

Migrateduser

Thank you for your quick response.

I probably should have mentioned it in the original post but yes I did carry out the iwidmap and when viewed in CC-pro all the users id's ownerships etc.. look exactly as we would expect them to so from that point of view everything looks correct. It's just that on the IFS it looks a little messed up.

I'll try the iwidmap again in case there was some remapping that may have been missed.

Bhargav Coca

Thank you for your quick response.

I probably should have mentioned it in the original post but yes I did carry out the iwidmap and when viewed in CC-pro all the users id's ownerships etc.. look exactly as we would expect them to so from that point of view everything looks correct. It's just that on the IFS it looks a little messed up.

I'll try the iwidmap again in case there was some remapping that may have been missed.

Well its a Windows system running on IIS, What I would do is reset the IIS. Bring down IIS and restart it, see if the Y-Drive is visible and browse there to the workarea which you migrated, and see if shows up nice now.

Thank You

ISCBorisB

Well its a Windows system running on IIS, What I would do is reset the IIS. Bring down IIS and restart it, see if the Y-Drive is visible and browse there to the workarea which you migrated, and see if shows up nice now.

Thank You

TeamSite SFS Virtual drive and mount (Y:\, iw-mount and whatnot) have nothing whatever to do to IIS or any other
Client Web Server you may want to use. Btw, Windows is not "...running on IIS" either, it's the other way around.

Bhargav Coca

TeamSite SFS Virtual drive and mount (Y:\, iw-mount and whatnot) have nothing whatever to do to IIS or any other
Client Web Server you may want to use. Btw, Windows is not "...running on IIS" either, it's the other way around.

My bad, if I was unclear in my previous post. What I was suggesting is that to check the IIS, I beleve if it is Windows Env, TeamSite would be using this App Server for mpunting its Y-Drive. So if at all he resets it it might resolve the issue. I do not see a reason if something works on UI doesn't work in the back.

Thank You

ISCBorisB

...I beleve if it is Windows Env, TeamSite would be using this App Server for mpunting[?] its Y-Drive..

TemSite does not use any Web Server whatever to create virtual SFS Drive. It's all done through iwserver.

Bhargav Coca

TemSite does not use any Web Server whatever to create virtual SFS Drive. It's all done through iwserver.

I agree with you, well i think we are thinking in same terms but some what little differently. Teamsite comes with inbuild Apache and is installed when TS is installed, this along with iwserver will actually build your Y-Drive taking it. I am more lookin it in a preview perspective, since the gentleman was seeing it in Ui and not in the Y-Drive. I wanna see if there is any way i can reset something here, I was going from IIS to may be using iwreset -a later if resetting IIS doesn't work.

Thats what I would do.

Thanks

Migrateduser

Thanks again for the replies and suggestions ..

I tried what you suggested and a few other things

IIS recycle didn't make any difference. I also tried resetting iwserver and carrying an iwreset -a, same result. In the end I rebooted the server but the result is still the same .. all looks good in CC-pro but still wierd in IFS.

I'm thinking that the next step would be to blow away the copied branch and try the iwmigrate again .. (documenting the steps in more detail this time!) .. I must have done something wrong during the original mirgation, just can't think what it could be

Migrateduser

Any updates on this? I have the same issue.

Migrateduser

Unfortunately not, I have tried a number of things but the results are the same.

I have decided now to migrate the entire content store from server A to server B rather than a single branch and then simply remove the redundant branches. I know the content store migration will work becasue I have carried this out before with no issues.

If you're not in a position to roll it back and try again then the only other option would be to escalate it to Autonomy support.

Thanks to everyone for their suggestios .. much appreciated.

Adam Stoller

I have decided now to migrate the entire content store from server A to server B rather than a single branch and then simply remove the redundant branches.

Remember to run iwfsshrink on the target of the migration after you're done (or in between runs of the migration) - as the iwmigrate process tends to create lots of redundant data that bloats the target backing store.