-------------------------------------------------------------------------
31x-41x.UPG -- 19980309 -- Email thread on Upgrading NetWare 3.1x to 4.1x
-------------------------------------------------------------------------

	Feel free to add or edit this document and then email
	it back to faq@jelyon.com




Date: Fri, 5 Jan 1996 17:36:32 -6
From: "Mike Avery" <mavery@aus.sig.net>
To: netw4-l@bgu.edu
Subject: Re: Across the wire Netware 4.1 to 4.1 migration

>Has anyone used the migrate utility to do a across the wire Netware 4.1
>to 4.1 migration.  We are upgrading one of our servers to a new one.
>
>Is there a better way of doing this?

The across the wire migration has a number of advantages, not the
least of which is the ability to recover from a failed upgrade.

The only serious problem I have had with the migrate utility is that
it is VERY slow.  We upgraded a server across 10baseT and the speed
was terribly slow.  On a subsequent try, we used TCNS - a 100mbps
topology from Thomas Conrad and had at best a monimal speed
improvement.  We also tried a FDDI link.  All in all, the speed
problems of Migrate are not media related.  It is just a slow
program.

If you are going to migrate one machine, and you have the time, it is
not a problem.  If you are going to migrate a number of machines and
you need them done quickly, then you need help.

We found our best strategy was to use Migrate to create the users,
groups, and group memberships, and then to use John Baird's NCOPY
program.  (The program is at work, I am not.... so the name may be
wrong.)

It is part of his JRB Utilities.  Part of the utilities, with
ordering instructions, are available on risc.ua.edu via anonymouse
ftp.  Look for the jrb230.zip file in the /pub/network/misc
directory.  The utilities are around $250 to $300 (US dollars), and
the copy utility you want is in the commercial package.

Now that I've told you what you want, I'll explain why.  The utility
is MUCH faster than Migrate, and if the owner of a file exists on the
source and target server the ownership is transferred.  Further, all
the rights and attributes can be transferred.  Better yet, you can
start mutilple copies from several PC's, which lets you make better
use of the network bandwidth.  The speed improvement is marvelous!

------------------------------

Date: Mon, 8 Jan 1996 08:30:37 +0000
From: Garry J Scobie Ext 3360 <GSCOBIE@ml0.ucs.ed.ac.uk>
Subject: Another FAQ entry?

A recent talk I gave to our support staff on upgrading to Netware 4.1
can be found at

ftp://mft.ucs.ed.ac.uk/guest/pub/nw41/docs/41upgrad.zip

The slides are in PowerPoint 4 format and are specific to our site but
other Administrators considering an upgrade may find them useful.

------------------------------

Date: Wed, 12 Jun 1996 18:11:01 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Upgrading from Novell 3.11 with nns to Novell 4.1

>A few questions about 4.1 upgrades:
>
>   How to you upgrade to a Novell 4.1 server and preserve all trustee
>assignments for files and directories (especially ownership)?
>
>  How do you upgrade to a Novell 4.1 server and change volume sizes
>and create new volumes? In other words, how do you move directories
>and files from one volume to multiple volumes and retain all trustee
>assignments?
----------
	One sits down under a shady tree with the NW 4.1 installation
manual and reads the mind numbing material from Novell on the matter,
particularly the Migrate section. After two readings and a pleasant
summer snooze to recover one does very good backups to tape, and then
you try what Novell suggests to a new (4.1) server. Do not use NETSYNC
because that beast sucks dry your NW 3 server's bindery and makes it now
wholly dependent on the NW 4.10 server you are trying to construct;
altogether the wrong way of going about this business.
	Don't destroy your NW 3 server if at all possible, and never
do so until you have *throughly* checked restoring from tape. Trust
nothing; have two or three different tested backups by independent
means. Talk it through with a friend to clarify the steps and discover
any omissions that will grab you.
	Notice that I recommend installing to another server. Overlaying
(in-place upgrade) is a one-way poposition where mistakes tend to make
you wholly dependent on backups (and they had better be able to restore
to a NW 4.1 system, hint hint, pretest to a temp NW 4 setup). NW 4 volumes
are unlike NW 3 volumes so that means you will be dependent on those backups
for an in-place upgrade.
	Joe D.

------------------------------

Date: Thu, 13 Jun 1996 12:00:27 -0400
From: Debbie Becker <dbecker@clark.net>
Subject: Re: Upgrading from Novell 3.11 with nns to Novell 4.1

There's a lot involved in upgrade/migration -- too much to cover on the list.

There are three ways to upgrade from NW3 to NW4:
	Across the wire to an installed server
	Across the wire to the same server
	In-place upgrade

Across the wire to an installed server should be used if you're installing
new hardware for the NW4.1 server. This method allows you to migrate multiple
3.x servers to one 4.1 server and there's no change of losing your data (as
you still have the 3.x server up and running). It does require that you
convert user login scripts to NDS properties (you can use UIMPORT). You can
migrate file system trustee rights if you select the "All Information"
option when you run the MIGRATE utility.

Across the wire to the same server if you're keeping the same hardware (and
have NW2 or NW3). Your data is at some risk in this procedure and you will
have to use third party backup as NetWare backup utilities will not work on
both the old and new operating system. Your file system trustee assignments
can be preserved, but you will have to restore the data on the system prior
to migrating the bindery. User login scripts are not migrated (again).

In-place upgrade can be run if you're keeping the same hardware and are
upgrading from NW3.1x. You won't be able to change disk block size or allow
suballocation unless you want to backup, recreate the volume and restore
data. However, it will leave your data untouched otherwise and provides
full bindery to NDS transfer (user login scripts become NDS properties
without you're doing anything), etc.

Container login scripts will have to be created in all instances. Print
services will have to be upgraded in all instances.

I have more info on migration, specifically -- if you'd like for me to
email to you, please let me know.

Also, check past issues of "Application Notes" -- there are a number of
articles covering migration and updating.

------------------------------

Date: Fri, 28 Jun 1996 06:50:50 -0600
From: "Mike Avery" <mavery@AUSTIN.aus.sig.net>
To: netw4-l@bgu.edu
Subject: Re: Upgrade?

Marketing is a strange thing.  In the situation discussed the
original writer will have to purchase a 100 user license.  So the
question is, should he buy a 100 user license 3.12 or 4.10?  There is
some resale value in the current 50 user license, but 3.12 does not
support additive licensing.

At this time, at least in the United States, Novell is pricing 3.X
and 4.X at the same level.  As a result, there is little reason to
purchase 3.X.  4.X offers many advantages over 3.X, and I have
trouble suggesting the purchase of 3.X.

There are a number of advantages to 4.1.  If the LAN continues to
grow, additive licensing is a real advantage.  It is usually cheaper
to add another license to the existing LAN than to purchase a new
one.

Disk compression helps increase disk space, and despite some negative
press, I have not had any problems with it.  (Some applications
insist that compression not be used, Oracle comes to mind.)  Under
3.X, using larger disk blocks saves RAM, but wastes lots of disk
space.  Under 4.X, sub-block allocation makes the use of larger disk
blocks less wasteful.  All in all, this can make the upgrade worth it.

Greater ease of administration is a very real benefit, although a
hard one to sell management on.  Printer support is supposed to be
better.  The print server can support up to 255 printers, a real
improvement over the 8 printers that 3.X allowed.  This would free up
a number of PC's in many companies.  (However, I still prefer third
party solutions.  I like Intel and HP printer drivers, as well as
Infinite Technology's IQS system.)

All in all, once a decision has been made to upgrade, I see no reason
NOT to upgrade to 4.1.  It's the initial discussion about whether or
not to upgrade that can be difficult.

---------

Date: Fri, 28 Jun 1996 10:03:58 -0400
From: "Christopher D. Heer" <CHEER@us.oracle.com>
To: netw4-l@bgu.edu
Subject: Re: Upgrade?

>I have a client who is running 3.12 with a 50 user licence & will
>need to upgrade to 100 users.    The network has only one file
>server and no WAN activity.   An app server might be added sometime
>in the future and some possible future WAN activity.   The centralized
>control over the network has been a big plus.
>
>Other than the coolness of 4.1 and the notion that someday Novell
>will cease to support 3.x, what compelling reasons are there to upgrade
>to 4.1, now,  rather than staying with 3.12??

Hmm.  I can think of only a few, in that situation:

1. Disk compression.  I'm not a big fan of this myself; disk is (relatively)
   cheap, and the fact of the matter is you're probably going to want to get
   at your files relatively often, which means you need the disk space to
   uncompress them.  It's also CPU-intensive.  Nonetheless, it's there.  :)

2. NWADMIN.  :)  Much slicker and easier, IMHO, then the old SYSCON/etc.
   tools.  But not a compelling justification, I admit.

3. Sub-block allocation.  This is the biggy, really; under 3.12, you can
   either (a) use *lots* of RAM and have 4K block sizes or (b) save on RAM
   and kick the block size up, which wastes disk space.  In 4.1, you can
   just use 64K block sizes and turn on sub-allocation.

There are other things, of course.  Print servers are much nicer under 4.1
and not limited to 8 printers, but around here I just use HPs or the
equivalent with their own solution.  If you have Macs, 4.x Netware for Mac
fixes a few things from the 3.x series, like handling >2GB volumes properly.
(Unless the 3.x NWFM has fixed that too. . . )  Lots of little things.  And
for later expansion, additive licensing as offered in 4.x is much simpler.

I would find out the difference in upgrade costs.  If it's the same or very
close, I'd make the move, but if there's a real cost difference, it doesn't
sound to me like you'd benefit that much from it.

------------------------------

Date: Fri, 19 Jul 1996 13:27:32 +0100
From: "David W. Hanson" <hansond@AFRC.GARMISCH.ARMY.MIL>
Subject: Re: Migration from 3.12 to 4.1

>What is the quickest and safest way to migrate a 3.12 sever to a 4.1
>server?

First, read the 4.1 documentation and do your planning so that you
aren't fumbling around during migration.

No matter which migration method you use, before you start, you want
to make sure that you are absolutely confident that your
backup/restore hardware/software/procedure works flawlessly on the
3.12 system.

Also, implement either VLMs or Client32 (I would recommend VLM at
this point, as Client32 isn't 'perfect' yet) on all of your clients
and verify that you have the client side all sorted out and your
applications tested before you migrate your server.

Then perform an 'Across-the Wire Migration'.

From the 4.1 documentation:

In an  Across-the-Wire  Migration, data  files are migrated across the
network from the source server to the NetWare 4.1 server.

Selected bindery  information is migrated to the  working directory on
the client workstation and translated to the NetWare 4.1 format, and
then migrated to the  NetWare 41 server through  bindery services.
Bindery services occurs when NetWare Directory ServicesTM  ( NDS)
emulates a flat structure for the objects within an NDSTM  Directory
tree.

The NetWare Migration utility lets you select specific information
from the bindery and data files so that you can upgrade a server and
create a customized NetWare 4.1 server. The Migration utility leaves
the source server intact and only copies information to the NetWare
4.1 server.

Across-the-Wire Migration allows you to preserve your user environment
(users and their trustee assignments) as well as the  default  account
restrictions, accounting methods, and  print queues and print
servers.

>We don't have that much user in our network, but I don't want to
>loose the accounts and trustee informations.
>
>The most important thing for me is the data on the server and how
>much time the migration take, i.e. can it be done on a weekend?

If everything goes smoothly, it can be done in hours.  The beauty of
across-the-wire is that if something goes wrong, you can always go
back to where you started and try again on another day.  The drawback
is you have to have two servers.

------------------------------

Date: Sun, 27 Oct 96 00:23:34 -0700
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Server upgrading

>I was planning on doing a same server upgrade (INSTALL) next weekend, but
>now you have me nervous. Ideally, the server will not be down for more than
>a few hours (you're probably snickering about right now). I DO have an
>identical new HP server which will be used for SFTIII in a few weeks after
>the upgrade from 3.12 to 4.1 (possibly 4.11). Right now, it's serving no
>purpose. It seems like you'd highly recommend I install 4.1 on the new
>server and then do an across the wire migration, correct? I'm definitely
>interested in finding out more about people's experiences with MIGRATE vs.
>INSTALL on the original server. My concern is that MIGRATE doesn't transfer
>passwords and printing services information, which are the main reasons I
>was opting for INSTALL. However, I'm wondering if people find MIGPRINT
>reliable at transfering printer objects, printer definitions, etc... If so,
>
>I can do without the conservation of passwords and let the upgrade assign
>random passwords. Any thoughts?

As I said, the issue isn't that the process is terrible, but rather what
happens if you get unlucky? I do this kind of thing frequently being a
consultant, so I have to think of worst case - eventually I'll see it.
I'd put up the new server and use the included DS Standard to migrate
everything. It really works MUCH better than migrate, which is why they
included it. it may even allow you to keep passwords in the migration;
can't recall offhand.

>This goes back to my point above. The printing transfer is supposed to be
>a lot smoother using INSTALL rather than MIGRATE and MIGPRINT, right?

I don't think you understand what I'm getting at. The problems I was
refering to are not with the migration process but rather with the
quality of NDS support by third party print server devices. It's been
pretty spotty so far - a lot of devices simply don't work as advertised
with NDS, and the hardware dependencies are suprisiing. So, for example
if you have an HP jetdirect card or external print server you'll have to
check the firmware rev and download the latest flash update and jetadmin
utility. Cards from just two years ago don't work properly and can't be
upgraded; the worst are ones that appear to be upgradable but don't work
properly in NDS mode even after the update. That's when you really need
bindery emulation and print services.

Bottom line here is that professional paranoia pays. If you do decide
you're going to do an in place upgrade make sure you have an upgrade plan
in place including a timetable for abandoning the upgrade and restore to
the previous configuration. BTW, One advantage not doing an in place
upgrade is that you can easily use the larger block size, which is a bit
more efficient.

------------------------------

Date: Sun, 27 Oct 1996 11:35:14 -0600
From: Darwin Collins <dcollins@fastlane.net>
To: netw4-l@bgu.edu
Subject: Re:  3.x to 4.11

This month's (October) issue of Application Notes:
(to subscribe 800-377-4136 / 303-297-2725. you can get a paper or
electronic subscriptions)

This issue talks in-depth about 4.11.  One of the chapters was on
upgrading from 3.1x to 4.11.

Basically, it went along the lines of:

Preparation:
	1. Plan your NDS tree.
	2. Install NetWare 4.11 on a new destination server.
	3. Log in to the destination NDS tree and to the source 3.1x server.

DS Migrate Utility:
	4. Start DS Migrate and run the Discover option to read the current
bindery information from the source server into an offline tree
template.
	5. Model the offline tree by creating new containers, merging
containers, combining duplicate objects, and deleting unneded objects as
needed to make the template match your planned NDS tree.
	6. Configure the live NDS tree with your offline tree.

File Migration Utility
	7. Start File Migration and select the source server to migrate file
information from the source to the destination.
	8. Select a source volume.  You migrate files from one volume at a
time.
	9. Select a destination directory including the server, volume and
directory into which the file system information will be migrated.
	10. Migrate the file system data from the selected source volume to the
destination directory.

PS. It also discussed 'Backing Up and Restoring NDS in NetWare 4.11'.
Basically, DSMAINT.NLM is not needed anymore.  It also discusses how the
newest TSAs will help out 4.10 shops too.

------------------------------

Date: Sun, 27 Oct 1996 11:58:29 -0600
From: Darwin Collins <dcollins@fastlane.net>
To: netw4-l@bgu.edu
Subject: Re:  3.x to 4.x

>I've read that there are lots of problems trying to do an across-the-wire
>migration with NetWare's MIGRATE utility. However, this is supposed to go
>much smoother with 4.11. Anyone have any experience to back up this claim?

I haven't used MIGRATE for the past year.  But, I do remember that it
did work. But, it was like taking everything (including junk) from the old
garage to the new garage when moving houses.   So, we found it useful, to
document everything,  dump 3.x bindery info to a spreadsheet.

Do user name changes and purged the 'luggage'.  On the printer side, our
JetPress and JetDirects were installed as Bindery, so, we did an reinstall
so we could get them to NDS.

>I was planning on doing a same server upgrade (INSTALL) next weekend, but
>now you have me nervous. Ideally, the server will not be down for more than

If you do a in-place upgrade, then, you can't redo the block size to
64k. On 4.x, 64k block size is preferred.

>a few hours (you're probably snickering about right now). I DO have an
>identical new HP server which will be used for SFTIII in a few weeks after

My first across-the-wire took the entire weekend.  (mostly, because of
the printers).  Last one, took about 3 hours of downtime.  (It took that
long to move user (dynamic) data thru a FDDI pipe)

The across-the-wire method, gives you a chance to 'gen' and customize
the new server, while keeping the old one online.

For example:  let say, upgrade day is the comming Saturday.
(the below items don't take all day)

Monday:    Install the server and name it 'temp'. install all patches.
Tuesday:   Document static items on the 3.x server and make those
	   'changes' on the new.
Wednesday: Copy over the static files (apps)
Thursday:  Document the trustees and make the change on the new server.
	   Document printers/queues and such. apply them to the new server.
Friday:    Document the users and create the accounts on the new server.
Saturday:  Copy the user (dynamic) data over.

Rename the two servers. (3.x server to 'old-one'. 4.x server to
'whatever you want') bounce them.

Reconfigure the printer cards for NDS / new server.

Hmm, I didn't explain it well above.  But, what I am trying to say that
an 'across-the-wire' gives you the time to get the new server setup
'right' before you need to 'do it'.

>the upgrade from 3.12 to 4.1 (possibly 4.11). Right now, it's serving no
>purpose. It seems like you'd highly recommend I install 4.1 on the new
>server and then do an across the wire migration, correct? I'm definitely
>interested in finding out more about people's experiences with MIGRATE vs.
>INSTALL on the original server. My concern is that MIGRATE doesn't transfer
>passwords and printing services information, which are the main reasons I

On printers.  I would re-install.  This also gives you the chance to
clean 'printer' house (like printers that don't exist anymore, or have
simply moved)

On the password side.  I have heard of folks running bindfix twice on
their 3.x server, moving the file to the 4.1, server and then running
'upgrade bindery info' to NDS. They said, that it works, but I have never
tried it.

>This goes back to my point above. The printing transfer is supposed to be a
>lot smoother using INSTALL rather than MIGRATE and MIGPRINT, right?

We have Castelle JetPress XIO printer cards.  While they work well with
Bindery, they have enough 'bindery specific' info, that they can't
simply be 'migrated'.  You have to install them.
We have better luck with the HP JetDirect cards, but re-installed them
since we wanted them to be NDS aware.

I think, you simply will have to reconfigure 'printer cards' since the
migrate/migprint items can't reconfigure your cards.

------------------------------

Date: Tue, 29 Oct 96 13:50:32 -0800
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: netsync / migrate

>>>>If being down for a few days isn't an issue, then go ahead and do an
>>>>IN place migration; just make sure you get your boss to sign something
>>>>first!
>
>The problem there is that I don't think that the advantages of NW4.x's
>file system ie sub-allocation would be available, although I have not
>tried this.

You can actually get suballocation and compression, but it's not very
easy. More important, you're stuck with the block size selected from the
original install, and preexisting blocks aren't suballocated. You'd have
to move files around first - of course, compression does do this.

------------------------------

Date: Tue, 12 Nov 1996 10:55:06 -0500
From: Clay Gibney <GIBNEY@WOODSROGERS.COM>
Subject: Netware 4.11 upgrade

I did my first of three Netware 3.12 to 4.11 (IntraNetware) upgrades
last night and was pleasantly surprised.  Finally, Novell has an
upgrade that actually works well and without pain!.  And the
Netware 4.11 support pack was easy to install too!

The server upgrade had potential for failure as the existing
3.12 server has Btrieve applications, SoftSolutions SEM NLM's,
Groupwise NLM's, and Palindrome backup NLM's.

The only thing that we had a problem with was the Palindrome,
and we have already found the update/patch needed to get it
working again when upgrading from 3.x to 4.x.
And when a Palindrome process abended (which normally
would have halted the whole server), what a pleasant surpise
to see Netware 4.11 only terminate the offending process and
keep on running.

Hurray for Novell.

------------------------------

Date: Wed, 13 Nov 1996 09:11:23 -0600
From: "Mike Avery" <mavery@pernet.net>
To: netw4-l@bgu.edu
Subject: Re: Novell 4.1 advantages

>We are getting ready to upgrade our 3.12 server to 4.1.  I have
>had many discussions with my boss regarding how we will integrate
>with our parent co's tree.  I cannot satisfy his questions and am
>asking if you guys and gals could give me more ammo.

So, your company is a subsidiary of another company.

>He is willing to upgrade to 4.1, however he wants each and every
>location (about 16 not including Canada and overseas) to be in its
>own tree (I KNOW!!!).  I have tried to explain to him why this
>would be insane. ( A messy tree, the pyramid theory, increased WAN
>traffic, etc) But he is still not convinced.

Your company has about 16 locations in the USA, plus additional sites
in other countries.

>He also wants to know what the benefits are of moving to 4.1 other
>than easier administration.  He is concerned about WAN outages,
> synchronization times, segment traffic, etc.  I have tried to
>ease his mind but am not doing very well.  (This is my first upgrade
>and I am not an expert with 4.1).

OK.... we all need to start somewhere.

>Can anyone please give me some more reasoning on this?

OK.

My first suggestion is to do a good planning job and convert a single
server.  Live with it for a few weeks and then move forward.

If your boss holds to his guns, remember with 4.1 and later you can
merge trees and perform major NDS changes quite easily.  You aren't
stuck with a disaster.  It's also worth mentioning that your bosses
idea does not integrate your operations with the rest of the company.
It doesn't even integrate your own operations.  And, his idea can
make daily operations difficult.  For example, the library at my last
job distributed the results of on-line research via printers.
Someone would ask for a literature search, and it would be printed to
their printer, even if they were in another country.  It is difficult
to impossible to print to a printer in another tree, as most of the
Novell utilities don't seem to support logging in to multiple trees
at once.

Two of the biggest advantages of 4.X are fairly controversial.  Data
compression and subsector allocation.  If you look at larger drives,
there are some real problems with mounting them.  If you use small
block sizes you need LOTS of memory to mount them.  If you use large
block sizes with 3.X you waste lots of disk space.  Most files don't
exactly fill a sector.  So the space that is not used by the file is
wasted.  The wastage is approximated by the (number of files) *
sector size /2.  If you have 12,000 files with a 64k block size,
about 400 megabytes are wasted on that volume.  With suballocation,
this wastage is reduced as the effective sector size is 128 bytes, so
only 768 thousand bytes.

Compression can also be helpful - the people in my last job just did
not know how to delete files.  So, they had stuff in their
directories that was 7 years old.  And the things had not been
touched, except to migrate it to new systems, in 6.  But, deleting
the files was just not acceptable.  Compression worked very well on
this large block of data.

You boss may have reservations about the management gains from 4.x,
but they often pay for the upgrade in a short amount of time.

The last job I had was for a good sized company - we had sites from
Austin Texas to Brussels Belgium.  From my office in Austin I could
manage the systems in Washington DC, Paris, and Brussels.  The
response time was excellent.  Not having to have technical staff at
every site, and not having to coordinate the staff's efforts can save
considerable amounts of money.

Traffic can be an issue.  It was for us until we read, and
understood, the manuals.  The key to keeping traffic manageable is to
partition the NDS appropriately.  I don't think we need to have a
broadcast message WANwide every time someone logs in or out, or a
printer goes off or on line.

Here's what we did.  We had a top level domain for the company
itself.  In your case, that would be for your parent company.  We'll
call that "parent".

Under Parent should be organization units that represent the various
subsidiary companies.  We'll call one of them TRS.

Under TRS should be another layer of organizational units
representing the geographic realities of your company.  At one time
Novell said that the tree should be designed around the corporate
organization structure - so the people in marketing in Paris,
Washington DC, and Austin TX would be in the same organizational
unit.  Novell realized that this caused massive and unacceptable
amounts of traffic over the WAN.  When I heard this, I realized that
with the ongoing management fad of corporate reorganizations, their
advice meant endless work as management rearranged the deck chairs on
their own little Titanic.

Novell's current advice is to first organize based on the geographic
realities.  So, in my case, Paris, Brussels, Washington, and Austin
would all be in separate organizational units.

A caveat - separate divisions should be in separate organizational
units, IMHO.  Many companies sell divisions.  It's in your best
interests to be able to easily cut them out of your tree.  In your
case, it could be all of trs, or one of your subsidiaries.

So, here's what I'd imagine happening....

The organization would be parent.

Under parent would be a number of organizational units, such as hq
for their headquarters and trs for you.

The organization and these organizational units should be in one
partition.  This partition should have 2 full replicas in the main
office, and at least one full replica in each physical site.  Other
than admin, there should be no users in this partition.  This
minimizes the amount of synchronization traffic.

Inside the companies, there should be additional organizational units
based on location.  The naming conventions can vary based on your
needs.  If you have one site per city, city name might work.  If you
have a number of sites in one city, the city name convention might
not work.  The key here is whether or not the units are separate
units, or a single unit that just happens to be in more than one
site.  The street name, or campus name, could be used also.  Let's
imagine you have one site per city, and then create the city org
units.  Let's use ITASKA, and BERLIN as examples here.  So we'd have
itaska.trs.parent and berlin.trs.parent as two of the org units.

Again, this level of org units should be in a single partition.  And
your main site should have 2 copies of it, with each physical site
having at least one copy.

Under this, you can create additional org units based on your actual
organization.  For example, marketing, accounting, production, mis
inventory management, and so on.  These org units are where your
users would start to appear.  Also, you can create admin level
accounts at any level of the structure, so you could have authority
over all of trs.parent, someone at your parent company might have
admin rights over all of parent.  And someone in Berlin could be
granted admin rights over berlin.trs.parent.

So, you'd have units like mis.itaska.trs.parent,
marketing.itaska.trs.parent, or accounting.itaska.trs.parent.  And
you might be sandy.mis.itaska.trs.parent.  Depending on size, you can
include all of these org units in a single parition.  That is, all
the ????.itaska.trs.parent org units could be in a single parition,
and the ?????.berlin.trs.parent could be in another parition.  Again,
at least 2 replicas should exist for each of these partitions.  If
the sizes become excessive, you could have paritions at the next
level, so mis.itaska.trs.parent and marketing.itaska.trs.parent could
be separate partitions.

The structure above gives minimal WAN traffic and a good amount of
redundancy.  One of the very nice things about NDS, compared to NT,
is that if any single machine goes down, NDS continues to function
normally.  NDS is a distributed data base, so a single machine
failure won't be a problem except for the loss of whatever data and
services were provided by that server - NDS will function well
without any single machine if you've done your homework.  When the
machine comes back up, the data base on that machine will be updated,
or re-synchronized.  NDS is a very flexible and powerful tool.

While putting each site into a separate tree will have slightly lower
WAN traffic than the tree discussed above, there will be a problem
there..... when it is time for you to manage the Berlin office,
you'll have to login there.  This causes delays, and is very
inconvenient.  It's easier to just be authenticated there.

I suspect that some of the people in the group will have suggestions
that will refine my suggestions, or that will totally contradict
them.  That's cool.... that's how we all learn.

My comments, though lengthy, were somewhat terse.  If you have more
questions, please feel free to ask away.

---------

Date: Wed, 13 Nov 96 09:55:54 -0800
From: Randy Grein <rgrein@halcyon.com>
To: "NetWare 4 list" <netw4-l@bgu.edu>
Subject: Re: Novell 4.1 advantages

>He is willing to upgrade to 4.1, however he wants each and every
>location (about 16 not including Canada and overseas) to be in
>its own tree (I KNOW!!!).  I have tried to explain to him why this would
>be insane.  (A messy tree, the pyramid theory, increased WAN
>traffic, etc) But he is still not convinced.
>
>He also wants to know what the benefits are of moving to 4.1
>other than easier administration.  He is concerned about WAN outages,
>synchronization times, segment traffic, etc.  I have tried to
>ease his mind but am not doing very well.

There's a lot more here than I could go into than there's time for, but
we'll hit the highlights. For more complete information point your
browser to http://www.novell.com; they've got all the competitive
advantages stuff you're looking for - the marketing hype as well as
serious techie stuff.

Long and short, your boss CAN have his own way - if each site has it's
own tree then there's NO DS syncronization traffic across the wan. It's
not insane, but usually not optimal. Now Novell has about 1600 servers
worldwide in an absolutely incredible WAN, and they HAVE segmented it
into a number of trees, based on logical units, but not 1 per site!

Here's some of the issues:
1. A properly designed tree has VERY little NDS traffic over a WAN
2. Sync time is flat out handled. There are issues, but they're minor.
WAN or server outages are minor issues that need to be dealt with, but
hardly issues to panic over.
3. If users need access to ANYTHING over the WAN, keep it part of the
same tree.

Advantages for upgrading:

1. Better performance under load
2. C-2 capable security
3. Easier user interface
4. Application management through NAL
5. Better server memory management
6. Better crash protection
7. Better drive utilization with suballocation and compression
8. If your supervisor doesn't understand the administration issues he
needs to be educated. US Bank here in the Pacific Northwest moved to NW
4, and supports 450 servers in 400 sites with 50 engineers. There are a
rapidly growing number of snapins for NDS that integrate application
management with server management; Managewise, Groupwise and Da Vinci
email come to mind right off. And don't dismiss the power of NAL for
application delivery. I've seen it used to completely eliminate the
headaches required to distribute new applications for even VERY large
networks. You might even have time to finally get everything documented!

------------------------------

Date: Sun, 26 Jan 1997 12:08:11 +1300
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: Already logged in problem

>We recently upgraded a 3.12 server to 4.1.  We had to run the upgrade
>multiple times because the server would crash when we tried to add it to
>our existing tree. the only way we got it up was to mack it in a tree of
>it's own. After getting it up we noticed the user login scripts, vol space
>restrictions, and authorities did not transfer from bindery to NDS.  We
>have worked thru all of these probelms but one we can't find out a
>solution to is on about 50% of the old bindery user show something in
>the  "network address"  attribute even when they are not logged on.
>Rebooting the server did not correct the problem. With logins restricted to
>1 this is preventing them from logging on again in NDS, They can logon in
>bindery which is also set to 1 connection.

The entries in the "network address" attribute wont be related to the
upgrade as there is no equivalent bindery attribute, but will be a
consequence of your problems since, or due to user logins since the
upgrade not having the address removed at logout. You can remove these
using Novell's REMADR.EXE which can be found at:

http://www.novell.com/corp/programs/ncs/toolkit/nw4tools.html

Thanks to Steve Wehrle providing a location for this file earlier last week.
I had been aware of REMADR for ages, but had never succeeded in locating
a copy.

------------------------------

Date: Thu, 20 Feb 1997 14:33:40 EST
From: seanstanton@juno.com (Sean M Stanton)
To: netw4-l@ecnet.net
Subject: Re: Whoami - Answer

The functionality of the ATTACH.EXE command line executeable was actually
incorporated into the LOGIN.EXE executeable in NW4.x. To perform the
exact same function in 4.x from the command line that you previously
peformed by executing:

	ATTACH SERVER/USER

you should use the command

	LOGIN /NS /B SERVER/USER

The /NS parameter tells LOGIN.EXE to not execute any login scripts, which
also forces it to not detach or log you out af any current bindery based
server attachments or any NDS authentications, and the /B parameter tells
LOGIN.EXE to create a bindery based attachment, as opposed to an NDS
authentication.

------------------------------

Date: Tue, 1 Apr 1997 13:43:52 -0600
From: "Mike Avery" <mavery@mail.otherwhen.com>
To: netw4-l@ecnet.net
Subject: Re: Migration fron 3.12 to 4.11

>We must migrate in a few weeks from a 3.12 server to a 4.11 one.
>Has anybody made this migration?  Tips, tricks, problems or ideas??

The best way to migrate is to do an over the wire migration to a new
server.  This give you the ability to call off the conversion quickly
and easily if you discover something didn't go as expected, all you
have to do is leave the 3.12 server up.

Between now and then, make sure you find all the patches and upgrades
for NetWare 4.11, and that you have the latest version of all your
critical applications.  Make sure they are 4.11 compatible.

Look at your existing server's layout and decide what you want to
change.  Volume names?  Volume sizes?  Definitely set up all the new
volumes with 64k blocks and sub-allocation turned on.  Other than the
SYS volume, I'd suggest enabling compression on all volumes.

If you have more than a 5 or 6 gigs to convert, you might want to get
a copy of John Baird's utilities.  He has a copy utility that will
let you copy from the 3.12 server to the 4.11 server and maintain
file ownerships and attributes.  It is dozens of times faster than
migrate, and it can be run on several PC's at once, which migrate can
not.  To do this, migrate the bindery, users, and groups, but stop
the migration before files are copied.  Then use John Baird's copy
program to copy the files.

------------------------------

Date: Fri, 2 May 1997 09:58:23 -0600
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: mixed 3.x / 4.x environment

>I have been researching an upgrade to 4.x versus adding a 4.x
>server to our current 3.12 server.  I have found very little on
>how to work with the two together.  So I am asking the list
>to relay any past experiences they have had.  I also have
>the follwing specific questions:
>
>1) How did you set up your tree and manage it?
>
>2) Are there any little quirks to watch out for?
----------------
	There's little to say. Manage each with its own tools. NW 3
is not part of any NDS tree so there isn't a tree design issue involved.
You can create a NW 3 server object in the tree if you wish, not that
it does anything constructive other than make pictures look nice.
	I recommend avoiding the "netsync" item shipped with NW 4. It
sucks out the bindery from NW 3 and makes that server now totally
dependent upon the NW 4 host. That's terrible for site robustness.
	If you have no NW 4 machine running now, as I gather from the
nature of your question, then the sensible thing to do is run one as
a test server until you become familar with it. Notice that you now
have just that mixed environment. Forget about bindery emulation.
	Joe D.

------------------------------

Date: Fri, 22 Aug 1997 10:11:42 -0400
From: Stephen Mellish <sgmellis@VAC-ACC.GC.CA>
Subject: Merging servers -Reply

>I currently have two Novell 3.12 servers running Mercury 1.31.  One
>server is used primarily for internet mail and MAC users.  The other
>is used for interoffice mail and applications.
>
>I would like to merge both mail capabilities to one new server
>running Intranetware and Mercury 1.32 (NDS capable).
>About one-third of all the users (about 200) have access, permission
>etc. to the internet server.  And just about everyone with the
>exception of the Mac population has access to the interoffice mail
>server.  I'm not sure which would be the most efficient way to
>recreate the user info on the new server.  Recreate or migrate?

Take a look at http://www.simware.com/products/rmt.

We are using this migration kit here to migrate 80 of our 3.12 servers to
Intranetware. Novell and Simware have just signed an agreement to
provide this toolkit free of charge to customers upgrading from 3.12 to
Intranetware. This tool kit will migrate all of the users, file systems and
passwords to the Intranetware servers.

------------------------------

Date: Wed, 29 Oct 1997 18:55:34 -0500
From: Bud Durland <ndurland@CAPITAL.NET>
Subject: Re: Mass Client Upgrade Question

>I am in the process of planning a Novell 3.12 -> 4.11 upgrade.  We
>currently have close to 800 clients that connect to our Novell 3.12
>network (onsite and remote).  I have split the project up into phases,
>bring each server up one at a time.

The first phase, of course, is the palnning phase.  Remember, 4.11
is "network centric", instead of 3.12's "server centric" outlook.
How many servers are there?  How are you going to arrange the NDS
tree?  Do you have a WAN?  If so, are your OU's organized by the WAN
links?  Will there be any run-time servers for comm, BorderManager,
GroupWise or the like?

>The first server is a 250 usr that has about 450 user accounts defined.
>I am a little overwhelmed at how to upgrade all of our clients to
>connect to this new 4.11 server.  There are a mixture of
>Windows 3.x, 95 & NT.  The majority being Windows 95 running the MS
>Client for NetWare Networks and close to all of the 3.x users are
>using VLM's of some version. Is the client upgrade something that can
>be done gradually?  Or should it all be done before the server is
>changed to 4.11?  If I do it gradually, what will the users that
>aren't running the IntraNetWare client not be able to do?

First and foremost, before you even install the first INW4.11 server,
get all the clients using VLMs (Dos/Win), INW Client 2.2 (Win95), or
Novell's NT Client.  These client software packages will all talk
just fine with your 3.12 servers.  The Win95 machines, using the MS
client that ships with Win95, will only connect in bindery mode --
letting this stay that way for production for any length of time will
have repercussions down the road.  The Win3.1 clients using VLM's
should be OK, but there is probably very little harm in upgrading
them to the DOS 32bit client as well.  Fortunately, these can all
be installed across the network, making the upgrade somewhat easier.

>If I do the upgrade before the server upgrades to 4.11 will there be
>a problem if the users do not have a preferred tree and name
>context.

I don't believe so..

------------------------------

Date: Wed, 10 Dec 1997 08:10:47 +1000
From: "Graystone, Don T" <Don.T.Graystone@CORPMAIL.TELSTRA.COM.AU>
Subject: Re: Migrating Passwords?

>>We are doing an across-the-wire migration from 3.12 to 4.11 using
>>DSMigrate.  I've read that the users passwords do not come over
>>during the migrate.  I've also done a 3.12 -> 3.12 migrate and was
>>able to bring the passwords over by running bindfix twice and
>>copying them to the new server. Then I ran migrate.exe and all was well.
>>
>>How is this done in a 3.12 -> 4.11 migrate?  Can I do the same thing?
>
>There is no way to get the password from 3.12 to 4.1x in a migration.
>You can have it assign generic password and expire them immediately
>and give user a few chances to change them though.

There is a way to get the password over to 4.11 from 3.x.

It involves doing a Bindery upgrade.  Run BINDFIX twice on your 3.x
server, copy the *.old files to sys:system on the 4.11 server, rename to
*.sys.  From the console (or remote), load install, select Directory
Options, select Upgrade NetWare 3.x bindery information to the
Directory. That's it, all to easy...but;

If an object in the bindery already exists in the directory, the
password will not migrate.
The bindery upgrade also brings over some maybe unwanted objects eg
License objects like XTREENET, LANDESK 1.51 etc, you can delete the
items afterwards make sure you know which ones your deleting, take note
of any bindery objects that may exist in your OU prior to the bindery
upgrade.  It looks a bit ugly as all objects are in lower case.

After that's done, use a program that will preserve Trustee assignments,
ownership etc (eg Arcserve copy job) remember that's not in the bindery,
to copy over your files and your upgrade is complete.  You don't need to
run DSMigrate.

---------

Date: Wed, 10 Dec 1997 17:05:42 +1300
From: "Baird, John" <BAIRD2@WHIO.LINCOLN.AC.NZ>
Subject: Re: Migrating Passwords?

One further step worth doing is to check for bindery objects with the same
name prior to upgrading. Novell provide a tool for this - DUPBIND but
as usual I cant find the URL when I need it...

>After that's done, use a program that will preserve Trustee assignments,
>ownership etc (eg Arcserve copy job) remember that's not in the bindery,
>to copy over your files and your upgrade is complete.  You don't need to
>run DSMigrate.

A possible complication here is that the object IDs change when the bindery
is upgraded into NDS and if your 3.x mail directories are restored, they will
no longer match the user's object IDs. This could be a problem if your users
continue doing bindery logins, or were using Pegasus Mail.

------------------------------

Date: Wed, 4 Mar 1998 22:32:24 -0500
From: "Nathan (Bud) Durland" <ndurland@CAPITAL.NET>
Subject: 3.12 server upgrade mini-guide

I've had many requests for a copy of a small checklist I devised for
migrating a NW3.12 server to new hardware.  To be honest, I am mildly
surprised at the demand.. To make life easier, I posted it on my personal
web page.  It can be found at

	http://www.capital.net/~ndurland/novelltips.html.

As it is, I might try creating a tips page, based on pearls of wisdom
harvested here.  If anybody has anything particular they'd like me to post,
just e-mail it.


------------------------------

Date: Thu, 5 Mar 1998 19:56:31 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Looking for multiple 3.X to 4.11 migration help

>We are migrating multiple 3.x servers to Intranetware.
>
>We are looking at RMT by Rexxware, but after reading
>the docs had the impression we needed a new server for
>each one we wanted to upgrade and do them all at once.
>Is this correct? We were hoping to do one server at a time.
>
>Biggest concern is duplicate user names on multiple servers,
>we'd like to eliminate duplicates but retain rights. In other
>words there would only be one Joe object in our tree,  Joe
>would be located in the BD container, but Joe would still
>have rights to files/volumes/server in other containers even
>though those containers/objects may not yet exist in NDS
>because that particular server is still 3.12. Does this make
>sense? We figure if we migrated all the servers at once this
>would be easy, but doing them one at a time?
>
>I'm quite sure this has alreay been beat to death. If someone
>could point me to a really good article or faq that would be
>cool too.
----------
	These things depend strongly on the scale of the operation.
If you are dealing with a modest number of servers and a modest number
of clients then incrementally replacing a few NW 3.12 with a single
INW 4.11 will be fine. Once users appear in NDS then you can move them
to whatever OU you wish, graphically with nwadmin drag and drop.
	Generally, try to avoid bindery emulation on NW 4. Make the jump
and discover life is actually easier in the end.
	Analyze the problem when computing the number of servers. Servers
move bytes and store them, so figure needs on this basis plus whatever
political arrangements exist. Many OU's can exist on a partition stored on
a single server.
	I sense you have not come to grips with NDS-thinking yet, and
that is understandable. To help I recommend you set up two or three
test servers which mimic your site. Live with them for one or two months.
Practice converting from NW 3.12 to INW 4.11 and creating OUs etc. That
experience is priceless.
	Joe D.

---------

Date: Fri, 6 Mar 1998 15:07:10 -0700
From: Joe Doupnik <JRD@CC.USU.EDU>
Subject: Re: Re[2]: Looking for multiple 3.X to 4.11 migration help

>Thanks Joe. I didn't word my message quite right. We aren't consolidating 3.x
>server to one 4.x server, we are upgrading all our 3.x to 4.x but can only
>do one at a time due to the fact that we only have one maybe two spare
>servers. This is why we can't convert them all at once. We are talking 7
>servers here. We have lots of users who login to one server then attach to
>other servers depending on their needs...thus duplicates. I don't see how
>we can avoid bindery emulation in this environment...unless the powers that
>be come up with enough money to buy seven servers just for the upgrade,
>then we could do all at once....not gonna happen. Sigh.
-------
	Disqualifying myself as "expert" in this area, my thought would
be to double stage this. By that I mean, create a INW 4.11 server and
migrate the bindery of a server to it. Put the users in decent NDS contexts.
Then do the same on another INW 4.11 server in the tree. Once the bindery
has been consumed move things to the other server. Remove the second 4.11
server from the tree, rebuild it, suck up another NW 3.x server the same
way. The idea in my mind is to absorb the binderies at each migration
step, and not kill the NW 3.x servers at the same time (the netsync killer).
	The above is loosely stated, but I hope the idea is clear.
Alternatively, create new users on INW 4.11 and don't bother absorbing the
old bindery. Then folks can switch as soon as you have transported the user
files and set the ownership & access privs.
	My own preference is to build new server images rather than overlay
a new o/s on an old one. This means I have good tape backups and keep the
old disk drive(s) handy during the transistion. There are fewer snags, fewer
leftover files, etc this way.
	Joe D.

---------

Date: Fri, 6 Mar 1998 15:50:38 -0600
From: Darren Rogers <emaildj@MINDLESS.COM>
Subject: Re: Re[2]: Looking for multiple 3.X to 4.11 migration help

As a battle scarred veteran of a recent 7 server upgrade, I gotta say Joe
is right on here (as usual).

We tried a few methods of upgrading, and the easiest by far was to install
a new INW server, then restore a tape of DATA ONLY (leave the sys vol alone
if you can help it).  Then run bindfix twice , and move the good *.old files
to your new 4.11 box.  At this point you can upgrade the bindery info into
NDS, and since the files are all there the trustee rights etc. will keep.
After you do this, try to avoid administrative work on the 3.12 server until
you complete the switch-over.  The day of the upgrade, you can copy all of
the changed files (xcopy has a date option on it) to the new server, and
unplug the 3.12 box.  If anything goes wrong, just plug it back in until
you can try again.

------------------------------

Date: Mon, 9 Mar 1998 19:50:32 -0500
From: "Nathan (Bud) Durland" <ndurland@CAPITAL.NET>
Subject: Re: Novell New Wizard for Migration

>Has anyone used the new migration wizard that was recently released?
>If so, any problems? Was this a same server upgrade or new server?

I just used it to upgrade two 3.12 servers to 4.11. It does *not* work for
in-place upgrades.  You must be migrating to a new server, or (as we
were)putting bigger hard drives in the server, and can use a spare machine
to bring up the 3.12 server.  This product works, as grandpa used to say,
"slicker than owl snot" (don't ask).

A fast over-view:

The migration wizard runs from a Windows95 workstation.  It comes with
some updated 3.12 NLM's.  Copy them to the SYSTEM directory of the 3.12
server and restart it.  Make sure TSA312 is loaded.  Using SYSCON,
carefully review your user names, print queues, and group names.  Since NDS
does not allow object to have the same name, even if they are different
types of object, rename any duplicates.

Install Netware 4.11 on the new server.  Create your NDS tree.  Using
NWadmin, create any additional OU's that you may need.  There is no need to
create any users, although you can create a user template if you want.

Run the migration wizard.  After answering some questions and connecting to
the servers involved, on one side of your screen will be an icon that
represents the 3.12 server's bindery, as well as an icon for each mounted
volume.  On the other side will be the NDS tree for the new 4.11 server.
Simply drag and drop the bindery into the appropriate OU, and drag and drop
the 3.12 volumes into the appropriate volumes on the 4.11 side.  It's OK to
combine volumes.

Tell it to begin, then go get coffee.  Last week, we did a small-ish
server: 15 users and 900MB of data.  From start to finish it took 3.5
hours.  This included installing the new hard drive in the server to be
upgraded, as well as setting up a workstation as a temporary server with
the old (3.12) hard drives.  The only thing to be cleaned up was to add the
'home directory' property to each user -- I'm that was only because we
didn't set up a template first.  Overall, we're going to make a lot of use
of this little tool.

------------------------------