Teamsite(5.0.2) and OpenDeploy(4.2) Upgrade Path

Hi

Can anyone please share their expereince as to what is the best upgrade path? We have Teamsite 5.0.2 and OpenDeploy 4.2. And we are planning to upgrade them to the latest versions 5.5.x.

For opendeploy, is it better to reinstall Opendeploy 5.5.x?

Can anyone please point to any resources on this.

Thanks
Teamsite Guy

Find more posts tagged with

Comments

Adam Stoller

OpenDeploy 5.5.1 (and very soon, 5.6) should be installed into a *different* directory than OpenDeploy 4.x - for at least two reasons:
(1) they are very different versions of the product
(2) by doing so, you can work on phasing-in the upgrade; using 4.x along paths where you have not upgraded, and using 5.x where you have.

Depending on how many existing 4.x OpenDeploy servers ("Receivers") you have, the need to phase-in may be great, or non-existant. I'd suggest making sure you have an accurate diagram of the machines involved in your deployment strategy, and start from the source [Base Server] machines and work your way out to the target [Receiver] machines.

By keeping 4.x around during this process, the two versions can co-exist for the period of time in which the transition takes place (NOTE: you need to use a different *port* value for each version - the default port in 4.x was 1701, the default port for 5.x is 20014 - so if you're going through a firewall, you may need to temporarily punch an additional hole through it, and later you can block the "old" hole)

If you are using TeamSite-based deployments with OpenDeploy 4.2 you will want to upgrade OpenDeploy *before* upgrading TeamSite (there is a configuration option in OpenDeploy to allow it to work with TeamSite 5.0.x) - once you've gotten OpenDeploy 5.x installed and working, then upgrade TeamSite and remove the OpenDeploy configuration option that indicated it was working with TeamSite 5.0.x.

It's not really all that complicated, but it does take a bit of planning and coordination.

--fish
(Interwoven Senior Technical Consultant)

tvaughan

I'd second fish's suggestion. I did a 5.0.1 --> 5.5.2 upgrade last Fall and found it very useful to stagger the OpenDeploy upgrade by 2 weeks, relative to the TeamSite & Templating upgrade. It lets you deal with issues in a more bite-sized fashion.

teamsite_guy

Thanks fish and Tom.

So, we will plan to reinstall Opendeploy 5.5.x in a different directory and then after it is successful, we will plan to upgrade Teamsite 5.0.2 to 5.5.2.

In opendeploy upgrade, since 4.2's deployment configuration files follow old conventions and in 5.5.x, it is xml based, is there any out of the box feature/script which converts the deployment configuration files to new format. OR should it be done manually?

Thanks
Teamsite Guy

Migrateduser

Hi -
I went through a 4.2 > 5.5 OpenDeploy upgrade and can add a bit more: while OD 5.5 is very powerful and stable, it also has some new components you'll need to learn in addition to new terminology.

The .xml deployment configuration is significantly different than the old configuration, but you'll eventually recognize all of the old capabilities within the new configuration. There's a utility to help convert the old configs into new. Get familiar with the GUI version of the configuration editor. It validates your configurations and helps you get acquainted with the xml structure. Studying the dtd for the deployment configs is a good exercise also.

You'll be using several additional ports with this version of OpenDeploy. It's worthwhile to find out what they are and why they're being used. If you deploy thru a firewall, you'll have to do some updating of the allowed ports on the firewall.

If you use workflow and have OpenDeploy invoked in workflow, it's best to get the new OD installed and get the deployments working, then upgrade the TeamSite and do the integration of the new OpenDeploy configs.

If you used the Global Reporting Center integration with your 4.2.1 installation, note that it won't be available to you in 5.5 - the integration was discontinued in the 5.0 OD release. However, in not too long, OD 5.6 will be available and will have updated reporting capabilities.

It'll also be valuable (and necessary) to understand the function of all of the log files. Figure out the function of the odbase.xml and odrcvr.xml files. Note the function and difference between the micro and maco audit logs for deployments.

You also should be aware that you now have an additional servlet engine that provides the Admin GUI and that you'll have to take user administration a bit more seriously than with 4.2.1.

Quite a lot to think about, isn't it? I've probably missed some isues also. But once you're used to it, it all fits together nicely.

teamsite_guy

Thanks walib. I appreciate your help.

Is the utility you mentioned about converting deployment config files come with OD 5.5.x, is it reliable?

Thanks
Teamsite Guy

Adam Stoller

The utility comes with OpenDeploy 5.5.1 (5.x actually, but 5.5.1's is better than previous versions) - it is called iwodcfg2xml and is documented in the OpenDeploy 5.5.1 Reference Guide (under Command Line Tools).

The strategy I recommend for using it is as follows:

Take your existing 4.x configuration(s) and - if there are a bunch of essentially unrelated definitions in a single file, break them up into separate files. By this I mean different source areas, different target areas, different target machines; however if you generally run two (or more) deployments together - keep them together.
Clean up the deployment configurations if they need it - make things global if they should be global, make them local if they should be local.
Run iwodcfg2xml on one of the files - look at the results. Often times, this will get you between 75% and 100% of the way there.
Do a simulated run of the deployment (assume a config named foo.xml): iwodstart foo -sim and look through the various log files that are generated.
Tweak the configuration file until your satisfied with the results (keep notes of the things you find you have to tweak)
Repeat for all the remaining config files

There are some other steps involved too - like cleaning up the odnodes.xml file and then another pass at tweaking the configuration files to refer to nodes by more meaningful names.

It sounds like a lot of work, and to some degree it is, but it's the kind of thing that has a rythym to it - once you get the first one or two under your belt, the rest take only about 5-10 minutes each, and you may find that you are able to take advantage of some of the newer functionality and reduce the overall number of configurations as a result.

Hope that helps

--fish
(Interwoven Senior Technical Consultant)

Migrateduser

It doesn't bomb off, if that's what you mean. But the difference in config files is different enough that I'd use it for the initial translation, and then use the resulting output as a starting point.

For instance, we had all of our 4.2 configs in a single file. When we ran that through the converter, we generated a single file output containing all the deployments. But what you're most likely going to want is a number of small, granular configurations so there'll be a process of breaking out the components of the one generated file into the granular ones.

Wally

teamsite_guy

Thanks fish and Wally. Your tips are really helpful.

Thanks
Teamsite Guy