In-Depth
Client-Side Interop
Rare is the company without non-Windows desktop clients. Yet getting Unix and Apple to connect to and access resources on a Windows-based network can be migraine-inducing. Here's your antidote.
You’ve probably read a lot on interoperability that focuses on the server
side. Normally, articles and books on the topic cover the integration
of Windows and Unix-based servers, which is certainly an issue many enterprises
are grappling with; but there’s another side to interoperability: the
clients. I’ve worked in a number of shops where the graphics design folks
insisted on using Macs and the geeks claimed they couldn’t live without
their Unix-based desktops. Working with Windows servers in a mixed-client
environment can be downright difficult. This set of articles walks you
through major interoperability problems and how to solve them with minimal
muss and fuss.
Neither Pain nor Heresy
Despite Microsoft’s ballyhooed “monopoly” of the desktop operating system,
few enterprises can claim an all-Windows client base. Macs dominate the
media departments; Linux, Unix and Lindows command the desktops of scientific
and engineering users; and plenty of other platforms, such as Palm OS,
crop up among business users.
Most Windows administrators view these non-Windows clients as pains in the posterior at best—heretics at worst. After all, providing access to Windows-hosted network resources for these clients is decidedly more difficult than for the fully compatible Windows clients we’re accustomed to, including Windows 9x, Windows 2000 and Windows XP. Yet, users love their applications, and they’re loath to move to Windows versions without truly compelling reasons. Therefore, we need to work on providing as much interoperability as possible. In fact, you’ll find that you can provide quite a bit of interoperability without much hassle.
What, exactly, does interoperability mean? Simply put, it’s making non-Windows clients work and play well with network resources and services that live on a Windows-based server. Those resources and services fall into a few basic categories.
Authentication. We control access to resources primarily through
domain user accounts, whether they’re NT- or Active Directory-based. Therefore,
a key component to successful interoperability is allowing non-Windows
clients to authenticate to the domain.
Messaging and collaboration. The “killer app”
for every enterprise is e-mail. While some companies provide non-Windows
users with a Windows client so they can access the corporate e-mail system,
interoperability should allow non-Windows users to access e-mail and other
collaboration services without forcing them to use two computers.
File sharing. Another core enterprise service,
file sharing, should be seamless and intuitive for non-Windows clients,
even files secured by NTFS permissions.
Document formats. Assuming you can provide file
sharing services, you need to ensure that users on non-Windows clients
can actually work with the shared files. Having cross-platform file formats
is an important part of any interoperability strategy.
Printing. Windows clients take it for granted,
and many enterprises simply provide dedicated printing services for non-Windows
printers. With a good interoperability plan, however, Windows-hosted printers
can be made accessible to non-Windows clients. You’ll reduce printer costs
and make administration more efficient, too.
Terminal Services. A growing requirement in many companies is the
need for users to access Windows Terminal Services. We’re all familiar
with Microsoft’s Remote Desktop Clients, available for all Windows-based
platforms. How can you accommodate non-Windows users?
Another important interoperability area is intranet services, specifically
Web browsing on intranet Web servers. Fortunately, that’s an easy problem
to solve: Internet Explorer is available for several Unix variants, as
well as for Mac clients. Other browser products, including Netscape Navigator
and Opera, provide even better cross-platform Web browsing. The variety
of platforms supported by these Internet Explorer (IE) alternatives allows
companies to provide fully functional, late-generation browsers for every
imaginable client operating system.
| Workgroup
Interoperability |
| While most administrators will concern themselves primarily with providing access to resources and services located on a Windows-based server, you may also have a need to provide interoperability between Windows and non-Windows clients in a workgroup. That’s a tougher situation, since many of the best interoperability products—such as Microsoft’s own Services for Unix and Services for Macintosh—aren’t available on Windows clients.
All isn’t lost, though. Mac OS X, for example, is a
near-perfect Windows workgroup citizen. OS X 1.2 and
higher provides a complete Windows file-sharing server
and client, allowing Windows and Mac clients to share
files at will. Mac users can use workgroup-hosted printers,
too, provided they’re PostScript printers and a PostScript
Printer Definition (PPD) file for the printer is available
for the Mac. Microsoft Office is available for the Mac,
as well, offering a great file-format solution. Older
Mac clients can take advantage of DAVE from Thursby
Software, www.thursby.com.
DAVE gives OS 9 and earlier many of the same features
that make OS X a good workgroup client. DAVE can even
allow Mac OS X clients to share USB inkjet printers
with Windows-based clients, providing an inexpensive
workgroup printing solution.
Unix clients in a workgroup can take advantage of a
number of Samba packages, which add Windows-style file
sharing (via Server Message Blocks or SMB) to Unix.
Samba has a pretty big open-source following, so you
can get some great packages for free. Check out www.samba.org
for more details. From a printing standpoint, both Windows
and Unix can use standard TCP/IP printing protocols,
such as LPD/LPR, to print to most network-attached printers.
For example, almost any printer connected to an HP JetDirect
device will be accessible to Windows- and Unix-based
clients in a workgroup. Samba also provides Windows-style
printing services, albeit with a few limitations. Samba
has become so important, in fact, that there are some
great books available on the subject, including Special
Edition Using Samba (Que Publishing).
—Don Jones |
|
|
Lingering Problems
Of course, all the interoperability solutions in the world can’t give
you the broad set of features available when Windows servers talk to Windows
clients. Advanced functionality, like Group Policy, just isn’t possible
on anything but Win2K or Windows Server 2003—and you won’t find features
like Offline Files or Windows 2003’s Shadow Copy on anything but a Windows-powered
PC. You’ll also find that the interoperability features that do exist
aren’t always perfect. Unix Kerberos clients, for example, can’t usually
take advantage of AD site boundaries or complex inter-forest trusts (as
I discuss shortly). And, while sharing Windows-hosted printers with non-Windows
clients is certainly possible, you may not always be able to find printer
drivers for those non-Windows clients, rendering the entire issue moot.
Still, the majority of basic network services are available cross-platform,
so it’s possible to create an environment that gives your non-Windows
clients everything they really need.
Interoperability doesn’t have to be as hard as it sounds, and you don’t
have to go on a mission to convert the non-Windows “heretics” in your
organization. Non-Windows desktops offer a rich variety of features, so
it makes sense to take advantage of those features when you can. The good
news is that you can still integrate those non-Windows clients into your
Windows-based network, successfully creating a melting pot of client operating
systems.