Groupwise 5.5 and 6.5 connectivity problem

Hi, I have a question regarding two groupwise systems I am currently working on.

System 1 is Groupwise 5.5, system 2 is Groupwise 6.5.  I am migrating a client to a Groupwise 6.5 on a new server.  There are two servers total in the tree.  Both are running NetWare, on system #1 it is NOS 4.11 and on #2 it is NOS 6.5.

My goal is to get both systems up and running concurrently to facilitate a gradual transition of users from the (operational) 5.5 system to the new 6.5.  However, although I have external links within each system to the other, and the systems "see" each other, they are not entirely connected.

Checking the MTA monitor on system 1, I see the following:
Domains: 2 open
Post offices: 2 open
Gateways: 1 open

The MTA on system 2 reports this:
Domains: 2 open
Post offices: 1 open
Gateways: 1 open

So, on both systems, nothing is closed.  

Logging into Groupwise on system 1, I cannot see a test user mailbox I have created on system 2 in the address book, and manually entering the address "tester1.sys2_dom.sys2_po" results in an undeliverable address error before I can send the message in groupwise.

Doing the same on system 2, I see only my tester1 user in the address book, and cannot manually enter an email adress with the domain and post office info, just as on system 1.

To summarize: I cannot send email between the systems nor see any address book information across the two.  However, I have an external domain set up in each system pointing to the other, and all links are set up as far as I can tell correctly.  The MTAs on both systems report that the domains are open.  The only difference is that on my 5.5 system, it reports two post offices open (presumably the post office on system 2), whereas on my 6.5 system it only reports one one post office.  Again, no domains or post offices are closed.

Does anyone have any ideas as to where the problem could be in my setup?  Any help is greatly appreciated.
Who is Participating?
You're fine thru Step #2.

The thing that allows you to bypass Step #3 is that GroupWise v6.5 will happily read and use GroupWise v5.x databases. You don't need to install GroupWise v5.2 and then upgrade it.

So, what you would restore is the Domain and Post Office directories. NOT the NLMs.

Instead, you'll install GroupWise v6.5, then replace the Domain and Post Office you create during that install with the Domain and Post Office files from the old system. Delete the NDS objects too. Then use the GroupWise Snap-Ins in v6.5 to graft the old Domain and Post Office into the new GroupWise system.

Mind you, I have not actually done this. I think it is worth your time to do this on a test run and work the kinks out and develop a written procedure to recreate it. You have a new box for the v6.5 system, leverage that to do some dry runs.

I strongly recommend you get Tay Kratzer's GroupWise v6.5 Administrator's Guide (ISBN 0-7897-2982-2) from your fave local bookstore. Also, I suggest you download and print the Novell documentation for GroupWise v6.5 ( especially the Administration Guide.
IMPORTANT - in the environment you describe (a single NDS Tree with a v6.5 server and a v4.11 server) do NOT put an NDS replica on the v4.11 server. I assume your NDS tree is not partitioned (i.e. everything is in one big partition). You cannot safely mix an ancient version of NDS found on NetWare v4.11 with a modern version on v6.5.

GroupWise v6.5 uses NDS a lot more than v5.5 did, so this is important and may have an impact on your Question.

Are you using GroupWise v5.5 or v5.5 EP?

Any Support Packs on these GroupWise installations?
dhawtAuthor Commented:
Actually, now that I'm back at my client and taking another look at the system, it seems I was incorrect initially.  The Groupwise version is 5.0, not 5.5 as I throught.

There are no support packs on the 6.5 installation, as I just did it fresh off the CDs from Novell.  On the 5.0 installation, I'm guessing the support pack level is at 4, but I'm not sure how to check.  (Any ideas on that?)

You raise an interesting point- for the purposes of the migration, do you think then that it would be worthwhile to create a seperate tree for the new 6.5 server, and go through the hassle of removing it from the 4.11 tree?
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

In the environment you describe, I would probably back off and do a Migration (see Remove the v6.5 server from the tree, then rebuild it into its own (temporary) tree. Be sure to use the NetWare v6.5 SP2 Overlay CD from That way you're getting a fully-patched install. Note there is one critical post-SP 2 patch (I don't think they've integrated it into SP2), and for that you should see Novell TID #10093726 at

You can check the exact version of the existing GroupWise v5.x install by, at the server's console prompt, entering --> MODULES GW*

Post the results here.

Once you have the environment migrated, restore the GroupWise environment from backup tape (be certain that when you perform the backup, the GroupWise environment is completely shut down, no clients are accessing it, and the databases are stable - run GWCHECK on them) and then use the GroupWise v6.5 ability to graft the GroupWise environment into the NetWare v6.5 tree.
dhawtAuthor Commented:
Okay, I think I see what you're saying.

(Our GW version is all 5.0 - various modules have individual version numbers in the 5.20-5.26 range)

Doing the migration as you state above was an option we initially looked at; however after doing some experiementation we realized that it wouldn't be the ideal way to go.  

I feel that way because we have a relatively small network with only one fileserver doing everything.  Doing the migration in the way described in the migration wizard requires us to do the switch all at once, since the new server assumes the identity of the old once the wizard completes.

This is okay of course, if it works.  However, since there are always problems, it probably won't work initially, and will either require extensive hours of work to get up and running (while the rest of the network is down), or we'd have to give up and switch back to the old server.

We'd like to be able to move things over piecewise, and maintain our current server structure so we can make the switch gradually.  Hence the current setup, where all users are still on our old server, while I'm trying to get the second groupwise system up concurrently so we can move users over to the new system one by one.

Do you think it would be better, then, to do it all at once using the migration wizard, and then upgrade the groupwise system once an (semi-)indentical system is running on the new server?

Thanks a lot for your help so far.
Sounds like you're running GroupWise v5.2. Hard to be more precise than that. v5.2 got up to SP 4, but without a lot of digging it'd be hard to pin it down more precisely (v5.2 is not supported any longer). Not that it makes a lot of difference for what you want to do.

"Do you think it would be better, then, to do it all at once using the migration wizard, and then upgrade the groupwise system once an (semi-)indentical system is running on the new server?"

If you were running a version of NetWare from THIS century, then I think the slower migration path you prefer (and I understand WHY you prefer it) would work fine. The issue is that ancient v4.11 and trying to get a v6.5 server gracefully inserted *as a replica host* in the tree without causing problems. The v6.5 server is going to be running eDirectory v8.7, while the v4.11 server is running NDS v6. There's a good 6 years of development dividing those two products, and starting around eDirectory v8.6 Novell quit worrying about backwards-compatibility with NDS v6.

I just don't want to see you mess up your NDS tree, since you only have one replica of [Root], and I'm at a loss as to how you can get the Master replica moved to the v6.5 server safely without going thru something like the Migration Wizard or the old DSMAINT procedure (which might not work when trying to restore to eDirectory).

As I recall, the Mirgration Wizard does have a graceful backout. You don't destroy the old server, and you can switch back to it fairly easily. I confess I haven't piddled with MW in years, but I'm sure if you study the docs ( they'll detail the backout/recovery procedure. See if what they say doesn't answer your legitimate concerns.

IMPORTANT NOTE: Do NOT use NetWare Migration Wizard v7.x. Since you are migrating NetWare v4.11, you *must* use the Migration Wizard v6.5.

dhawtAuthor Commented:
Okay, I gotcha now.  I just have one further question regarding your comment here:

"Once you have the environment migrated, restore the GroupWise environment from backup tape (be certain that when you perform the backup, the GroupWise environment is completely shut down, no clients are accessing it, and the databases are stable - run GWCHECK on them) and then use the GroupWise v6.5 ability to graft the GroupWise environment into the NetWare v6.5 tree."

I'm missing a bit of the logistics of this.  I picture this process to be as follows:

1. Do full backup of current (old) server to tape, as always
2. Run migration, bringing over users, trustees, containers, print queues, etc., into the new 6.5 server
3. Install Groupwise 5.2 on to the new server using our original installation CDs, creating identical post office and domain structure, then overwrite the created domain and post office directory structure with the mail directory off the backup tape, so that all the existing mail gets put where the new groupwise system expects to see it?
4. Upgrade to Groupwise 6.5 once the 5.2 system is up and running as it was before on the old system

Now, I don't think #3 would actually work.  I think my trouble lies in my understanding of what you mean by restoring the GroupWise environment from tape -- does this mean, all groupwise components such as NLMs, config files, and domain and post office directories, or a subset of this?  

You've been an immense help.  I think once I get this idea clear in my head we should be good to go on this.
dhawtAuthor Commented:
Fantastic.  That gets me going again.  Thank you kindly.
Good luck, and I'd be interested to hear how things work out. I've not actually done what you're doing, and theory usually pans out at least slightly different from practice.
dhawtAuthor Commented:
Just to follow up, here's how it ended up working out:

I did the migration using the Novell migration wizard, which worked well the second time around.  There were a few problems with certificates not being automatically recreated once the server was renamed and such, but I just recreated them and everything was fine.

I created a new domain and post office with the same names as the ones on the original server, ran the agents, then shut everything down.  I moved the new domain and post office directories out of the way, then replaced them with ones I had copied off the original server.  Firing up the agents once again, everything seemed to work dandy for about a day.

Then, we began seeing lots of C00E error showing up in the GWIA.  These didn't seem to pose a problem initially.  I was away from the site for a few days and everything began going haywire.  I came back and found that I had inadvertantly left relaying open, so lots of spam was being sent through us.  Closed relaying, and after about a day, things calmed down and our domain got taken back off the blacklists.

Still was getting C00E errors, so spoke to Novell support about the issue.  Turns out it's incredibly easy to convert a 5.5 post office and domain to 6.5... all that needs to be done is a few files are copied from the software distribution directory into your domain and post office.  

I copied the following:

SYS:/grpwise/software/domain/*.DC to overwrite files in SYS:/MAIL/gwdom/ (my domain directory)
SYS:/grpwise/software/po/*.DC to overwrite files in SYS:/MAIL/gwdom/gwpo/ (my post office directory)

Then I shut down the MTA, POA, and GWIA agents.  From console one, I then right clicked on the domain and post office objects and did Groupwise Utilities->System Maintainance->Rebuild Database on the domain and post office.  Started everything back up again and they were reporting version 6.5, fully upgraded.

Once I did this, all my c00e errors went away and everything was working dandy.  I could connect to the post offices using the new 6.5 client with no trouble.

So, the end solution for getting everything up to 6.5 turned out to be very simple - no grafting, no multiple systems, etc..  Took me forever to get to the bottom of how to do it.  Thanks again for all your assistance.
That's great. I hadn't done a v5.5 to v6.5 database conversion like that, its a handy trick I'll add to my toolbox. Glad to hear its working and that it sent smoothly (relatively speaking).
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.