------------------------------------------------------------------------- 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" 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 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 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 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" 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" 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" 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 To: "NetWare 4 list" 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 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 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 To: "NetWare 4 list" 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 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" 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 To: "NetWare 4 list" 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" 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" 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 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 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 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" 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" 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" 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 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 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 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" 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. ------------------------------