Jan 00 NetManage
Volume Number: 16
Issue Number: 1
Column Tag: Net Management
Network Management
by John C. Welch
Working with Mac OS and Windows in a Unix
environment
This article is based on my experiences in the last year and a half in converting my
non-Unix network from AppleTalk and NetBIOS to 99% pure TCP/IP, or as close as I
could get. Although this article primarily focusses on Macs, I will also deal with the PC
side, as they are both intertwined in this project.
When I started in my current position, the original non-Unix network was, to put it
mildly, a mess. This was not due to incompetence, or a lack of desire to do things right,
but to two elements:
1. The Macs had been so easy to network, that there hadn't been a need to
think about them, so they just 'grew in place.' This caused a lot of hidden
problems, which I will go through in more detail. The Macs were there, they
mostly worked, and therefore were okay, as far as the net managers were
concerned.
2. Both of the current staff were ignorant of the ways that the WinTel
architecture functioned, and had bought all the PCs pre-configured from a
local vendor. A nice idea, but as we will see, not a practical one.
I was lucky in a way, since as there was no actual architecture for the non-Unix
machines, I was free to create one. The downside of this, of course, is that I had to
create one from scratch, and as any artist will tell you, creation can be painful. (I do
consider myself an artist in that most of what I do requires an eye for the creative, as
any I.S. pro will tell you).
Problem Identification
The Macintoshes at this site were running a mixture of Mac OS versions 7.0.1 to
7.5.5, with various forms of MacTCP and Open Transport (OT) TCP/IP stacks
installed. AppleTalk was intensively used for all printing and file sharing duties. All
Unix server access was performed via Syntax's Total Access Server (TAS), running on
Solaris. All Windows network access used AppleTalk network stacks running on the
PCs. All printing was via various forms of Apple's LaserWriter driver over EtherTalk.
The PCs were all Windows95, with various service packs, accessing the Unix file
systems via TAS, and the Macs via AppleTalk stacks. All printing was done through
either AppleTalk, or Hewlett Packard's (HP) JetAdmin software, and in some cases
both. The printing was further complicated by the JetAdmin version's requirement for
NetWare as the printing protocol. In effect, the PCs were using four protocols just to
live on the network.
Backups were performed for these systems by a Mac running Dantz Development's
Retrospect 4.0. Although an excellent and reliable product, the backups were running
across a mixture of AppleTalk and TCP/IP, slowing overall performance.
The problems with this system, or lack thereof, were many:
1. Due to all the different MacOS versions, troubleshooting a problem
required sitting at that user's Mac, and testing, because trying to reproduce
the problem elsewhere introduced too many variables into the test.
2. The multiple versions of the Mac networking stacks made troubleshooting
network-related problems difficult and tedious. Even relatively simple
problems required weeding out known issues with versions of OT and MacTCP.
3. The PCs using AppleTalk and NetWare were causing more than a few
problems for those systems.
4. The use of AppleTalk and NetBIOS on a TCP/IP network caused
performance and reliability issues for the Unix users as well as other
platforms.
5. There was no central way to monitor the printer queues to see when a job
was blowing up or stalling the printers, because the Macs and PCs printed
directly to the printers. In addition, the PCs were using vendor-specific
drivers for printing, again making maintenance difficult.
6. Although TAS is a good server product, using AppleTalk and NetBIOS as an
interface for Network File System (NFS) shared file systems was adding a
layer of complexity to the network.
7. The PCs had various types of 'combo' cards installed, attempting to
combine networking, video, and sound onto the same card. In each case, only
the video worked, so additional sound and networking cards had to be installed,
resulting in duplicate cards for these functions. This made the hardware
reliability of the PCs sketchy at best.
8. Finally, the backups needed to be reduced to a single protocol where
possible.
The Fixes
Get everyone on the same OS page
The first order of business was to move each platform onto a current and consistent OS
version. By this time, Mac OS 8.0 had been released, so all capable Macs were
upgraded to this version. This left about five Mac IIsi's out in the cold, because OS 8
would not run on Macs with that processor, (68030). Rather than upgrading them to
version 7.6.1, we decided to purchase new machines for these users, and for other
users whose needs outstripped their hardware. Since the G3 was not available to us,
the machine settled on for desktop Macs was the 8600/300, with the Mach 5 604e
processor. The 8600s were equipped with 128 MB of RAM, so that Connectix Corp's
Virtual PC (VPC), also purchased with each Mac, would be available (see sidebar).
Emulation issues
Although I have seen many people dismiss VPC and other emulators out of hand, by
making sure that each Mac was able to devote 100 MB of RAM to VPC, we have gotten
consistently good performance out of the product. I have seen performance equivalent
to that of Citrix's MetaFrame product at least in almost every case.
For laptop users, we purchased either PowerBook 3400/240s or 2400/180s, along
with one first -generation PowerBook G3. This phase took approximately five months
to complete. When we finished, only one 68K Mac was left in use, and it was targeted
for replacement within the next month.
The result of moving everyone to the same OS level is that the Mac users realized
immediate gains in reliability and performance. One of the side benefits was that a
growing desire to replace all the Macs with PC's was now seen as unnecessary. The
same benefits occurred with networking, since everyone was now using the same
version of OT (1.2), this gave them gains in performance and reliability. From an IS
perspective, [TK fill in missing sentence fragment or remove]the consistency between
the platforms immediately slashed maintenance and troubleshooting time as problems
could be duplicated or verified at more than one workstation.
On the PC side, all the machines running Windows95 were upgraded to the most
current Operating System Release (OSR) version. This allowed the use of PowerQuest's
PartitionMagic to convert the Windows machines' hard disks to FAT32. Use of FAT32
resulted in a more stable file system, and some fairly impressive (300MB to
700MB), space recovery on those drives, along the same lines as the gains Mac users
experience when moving to HFS Plus with Mac OS 8.1. In addition, the troublesome
combination video/sound/network cards [TK were these mentioned earlier in the list
of problems? If not, identify 'em more thoroughly here] , which had only worked as
video cards, were replaced by reputable models. We used ATI or Matrox (video),
SoundBlaster (sound) and 3Com, (network) cards. The new cards resulted in each of
these features now being usable, and eliminated a lot of squirrelly drivers from the
mix. Finally, the HP JetAdmin software in the PC's was updated to allow the use of
TCP/IP instead of NetWare and AppleTalk to print, again, eliminating errors and
problems by simplifying the configuration.
We started in August '97, and by January '99, we had finished one part of the
conversion to TCP/IP. We also joined the Apple Developer Program, installed two new
web servers, including a Power Macintosh 8600/300 running WebStar 2.x and
Rumpus, 1.x, (For FTP services). [TK mention the platform?], converted from 2 Mb
Ethernet with a 10Mb backbone, to 10Mb Ethernet with a 100Mb backbone, upgraded
all the Sun machines to Solaris 2.6, and installed a new email system. The next step
was to deal with the printing issue.
Printing the Unix way for fun and profit.
The printing differences between Unix and the other machines had been the cause of a
few arguments in the company. The Unix users could easily check on each other's print
jobs, and printer status, but could not tell when the delay was caused by a Mac or PC
print job. Since in the science world, a PostScript file of a color plot sent to our color
printer (a Tektronix Phaser 550 with the 1200dpi option, if you're curious) could
easily exceed 20MB, making the wait for an unknown job to finish mildly frustrating,
especially if you had one of your own to process.
The most logical solution was to get the Macs and PCs to use the existing Line Printer
(LPR) server, and print over TCP/IP, which increased the efficiency of printer
usage, and allowed for more accurate print job monitoring, plus eliminated a lot of
AppleTalk and NetBIOS usage. The Macs were helped by the fortuitous release of Mac OS
8.1, which included the LaserWriter 8.5.1 drivers and LPR printing support. The
upgrade was quickly implemented and by mid-February to early March, all our Macs
were printing solely via TCP/IP to our main Unix print server. The Mac users were
happy that their print speed was much faster (spooling to a server is faster than
spooling to a printer), the Unix people were happy that the number of unknown print
jobs had dropped by over half, and the IS staff, were happy because we now had better
control over how the printers were being used.
On the PC side, our TCP/IP printing architecture was implemented in two phases. The
first was the purchase of a site license for the Exceed X-Windows package, from
Hummingbird. Primarily intended as a way for Windows users to access Unix
programs instead of using telnet, the Exceed software included an LPR print server,
which allowed us to create new ports for the existing HP and Tektronix printers. These
new ports rerouted the print jobs to our main Unix print server. All users were now
placed in the same printing queue(s), which provided better monitoring and control
over print jobs and problems. In addition the PC users received faster printing times,
and fewer system errors from the HP drivers, which were turned off at this point. For
our, Windows NT users, that OS has built - in LPR capabilities, so it was a matter of
installing the correct printer drivers, and connecting them to the appropriate ports.
The next step for the PC users was to replace the multiple vendors' printer drivers
with one better suited to the printers we own and the way we print. Since all of our
printers are PostScript, the only logical choice was Adobe's. The Adobe drivers were
installed, and again, printing became a much more reliable and forgettable process. (It
is my firm belief that in the IS business, the best programs are the ones that do their
job so well, you forget they are running. Obviously this list is too short.) A side
benefit was that we are now able to use one PostScript Printer Description (PPD) file
for all of our platforms, so that all of our users can print with consistent capabilities
and quality, regardless of platform. This final phase was only completed within the last
few months.
Connecting the whole world in a consistent way
The final and most complex step to our total solution was the file connections. There
had been no standard way for all the computers on our network to connect to each
other, so as a result, we had a chaotic conglomeration of confusing configurations and
protocols, from TCP/IP (Unix), to NetBIOS (PC), to AppleTalk (Mac).
Although we were using the TAS product, it had several disadvantages, among them,
speed, (it was agonizingly slow on the AppleTalk side, to the point of causing even our
G3 systems to grind to a halt to even mount a drive). TAS was also a very complicated
product to deal with, the worst example being the way it dealt with the Mac OS's dual
file fork system. TAS would keep the resource forks in a separate directory, and use
index files to match them when a Mac would attempt to access them. Unfortunately,
this was unreliable, as about 20% to 30% of application files would become corrupt
under this system. In addition, if a file was moved or added using the standard Unix
commands, and it was a Mac file, it lost the resource fork, and become corrupt and
crashed machines when accessed via AppleShare (we determined TAS was responsible
for this by FTP'ing the same file to a Mac, which allowed it to be used without error.)
On the PC side, the password setup was unreliable for Windows 95/98, and for
Windows NT, because it required a registry edit to enable plain text passwords. Since
well over 50% of our systems and 95% of main servers are Unix machines, the
obvious solution was to install an NFS client on the Macs and PCs. After some diligent
and obscure searching, I found a solution for both platforms, IntragyAccess, from
Ascend Communications. IntragyAccess is a suite of TCP/IP applications, including an
LPR client and Server, an FTP server, and, most importantly, an NFS client. By
installing the NFS client on both the PCs and the Macs, we were able to complete most
important part of the puzzle: Unix fileserver access. To handle the issue of non-Unix
file access, for things like PC to Mac filesharing,we implemented two solutions .
First, we purchased a G3/300 AppleShare IP (ASIP) server. Version 6.0 of ASIP
supported Windows access via Server Message Block (SMB) protocols, so this Mac is
able to function as a network install point for both the PC and Macintosh machines. Due
to the implementation of a LPR server in ASIP 6.X, it has also, on occasion, functioned
as our backup printer server. The server is also our Retrospect server, and has 3 sets
of mirrored hard drives, and backs up to a seven - tape Digital Linear Tape, (DLT)
changer, and also holds a Zip, and a 2GB Jaz drive. (The floppy was pulled to make
room for the Jaz.) The G3 server is also running FilmakerPro as one of the main
applications on the corporate intranet. To allow the PCs and Macs to share files easier,
we have begun to install DAVE, from Thursby Systems. This allows the Macs to use
SMB as a filesharing protocol for two - way file access between Mac and PC systems.
DAVE is essentially an IP-based NetBIOS stack for the MacOS, so it fits in nicely with
our network strategy.
Conclusions
Although the complete changeover described took a year, and went on simultaneously
with a lot of other projects, it has been worth it so far. Cross-platform file access
(considering we have more than 3 versions of Unix, that is a bit more than the usual
meaning of cross-platform) has improved in both speed and reliability. With all our
printing routed through the same server queues, monitoring and handling print jobs
has become much easier. Although the printer hardware is no faster, the spooling
process is faster and the users are quite pleased. Currently, unless a Mac to Mac file
transfer is taking place, almost 100% of all traffic on our network is TCP/IP, and we
are able to maintain an average speed of 6+Mb/sec on our 10BaseT Ethernet lines. In
short, it has been a rousing success.
That is not to dismiss the effort behind the upgrade. This was a year of hard, and often
frustrating work. Neither PCs or Macs really are yet designed for 100% TCP/IP
utilization, but it is getting much easier. It takes a lot of planning, diligence, and
discipline to stay focused on what can be an ephemeral goal, but the end result is a
better used and maintained network, that can easily handle almost any client.
• Adobe - http://www.adobe.com
• Apple Computer, Inc. - http://www.apple.com
• Citrix - http://www.citrix.com
• Connectix - http://www.connectix.com
• Dantz Development - http://www.dantz.com
• Hewlett Packard - http://www.hp.com
• Hummingbird - http://www.hummingbird.com
• Novell - http://www.novell.com
• Solaris - http://www.sun.com
• Syntax's Total Access Server (TAS) - http://www.syntax.com
• Thursby Systems - http://www.thursby.com
______________________________
John Welch (jwelch@aer.com) is an I.S. Professional at a weather and atmospheric
science company in Cambridge, Mass. He has over fifteen years of experience at
"making computers work." He has worked on almost every platform, and is keeping his
options open.