Novell Home

Implementing NetWare 5 @ Novell

Novell Cool Solutions: Feature
By Grettir Asmundarson

Digg This - Slashdot This

Posted: 7 Jun 1999
 

Acknowledgments: This article could not have been written without the generous help and input from everyone in Novell's IS&T Global Technical Architecture group and Grettir Asmundarson, a pseudonym (duh).

In this article we’re going to tell you exactly how we use our own products to run our own company here at Novell. After all, we are not a small, tidy computing environment suitable for documentation. We are a big, sprawling environment made up of over 500 production servers and 20,000 workstations in 130 locations throughout the world. In other words, we’re probably an awful lot like you.

And it’s not that we’re necessarily any smarter than you are, we just have a distinct advantage. By the time you get your hands on one of our released products, we’ve already been using it to run our business for quite some time. For instance, a month before NetWare 5 shipped, over half of our 500 production file servers had already been upgraded to NetWare 5 and were being used by Novell employees to get NetWare 5 and other products out the door. (Keep in mind that these are production servers. These are not test servers that we have safely tucked away in antiseptic labs. These are real-world servers in a real-world environment solving real-world problems.) And through the different alpha and beta product cycles, we’ve upgraded most of those file servers multiple times. So I think that it’s safe to say that, at this point, we have performed more NetWare 5 upgrades than anyone else in the world. That means we’ve probably gained some insights into implementing NetWare 5 in a big, sprawling environment, and this paper is an attempt to share those big, sprawling, untidy insights with our customers.

The Implementation Process

The process for implementing NetWare 5 in any large organization is really quite simple and straightforward. It’s just a matter of following seven, simple steps:

Note: Since we’ll be using examples from our own environment, this article will deal mainly with upgrading an existing NetWare 4.11 infrastructure to NetWare 5. You’ll obviously have to make adjustments if you’re dealing with NetWare 3.x, 4.0x, or 4.10.

Prepare the Tree

Before upgrading any of your existing NetWare 4.11 servers to NetWare 5, you need to extend your tree's NDS schema by installing DS.NLM 5.99a (or higher) on all existing NetWare 4.11 servers. (DS.NLM 5.99a can be found in the \PRODUCTS\411_UPG directory on the NetWare 5 CD-ROM.) This adds the operational schema extensions to your existing tree that are required by NetWare 5.

This is very important. If you attempt to install a NetWare 5 server into the tree without having first installed the operational schema extensions you'll end up paying for an embarrassing Support call. And while our accountants love revenue-generating embarrassing Support calls, we’d just as soon save you the expense and embarrassment on this one.

And speaking of the NDS schema, if you are going to be implementing some of the more object-heavy aspects of NetWare 5 (DNS/DHCP, Z.E.N.works, etc.) this might also be a good time to evaluate the memory needs of your DSMASTER servers.

Your DSMASTER servers can operate much more efficiently if they can store their entire database in RAM. And if you’re going to be adding tens of thousands of new objects to the tree, now might be a good time to upgrade if you’ve been squeaking by in the past.

Pick a Target

Once you’ve prepared your tree, you’ll need to decide which NetWare 4.11 file server to upgrade to NetWare 5 first.

A prominent computer publication (which shall remain nameless, though I will tell you that it covers the “PC” industry and is published every “Week”) recently reported that those upgrading to NetWare 5 should upgrade their DSMASTER servers first.

Well…umm…you could upgrade your DSMASTER servers first if you really wanted to, but I would keep in mind the instructions found on most household laundry products:

Warning!

If in doubt about the reaction of a particular fabric to this product, test on an inconspicuous area of the garment prior to use.

So, even though NetWare 5 is safe for all of your machine-washables, we would recommend testing for colorfastness on something a little less conspicuous than the servers that are storing the master replicas of your NDS partitions.

We usually deploy any new technology on an IS department application server first. We know the servers well, we can keep a close eye on things, and if something goes horribly wrong we can just tuck the unsightly spot into our trousers and no one's the wiser.

Review the Pre-Upgrade Checklist

Come on, admit it. Who hasn’t downed a file server to perform some sort of maintenance only to realize that the information or software they needed was on the file server they just downed? The following pre-upgrade checklist keeps that sort of thing from happening. (We’ve also appended a copy of our official checklist at the end of this document.)

1. Record the following information:

Server Name:

Person Performing Upgrade:

Date of Upgrade:

Start Time:

End Time:

IPX Internal Network #:

IPX Network #:

IP Address:

Subnet Mask:

Default Gateway:

2. Verify that the server meets your minimum hardware specifications.

In our case, here’s what we like to see in a production server that is going to be upgraded to NetWare 5:

  • 200 MHz Pentium Pro
  • 128 to 256 MB RAM
  • 1 GB DOS Partition
  • 2 GB SYS Volume
  • As much disk space as we can cram in the beast

Obviously this is above and beyond Novell's official “minimum hardware specifications” for NetWare 5 (which, last I heard from Marketing, were a Commodore 64 and a cassette tape player). Nor is this to be considered “recommended hardware specifications” for everyone in every case. These specifications simply fit the needs of our particular production environment.

These rather hefty hardware specifications reflect a cultural/computing shift that we are making from having numerous, smaller file servers to deploying fewer, larger file servers. And our 1 GB DOS partitions will almost certainly be larger than you will need, but we need the room for the diagnostic core dumps we use when debugging alpha and beta code.

3. Verify that your hardware is NetWare 5 Compatible.

On the whole, we haven’t had any significant problems finding NetWare 5 driver support for our servers. We did have to swap out a few of our more obscure FDDI cards, and you may have trouble finding NetWare 5 drivers for that parallel port-based ATM adapter that you bought from your brother-in-law. But, even before NetWare 5 was released, we were seeing tremendous support from all of the major server/peripheral manufacturers.

Still, double-check support for all of your components, especially your SCSI adapters and NICs. A good place to start is the Novell bulletins,

YES Tested & Approved.

4. Verify that a full backup has been performed on the server.

Obviously.

5. Run DSRepair & check NDS synchronization.

Clean up any NDS replica irregularities and ensure that local replicas are properly synchronized.

6. REM out 3rd-party NLMs.

Until you've verified that all of your 3rd-party NLMs are fully NetWare 5 compatible and won't interfere with the upgrade process, it’s better to play it safe (anti-virus and backup NLMs can be especially troublesome). Let us repeat, a good place to start is the Novell Solutions Search, searching for

YES Tested & Approved.

7. Install a mouse.

And make sure the mouse port is enabled. In a late-night fit of troubleshooting, someone may have disabled the mouse port in order to free up an IRQ. You’ll need the mouse for the new GUI install.

Perform the Upgrade

The upgrade/installation itself is explained in great detail in the documentation and Readme files, so I won’t waste your time here. But there are two things to watch out for:

  • The first dialogue boxes default to an installation type of “New Server.” If you’re performing an upgrade, you’ll want to change that to “Upgrade From 3.1x or 4.1x.” Don’t worry. If you miss it, it will warn you a few times that you’re trying to do something foolish, but keep an eye out for it.
  • And on new installs, you’ll want to specify an internal IPX number for the server (or server ID number as it is now called) on this same screen. It’s hidden in the Advanced Settings section (press <F2>).

By the time you read this, we should have released a free tool called the NetWare 5 Accelerated Upgrade Utility on our web site Migration and Upgrade Utilities. It is a text-based, scripted, across-the-wire upgrade tool that we’ve been championing internally to the point that they decided to turn it into a product.

As the name would suggest, it has allowed us to significantly speed up the process of upgrading a large number of servers to NetWare 5. For instance, with the Accelerated Upgrade tool, we were able to upgrade over 100 servers in less than six hours. For all of the aesthetic loveliness of the GUI install, it’s just not possible to roll out multiple upgrades that quickly.

The only downside of the NetWare 5 Accelerated Upgrade is that it is only an OS upgrade. It does not allow you to install any of the new NetWare features such as DNS/DHCP, etc. But, since most of our internal servers are acting as generic application servers, the tool has proven to be quite handy.

The Post-Upgrade Checklist

After you've performed the upgrade, the following steps will ensure that everything went smoothly and the server is functioning properly:

1. Restart the server.

2. Check the bindings.

Make sure both IPX & IP are bound and functioning properly.

3. Check volume mount status.

Make sure all of the volumes are mounted and functioning properly.

4. Check Timesync & NDS synchronization.

NetWare 5 now has support for NTP, but that doesn’t mean Timesync has gone away. Timesync is still necessary for NDS synchronization. You could load NTP on every file server, but you just may want to have your Reference server use NTP to set its time, but then use Timesync alone on your Primary and Secondary servers.

Another thing you might want to consider taking the time to do is setting “Configured Sources = ON” and specifying both the server name and IP address of the server’s Timesync Time Source. In other words, something like:

MS-DSMASTER;207.46.131.137;

(Notice the placement of the semicolons.) That way, if you ever switch to Pure IP, you’ll be ready to go.

5. Change SET parameters.

The following is a list of recommended changes to the default SET parameters:

SET Maximum Packet Receive Buffers = 2000

SET Maximum Service Processes = 500

And on Pentium Pro hardware or higher:

SET Maximum Concurrent Directory Cache Writes = 200

SET Maximum Concurrent Disk Cache Writes = 2000

6. Check licensing.

Log in to the server and map a drive to one of its volumes. If the server is not properly licensed, it will tell you soon enough.

Here are a few licensing tips:

  1. If you license a server and then immediately try to log in, you might get messages stating that the server is not properly licensed. This happens because the licensing object’s attributes are especially large and take a while to synchronize. Wait a minute and try again.
  2. Here at Novell, we’ve installed an MLA license in every container that contains (or might contain in the future) server objects. That reduces the amount of tree walking required to find a valid license since it’s always right there in the same container.
  3. And if a container has both NetWare 4.11 servers and NetWare 5 servers, and the NetWare 5 servers hold no replicas, we load NLS on a NetWare 4.11 server that holds a replica in that partition. (Was that confusing? We thought so...)

7. Verify printing.

Your old queues should operate just as they always have. We’ll get to NDPS in a minute...

8. Load and re-enable 3rd-party NLMs.

Again, make sure that your 3rd-Party NLMs are NetWare 5 compatible before attempting to reload them.

Did we mention that a good place to start is the Novell bulletins,

YES Tested & Approved?

9. Notify the backup team of the upgrade and verify the back up.

Make sure the backup folks know that you’ve upgraded the server to NetWare 5 and make sure they are able to back it up successfully.

Upgrade the Clients

Clients can be easily upgraded using the automatic client upgrade (ACU) process. After creating a configuration file with the Novell Client Install Manager utility (NCIMAN.EXE) that specifies your preferred defaults, you can insert the following commands into the login script:

IF “WIN95” = “%PLATFORM” THEN BEGIN

@\\servername\sys\public\client\win95\setup.exe /acu /u:script file

END

IF “WINNT” = “%PLATFORM” THEN BEGIN

@\\servername\sys\public\client\win95\setupnw.exe /acu /u:script file

END

The at (@) symbol allows the script to continue running while the client setup is starting. If you use the pound (#) symbol, all processes will be suspended while the client is being upgraded and could make some other processes very unhappy.

The /acu switch instructs the client setup program to check the version of the client on the workstation and only upgrade if it is a newer version.

The /u:script file option is used to specify a configuration file for controlling how the client will be installed. You must specify the full path to the configuration file for Windows 95 clients. But for Windows NT clients, the filename is sufficient if the configuration file is in the same directory as the SETUPNW.EXE file.

There is very good documentation online that outlines this process completely. Take a look at the Novell Online Documentation web site.

Play with Your New Toys

Once you’ve gone through your Post-Upgrade Checklist, you’re ready to start playing with some of the new toys that are part of NetWare 5. What follows is a list of some of the more significant new features in NetWare 5 and how we’re deploying them internally.

DNS/DHCP

Before we implemented the DNS/DHCP portion of NetWare 5, almost 20% of our Help Desk calls were related to IP addressing issues. Now that almost all of our workstations have IP addresses that are dynamically assigned and managed via DNS/DHCP, IP-related support calls have fallen off dramatically.

DNS/DHCP can add an enormous number of objects into your tree. If you were to set up your entire Class B address base (approx. 65,000 addresses), you can expect about 240,000 new objects in your tree before you’re through. (Keep in mind what was said earlier about large numbers of objects and the memory requirements of your DSMASTER servers.) And these objects are fairly dynamic. So if you want to optimize your NDS synchronization, you might want to seriously consider segregating DNS/DHCP data from the rest of your NDS data.

At Novell, we’ve partitioned the DNS/DHCP data off in its own container, with its own replication ring dedicated solely to DNS/DHCP. That way, the synchronization of regular NDS data doesn’t get bogged down if 10,000 workstations all decide to release and renew their DHCP-assigned addresses at the same time.

And if you’re particular about having a tidy tree, you could even deploy DNS/DHCP in its own separate tree. There are obvious disadvantages to this (additional hardware requirements, maintaining separate administrator accounts in both trees), but it’s an option.

Here are a few other tips:

  • The DNS/DHCP Management Console is very dependent on being able to find the DNS/DHCP Locator Object in the tree. You can speed up the launch of the Management Console by finding the Locator Object within NetWare Administrator first and then launching the Management Console. And if people in outlying areas are going to be administering DNS/DHCP, they’ll be a lot better off if there is a replica of the partition that contains the Locator Object as close to them as possible.
  • NetWare 5's DNS/DHCP will work fine with any other DNS solution that you might be using (UNIX, etc.), so you can just plug it in and start using it as a secondary DNS server right away. Later, if you’d like, you can promote it to become your primary DNS server just by clicking a radio button.
  • And it is BIND 4.9.6-compliant, but without any of the security risks. Huzah!

NDPS

There are several articles on the Novell Web site which will help you understand NDPS.

Read some of them for a detailed explanation of what NDPS is, what it can do, and how you should use it. But here are a few things we’ve found from our own implementation:

Your HP JetDirect printer server firmware needs to be version x.03.06 or higher in order to work with the HP Printer Gateway. Some of our older HP JetDirect cards weren’t up to snuff in that respect, but they did have support for LPR. So, since NDPS also supports LPR, we were able to continue using them (via LPR) until we could swap them out for newer cards.

And we’ve ended up keeping most of our old queues around because you can’t currently capture directly to an NDPS printer. In order to print from DOS applications, you’ll need to capture to a print queue and then have NDPS service the queue.

NSS

There are a lot of advantages to NSS: huge volumes, huge files, lightning fast mounting, the ability to easily mount the DOS partition and CD-ROMs, very fast repairs of incomplete transactions, etc. However, there are a few things that you need to keep in mind about NSS.

Your SYS volume cannot be on an NSS partition. This is because NSS does not support TTS (yet), which is required on the SYS volume. NSS doesn’t support user space restrictions or compression. And there is currently no way to upgrade conventional NetWare partitions to NSS. You have to back up the data, delete the old partition, create the new NSS partition, and then restore the data. Because of this last limitation, we aren’t doing a wholesale upgrade of our existing servers to NSS. But, since the advantages of NSS are so compelling, we will be deploying NSS on the non-SYS volumes of all new file servers that we roll out for now.

Pure IP

What’s the best way to test NetWare 5's native IP support? Well, we decided the best test would be to remove all traces of IPX from the building that houses our core OS developers. (Let’s just say that any bugs that cropped up were promptly addressed.) So, our Core OS Development Building in Provo has been running IPX-free since July. Our Client Development Building in Provo and one building in San Jose went IP-Only in the first part of September. And our new San Jose campus is Pure IP from day one. The plan is to have the entire corporation “IP Only” within 4-6 months. At that point, you’ll have to check all IPX packets with a security receptionist before entering the buildings.

As a preview, we’ll outline the two different approaches you can take.

First, you need to answer two questions:

  1. What are your IPX dependencies?
  2. How big of a hurry are you in?

These two questions are important because the answers to these questions will determine where you are going to devote your time and resources.

The ideal way to transition to Pure IP would be to spend your time getting rid of your IPX dependencies. In other words, leave IPX on the wire, but slowly remove your dependence on it until it is a vestigial protocol. Spend your time converting your servers to NetWare 5 and upgrading from IPX-dependent applications (e-mail, backup, anti-virus, faxing, remote access, etc) to IP-based solutions. Eventually, IPX will simply disappear on the wire and it becomes a non-issue.

However, if the router czars are anxious to get rid of IPX as soon as possible, or if your CEO bases your salary on your ability to purge IPX from one of your network segments by the end of the month, you may need to devote your energies to setting up an infrastructure that allows you to turn off IPX one segment at a time.

Here’s a brief outline of the necessary steps for this second option:

Objective: Convert all services on a network segment from IPX to Pure IP with Compatibility Mode and then turn IPX routing off at the router.

  1. Place the Migration Agent (MA) and Directory Agent (DA) in a central location within the network topology. Since the rest of the network will still have IPX, the MA must be placed outside of the segment being converted so it can collect the SAP/RIP for clients and servers in the Pure IP area.
  2. Before you start upgrading clients to IP/CMD you should upgrade all the servers in the Pure IP area to NetWare 5 with IP and IPX bound. IPX clients and IP clients will then be able to access these servers while we are converting the clients from IPX to IP/CMD.
  3. Before you start upgrading clients in the Pure IP area to IP/CMD you may want to convert the printers in the area to NDPS and configure NDPS to print via IP.
  4. To avoid upgrading the clients twice (IP/IPX and later to IP/CMD), the MAs need to be in place in a central location within the network topology. During the client upgrade, you can configure the clients to use the MAs to access IPX services.
  5. Once the clients have been upgraded to IP/CMD, you can remove IPX from the NetWare 5 servers and load SCMD.
  6. Once the clients, servers, and printers in Pure IP area have been upgraded to IP/CMD, you can shut off IPX routing to the Pure IP segment.

Now wasn’t that simple?

Z.E.N.works

As we continue our internal roll-out of Z.E.N.works, we are concentrating our efforts in two areas: Application/Software Distribution and Desktop Management.

We are using Z.E.N.works’ Application/Software Distribution capabilities to push out Windows 95/98/NT patches and service packs, install and upgrade web browsers (with automatically personalized settings), distribute all manner of client software (Oracle, etc.), and later this year we will be rolling out a new application suite to every user in the company. And none of this will require a visit to the user’s desk.

Our internal Help Desk is also using Z.E.N.works extensively to help with the diagnosis, management, and the remote control of workstations with technical problems, again minimizing the need for visits to the user’s desk.

We have yet to take full advantage of power of workstation policies, but we are working on an implementation plan right now.

Like DNS/DHCP, you will see a pretty hefty increase in the number of objects in your tree after you’ve deployed Z.E.N.works (at least one object for every workstation), so keep that in mind if you’re redesigning or rearranging your tree.

Conclusion

Well, this wasn’t intended to be a thorough analysis of NetWare 5, but hopefully it has given you some ideas as you go about planning and deploying NetWare 5 in your big, sprawling, untidy environment. Maybe now it won’t seem as big, be as sprawling, or look as untidy as it once did.

Hope to see you next time.

As promised, here's our NetWare 4.x to 5.x Server Upgrade Checklist

Record Information about the Server

  • Server Name:
  • Person Performing Upgrade:
  • Date of Upgrade:
  • Start Time:
  • End Time:
  • IPX Internal Network #:
  • IP Address:
  • Subnet Mask:
  • Default Gateway:

Pre-Upgrade (Before Downing the Server)

  1. Verify That Server Meets Minimum Hardware Specifications
  2. Verify That Hardware Is NetWare 5 Compatible
  3. Verify Backup
  4. Run DSRepair and Check NDS Synchronization
  5. REM Out 3rd-Party NLMs
  6. Install Mouse (Check EISA Configuration)

After the Upgrade

  1. Restart Server
  2. Check Bindings (Ping xxx.xx.x.x)
  3. Check Volume Mount Status
  4. Check Timesync and NDS Synchronization (Configured Sources = On, Time Source= MS-DSMASTER;xxx.xx.xxx.xxx;, and Use Local Time Source on Servers Not Located In City of Your Master Servers)
  5. Change Set Parameters (SET Maximum Packet Receive Buffers = 2000, SET Maximum Service Processes 500, And on Pentium Pro Hardware or Higher: SET Maximum Concurrent Directory Cache Writes = 200, and SET Maximum Concurrent Disk Cache Writes = 2000)
  6. Check Licensing (Login to Server and Map a Drive)
  7. Load and Re-enable 3rd-Party NLMs (Management)
  8. Notify Backup Team of OS Change And Verify Backup


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell