TS 7.5 iw-cc.war failure with migrated content store

Hi,

We are in the process of migrating from TeamSite 7.3.1 on old server A to 7.5 on new server B. The guy who performed the last migration onto 7.3.1 is no longer available. The notes that he left us suggest that all we need to do is freeze the store on A, copy the whole iw-store folder across to B and then activate the store there.

Both servers are Windows 2008 R2 Enterprise, in the same domain. The content store location on both is I:\iw-store.

I have not found anything in the official HP guides that fits our scenario, i.e. "importing" an existing store into a fresh TeamSite install.

Directly after the installation of TeamSite 7.5 we are able to connect to ContentCenter and see the empty store that was created. But once we replace the original I:\iw-store with the copy taken from the old server ContentCenter fails to come up. There is an iw-cc.war.failed file in ApplicationContainer\standalone\deployments. If we revert back to the original store then ContentCenter is available again.

I have not found anything useful in the JBoss logs. Any suggestions what to look out for?

The admins state that the copy of the frozen store from the old server (using robocopy) was successful. Also my colleague ran iwfsck on it while we had it activated and nothing was reported.

Find more posts tagged with

Comments

Adam Stoller

You should run iwfsck on the copy of the store while TeamSite is down (inactive, not active as you seemed to indicate was done)
When you ran iwfsck, did you run it on the original server or the new server?
The TeamSite process on the new server should be down when you put the copy of the store into place, and then brought up afterwards (you weren't clear on whether you tried to put the copy in place while TeamSite was running)
I don't see how replacing the store would cause the creation (or removal) of an iw-cc.war.failed file - did you check the date on that file?

AndrewL

Sorry for not being clear on those points. I will have to check with my colleague whether TeamSite services were up or down during the iwfsck. The CLT Guide does not mention any requirement in this respect. However looking at the entry I guess a simple iwfsck with no further options will only have checked "areas and branches", so probably not very useful for what we wanted anyhow.

iwfsck was run on the new server, in an attempt to check that the result of the copy operation was ok. (The admins state that robocopy completed successfully but we wanted some kind of second opinion.)

Yes the processes were down when the copy was put in place. I'm fairly sure we should not have been able to move the original empty store aside if a running TeamSite still had any locks on it.

The timestamp of the iw-cc.war.failed file corresponds to the time when JBoss attempted the deployment. If I rename it to iw-cc.war.dodeploy to force a new deployment it ends up back as .failed with the current time.

This behaviour is reproducible over and over. Stop TeamSite, exchange the two iw-store folders, start TeamSite (and JBoss deploys the apps). With the empty store we can connect to ContentCenter and there is an iw-cc.war.deployed file indicating successful deployment of ContentCenter. With the copied store the web server returns a 404 error and we see the iw-cc.war.failed file.

I'm not sure if it is worth asking for another copy of the content store (80 GB, takes a while) or if we are just missing some detail once we have that store on the new server. The servers obviously have different hostnames, but all OS users are in the domain and the groups are non-OS. So I see no need to run anything like iwidmap -s.

AndrewL

Ok, so I've run "iwfsck -d" on the copied store while TeamSite was down and 0 errors were found, but I still think the copy is messed up somehow.

One thing that we had totally lost track of was to check not just the JBoss logs but also the regular TeamSite logs. In content_center.log I now found this:

com.interwoven.cssdk.common.CSException: (Edition /iwadmin/main/config/EDITION/INITIAL does not exist when creating workarea /iwadmin/main/config/WORKAREA/shared)

followed by a string of "Unknown Hopi error(No branch found)" which ultimately lead to Content Center curling up its toes.

Y:\iwadmin\main\config\EDITION is empty on the new server, whereas on the old server it does contain a folder named INITIAL.

So I guess we need to make another attempt at getting a clean copy of the content store from the old server.

Adam Stoller

Are you trying to replace the entire iw-store directory - or just the iw-store/default directory?

If you're going to 7.5 you need to leave everything else and just copy over the iw-store/default directory.

AndrewL

Thanks, that is it! We have been trying to replace the entire iw-store directory with the copy from 7.3.

With whole iw-store from the clean 7.5 installation and only iw-store/default from the copy Content Center starts up fine.

Maybe a silly question, but where is this documented??? I see now that we did not actually follow the Installation Guide which has the steps in the order first copy the content store, then perform the installation. Would that have made the difference? (The copy was taking so long that the project team urged us to begin the installation in parallel.)

What about existing workflows, tasks etc.? Can we copy over iw-store/workflow in the same way?

Adam Stoller

Copying over the workflow store is questionable at best. It might work, but it might not - any processes that were running as part of active workflows may or may not start up again automatically - which includes timing events for timeout transitions.

In general, it has been myexperience that you instruct all users to try to finish as many jobs as they can before the cut-over and be prepared to restart workflows afterwards - and don't bother trying to copy the workflow store.

AndrewL

Thanks. We will keep that in mind when the time comes to cutover the production system. I guess it is also a good chance to get rid of any abandoned jobs that are still lying around...