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

Migratign to a new server

13adam13

Hey. I am trying to migrate my current TS(5.5.2) from one W2K server to another. I restored the backing store from tape, and used the iwidmap to remap all of the local users (most are domain, but there are a few stragglers).

This seemed to work fine, as the file owners and branch owners are showing the same on the new server as the old. However, the workareas are showing to be owned by "Everybody" and the "TS Web Preview" user, when they should be a lot more restrictive.

Is there a step that I am missing, or is this a bug?

Thanx a bunch for any insight,
--Adam

--Adam Wilson
Senior Programmer

Find more posts tagged with

Comments

TJRees

Hey Adam,

We are about to migrate from one w2k to another as well...and was wondering how yours went. First off, did you also have to manually copy the workareas or did you end up with temp workareas that were owned by EVERYONE? I believe this is what happened to us after converting the BS to TS 552. Any feedback you can give me will be most appreciated!!!

13adam13

I would have to say that the migration went well, overall.

The hardest part of the whole process was actually the fact that the new box had a different name than the old, so I had to search through all of the files on the system for any reference to the old system (or IP Address, for that matter). Most of what I found were related to e-mails being sent around by external tasks in our workflows.

These kinds of hard-coded references to the name of a machine is the kind of thing that I would not have programmed in, but that bring up the second hard part of the migration. I walked in the front door here, and almost immediately was put to the taskof migrating the servers. There were tons of customizations that were hard to track down. Everything from new perl modules to different Oracle clients, and custom logging directories that had to be hand coded.

It took a while for us to have success because the first time that we went to make the switch, they just opted to change IP addresses on the machines to keep all of the DNS entries working. However, there were domain trust issues that arose when we changed the IP Address. This caused tons of problems, not the least of which being that although all users could log into the TS interface without issue, when that user attempted to modify anything on the file system, they were not allowed.

Then, after getting this resolved, and finding ALL references to the old machine name, everything was smooth. As I had to actually install TS, instead of migrate it, there were all the typical installation considerations, but not really any migration considerations with the application itself.

For the backing store, there was only one thing that I had to do to get everything working. First, ensure that all users from the old system were on the new system (while most of the users are domain accounts, not all of them were), and then use the iwidmap to export and then import the users. Beware if you have to bring users over from the old system to the new, your local admins my choose to rename such standard accounts as the Administrator account for security reasons, and whatever they rename it to may be different from one machine to the other.

Along with the backing store came all of the working areas, as well as all of the jobs, so we lost nothing in the transition. We upgraded the hardware in the process, so although it cost MANY hours for the migration process, I believe that it was worth the effort.

--Adam Wilson
Senior Programmer

TJRees

Thank you so much for the insights! I will make a note of these issues. Hopefully, we won't run into major problems. Our plan is to migrate to the new server, take the old one off the network and apply the original name to the new one. As far as IP addresses go, I will need to consult with our Systems Engineering team...But thanks again!

TJRees

Just came up with more questions...you mentioned that all workareas will migrate with the backing store...does this mean that the users do not need to do anything at all? For example, unlock files, submit files, etc. Thanks!

13adam13

The backing store contains all of that information, so there should not be any action required by your users.

Having said that, I tried to get my users to complete as many of the outstanding workflows as possible. There were two reasons,

I like to occasionally try to clean up all the pending jobs in the system. When there are huge amounts of them, loading the todo list, as well as some workflow functions, run much slower. If I didn't do anything to try to clean up the loose ends, the number of active workflows easily reaches +200.
The fewer "alive" workflows there are on the system, the smaller the backingstore is. This is also a good reason to occasionally try to do a sweep of modified files in workareas.
- I like to occasionally list modified on workareas, and look for files that are many months old, and ask the owners if they still want these modified files. Often times, they just didn't know how to get rid of them.

Neither of these reasons are directly related to moving to a new system, but it might be a good opportunity to clean some things up.

--Adam Wilson
Senior Programmer

abhishek_gupta

Hi,

I have gone through the posts of migration. Have some clarifications. We are using TS 5.5.2 (without any patches) on Solaris 8. I have around 100 MB of content only. Now I want to transfer/migrate the content to a new server with exactly the same configurations. There are no workflow tasks/locking etc in the current TeamSite.

Can I simply do iwfreeze on the current teamsite server and then copy the iw-store from old server and replace the
iw-store on the new server? Will this work and all the branches, workareas and the other folders/files would be replicated. Or do I have something more than this to do. This is what the Knowledge Base Article: 1256 says.

I hope doing this should also copy the extended attributes on the HTML pages and the DCR's too.

Bowker

a_g

I'm far from an expert on this topic, but with some experience. You should shut TS down. An iwfreeze still leaves files locked. On windows, shutting down all the interwoven services would be enough, on Unix, I'm assuming they run as daemons of some sort.

Scan 001.pdf.pdf

Scan 001.pdf.pdf (2).pdf

Scan 001.pdf.pdf (1).pdf

Scan 001.pdf.pdf.pdf

abhishek_gupta

Thanks for the info bowker.

So I assume that after stopping the TS Server, copying the iw-store from the old server and replacing it on the new server would work. This in turn would take care of the extended attributes too.

Edited by a_g on 10/07/03 06:20 AM (server time).

Bowker

Yup - everything is in the backing store, EA, workareas, active workflows...Don't forget other files like submit.cfg, all the config files for workflows, opendeploy, roles files...

The only issues you will have is (at least in the window's world) are SIDs being different if you are using any local user accounts instead of domain accounts. If you do there is an id mapping feature (iwmapid ?) that you will need. There's a bunch of other postings here talking about the id mapping utility.

abhishek_gupta

Thanks a ton!