Mac OS X Server's Print and File Services for Mixed Networks
Volume Number: 21 (2005)
Issue Number: 1
Column Tag: Programming
Mac OS X Server's Print and File Services for Mixed Networks
by Mark Underwood
Providing Essential Services in the "Mixed" IT World
X Server was designed from its first iteration to supplant the need for multiple servers, each providing
vertical access protocols. Buy a windows server to support Windows boxes, a Mac server for Mac boxes, ad
nauseum. Hey, this is a Mac-based Server, right? So as the X clients can talk the multiplatform talk, X
server should be able to walk the walk with ease, right? That it does. Not only does X Server speak AFP-ease
(Classic Mac), SMB-ese (Windows) and NFS-ease (UNIX), but it can over all of the networking protocols X server
handles without hyper configuration! In this article, we'll give the detailed instructions for those support
staffers who want to set up and customize print and file services for Mac OS X Server.
No way is this article intended to teach you how to set up and configure a MacOS X Server efficiently,
effectively, and with the least amount of wear and tear to your geekdom. In fact, we assume you already have
an X server in that state of mind and are just wanting to configure the file and print services properly to
work in an existing mixed network. We also aren't going to fidget with the internals of setting up a WinNT
PDC or an Active Directory server hierarchy - again, we assume you have one of those already that you're
either trying to replace with an X server, or make sure the X server works with it.
In general, when you set up an X server, the good news is that you don't have to know everything up front -
all of the services cane be added/changed/reconfigured at will. But you will have to get a couple of things
right the first time in order to avoid a nasty quandary later -- the domain name this server is working on and
if this server will be the primary or secondary directory server. If you're adding the X server as the first
server in your LAN, congrats! You can provide the best for all worlds without too much hassle. If you're
migrating a Windows server to an X server, double-kudos! It's an easy migration, and we'll step you through
the basics for the file and print services in this article. If you're adding an X server into an existing
domain already controlled by a Windows-based server and only want the Mac Server to provide services to Macs,
shame on you! It's worth the extra set-up to replace the Windows server to act as everything and so help to
secure your LAN better.
X SERVER RE-CONFIGURATION - GENERAL FILE SERVICES
Either sitting at the X server, or from a X client with the Server Admin Tools installed, start up the
Server Admin program, which is located by default in a folder called "Server" inside "Applications". If this
is your first time opening this program, you'll need to click on "Add Server" and give the Rendezvous or IP
address of the server, along with one of the administrator-level accounts on the server and its password. In
a few moments, the current status of the server and a quick overview of its status will be listed on the left
pane. Click the triangle in front of that name downward and you'll get the complete list of services, and
their current state (green - go, yellow - recoverable problem, red - ouch, clear - service not active).
We'll start with the Mac-side file services - which works for both pre-X and X Mac clients. This protocols
is known as AppleShare File Protocol, or AFP for short. Click once on the indented item named AFP in the
list, then on the Settings tab at the bottom, and you'll get this dialog:
Figure 1: X Server - AFP General Settings
Here we enable Rendezvous and AppleTalk browsing to make sure the server shows up under the "Browse" button
in the "Connect to Server" dialog (for MacOS X) or under the list of servers in the same AppleTalk zone of
Chooser (For Pre-X or Classic mode). Add a greeting that will be shown to the user once connected, and check
the last box to only show it to them the first time they log in...not subsequent times.
Clicking on the Access tab here shows the next set of changes/settings to review:
Figure 2 - X Server - AFP Access Settings
This group of settings have to do with how people log in to the server. Enable Guest access lets that
button be shown on the Chooser for Pre-X/Classic access, or a "Guest" account to be used under X. Enable
secure connections is used with Kerberos or the standard basic encryption technique for AFP under
Pre-X/Classic. We'll talk more about Kerberos later, but there's no problem with having this option checked
whether you use that approach or not. Enable administrator to masquerade... gives the System Administrator
account to "pretend" it's a normal user ID as needed for diagnostics and checking access rights. Set the
maximum number of connections (both normal and guest) to what you want the server to handle, then walk on to
the Idle Users tab.
Figure 3 - X Server - AFP Idle Users
While the defaults (which you see above) are pretty much okay, if you have people who leave their Macs
running all the time you may want to have them disconnected when idle. This is the place to set that. You
can also set a message that explains why they've been disconnected.
If you've changed any of these, you'll have the "Save" button active in the lower right. Click on that and
your changes are put into place right away. If the service isn't running, the Stop Service icon in the top
pane will be a green Start Service one. Click that and you're done with AFP.
Configuring for UNIX file service clients is very easy. Click on the NFS service in the list on the left,
and then the Settings tab at the bottom. Here's the dialog:
Figure 4 - X Server - NFS
Defaults here are pretty much what you'll stick with, since underneath X is UNIX. But if you're a stickler
for the protocols used on your network, or if you want to optimize the number of simultaneous UNIX clients,
here's where to change and save the settings.
X SERVER RE-CONFIGURATION - WINDOWS SERVICES
As you might guess, configuring the Windows file sharing is the most difficult of the client triumvirate.
It involves a two-stage process: setting up Windows-type authentication (so that the Windows machines can log
in) and settings up the Windows file sharing protocols (so that they show up at all in the Network
Authentication for Macs and UNIX boxes is straight forward - if the user ID is in the list of users on the
X server (whether in a directory or in the list of local users), you get in. Windows isn't that easy. We
must create a directory and services that the Windows clients can understand and use. All Windows clients can
use the "basic" Client for Microsoft Networks access, which is WINS-based or NT Services (depending on the
client). Newer clients can also use a domain controller (NT-based servers) or Active Directory (2000 and
later servers) to authenticate and encrypt the sessions. In addition, 2000 and XP can use an LDAP-based
authentication, but that has to be added via 3rd party extensions.
We're going to examine the three possible X server directory service configurations and indicate which
context they're used, so you can select which one fits your bill. First is the Open Directory Master, as
shown in Figure 5.
Figure 5 - X Server - Open Directory General Settings
Click on your Open Directory service in the left list, then on the Settings tab. The "Role" menu has four
options: Standalone Server, Connected to a Directory System, Open Directory Replica, or Open Directory
Master. If you took the defaults when you set up your X server, you may see "Standalone Server" here. We
will have to change that to one of the others, of course...but which one? Here's how to decide:
Connected to a Directory System means there's already another directory service in your LAN, and you want
the X Server to use that one without replicating the directory on the server. That directory can be an
NT-server, Active Directory Server, LDAP server, etc. Setting the server up to do this is done not in Server
Admin, but with the normal Directory Access program, and must be done on the server itself - not from a remote
location. While this sounds like what you may want if you have such a server in place, doing this would also
force the Macs and UNIX clients to authenticate to the existing server...and would eliminate all of your Pre-X
clients and some of the UNIX clients, as there are restrictions on this approach. If you feel you fall into
this category, we recommend that you leave this server as an Open Directory, and change the Windows server
settings instead - we cover those later in the article.
Open Directory Replica means you have a master X server someplace that you want this X server to bow to and
get orders from. A directory replica is a way of divvying up the directory services load when you have more
than a few hundred folks using it. Since in this example, we're trying to get the first step done, we don't
use this setting now. However, once we get the first X server's configuration in place, the rest of the X
servers that you add can be "chained" to it using this setting and providing the right information. This
setting would also be the one to use if your existing authentication directory was UNIX or LDAP based.
Open Directory Master is the best setting for doing the deed, because it provides something for everyone.
It works as a standalone directory server, it works as the boss for replications, it allows the window
directory services to be part of its "domain", and it handles the Kerberos mastery when needed. Pick this one
and you can't go too far wrong. Skip the replicas section, dodge the Kerberos record for now, and move over
to the Protocols tab.
Figure 6 - X Server - Open Directory Protocol Settings
Under the Open Directory service is the OpenLDAP protocol. LDAP (Lightweight Directory Access Protocol)
needs a few pieces of information to help its schemas and search results: the search base, the number of
returned results, and how long before giving up on a search. The latter two can stay at their default
values...but the search base controls the default scope of the stuff returned. If it's like in our example -
dc=local - leave it alone and go on to the Authentication tab. If it isn't, then you may have entered
incorrect information when you installed X server...and unfortunately, changing it is rather iffy to do (short
of a few unsupported command hacks apple didn't recommend but would work) without reinstalling. If you didn't
get dc=local, or find that the field can't be edited, send me an email, and I'll be glad to pass along the
non-reinstall way (along with a heavy-duty dose of caveat emptor).
Figure 7 - X Server - Open Directory Authentication
Notice that all of these settings are blank? These are the exceptions to how authentication is handled for
odd circumstances, and doing nothing in these cases is the default approach. All of the options are pretty
much self-explanatory, so I won't go deeply into them here. One we will touch base on is the password matrix
to enforce stringent types of them. Pick your established practice of them (monthly, needs at least a number
or two in it, etc.) and match anything you already have in the existing window directory, if you use one.
Save your changes and let's move now to the Windows service settings that have to change.
Click on the Windows service at the bottom of the left list and then on the Settings tab at the bottom.
The General sub-tab here picks the way the Windows-world will see this X server as a server, and again the
"Role" menu gets tricky. Only three choices here, but they're really important with respect to an existing
Windows/Mixed network or directory schema, so we'll go into a lot of depth here. The three choices are
Standalone Server, Domain Member, or Primary Domain Controller.
A Standalone Server is the role for an X server if it is replacing an existing Windows file/print server,
or if you never had a server to begin with and have a mixed client network.
A Domain Member server role is for this server if its not the main Windows file/print server controller -
like the "replica" from the Open Directory settings.
The Primary Domain Controller (PDC) is only if you have an NT-server that you're replacing, that uses the
old style of domains - pre-Active Directory days.
How to decide? What do you have now?
If you have no Windows-based file/print servers, then standalone.
If you have NT-based file/print servers, then PDC for the main X server and domain member for secondary
domain controller roles.
If you have Active Directory, you are back to the Open Directory settings - see above.
Here are how those three dialogs look, and what to put in the fields.
Figure 8 - X Server Windows service - Standalone
In all three, the "description", "computer name", and "workgroup" are what you would use if configuring a
Windows server. "Name" and "Description" show up by the icon for the server when browsing for them, and
"workgroup" is the critical value used to stick the server in with the other associated machines. This is not
the Windows domain! That is used by Active Directory, and would be constructed there. This is the good ole
Windows workgroup those folks are familiar with seeing in the Network Neighborhood.
Figure 9 - X Server Windows service - Domain Member
Figure 10 - X Server Windows service - PDC
So with this tab, it's just the type that is important. Now we move to the Access tab.
Figure 11 - X Server Windows service - Access
Very critical setting here: Allow guest access. Turn it on. This isn't what you think it is, although
you get that as a side-effect of turning it on. You see, the broadcast of what file and print servers are
"seen" when you open the Network Neighborhood under Windows is dictated by if that server has guest access or
not. If not, then you don't see them browsing. You have to connect to them by name or IP address directly -
something normal Windows users may not know right off the bat. They are used to browsing for services (sounds
like a game show - with Art James or Monty Hall, perhaps), so give it to them. If their PC has a "Guest"
account, then its also needed to let users of that account even log in to the X server. But it's not creating
an account called "guest" for the server itself - just the file and print services from the windows clients
only. There. Keep it clean and as secure as possible.
Moving on to the advanced tab...
Figure 12 - X Server Windows service - Advanced
Okay, what we want here depends on that type of server again. If you chose standalone or domain member,
check the Workgroup Master Browser. If PDC, check both Workgroup and Domain. If Active Directory is the way,
WINS is the really old access method. If you support 95 and 98 clients, have no domain or directory
servers, and run really old 16-bit Windows programs, you may need this enabled. If you have a really, really
old NT-type set up that has already a WINS server enabled on it, and you want this X server to use it, then
you register the server with that old clunker here. Skip the virtual share point concept for now...that's
another article for another day. Save settings and now we go to print.
X SERVER RE-CONFIGURATION - PRINT SERVICES
<Whew!> After that mess, print's a walk in the park! First off, you define the printer to the
server as you would on X client through the Printer Setup Utility in the Utilities folder. Yes, you can share
USB/Firewire printers through X server. Yes, anything it can see, you can share to anyone else - Windows,
Macs, UNIX, etc. In fact, once you have defined the printers in Printer Setup, they will automatically appear
under the Server Admin Print service. Click on that line on the left, the Settings tab at the bottom, and
then the Queues at the top, and you should see all of the currently defined printers that the server knows
Figure 13 - X Server Print service - Queue Settings
To examine the server-related settings for the automatically-generated print queue, select the name and
then click on the "/" button under the list ("+" adds a queue, "-" removes one). You'll get the guts of the
Figure 14 - X Server Print service - Print Queue Settings
Here we go. The "sharing name" is what you want folks to "see" as the name of the print queue. Remember
that some characters don't map too well on Windows and UNIX boxes, so use underscores and hyphens instead of
spaces. Also, really old Windows clients can't handle more than eight character names too well.
Check all of the supported protocols - it doesn't hurt. AppleTalk is for the Pre-X crowd and shows up in
the Chooser, LPR is for UNIX and raw MacOS X through Rendezvous, SMB is for Windows. Technically, any client
can handle printing through LPR, which is via direct IP...but you get better results to use the local parley for
each as needed. Check off the quota option if you need to restrict the use or quantity of printing - but
those details are then passed to the Workgroup Manager to allow associating it with users, groups, or specific
machines, and yes, that's again for another day. Click Save, and the printer is ready to go!
Now that the server's happy, what do we have to do on the client end?
CONFIGURING MAC OS X TO USE THE SERVICES
With the server ready to go, let's turn our attentions to the Mac. Everything will be automatically
handled under X (it's an X server folks...) - but where do we find these services?
File services are done through the "Connect to Server" menu under the Finder's Go menu, and the print
services are accessed and added through the Printer Setup utility - no brainers, right? But since you're in a
mixed world, when you go to mount an X server volume, you may now see more things than were originally
there...or more than what you expected.
Since X can handle all three flavors of file/print services (Mac, Windows, UNIX), when you do a general
Browse via the Connect to Server, you will see all three ways to connect. The other two clients will see only
what they're supposed to see. Will that throw you or your end users? If so, you can turn off the other two
ways on the X client...or use those extra methods to your advantage. Let's see what I'm talking about by trying
it from a Mac:
Figure 15 - X Client - Browsing the Network
If you click on the Network icon on the Finder's toolbar...or to the Browse button under Connect to Server,
you'll see this sort of window. And the three top folders are the three ways to access the services. An IP
address shows straight IP servers (UNIX and such - using NFS). The "KAUi" folder is the Windows workgroup we
put the server in (Windows using SMB). And the "Local" folder is the AppleTalk/Rendezvous set of services
(Macs both old and new using AFP). Punch into a folder, see the machines/services it contains. Let's switch
to a column view to show this hierarchy:
Figure 16 - X Client - Accessing via SMB
Here we go down the Windows path...KAUi is the workgroup, Osiris the server (see all the other windows boxes
here? All of them have "guest" enabled...) and we click on the Connect button to provide the list of shared
server mount points that will then be available.
Let's wander back down the AFP path...
Figure 17 - X Client - Accessing via AFP
We go through the AppleTalk zone named Local to the server named Osiris (note the case is sensitive
now...that's a dead giveaway), and get a straight Kerberos prompt to mount it, since we turned that on in our
choice of Open Directory server authentication. So right here, we see a reason why you need both ways to go
from a X client. If you have a person needing to use services that doesn't have an account, then SMB guest
access will provide a secure, non-intrusive approach. Permissions to the guest access control what that user
CONFIGURING WINDOWS TO USE THE SERVICES
Meanwhile on the other side of the client, what did all of this configuring and such buy us? Well, it
looks even simpler from a Windows user's perspective - another feather in your decision-making cap! Here's
the basic Network Neighborhood:
Figure 18 - Windows client - Network Browsing
Ah! Sacrilege! A Windows Figure in a MacTech Magazine?!? No, just conclusive proof that X server does
the trick...see the icon for Osiris? That's a Mac X Server! It even says it from the description we put in to
the server settings! They'll flinch but be in awe when they double-click on that icon and see...
Figure 19 - Windows client - X Server Browsing
WOW! Is that the proverbial duck I hear quacking? Look! All of the X server-based mount points show up
as mountable folders...and there's the shared printer queue! This is spiffy...and we didn't have to do any wicked
tweaks or buy 3rd party software to do it! Hey, may we can add an X server shared printer that easy...
Figure 20 - Windows client - Adding a X server-base printer
No way! Too easy! How did this happen? Did the Boys From Redmond invade Cupertino when Steve wasn't
looking? Tsk, tsk, tsk. You, the Mac Faithful, should have known better. If it works, it's a Mac, right?
And you Switchers - both IT staffers and end users - did you think they were going to forget that "mixed" is
just that? Negatory!
Here we see how the whole concept of a "mixer" changes...with the advent of consistent document formats in
all of the major apps for the last three years, the next step of making the clients and servers really see and
interact each other normally was icing on the cake - but a very tasty one indeed, and well worth the UNIX
revision that was X.
As you might guess, once this is in place, other side-effects come in, such as straight point-to-point file
transfers, cross-platform co-authoring, and more. I won't even begin to talk here about the system
administrator benefits, such as adding Macs to the Active Directory pool as if they were PCs, or performing
full user/group administration to even an all-PC shop from a single X server to avoid all of the security and
hack issues in Windows-based servers. No, I shall leave those for a future article or as a joyous exercise
for the IT migration student.
by Mark Underwood