Have a site that has a GroupWise 8 system that we plan to upgrade. The edirectory backend is a mess and was thinking it might be cleaner to move the current GroupWise system to new edirectory tree. Does anyone know of a procedure for moving a GroupWise system to a new tree and graft in the objects?
Yeah, I ran across that tid yesterday in my researching. I can't believe there isn't a newer tid on this topic. I have never done it myself, nor seen a situation until now where I would even think of it. I would assume this would still be relevant today, but wish something newer would be out there. Thanks for the info.
Have you ever done this before? It appears that you can do this without effecting production users on the system. So technically we could move the system over to a new edirectory tree/servers and graft it into the new tree and test it without effecting production users.
I understand, thanks anyway. Yeah, I have never run into this before so it would be nice to actually speak to someone who has done this. I just want to confirm some of the steps in the tid. It leave off some preliminary info I think.
In reality, there is no problem with this being an "old" TID, as the procedure for grafting hasn't changed since GW 5.0, other than it once used NWAdmin, and then ConsoleOne ;-)
And while you could "test it", there is little reason to do so. This is a very non-invasive procedure. The only issue you will run into AT ALL is if you are using LDAP authentication. You will, of course, need to set up the new LDAP servers on the new tree, and redo that portion of the GroupWise setup. Otherwise, if you are not using LDAP authentication, the GroupWise system would likely come up and work just fine prior to doing the graft. GroupWise is only "loosely" integrated with eDirectory, and other than for LDAP authentication only requires that eDirectory even be accessible when you are trying to administer it.
Yes, you can do it as a test without affecting anything on the production side. For example, if you have to send Novell (or me) your wpdomain.db file in order for them to fix something, they set up a container in a test tree, and graft your domain into that container to check to see what's up with it. The only downside, as I mentioned in my other post, is LDAP authentication. If you have that for your system, there is more work to do than is indicated in the TID.