Netware 4.1 conversion to Windows 2003

My main experience with migrating NetWare to Windoze is that it usually ends up costing the organization more hardware, more administration time, and more money. Not to mention turning your network into one that any 16-year-old twerp in Germany can bring to its knees on a whim. Enjoy the endless stream of "critical" security patches, virii and worms; and the knowledge that any bozo with a compromised laptop can plug into your network and bring down your servers as well as your workstations. Good luck... you'll need it.

As to your specific questions....

1. Probably nothing - they'll continue to run as before, assuming that the M$ migration tool doesn't hose them like XP SP2 has been trashing machines left and right.

2. Would you like that list alphabetically, or just the first 100?

Some major issues spring to mind... file security in the Windoze environment is a crude subset of the granular and adaptable security you're used to in the NetWare environment. You can't prevent users from seeing that subdirectories exist, for example; nor can you grant a user the limited ability to give directory rights to other users without granting them "full rights" to the directory. So forget about trying to migrate your file security - you're going to have to sit down and re-think it from scratch, and work as best you can around the crude limitations of Windoze file security.

Similarly, if you've made ANY use at all of the Directory Service structure to help you manage your environment, that all goes out the window (no pun intended) with the laughable excuse for a directory service known as AD. For example, there is no time synchronization in AD - for this and several other reasons, it is possible for changes to overwrite each other - you thot you added Joe to that Group, but whooops! It just vanished. Now where did it go? Also, you can only use Groups and Users as security principals. Have you made use of Org Roles? Assigned rights to an OU so all the user accounts in the OU get those rights? Sorry, no can do in AD. So, forget about migrating and sit down and re-think your entire directory service tree structure from scratch, doing you best to work around the limitations that AD places upon you.

Want to keep your directory structure and DNS independent? Ooops! Can't do that in AD.

3) As Long as you leave the NetWare Client 32 on them, yes. Just add the M$ Client for M$ networks.

4) Services for NetWare is garbage. It is a deliberately crippled pile of crap. It also makes the Windoze box look like a NetWare v2 server. I would avoid it (I'd also not do a migration like this, I'd upgrade to NetWare v6.5, but then I like quiet nights at home not having to worry about the LAN at work).

5) Yes - NetBIOS is a VERY chatty protocol. AD replicates entire objects, rather than just the deltas, so you can expect the bandwidth consumed by network "housekeeping" to increase significantly.

6) Yeah, but I doubt you want to hear how you're pouring money down a rathole, or that NetWare hasn't needed IPX since v5.0 came out in 1999, or that NetWare v6.5 (the latest) ships with Apache v2 webserver, Tomcat, PHP, Perl and MySQL - none of which will you find on your Windoze boxes.

I'm always amazed to see people still fall for the M$ line of BS. It amazes me how the endless parade of malware and security warnings and media reports of anti-competitive strong-arm tactics from Redmond fails to dissuade people from turning their enterprise over to Redmond. But hey, mebbe your company's competitors are making better business decisions.

Thanks for the answer that is what I want to hear.  You helped me with another question and was very helpful.  I can open this as an additional question...One of the reasons we are considering this is becuase the current Novell Tree does not function correctly.  For example, when I am logged into the CO context and go to change permissions of a user in the MS context I will see the changes but if I log directly into the MS server the changes never get there.  Also, the permissions provided on different file shares do not work correctly.  You assign access to users but the users do not have get the access.  You see them assigned correctly in the manager but in practice they don't work.

Ah. Well, yes, like any hierarchical database, the NDS Tree does require care and feeding. You pardon for a moment while I....

<soapbox>
I'll note that you have a rather old version of NDS, running on an EOLed and unsupported version of NetWare. If you were running NT v3.51 and having these problems, what would you do? Upgrade, right? It strikes me as odd that you're planning to throw the baby out with the bathwater by switching platforms, and to a significantly more expensive one at that.

The current version of NetWare is v6.5, and v5.1 is the oldest one that is still supported. v4.1x has been EOLed for YEARS. I'd like to suggest that if you've let your NetWare environment languish this long without any maintenance and patching, that:

1) Issues are to be expected

2) You're an excellent test case for the business value and durability of NetWare and NDS, seeing as how it has gone this long without that maintenance, and yet has managed to degrade gracefully rather than choking and dying on you
</soapbox>

You speak about the "CO" and "MS" contexts. Are you running NDS for NT?

If the NDS Tree is not functioning properly, as you say, that even if your intent is still to migrate, I would recommend that you get it healthy before attempting such a migration

Can you be more specific about the problems the tree is experiencing? Is TimeSync functioning? Are any servers showing Synthetic Time messages? Are all Replicas in Sync? Does DSREPAIR report any issues?

I have been newly hired to this position and the entire previous staff was let go.  I really have no idea how it got this bad...but it is.  I will attempt to run the commands you mentioned and report back.  Can you give me any specifics in how to run these commands.  Also, do you think it would be necessary to repair this problem before upgrading as well?

"One of the reasons we are considering this is becuase the current Novell Tree does not function correctly."

Depends, if we fix it - are you still going to rip and replace? ;)

"do you think it would be necessary to repair this problem before upgrading as well?"

YES. If you plan to upgrade to a modern/supported version of NetWare, you definitely need a healthy Tree before doing so.

Hmmm....basic NetWare and NDS diagnostics.....wow, gotta hop into the Way Back Machine for this one....

0) Grab a notebook and start documenting your environment. If this was an incomptently-administered environment, then you probably don't even have a network map. Start writing down things you find. Write down what you do and see in 1) and 2) below.

1) Take a look at Novell TID #10024131 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/10024131.htm) and make sure you have IPX communications working.

2) Next, look at Novell TID #10011026 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/10011026.htm) and get a feel for the overall health of your NDS environment.

The following commands are typed at the NetWare Console prompt:

A) To determine the NetWare version and Support Pack level of a NetWare server, enter --> VERSION

B) To determine the Time Synchronization status of a server, enter --> TIME

C) To determine the overall synchronization status of the NDS tree, enter --> DSREPAIR
and then select --> Report Synchronization Status

D) To determine the network numbers for the NetWare server, enter --> CONFIG

You need to gather information and assess the environment before progressing.

be nice to know the server names, physical locations and locations within the tree as well as partition and replica layouts.

"Hmmm....basic NetWare and NDS diagnostics.....wow, gotta hop into the Way Back Machine for this one...."

that's sKERRY... ;)

Do not fix the novell netware stuff unless you need to. Get data and any thing else need off the netware and move on.  

gjohnson99:

he NEEDS to.

"that's sKERRY... ;)"

hehe.

I take it gjohnson99 doesn't know Windoze from shinola ;)

This is what I have learned:

A) Netware Version -- 4.11 it did not reference "support packs"
B) Time Scynchronization on all servers but 2 are fine.  The servers CO4 and SE2 can not synch. But CO4 can synch to others.
C) DSREPAIR from the main server CO3 shows all servers synchronized.

The layout of the servers are the following:

CO4 and CO3 are located in the main office. (CO3 is the lead server)
SE2 is located in a school
ME2 is located in a school
MS2 is located in a school
MH2 is located in a school
FH2 is located in a school

When we looked at the SE2 server that is having the synchronization problem it shows an error that the volumes are not installed but the volumes are installed and in use.

Thanks.

A) Ooops. Yeah, it is that old. Sorry. I think you can still go into INSTALL at the server console and find the Product Installation screen and get a list of things installed since the server was first set up. Its been awhile since I was in front of a v4.11 console. You can also go to the Novell Support website (http://support.novell.com) and download SP 9 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/2957945.htm) and apply it - it won't hurt the server to re-apply the SP (there is a slight chance you could back-level something, but I'd doubt it, given the fact there are very few Post-SP9 patches).

You can also use the NetWare Server Configuration Checker (http://support.novell.com/cgi-bin/search/searchtid.cgi?/2956502.htm) to baseline your servers and compare one against the other.

B) This is a Very Bad Thing (tm). You need to diagnose and correct this before you do ANYTHING else (including A). To get you started, see Novell TIDs #10064019 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/10064019.htm), #10011517 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/10011517.htm), #10011516 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/10011516.htm), #10013084 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/10013084.htm), #10014286 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/10014286.htm), #1006969 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/1006969.htm), and #10011024 (http://support.novell.com/cgi-bin/search/searchtid.cgi?/10011024.htm). These should explain TimeSync in the NetWare v4.11 (IPX) environment - things change when you go to NetWare v5 or later and start using IP.

C) That's good - this means DS is fundamentally healthy, at least from the replication standpoint. The problem you describe with Server SE2 is relatively minor and can be fixed once other things are addressed.

One additional point while we do what you suggest.  If DS is fundamentally healthy.  Why when we make a change on one server is it not changing on a another.  This is specific to user permissions.  For example if I am logged in to CO and I open of the Netware tool and change the context to ME and change the permissions for that user.  The actual users permissions will not change until I log into ME and do the same thing.  Log in meaning .username.ME

Thanks.  We are working on this today.

I'm not sure I understand your question. Do you mean that changes to user accounts are not propogating?

Do CO and ME both have replicas? How many partitions do you have in your NDS tree? And how many replicas of those partitions?

Replication can take up to 10 minutes to occur, unless you change the replication defaults.

It depends a lot on how your partitions are configured and whether the replication is occurring as it should.  If you are logged in as an admin-level user, the NDS change should replicate fairly quickly.  It should not matter where you log in - what matters is where replicas are stored, and how replication occurs.

NDS replication in 4.11 was fairly efficient - far more so than AD replication is.

On a side note - it bugs me a tad that you are a school system, but are planning to switch to Windoze instead of upgrading your NetWare environment.  NetWare is a very popular choice for schools for very good reasons, not the least of which is its well-documented low Total Cost of Ownership, which is much more favorable than that of Windoze.   Since school systems tend to appreciate cost-savings much more than other businesses, I would suggest that the decision be revisited.  Unless Micro$oft is giving you their products for free, upgrading all of your WAN links (including paying for the ongoing telecom costs) and giving you free consulting services to install and support an all-Microsoft network, I don't see how there could be ANY gain for your district in making this move.

I also don't see how you can do any comparison between your *current* NetWare installation and a current Windoze version. You're running a version of NetWare from about 1996. Its contemporary was NT v3.51 (not that is a *chronological* observation - in terms of *technology*, NT v3.51 is roughly equivalent to NetWare v2; W2K is roughly equivalent to NetWare v4 in terms of technology).

If you're going to evaluate a move, then you need to compare NetWare v6.5 to the currently-shipping Windoze. And I agree with ShineOn, unless M$ is giving you everything for free and planning to pay for your telecom charges for the next 5 years, I don't see how you can come out ahead, financially (or technology-wise, either).

We are at the point now that the DSRepair log on some of the servers shows this error in the log but lists 0 errors when it is actually running.
Error Reading Remote Replica Ring for Schema: Information Error: -610

PsiCop---
You are correct.  When the user accounts are created or exsisting users are updated that information does not propigate.

Yes CO and ME have replicas all of the partitions do.  If the partitions you refer to are what I have been calling context we have 6.  But I am looking this up further.

I have waited as long as 2 days to see if the user account information would update and it does not.  Also if you update the user being logged into CO and the user is in ME you will see your changes.  If you then log into ME you will not see your changes and then can make the same or different changes and CO will never see it.  This is happening with all of the contexts (CO,ME,MS,FH,MH,SE)

Thanks.

without proper time sync on ALL the servers - it ain't going to happen.

Well, you DO have a replication problem. My analysis previously was predicated on your statement that DSREPAIR ran fine. You didn't mention the -610 errors.

Your DS environment is NOT healthy and that is why your user changes are not replicating. Your "workaround" - logging into the servers separately and making the changes on each one, would be a disaster in an AD environment. Fortunately, you're running NDS, and its fairly likely that once your replication starts working properly again, NDS will sort things out properly.

Contexts and Partitions are two different things. In an environment as small as yours, your NDS Tree may not have been partitioned.

What troubleshooting of the replication problems have you performed? What have you done to verify the integrity of the IPX routing between sites?

I am limited in my Netware skills.  At this point following recommendations from you.  I know that I do not get error messages that the servers are no communicating.  When the servers do not communicate I see an error on the console.  I also know that running the DSRepair shows no errors when it is run on CO4 and then the log reflects above.  Also when we verify the time sync it shows all servers sync except for CO4 with ME2.  Since the servers appear to see each other I assume IPX is functioning correctly.

Additionally I have learned that this problem has exsisted since the rolling black outs of the summer of 2003. (about 1.5 years before I thought I'd be working here)

I also know that CO4 is looking to two computers (CO9 and CO5) that nolonger exsist.  But when I try to remove those entries it asks for a user name and password when I enter mine it tells me I do not have the rights to do it.  Yet I was told by my predessor that I was given trustee rights to everything.

Thanks for all the help.

They have a WAN, probably slow links.  I'll bet they're partitioned at the OU level, assuming the tree design is WAN-based.

Yes, ctunks, you have an NDS replication problem.   What DSREPAIR options have you tried?  It has been a very long time since I have used 4.11, so I don't want to tell you to do something that does not exist in the 4.11 DSREPAIR.

If you have a problem performing any functions, and you are using your own ID and not the tree's "admin" user, it is probably because your user's rights haven't propagated through the replica ring.  Do you have access to the "admin" user?

I worked with a Novell 4.1 person here and this is what I have been told....
The root directory called MH nolonger exsists.  It was contained on the server C05 and that is one of the servers that do not exsist here.  The person I spoke to (he was the guy that used to run this network) is the guy who provided this information.  He made 2 suggestions to try to use the DSMaint utility to repair the root directory or attempt to rename the tree.  What do you think?

I was told that renaming the tree theoratically will force the tree to be recreated and go out and get all the servers.  Is this correct?

What use would DSMaint be in the process?

Is there an order of events we should use and is there any documentation to support this process?

Thanks.

Partitions are segments of the NDS database.  Partitions are usually created in a WAN environment at each location's OU level, but it is not a true statement to say OU = PARTITION .  Replicas are copies of partitions housed on multiple servers, usually at multiple sites, primarily for redundancy.  A replica ring is comprised of the servers that house replicas (master or read/write) of a partition.  Each partition has its own replica ring.  The replica rings synchronize changes between them, but time has to be in sync for replication to occur successfully.

As far as timesync is concerned, one of your servers should probably be configured as a "single" time source server, with all of the other servers configured as "secondary."  The secondary servers should all be pointing to the "single" server as its time source, for time synchronization.  The secondary servers should not be attempting to timesync with each other, only with the "single" server.  If  you physically type "time" on each server console and any of them say time is not in sync, it may be either a communication problem or a timesync configuration problem.  Timesync and replica synchronization are not the same thing, but replica synchronization requires time synchronization.

Replica sync is your problem here, and will not take place properly (as DSPoole has mentioned) if timesync isn't working right.  Heal the timesync before trying to heal the replica sync.  Hopefully, none of your servers have been using "synthetic time" while you've been making your NDS changes to specific servers.

A full unattended DSREPAIR should be done on all servers that house an NDS partition replica after timesync has been established, to make sure the individual local NDS databases are not corrupt.

Once the replication is working again, you should attend to proper removal of the old servers.  Servers shouldn't simply be unplugged - they should be removed from NDS first.

Also, he's got servers (CO5 and CO9) that no longer exist, but were not properly removed from the NDS tree.

No wonder the previous administration was let go - they were grossly incompetent. Altho if this is a school system, its more likely they started out as some librarian or media specialist who got shoved into the network administration role and was given no training, support or resources; and muddled along as best they could until their mistakes added up to the mess ctunks has now.

ctunks, this is what I'm hearing from you: You have a NetWare environment that is a mess. If it were Windoze, it would have choked and died a long time ago, but NetWare is doing the best it can given the incompetent way its been installed and managed. Frankly, you're lucky its even operating with any sort of usability. Like I said, Windoze would be pushing up daisies before now.

In any case, you've got a really bad situation, with timesync not working, replication not working, dead branches on the NDS tree (those servers that were not properly removed), and god only knows what else wrong. Add to that you're running an elderly and unsupported version of the NOS. And finally, by your own admission, you've got limited NetWare skills.

The big stumbling block I see is that the mess you've inherited requires from fairly sharp NetWare skills. ShineOn, DSPoole, waybadmojo, myself ...we probably have the level of skills needed. But we're not there (altho if you're in North Carolina, lemme know). And this forum is limited in how much of the knowledge you need that can be reasonably transferred to you.

At this point, I really do suggest that you engage some folx with up-to-date NetWare skills to come on-site and help you clean this up. Its not going to be easy or quick - a lot of mistakes have been made, a lot of damage has been left to fester, and the system's performance has degraded seriously. But I think it CAN be salvaged. Some time and a LOT of TLC and I think you can restore the system to a healthy state (and I doubt you'd be able to do that in a Windoze/AD environment that had been neglected so badly).

If you can tell us where you are, we might be able to make some recommendations for some VARs in your area that have the expertise. Or you can engage Novell Consulting (http://www.novell.com/company/contact.html). If you're a K-12 school system and an ELA customer, you might even be able to beg them to do it for free; or you might be able to engage them thru your state's central education department (we could do that in NC).

But I don't think this forum is going to provide the environment that will let us help you fix a situation THIS BAD when your NetWare skills are limited. If you want to have a Moderator PAQ this Question and refund your points, I have no objection (I can't speak for the other Experts, tho).

Whaaa-aa--aaa?

I think we're mixing terms.  A root directory is not a directory root.  Hopefully, this guy wasn't saying that the only server holding the directory root partition was unplugged without making another server master?   Was he maybe saying that the master of the MH partition was removed?  

Rename the tree?  What is the tree named, now?  Is it MH?  Did someone really unplug the Master of [ROOT]?  If so, find that person and shoot them - they're too stupid to live.

I'm not sure DSREPAIR is going to be able to tackle this until timesync has been restored and the servers (the ones that are left in the tree, at any rate) can all see each other.

PsiCop:

To answer your questions....
We have 6 Partitions.
For each partition we have a master replica, a read/write, and a subordinate reference.

We have NO master replica for the root directory that was called MH.  For example when you open the NDSManager. It imiediately gives and error message that the root directory could not be found and then you must manually connect to each context.

My predessor believed this not to be a significant problem therefore repair was never attempted.

I am being told now that I should focus on repairing the Master root directory.  And if I can do this my other problems will go away.  My predessor is not a resource that I can use on sight nor do I believe he is completely confident in what to do.  So I am depending on everyone here right now.

Do you agree with the repair idea?

Thanks.

"My predessor believed this not to be a significant problem therefore repair was never attempted."

Your predecessor is a drooling idiot.

Is there a R/W replica of [ROOT]?  If so, make it Master.  

It's no surprise that none of your changes were replicating.  You NEED a Master of [ROOT] for NDS to work.  Period.

Shineon and PSICop:

To be clear.  I am saying that we do not have a copy of the directory root partition.  That was contained on a server that crashed last year and was not recoverable.

What to do now?

Yes the master root was called MH.  It is too late for me to worry about the past I need to move foward with this.

What are your opinions on renaming this master root and having it recreated.

Thanks.

"My predessor believed this not to be a significant problem therefore repair was never attempted."

Your predecessor was #)(%!n& idiot. I'm with ShineOn - shotting them would be like putting chlorine in the gene pool.

OK, so there is no Master replica of the [Root] partition. Is there at least a R/W replica of the [Root] partition, and can you identify the server on which that is located?

I still think your best route is to engage people with the necessary skills to come on site.

http://support.novell.com/cgi-bin/search/searchtid.cgi?/10051168.htm

Pretty much says the same thing

Do you have a backup of NDS that you can restore from after re-creating the basic tree structure from scratch?

If there is no replica, at all, of the [Root] partition, you're basically hosed. You're going to have to destroy this tree. If you can restore from some backup media, you may be able to rebuild it, but even then, it will be an old version from however old that backup media is.

If you can't recover it, then you're going to end up recreating all the user accounts and directory permissions and so forth. However, the user data on the Volumes will NOT be lost by removing and re-installing the NDS database.

We have no back-ups and we have no relicas that we can point to.

For clarification.. If we create a new root partition and lets say call it MC.  We will need to remake all the users and all the security permissions?

What do you mean by removing and re-installing the NDS database?

What happens if we take a new machine and create a new Tree and place it on the network.  Could we then tell the exsisting servers to connect to it?

Thanks.

"What happens if we take a new machine and create a new Tree and place it on the network.  Could we then tell the exsisting servers to connect to it?"

Yes.  But you must remove DS from the old server before you can put it into a new tree.  I also suggest that you capture your file ACL's using TrustNDS which you can download from Novell Coolsolutions.

btw:  you can have multiple trees on the network, they just can't have the same name.

Oooo. Good idea, DSPoole, altho it will only work if he re-creates the same Tree structure and same user/group names. He may want to take advantage of this situation to re-think the NDS structure.

We have added a tree called TC to the network.  We can see it correctly at this point.

DSpoole:
Is your solution the same as PsiCop that I will have to recreate the user names and security.

My concern here is that I have over 4,500 user names.  That task would be huge.

I understand this has to be re-thought but I have a very limited time frame to make this work becuase the district has committed to a training on Tuesday that we be done and this problem could present them with an issue.

If you're up against a tight timeline, that could present you with problems. If you had the time, you could use a user export to save at least part of the information from the old Tree, and then import it into the new. I'm not familiar with the stock tools in a NetWare v4 environment for this, however. Mebbe another Expert can speak to that.

I think you're options are pretty much limited to one:  re-creating your tree from scratch - including all containers, users, groups, printers, etc.  

I know it's not helpful to the current situation, but whatever you end up doing after working through the immediate problem - get a tape backup system in place, and use it!  Also, assuming you stick with NetWare, make sure there is at least one read/write replica of [ROOT] besides the master replica.  It's a corny analogy, but if you take away the root, the tree dies...

"My concern here is that I have over 4,500 user names.  That task would be huge."

You asked and I told you that you could.  Now that I know you have 4,500 accounts, the question is, SHOULD you?  The answer, of course, is no.

I suggest you repair your replica's and get time sync working again.

If he doesn't have any copies of the [Root] partition, he's hosed.

so much for synchronization then.

"drooling idiot" - love it!

what about creating a new tree and grafting the old partitions into it?

YES I would like to create a new tree and graft the old partitions.  Do we know if this can be done and any instructions on how to do it?

If I understand DSPoole from earlier I can do this but have to remove the DS from the old servers.  Is this the same thing?

Thanks again for all your help.

Hmmmm...might work. I'm concerned about the amount of damage that's been done to the existing tree. I'd hate for him to import serious data corruption into his new Tree and perpetuate his problems. That said, the grafting idea does offer the only chance to preserve a large amount of info from the old environment.

no - not the same thing.  You would bring up a new server with a new tree with a new Master Replica of the [Root] partition and then attempt to graft the context the server belongs to into the new tree.

I don't know if it will work with you missing any replica's of the [Root] on your existing tree.

It MIGHT though....

you would use DSMERGE on your existing server to graft it into the new tree.

I REALLY REALLY REALLY recommend that BEFORE you graft anything into your new tree, you set up TWO new servers so that you have a Master Replica of the [Root] partition of the new tree on one and a Read/Write Replica of the [Root] partition of the new tree on another and that there are NO COMMUNICATION errors between them.

I know it is not the best but if it would get me through so that I could then ask the district to re-evaluate its decisions and begin to look at the network again it would be very helpful.  Is 'grafting' the correct term for this.  I will try to search for supporting documentation that may help me in the process.

Thanks.

ask yourself this question:

if the decision to move to Windows was because NetWare NDS was broken, and Windows AD is MORE fragile than NDS is - would you REALLY want to migrate and end up in a WORSE situation a year later.

Remember, with NDS you can repair while the server is online and users are logged in.

With AD you have to reboot the server into a special AD Repair mode when no one is logged in.

Try telling 4,500 users they have to log off while you repair the directory and see what sort of response you get.

also - you may want to run DSMERGE from the server holding Master replica's instead of Read/Write replica's.

Technically speaking "Grafting" usually refers to adding GroupWise objects. "Merging" is what we should be calling it (just to avoid confusion with the terms used in the Novell Knowledgebase).

Speaking of the Knowledgebase, here are some helpful TIDs:

http://support.novell.com/cgi-bin/search/searchtid.cgi?/10011011.htm

http://support.novell.com/cgi-bin/search/searchtid.cgi?/10050607.htm

http://support.novell.com/cgi-bin/search/searchtid.cgi?/10014937.htm

http://support.novell.com/cgi-bin/search/searchtid.cgi?/10014289.htm

This is more than just "not best". This may not work, and is a non-trivial exercise. You could spend a lot of time and not be any better off at the other end than you are now. But, you can't make the situation much worse, so I guess you don't have a lot to lose.

I think the idea of using DSMAINT has some merit in this discussion - if for no other purpose than to have some form of backup of the old partitions before starting the process.

Remeber, guys - this is NetWare 4.x.  DSMAINT may be the proper tool for this process.

- I should have said "a proper tool" not "the proper tool."

Some more helpful TIDs

http://support.novell.com/cgi-bin/search/searchtid.cgi?/10013535.htm
http://support.novell.com/cgi-bin/search/searchtid.cgi?/2946962.htm
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10010933.htm
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10064019.htm

oh, remember to install any applications into the new tree to get the proper schema extensions that may exist in the existing tree (ie:  GroupWise, ZENworks, etc.) BEFORE you "merge".

The applications your are referring to are only Netware related applications not any thrid party applications that were used by end users. Right?

any application that extends the NDS schema.  Novell is not the only company that makes products that integrate at some level with NDS.  Computer Associates ARCserve, for example, extends the schema.  American Power Conversion (APC) PowerChute Plus also extends the schema.  There are also products for end users which extend the schema such as GroupWise from Novell or FaxServer from ACCPAC International.

Ok I am going to try this using a makeshift test environment with a new server that contains a new tree and a server off of my exsisting tree and a second server that is also alone in a separate tree to see if this will work before I try one of the live servers.  Also I am in the process of running new back-ups on all the servers.  We do not unfortunately have backup software I have to mirror all the drives and then remove the mirror and call it a back-up.  

that's not a good backup - things can go horribly wrong with NDS when you "backrev" the timestamps.

And you DO have backup software, it came with NetWare.  SBACKUP

BUt I have no tape drives, writable CD ROM's.  Would SBACKUP write directly to a new hard drive?

Thanks.

I don't know - I've never used it.  I guess it all depends on your version of NetWare (4.10? really? wow... I haven't seen 4.10 in about a decade).

No, I think SBACKUP wants a tape. Its a very, very basic backup tool. Not a lot of features. Especially such an old version of SBACKUP. There was a developer tool that would let you emulate a tape drive on disk, but its not supported and I never had much luck getting it to work.

Thanks, all!

We are attempting to use the DSMerge Utility.  When we try to says that we do not have the correct admin account and password.  Yet we use that account and password to log in from a work station.  We did check that the account has all rights to the new Tree.  Any ideas?

We have verified that the password complies with password rules as that was the only Internet reference we could find.

Above problem with the user name is OK now.  The current problem. ...

The two trees are not in Time Sync so they can not merge.  I have found articles on the Internet that indicate that the two trees must be in time sync to do this.

I have tried to modify the time config file as best as I can from what I found on the Internet but it does not work.

Mainly I am thinking that in the field called "Add Time Source"  when we add the other tree to this it does not stay in the field.  When I hit enter the field goes blank and closes.

I am sure I am missing something very basic here but does anyone have any input on what is wrong now.

It is late it has been over 12 hours so we are going to pick this up again Friday morning.

Thanks.

Check out this Novell TID on the TimeSync issue --> http://support.novell.com/cgi-bin/search/searchtid.cgi?/10014289.htm

tell the server you are trying to merge from to use the server you are trying to merge into to use it as a time source.  In fact, tell ALL your existing servers to use the new server as their time source.

When I try to do that.  It does not stay.  The new tree is lets say MW.  With the server name of TC.  I have tried to enter MW it does not work.  What is the naming convention I would need to enter there for it to take.

Make these changes to timesync config:

1) set all servers to turn directory tree mode off  (Directory Tree Mode = off)

2) Make sure all servers are not using a configured list. (configured sources = off)

3)  Make sure all servers are using service advertising (service advertising on)

Make sure the TC server is the only server designated as "single" and that all of the other servers are set as "secondary."

This configuration will force timesync to occur based solely on SAP broadcasts with no filtering.

Well, what happened? Its been 4 months, ctunks. Bring us up to date!

I wonder what happened....

how long does it take to completely rebuild a crashed Windows network of 7 servers spread across a WAN from scratch?  About 6 months, right?

;)

*chuckle*