One of the most remarkable features that Microsoft included with Windows NT Server is the capability to act as a fully functional file server for Macintosh clients. Services for Macintosh, which provides this functionality, turns Windows NT into not only a fully-compliant AppleShare file server that can support an unlimited number of Macintosh clients, but also a Macintosh print server and a native AppleTalk router.
This chapter examines the pieces that compose the Services for Macintosh, as well as the tools that are used to administer them. I've included some concepts of how to plan and implement your NT network to include Macintosh clients, and provided essential information for NT administrators new to the Macintosh world. I've also tried to make it useful for people coming from a Macintosh world who are new to NT Server by presenting the chapter in a capsulized format.
Windows NT Server enables Macintosh and PC users to access the same files, which provides a true cross-platform, collaborative environment. When running Services for Macintosh, DOS and Windows users connect to the server as they normally would. They see no evidence that they might be sharing files with Macintosh users. Additionally, Macintosh clients see and connect to the NT Server in the exact same way they would connect to any other standard AppleShare server.
To create an enterprise-level solution for Macintosh clients, Microsoft leveraged many of the features integral to NT's architecture when designing Services for Macintosh. NT Server provides exceptional compatibility, performance, scalability, fault-tolerance, and security. For instance, part of the Macintosh file server portion, known as the AppleTalk Filing Protocol (AFP) server, runs inside the NT Executive, which provides significant speed benefits. Also, because the AFP server is multithreaded, it can fully leverage NT's capability to run on multiprocessor hardware. You can also take advantage of the software RAID options in Windows NT to provide increased performance and reliability. Furthermore, Services for Macintosh fully integrates with the NT security model to provide the same level of high security available to all Windows NT clients.
NOTE: The AppleTalk Filing Protocol (AFP) is a protocol that resides in the presentation layer of the ISO's OSI Reference Model. It is responsible for handling the logistics of accessing files and directories on a remote computer system.
There is no hard-coded limit as to the number of simultaneous Macintosh clients that can connect. To demonstrate the extensibility of Windows NT Server as a Macintosh file server, Microsoft has conducted real-world testing where they created over 1,000 simultaneous Macintosh connections to a single NT Server.
TIP: Because of the scalability of NT Server, it provides the most powerful Macintosh file and print services on the market—even better than any system Apple currently sells. In fact, a recent alliance between Microsoft and Apple should bear fruit in the near future, and there is a good likelihood that Apple will sell NT Server-based solutions under their own label.
In addition to acting as a standard file server, Windows NT can also act as an AppleTalk print server. This leverages three important pieces of Windows NT's print architecture. First, Windows NT permits Macintosh clients to print to any printers available on the NT Server. It even allows the Macintosh clients to print to non-PostScript printers by providing a PostScript interpreter that generates a bitmapped image that can be sent to any non-PostScript printer. Second, Services for Macintosh leverages NT's capability to print to a number of remote network printers, including network printers using DLC, TCP/IP, and AppleTalk. Third, it exploits NT's capability to print to almost 2,000 different models of printers.
To complement the file and print services, NT also includes a full AppleTalk router. This provides you with the ability to natively participate in an AppleTalk inter-network. The router can be configured to route AppleTalk between any standard network card supported by Windows NT, including Ethernet, FDDI, Token Ring, and even LocalTalk.
NOTE: Windows NT supports the Daystar Digital LocalTalk adapter.
You can also use the AppleTalk router to create new AppleTalk zones on local subnets, through a process known as seeding, which provides logical organization of the AppleTalk network.
There are mostly two types of people who will read this chapter:
I have written this chapter to be as useful as possible to both audiences. No matter which category you fit into, or even if you don't fit into one of these two categories, you'll probably find a discussion of the differences between the two platforms useful.
NOTE: A little terminology review is definitely in order. Traditionally in the MS-DOS and Windows environment, files were stored in directories and subdirectories. Macintosh nomenclature has always referred to folders and subfolders, which are functionally identical. With the introduction of the Windows 95 interface, Microsoft has begun using the terms folders and subfolders to replace the traditional directories and subdirectories. In this chapter and elsewhere in this book, I use the terms interchangeably.
It would be impossible to cover all the concepts of Macintosh networking in this single chapter, but there are a few important concepts that should be understood about before continuing. This section will be especially useful for a person with minimal Macintosh background to hit the ground running with Services for Macintosh.
If you're new to the Macintosh arena, you'll quickly recognize that Apple is very big on using the word Talk in naming its communications products and technologies. Of course, since networks are used to communicate, Talk is an appropriate word. However, keeping all these terms in order and using them to describe the appropriate technologies and products can often take a little practice, so let's do a quick review:
NOTE: Macintosh computers traditionally use the printer port as the designated LocalTalk port, although newer Macintosh computer, and newer versions of the Mac OS actually permit you to use either the printer port or the modem port.
When Apple first designed AppleTalk, there were a number of limitations, which as networks grew, began to cause problems. This original release of AppleTalk, is now known as AppleTalk Phase 1. In 1989, Apple redesigned the AppleTalk protocols to support larger and more complicated networks. The new version of AppleTalk is known as AppleTalk Phase 2.
NOTE: Windows NT Server only supports AppleTalk Phase 2.
The original version of AppleTalk only permitted 254 nodes on an entire physical network, because nodes were addressed using a single 8-bit node ID. However, with the revamped AppleTalk Phase 2, you could now address over 16 million network nodes on a network. Each node is addressed using an 8-bit node ID, and a 16-bit network address.
With extended addressing you can use multiple network addresses on a single network cable. This means if you could have 500 clients on a single network segment, using two or more network addresses. This extended addressing is supported under EtherTalk, TokenTalk, and FDDITalk. It is not supported, however, under LocalTalk. This means that you can still only have a single network number per LocalTalk cable segment, limiting the number of clients to 254 per segment.
There were many other changes to the AppleTalk protocol with the introduction of AppleTalk Phase 2. These changes include modifications to the way AppleTalk devices acquire their dynamic node IDs when they start up, changes in the AppleTalk routing scheme to reduce network traffic, and the inclusion of directed broadcasting, which uses multicast addresses to prevent non-AppleTalk clients from being impacted by AppleTalk broadcast packets.
The most significant changes for many people was the incorporation of networking standards, such as the IEEE 802.3 and 802.5 standards for Ethernet and Token Ring, respectively.
The AppleTalk protocol suite defines a number of other protocols that operate at different levels of the OSI Reference Model. The more important of these protocols are listed in Table 10.1.
Table 10.1. AppleTalk Protocols matched with the OSI Reference Model.
| Protocol | OSI Level | Description |
|---|---|---|
| RTMP | Transport Layer | Routing Table Maintenance Protocol. The RTMP is responsible for maintaining a list of all the routers on the AppleTalk network, as well as providing the rules for how routers exchange routing information. Each entry in the routing table consists of a network range, a distance in hops to the remote router, a port number on the remote network, the AppleTalk node ID of the next router on the path to the destination network, the status of each port on the network. This is similar in functionality to the RIP protocol in the TCP/IP protocol suite. |
| AEP | Transport Layer | AppleTalk Echo Protocol. The AEP provide a protocol similar to ICMP in the TCP/IP suite. It supports sending an echo datagram from the requestor to the echo port on a destination computer, which then responds with a echo response datagram. This can be useful for detecting if a particular host is reachable. |
| ATP | Transport Layer | AppleTalk Transaction Protocol. The ATP is used to set up a transaction-based conversation between two computers. Although ATP does guarantee delivery of packets, it does not guarantee they are received in any particular order. When one machine sends an ATP request datagram, it waits for the second machine to respond with a ATP response datagram before it can proceed. When all the data has been sent between the two machines, a ATP release datagram is sent to indicate the transaction session is complete. The ATP is not intended for transporting large amounts of information, nor for establishing sessions that need to be kept open for long periods of time. |
| NBP | Transport Layer | Name Binding Protocol. The NBP is important to the working of the AppleTalk protocol suite. The network itself sends packets by using a numeric address to identify network entities. However, AppleTalk itself uses names internally to locate resources. The NBP is responsible for resolving the AppleTalk names into the node ID that is required for locating the machine on the network. AppleTalk stores names internally in the format name:type@zone, where name is the AppleTalk name of the resource, type is the resource type, such as LaserWriter, and zone is the name of the AppleTalk zone where the resource resides. An example of a complete AppleTalk name is Jason's Macintosh:AFPServer@Home. |
| ADSP | Session Layer | AppleTalk Data Stream Protocol. ADSP is similar to the ATP in that it provides guaranteed delivery of network packets. However, unlike the ATP, which is intended for small and quick data exchanges, the ADSP is intended for transmitting larger amounts of data, and for supporting long sessions. While the ATP does not guarantee the order in which packets are received, the ADSP ensures that packets are received in the order they were sent. Another advantage of the ADSP protocol is that it supports full duplex communications, meaning that both network entities can speak to each other at the same time. The ADSP protocol also supports flow control, which ensures that one of the network entities is not bombarded by more network traffic than it can handle. |
| ASP | Session Layer | AppleTalk Session Protocol. The ASP provides session-level communications between a client and a workstation for sending command streams. While ATP and ADSP are used to send raw data, the ASP is used initiating a session control mechanism between a client and the server. Also, in ATP and ADSP, the two network entities are connected in a peer-type relationship, whereas the ASP clearly defines a client, which must initiate a session, and the server. With ASP commands can be sent from the client to the server, but the server is not permitted to send commands to the client. The only thing the server can send to the client is data requested by the client, and an alert packet to notify the client of a problem. |
| PAP | Session Layer | Printer Access Protocol. The PAP is used for communicating with AppleTalk print devices. It is responsible for opening a session with a PAP server (printer), transferring the print job to the printer, performing flow control to prevent the client from sending too much data too fast to the printer, and reporting printer status back to the client. The PAP actually uses ATP datagrams for communicating on the network. |
| ZIP | Session Layer | Zone Information Protocol. The ZIP is responsible for creating and maintaining the Zone Information Table (ZIT), which is stored in each AppleTalk router. The ZIT is a map that is used to link the friendly zone names back to the unique network numbers that are used to actually locate what subnets a zone actually resides on. The Zone Information Protocol is responsible for working with the RTMP protocol to keep the ZIT up-to-date. |
| AFP | Presentation Layer | AppleTalk Filing Protocol. The AFP is the high-level protocol that is used for sharing files from one computer with other machines on the network. AFPs primary focus is on providing a mechanism to control user access to folders, as well as how these permissions are displayed to the user. AFP is also designed to deal with naming inconsistencies between different operating systems and file systems, which support different allowable naming schemes. AFP relies on the ASP protocol for handling the logistical portion of setting up connections between the client and server. |
Services for Macintosh supports all of these protocol and like the Mac OS itself, addresses each of them in different pieces of software. RTMP, AEP, ATP, NBP, ADSP, ASP, and ZIP are all addressed in the AppleTalk protocol loaded in Windows NT, along with related drivers that are loaded with the AppleTalk protocol. The PAP protocol is address in the Print Server for Macintosh service, and support for the AFP protocol is located in the File Server for Macintosh service, and related kernel-mode driver.
Macintosh files are different than PC files. Most computers use file structures in which all the file's data is stored as a single stream of information. This is the way MS-DOS, Windows and Windows NT works. Additionally, there is no set method of identifying what program created the file or what indicating what kind of data is contained in the file. The only standardized method of identifying a file's type is by using the filename extension, which is not always reliable.
NOTE: Microsoft is beginning to use OLE objects within files. This provides even more flexibility than multiforked files, because the OLE objects can be defined and included only as necessary. Future OLE-based file systems could potentially support Macintosh files by storing each fork in a separate OLE container.
NOTE: When discussing files, the terms fork and stream are used interchangeably to indicate discrete containers within the file. Fork is the term in common use in the Macintosh lexicon, while stream is the term used by Microsoft to describe the identical ability in the NTFS file system.
In contrast to this single fork approach, the Macintosh uses two file forks—the data fork and the resource fork. The data fork is directly analogous to a standard PC file. However, the Macintosh computers also have a resource fork. This is where special information about the file is stored. A resource fork can contain icons, bitmaps, fonts, small blocks of code, menus, window definitions and other things.
NOTE: Not every Macintosh file contains both forks. Some might contain only a data fork, others might contain only a resource fork, and others might contain both.
Additionally, Macintosh files attach supplementary file properties not included on standard PC files. Of particular importance is the creator and type information. These are both four-digit codes that allow the Macintosh operating system and other applications to identify the program that created the file as well as the nature of the data contained in the file.
NOTE: Apple maintains a registry of creator types for Macintosh files. If a new software vendor wants to make a Macintosh version of their program that creates files, they must register a unique creator type with Apple. This ensures that no two vendors use the same identifier codes, which could cause the wrong application to launch when a user tries to open a file. Microsoft's registered creator code is MSFT.
Because NTFS offers native support for multiple data streams in a single file, it has no problem supporting Macintosh resource and data forks. This is in comparison to NetWare 3.1x, which tries to provide Macintosh file support by splitting the data and resource forks into two separate files. The problem with this approach is that a look-up table is used to provide mappings between the resource forks and data forks of all the files on the Novell partition. If this look-up table fails, all the Macintosh files on the partition would be destroyed. An additional advantage of providing native support for multiple file forks is that if a non-Macintosh user deletes a Macintosh file, both forks will be deleted, which is not guaranteed under a system using a non-native lookup table..
Macintosh files support filenames of up to 31 characters. Additionally, Macintosh filenames permit characters, such as the backslash (\) that are forbidden in standard DOS-style 8.3 names. Furthermore, the Macintosh OS permits virtually unlimited nesting of folders within folders, whereas there is an effective limitation of 255-character path names in Windows NT (and Windows 95). This means that the full name of the file, which includes its entire path, cannot exceed 255 characters. This limitation is actually created by the Win32 API calls that are used to handle file references. In fact, NTFS will allow Macintosh users to nest folder within folders to their hearts' content. The problem is that if you try to use the Explorer or File Manager to look at or manipulate those files, you will get an error. To make matters worse, because most backup programs rely on the Win32 API to access files, you will not be able to backup any file that has a full path name of greater than 255 characters.
Because NTFS supports 255-character filenames, and Macintosh users can only use 31 characters, it is important to realize how the filename translation works.
If the Macintosh user views a file or directory whose name is 31 characters or shorter, the Macintosh user will see the full NTFS long file name. If the name is longer than 31 characters, however, the user will see the short 8.3 name that is created automatically for all NTFS files and directories.
NOTE: If a Macintosh client opens a file using its 8.3 filename and then saves the file, the long filename will be preserved, even though the Macintosh user cannot see it. This is done through a technique called tunneling. However, some applications copy the file you open to a temporary file and make all your changes to the temporary file. When you save it, the original file is deleted, and the temporary file is renamed as the original file. In this case, if the file was opened with the 8.3 filename, the long filename will not be preserved.
WARNING: :If you copy a Macintosh file containing a resource fork to a FAT partition, the resource fork will not be copied, and thus the copy will be effectively useless.
Macintosh folder permissions on Services for Macintosh are based on NTFS file and directory permissions. Under AppleShare, access restrictions can only be made on a folder-by-folder basis.
You can use the MacFile menu in the File Manager to set permissions on a particular folder on a Macintosh-accessible volume.
NOTE: You must use the File Manager interface or the MACFILE command-line tool to set permissions on Macintosh-accessible volumes. There is no Explorer interface for performing this action.
NOTE: If you try to set permissions on a folder that is not part of a Macintosh-accessible volume, you will get an error message.
The way that Macintosh computers assign permissions to folders is dictated by the AFP protocol. It permits the security permissions for a folder to include permissions for an owner, a primary group, and everyone else. These permissions are set with the File Manager as shown in Figure 10.1.
The File Manager provides an interface for setting permissions on a Macintosh volume.
TIP: You can also log on from a Macintosh workstation to modify permissions.
Notice that for each of the three access control entries (ACEs)—Owner, Primary Group, and Everyone—AFP only permits three levels of permissions: see files, see folders, and make changes. When you make apply these AFP permissions to a folder shared as a Macintosh volume, NT converts the AFP permissions into NTFS permissions and applies them to the selected folder as well as all files within the folder.
CAUTION: When you change the AppleShare permissions on a folder, it has a direct effect on the NTFS permissions for the folder and for any files within the folder.
Let's look at some of what happens when you choose different options and how this affects the NTFS permissions and attributes.
First of all, when you set the Macintosh permissions for a folder, NT will add the Owner, the Primary Group, and the Everyone group to the NTFS permissions for the folder, as well as all the files contained in the folder. The way that NT translates the Macintosh permissions into NT permissions is shown in Table 10.3.
Table 10.3. Translation of Macintosh permissions into NTFS permissions.
| See Files | See Folders | Make Changes | NTFS Permissions |
|---|---|---|---|
| X | RX | ||
| X | RX | ||
| X | WD | ||
| X | X | RX | |
| X | X | RWXD | |
| X | X | RWXD | |
| X | X | X | RWXD |
NOTE: You'll notice that many of the different Macintosh permissions translate into equivalent NTFS permissions, so you'll be unable to identify the exact Macintosh permissions by looking at the NTFS permissions.
In addition to the permissions listed in Table 10.1, the owner also gets the (P) and the (O) permissions on all of the preceding combinations. If the owner has all three permissions, the owner will be assigned the NTFS Full Control permission. This is not so with the primary group, or the Everyone group.
Remember, the NTFS permissions are as follows:
You'll also notice that the see files and see folders options actually appear to have the same effect on the NTFS permissions. Although it is not reflected in the visible permissions, NT honors these two flags for Macintosh clients. When a Macintosh user does not have the see files permission, a little file icon with a slash through it appears in the upper-left corner of the window. Likewise, if the user does not have permissions to see folders, the icon will be a small folder with slash through it. The icon that indicates a user does not have the see folders permission is shown in Figure 10.2.
The little icon of the folder with a line through it indicates that the user does not have permission to see folders.
Here are some things to be aware of when working with these permissions:
When you remove Macintosh permissions, place-saving entries are retained in the NTFS access control list (ACL).
When a Macintosh user connects to an AppleShare file server, there are normally two methods of logging in:
To illustrate this point, Figure 10.4 shows the Macintosh user validation screen.
Macintosh users can log on as a Guest, or as a registered user.
When the user logs on to an NT Server running Services for Macintosh as a registered user, they can use a standard Windows NT user account and password, much as would be expected. This is very straightforward.
The problem, however, is when the user tries to logon as a Macintosh guest. I often run into people that don't quite understand how this works, and they often encounter problems because of it.
There are two basic things to remember, and everything else will fall into place:
NOTE: The pseudo-group Everyone is unrelated to the NT Guest user account. The reason I call it a pseudo-group is that you cannot directly control membership in this group the same way as other groups. The actual membership of the Everyone group could be simply defined as every non-disabled user account in this domain and all trusted domains.
So what does this mean? Well, it means that you can disable the NT Guest user account and Macintosh guests can still connect. Many people don't believe this until they've tried it, so feel free to go ahead and try it. Now that we've gotten over that, let's move on and figure out how the Macintosh guest access really works.
First of all, if you absolutely don't want guest access from Macintosh users, you can disable it by going to the MacFile Control Panel, choosing Attributes and then deselecting the Allow Guests to Connect option. This will prevent all Macintosh guest access, no ifs, ands, or buts.
However, you might want to rethink this strategy. There is a reason Macintosh guest access is there, and there is a reason it is enabled by default. When you install Services for Macintosh, NT creates a read-only, Macintosh-accessible volume called Microsoft UAM Volume and enables guest access. By default, when Macintosh users connect to NT Servers, their passwords are sent in clear-text over the network, which creates a security problem. However, the Microsoft UAM allows Macintosh clients to connect to the NT Server using encrypted passwords.
The catch-22 is that the users must be able to logon to the server to download the UAM. So the theory goes that they should connect to the server as a guest, which doesn't require a password and download the UAM. Because the volume is marked as read-only, it cannot be tampered with. Additionally, rather than disabling Macintosh guest access globally, and preventing people from downloading the UAM, you can restrict Macintosh guest access on a volume-by-volume basis—and leave it enabled Microsoft UAM Volume.
So where does that leave us? Well, we now know how to restrict Macintosh guest users from accessing an NT Server running Services for Macintosh. Once they've been allowed to connect to the server, access to particular files and folders is dictated by the permissions set for Everyone at each folder level.
If you remove permissions for Everyone from a particular folder, a Macintosh guest will not be able to access files in that folder.
NOTE: The Everyone group that shows up when you set the AppleShare file permissions is exactly the same as the NT Everyone group that shows up when you set NTFS permissions.
This section is for the techie folks who really want to understand what's going on. We've identified in this chapter that Macintosh guest users do not in fact use any standard NT user accounts. If this is true, how can we explain the fact that NT requires all system events and processes to be auditable to a single user? Well, the answer is that when a Macintosh guest logs on, he or she is logged on as a special ANONYMOUS LOGON account that is built into Windows NT.
We can see this account by enabling auditing of user logons. Figure 10.5 shows the audit event that gets registered in the Security Log when a Macintosh guest logs on.
A Macintosh guest generates logon events as the user NT AUTHORITY\ANONYMOUS LOGON.
Well, at least we know how the user logs on. Just remember, the NT AUTHORITY\ANONYMOUS LOGON is built-in to NT and cannot be disabled. However, the rights of the ANONYMOUS LOGON is based on the privileges assigned to the Everyone group for a particular resource.
Enabling Macintosh support for Windows NT Server is exceptionally simple. In fact, it is just as straightforward as installing almost any other service. There are essentially five steps:
When you install Services for Macintosh on your system, there are a number of changes that take effect. These include the following:
NOTE: After installing Services for Macintosh, the AppleTalk Protocol will not be listed in the list of installed protocols in the Network Control Panel.
NOTE: In order to install Services for Macintosh, you must have at least one NTFS volume.
To install Services for Macintosh you should be logged on as a member of the Administrators group and follow these steps:
Select Services for Macintosh from the Select Network Services window to install Macintosh client and printer support.
When you have highlighted Services for Macintosh, click OK.
Once you have installed Services for Macintosh, it will appear in the list of Network Services in the Network Control Panel.
The Microsoft AppleTalk Protocol Properties window is used to configure the AppleTalk protocol necessary to support Macintosh clients.
This window is used to configure the AppleTalk protocol options.
NOTE: AppleTalk zones are similar to NT workgroups, except that zones also contain routing information and workgroups do not.
For information on configuring NT Server as an AppleTalk router, see the section, Configuring Windows NT Server as an AppleTalk Router, later in this chapter.
NOTE: When the system restarts, all printers created on the NT Server will become available to Macintosh clients.
You can configure Services for Macintosh by three different methods. The most common is to use the MacFile Control Panel, as we will do here. However, you can also use the Server Manager or the MACFILE command-line utility to perform the same functions.
To configure Services for Macintosh using the MacFile Control Panel, follow these steps:
The MacFile icon in the Control Panel is used to configure the Services for Macintosh options.
The MacFile Properties window displays file usage and information on logged on users.
From the MacFile Attributes window, you can configure global options for Macintosh services on your NT Server.
The options for the MacFile Attributes window are as follows:
NT supports the capability to send logon messages to Macintosh clients.
By default, no logon message is sent to Macintosh clients.
WARNING: :Even if you have the Require Microsoft Authentication option checked, users can still log on as guests, provided the Macintosh guest access is not disabled. This permits users to connect to the Microsoft UAM Volume and download the MS UAM. Because the guest access does not require sending a password, there is no security problem with this configuration.
NOTE: In Windows NT Advanced Server 3.1, there was a physical limit of 255 simultaneous Macintosh connections that was due to the design of the Services for Macintosh. However, with NT Server 3.5, Microsoft removed that limit. In fact, Microsoft has actually done internal testing of NT Server 3.51 with 1,000 simultaneous Macintosh clients without a problem.
TIP: Two other methods of configuring the Macintosh Services options are using the Server Manager and using the MACFILE command-line utility. Additionally, both of these methods enable you to configure Services for Macintosh on remote machines.
You can configure AppleTalk routing either during the Services for Macintosh installation process or at a later time. To configure the options at a later time, make sure you are logged on as a member of the Administrators group and start at step 1. If you want to configure AppleTalk routing during the Services for Macintosh installation process, start at step 4.
The options on the Routing page can be used to configure NT Server as an AppleTalk router.
If you click the Get Zones button, NT asks you if you want to replace the zone list you entered manually with a list it acquires from existing AppleTalk routers.
Figure 10.15 shows sample configuration information for AppleTalk routing.
These configuration settings indicate that the NT Server will act as an AppleTalk router and seed the local network segment with network values 10 through 12. Additionally, zones SALES and PROCUREMENT are on the local network segment.
If you're not intimately familiar with AppleTalk routing, it might be hard to determine when you need to use it and how best to configure it. There are two basic configurations where AppleTalk routing might be useful to you:
In both cases, you can use the NT Server as a seed router, depending on the existence of other AppleTalk routers on the network.
NOTE: You need to have a seed router for each zone that you want to appear on a subnet.
Let's address these scenarios separately.
Let's say that you are working on a large, private network, with 1,000 Macintosh clients spread around the network. You have five major zones: Sales, Procurement, Tech Support, Administration, and General. You have a new suite of 20-30 Macintosh computers served by an NT Server running Services for Macintosh that you need to connect into the existing network backbone.
Of course one option would be to connect the computers directly to the network backbone, as shown in Figure 10.16.
Connecting a series of Macintosh clients served by an NT Server directly to the network backbone.
In this case, the Macintosh clients in the group of computers we just added can communicate with the NT Server, as can any Macintosh clients on the rest of the network. Additionally, the newly added clients can become part of any of the zones available on the backbone.
As far as the NT Server goes, you don't need to enable AppleTalk routing because there is no need for actual routing, nor do you need to seed a new zone.
While this might seem nice and simple, there are two problems. First the minor one. You might not want the clients on the newly added network to be able to join any of the zones on the network. For instance, if the people in the newly added group of computers only need to be part of the Procurement and Sales zones, you might want to be able to restrict them to these zones. In this example, there are only five zones, so this might seem unnecessary. However, it is not uncommon for larger enterprises to have dozens and even hundreds of zones, where being able to restrict groups of computers to certain zones could be a necessity.
The second reason that the network architecture in Figure 10.17 is not adequate is that the users on the newly added computers will share all network bandwidth with the rest of the users on the network. This single-segment approach can have a negative impact on network performance.
To help alleviate both of these problems, you can use the NT Server as an AppleTalk router, as shown in Figure 10.17.
In this scenario, the NT Server is used as an AppleTalk router between the local subnet and the rest of the network.
To make this scenario work you need the following:
Let's say you will use the network range 36-38, since it's not being used elsewhere on the network.
To configure NT properly for this scenario, you would use the following steps:
NOTE: Make sure you enter the AppleTalk zone names exactly the same as they appear elsewhere on the network. Be especially careful to include exact spacing, punctuation and case.
Because you entered the Sales zone first, it appears as the default zone. This means that all Macintosh clients will appear in this zone automatically, unless you manually configure them to use a different zone.
Figure 10.18 shows the configuration options discussed in the preceding steps.
Services for Macintosh is now configured for AppleTalk routing.
When the computer comes back up, it will be configured properly to support the routing scenario depicted in Figure 10.17.
The second common scenario is to use the AppleTalk routing capabilities to create AppleTalk zones on the network. My experience is that this is what the vast majority of people using NT Server's Services for Macintosh use AppleTalk routing for.
Remember, in the Microsoft world, there are workgroups and domains that provide logical grouping of computers. These logical groupings make locating a resource on the network easier.
In the Macintosh world, you can use an AppleTalk router to create zones, which are used to logically group machines and resources on the network. In a smaller network, full-fledged routing is often not necessary, but it is still often useful to create zones for organization of resources. Windows NT Server enables you to do this.
Let's use an example. Let's say that you have a small network that has 45 Macintosh computers and a couple of networked AppleTalk printers. You want to logically group our network into five zones: Development, Production, Advertising, General, and Printers.
You can use the AppleTalk routing capabilities of NT Server to do this. While it won't make your network any faster, it does help you to organize a little better.
To configure NT properly for this scenario, you would use the following steps:
These options will create five zones on the AppleTalk network.
When the server comes back up, it will create the five zones specified earlier in the example. Now you'll be able to see the zones on your Macintosh clients, and you'll be able to move them into the appropriate zones.
In the AppleShare world, network volumes are the resources that are made available on an AFP file server for network users to connect to. They are logically the same as network shares, share points, or mount points in the Windows networking world. The process for creating a Macintosh-accessible volume with NT Server is similar to that of creating a standard network share that would be accessed by Windows networking clients.
NOTE: There is one major difference between Macintosh volumes and standard Windows share, which you should be careful of. With Windows shares, you can create shares within shares. Let's take a look at an example. If you had a file structure that looked like the one shown in Figure 10.20, you could create a share-point for the Divisions folder. You could also create separate share-points for each of the folders in the Divisions folder, Accounting, Advertising, General, Procurement, and Sales. If a user attached to the Divisions share-point, he or she would be able to see the folders beneath that folder, given the correct permissions, of course. Likewise, if a user attached to the Accounting share-point, he our she could see the things below that level, but could not see anything else in the Divisions folder. This provides for a useful method of organization.
Sample Windows directory structure showing shares within shares.
NOTE: However, with Services for Macintosh, you cannot create Macintosh-accessible volumes within other Macintosh-accessible volumes. This would preclude you from setting up an environment like the one described above. You could either create a volume for each division, or you could create a single volume that contained all the divisions, but not both.
There are four tools you can use to create Macintosh-accessible volumes in Windows NT:
The easiest of these options is to use the Administrative Wizards, which we'll discuss in this section. We'll also look at using the File Manager for creating Macintosh volumes. The Server Manager interface for creating Macintosh volumes functions in almost the exact same manner as the File Manager interface. The syntax for using the MACFILE utility is listed at the end of this chapter.
NOTE: Microsoft did not include a method for creating Macintosh shares from the NT Explorer interface.
NOTE: NT Server automatically creates a Macintosh-accessible volume called Microsoft UAM Volume when you install Services for Macintosh. This volume is created on the first NTFS partition on your server.
One of the new features of Windows NT Server 4.0 is the inclusion of a set of administrative wizards that simplify common administrative functions. There are eight basic administrative wizards, on of which is called Managing File and Folder Access. This wizard permits you to specify files and folders on the local server or on a remote server that should be shared to the clients—including Macintosh clients—on the network.
To use the Administrative Wizards to create a Macintosh-accessible network volume, follow these steps:
NOTE: You must be logged on as a user with administrative privileges to create network shares.
The Administrative Wizards permit you to perform a variety of common administrative tasks.
You can use the Share Management Wizard to create network shares on the local computer, or on a remote NT system.
You need to specify which local drive contains the files and folders you want to make available to the network.
TIP: If you know the exact path of the folder you want to share, you can enter it in the field at the bottom of this screen, rather than browsing for it.
The Share Management Wizard permits you to specify the permissions on the folder you specified.
CAUTION: The Share Management Wizard is not a very robust tool and is probably best used by beginners who are just beginning to learn about Windows NT. However, if you are a more advanced user and commonly change permissions on files witholding subfolders, and want a fine level of granularity when specifying permissions, you should not use the Share Management Wizard.
You need to specify a name for the network share, as well as what kind of clients should be able to connect to it.
NOTE: Each shared volume on an NT Server must have a unique name. If you enter a name that is the same as an existing share name, NT will advise you that the name is already in use and ask you to choose a new name for the share.
NOTE: If the Macintosh Users option is grayed out—indicating that you cannot share the folder with Macintosh users—then you either selected a folder located on a FAT partition, or you don't have Services for Macintosh installed on your NT Server.
The share should now be available for users on the network. You can change Macintosh permissions for the file using the File Manager, or the MACFILE command-line utility.
To create a Macintosh-accessible volume using the File Manager, follow these procedures:
NOTE: The easiest way to get into the File Manger in NT 4.0 is to click the Start menu, choose Run and then type winfile and hit return.
Select the directory you want to make accessible to Macintosh clients.
The Create Macintosh-Accessible Volume window enables you to specify options for the new volume.
From here, you must specify the following:
NOTE: Services for Macintosh allows you to create Macintosh-accessible volumes on a CD-ROM.
Guest access from Macintosh clients has nothing to do with the NT Guest account. For more information on Macintosh guest access, see the section Understanding Macintosh Guest Logons, earlier in this chapter.
The sum of the number of users of all the Macintosh-accessible volumes cannot exceed the Macintosh user limit in the MacFile Control Panel.
You can use NT to specify the Macintosh permissions exactly as you would on a standard AppleShare server.
From here you can specify the permissions for the Owner, Primary Group, and Everyone. Additionally, you can change the Owner and Primary Group.
For more information on setting Macintosh permissions, see Working with Macintosh Permissions, earlier in this chapter.
WARNING: :It is very important to realize that Services for Macintosh does not distinguish between share permissions and file folder permissions. Standard Windows NT shares have their own permissions, which are different from the permissions set on the files and directories contained within. However, the volume permissions for a Macintosh, are exactly the same as the folder where the volume begins. This means that if you change the permissions when you create a Macintosh volume, the NTFS permissions will directly and immediately reflect the change.
Macintosh users should now be able to access the share.
You can use the MacFile option in the File Manger to view and modify the settings for Macintosh-Accessible volumes.
Any changes you make to the volume, including setting or clearing the read-only flag, will take effect immediately. However, if you remove guest access for the volume by clearing the Guests Can Use this Volume option, it will not affect any users currently logged on as guests. This is because this option is only checked at logon.
You can remove Macintosh-Accessible volumes, by using the Remove Volumes option under the MacFile menu in the File Manager.
If there are any Macintosh users accessing the share, you will be warned that removing the share could result in the connected users loosing data, as shown in Figure 10.29.
You will be warned if you try to remove a Macintosh-accessible volume with active users.
You can wait until the users have logged out, or you can click Yes to proceed and remove the volume anyway.
When a Macintosh client connects to an AppleShare file server, it uses a user authentication module (UAM) to handle the authentication of the user by exchanging user name and password with the server. Macintosh computers running System 7.x (or System 6.0.7 and above, running AppleShare 2.1 or greater) have a built-in Apple authentication module. When communicating with other Macintosh computers running System 7.x, or with Apple's AppleShare servers, this allows the user's password to be encrypted before being sent over the network.
However, because of the way Windows NT stores passwords, it cannot take advantage of the Apple encryption method, called Apple Random Number Exchange. This means that when a Macintosh client wants to connect to an NT Server running Services for Macintosh, it sends the password in plain text over the network. Passing the password in clear text over the network results in a situation where anyone on the network could see the password as it goes between the network client and the server, thus sacrificing the security of the user's account.
Additionally, Apple's built-in UAM only supports passwords of up to 8 characters, while NT Server supports passwords of up to 14 characters. If a user has a password longer than 8 characters, he or she will not be able to login to the NT Server from a Macintosh client using Apple's standard authentication module.
Thus, there are two occasions where you would want to install the Microsoft UAM:
To help rectify the security problem, Microsoft created the Microsoft User Authentication Module (MS UAM). This module must be installed on each client that wants to use it. It interfaces with the Chooser, and provides for encrypted user verifications using Microsoft's Challenge Authentication Protocol (MS-CHAP). In addition, it supports up to 14-character passwords.
When you install Services for Macintosh on an NT Server, it automatically creates a directory called Microsoft UAM Volume on the first available NTFS partition. It then shares this directory as a read-only Macintosh volume and grants guest access. Macintosh clients can then connect to this share to obtain the MS UAM and install it on their system.
NOTE: The reason the Microsoft UAM Volume is created with guest access enabled is so that Macintosh users do not need to sacrifice their passwords in order to obtain the UAM!
The MS UAM might seem like a great thing, and worthwhile to rush off and install it on all your systems. However, before you do this, let's take a look at the downside.
In the README.UAM file that is installed with Services for Macintosh, Microsoft writes, "Microsoft encourages you to install Microsoft Authentication (MS UAM) only if you need increased security on your Windows NT computer."
The reason for the caveat is that installing the Microsoft User Authentication Module adversely affects two major functions on Macintosh computers:
NOTE: For those not well versed in Macintosh terminology, file aliases are very similar to Shortcuts in the Windows 95-style interface.
When Macintosh users connect to AppleShare file servers, they have the option of designating that certain shares should be reconnected automatically at startup, as shown in Figure 10.30.
Macintosh users can designate certain network volumes to be reconnected at startup.
This is similar to the persistent connections option on Windows systems.
However, because of problems internal to Apple's system software, the Macintosh cannot use alternative UAMs to reconnect at startup. This means that either one of a couple of things will happen, depending on the server's configuration:
The second problem with the MS UAM has to do with the way it interferes with reconnecting to file aliases located on network resources. Very often Macintosh users will create aliases to files or folders on remote file servers. If a user double-clicks an alias and is not currently connected to the file server where the file is located, the Macintosh tries to connect to the server. This is considered a great feature by many Macintosh network users. However, the problem is that the alias will always try to connect using the standard Apple UAM. The results are the same as listed previously when users automatically connect at startup.
However, there is one slight saving grace. Once the user is attached to a network volume, the aliases will work. This is because the user authentication process is only dealt with when you first connect to the resource. While this doesn't provide a solution for connecting to systems at startup, it does mean that your users can use the MS UAM to attach to a Macintosh-accessible volume on the NT Server, and then use their aliases.
This leaves the system administrator, you and me, in a very unenviable position. It means that we can either forfeit the security provided by the MS UAM, or you can cripple the functionality of your users' systems. The correct solution to this problem must be handled on a site-by-site basis. If you choose to require the MS UAM, I encourage you to not turn it into a PC versus Macintosh argument.
NOTE: I want to make one thing clear. This problem is mostly because of defects in the Macintosh OS. All custom UAMs, including the NetWare UAM provided by Novell, have this same problem. Hopefully Apple will resolve this problem by adding full support for custom authentication modules sometime in the near future. As for the question of why can Macintosh clients use encrypted authentication with other Macintosh computers, including Apple's AppleShare servers, it is because Apple uses a different encryption method that requires the clear text password to be available at both ends. NT Servers do not store user passwords in a form that can be decrypted.
Installing the Microsoft UAM on Macintosh clients is straightforward. If you are going to require users to use the MS UAM, you need to install it on all Macintosh clients.
NOTE: Don't be too concerned about the size of the MS UAM. It's only about 30KB.
To install the MS UAM on a Macintosh client, use the following procedure:
If you require Microsoft authentication and have disabled guest access, you will get an error.
You can copy the Microsoft UAM from the Microsoft UAM Volume, which is created on the NT Server when you install Services for Macintosh.
NOTE: Be sure not to put a check mark in the box of the right side of the entry. If you check this box, the Microsoft UAM Volume will automatically appear on your desktop the next time you restart the Macintosh.
If you have a logon message configured, it will appear now. Click OK to continue.
The Microsoft UAM Volume should now appear on the desktop.
The AppleShare Folder contains the MS UAM file needed to provide secure logons.
CAUTION: By default, there is no folder called AppleShare Folder inside the System Folder. However, if you have other UAMs installed, such as the NetWare UAM, the AppleShare Folder will exist and you will receive an message asking if you want to replace the AppleShare Folder. Do not do this. Simply open the AppleShare Folder on the NT Server and copy the MS UAM file inside into the existing AppleShare Folder on the Macintosh client.
Using the Microsoft User Authentication Module on the Macintosh is just as easy as installing it. Here's an example of connecting to an NT Server using the MS UAM:
After you install Services for Macintosh, you can create an NT printer that sends jobs to any printer on an AppleTalk network. This is quite a neat feature because even if you don't have Macintosh computers on your network, you might still have a printer that takes advantage of AppleTalk networking. If this is the case, you can use NT to allow Windows and DOS clients to print to this printer exactly as they would any other printer on an NT Server.
To create a printer on the NT Server that sends jobs to a printer device on an AppleTalk network, use the following procedure:
NOTE: In order to print to a printer on using AppleTalk, you must have Services for Macintosh installed. See the section Installing and Configuring Services for Macintosh earlier in this chapter for more information.
The Add Printer Wizard is used to create or connect to an NT printer.
NOTE: It might not seem obvious to choose the My Computer option, because you are in fact connecting to a computer on the network, so let's take a quick look at this. You can choose the Network Print Server option only when the printer has been created on another NT or Windows for Workgroups system, or on a Novell system if you have the Client or Gateway Services for Novell installed. For stand-alone network printers that you print to using AppleTalk, DLC, or TCP/IP, you must create the printer on your system. This is why you choose the My Computer option.
Choose the AppleTalk Printing Devices option.
NOTE: If the AppleTalk Printing Devices option does not appear in the list of available print monitors, then you have not installed Services for Macintosh. See the section Installing and Configuring Services for Macintosh earlier in this chapter for more information on installing Services for Macintosh.
The Available AppleTalk Printing Devices window is used for browsing the network to locate an AppleTalk printer.
When you expand the AppleTalk zone, all AppleTalk printers in the zone will be displayed.
NOTE: An AppleTalk name must be unique in its zone. However, you can have the same name used in multiple zones without problems, since AppleTalk resources are identified and located by both their name, and their zone.
NOTE: You cannot use NT to change the actual name of an AppleTalk printer. If the printer is an Apple printer, you can use the LaserWriter Utility program that came with the printer to rename it.
You can capture an AppleTalk print device, which prevents people from printing directly to it.
TIP: For security reasons, you should capture the AppleTalk printers. The first security issue is that people if you permit people to print directly to the printer, you have no method of auditing and tracking printer usage. The second, more critical problem is that if you don't capture the printer, someone else could capture the printer and deny everyone else access to it. Even in a smaller network where this might be easy to troubleshoot, this denial of service could result in lost productivity and angry users.
The AppleTalk printer you specified will appear in the list of available ports.
You must specify the make and model of the printer.
NOTE: It is important that you choose the correct make and model for the printer so that NT knows exactly what features the printer includes and how to work with it. Choosing the wrong printer can often cause unpredictable results.
Give the printer a name and specify if you want it to be the default printer when printing jobs from the server console.
Give the printer a share name and choose the additional operating system drivers to install on the server.
The Printer Properties page is used to change various settings once the printer has been created.
You should take the opportunity to enter any comments about the printer, as well as the location. If you want to change scheduling, sharing, security, or device settings you can do it now, or later as necessary. For more information on these options, refer to chapter 8, Configuring and Installing Print Services.
Click OK when you are finished configuring the printer.
The printer you just created and shared on the network is capable of receiving print jobs from any Windows NT client. This means that standard Windows clients, other NT clients, Macintosh clients, Novell clients (with File and Print Services for NetWare) and UNIX clients (using LPD and TCP/IP) can all print to this printer through the NT Server. The strength in this feature is that the clients don't need to have AppleTalk installed; only the server must have AppleTalk installed.
One of the truly remarkable aspects of NT Server is how seamlessly the Services for Macintosh are integrated with the rest of the system. Perhaps this is seen best in how easy it is for Macintosh Clients to print to printers through an NT Server.
When you install Services for Macintosh, NT automatically makes all printers on the NT system available to Macintosh clients. This means there is nothing that needs to be done for your Macintosh users to begin printing. All printers created on the NT Server will appear in the same zone as the NT Server.
NOTE: It is extremely important when you create printers on NT Server that you choose the correct printer type. NT knows from the printer type exactly what features are supported by the printer. With Macintosh clients, it is important to know which printers have PostScript and which don't. For example with HP printers, all printers with an M in the model name have PostScript. The M is HP's standard designation that lets you know the printer is made to work with Macintosh computers. (It also means the printer has a built-in LocalTalk interface.) If you have an HP LaserJet 4M Plus, you should be certain to select this when configuring the printer. If you choose HP LaserJet 4 Plus instead, NT will think the printer does not support PostScript and will rasterize the PostScript and send the bitmapped image to the printer, resulting in reduced print quality.
From a Macintosh client, you use the Chooser to select a printer on an NT Server exactly the same way you would to any other AppleTalk network printer.
NOTE: The PostScript interpreter built into Windows NT Server emulates an Apple LaserWriter Plus v38.0.
There are three major places you will need to go to for configuring Services for Macintosh:
Additionally, there are two other places that enable you to manipulate the Services for Macintosh options:
If you need to identify what Macintosh users are logged on, what volumes they are accessing, and what files they have open, you should use the MacFile Control Panel.
NOTE: When Macintosh users connect through Services for Macintosh, they will not appear under the list of active users in the Server Control Panel. The Server Control Panel only lists users who connect using the standard Microsoft networking.
The MacFile Control Panel, shown in Figure 10.44, provides four different sets of information that enables you, as the system administrator, to find out who is access in what files through Services for Macintosh.
The MacFile Control Panel enables you to get information about what Macintosh users are connected to the NT Server.
This screen gives you a summary of connections provided by Service for Macintosh. Included are the number of connected users, the number of open files, and the number of file locks. File locks typically occur when files are opened with write access.
The other connection-related information that can be obtained from the MacFile Control Panel is as follows:
You can find out to what volumes a particular user is connected.
The top box includes a list of all the current Macintosh users, their computer name, how many files they have open, and how long they've been connected. When you click a user, the bottom window will show the volumes that user is connected, the number of open files the user has on that volume, and how long the user has been connected to that file.
While you have a user selected in the top window, you can select the Disconnect button at the bottom of the screen. If the user has no open files, you will be asked if you want to disconnect the user. Click Yes if you really want to disconnect the selected user. This will disconnect the user from all Macintosh volumes.
However, if the selected user has files open, NT will warn you that the user has open files and could loose data if you disconnect the user. It then asks you to confirm that you really want to disconnect the user. Click Yes to disconnect the user. This will disconnect the user from all Macintosh volumes.
If you want to disconnect all users, you can use the Disconnect All button.
You can find out what users are connected to a particular volume.
The top window shows all the Macintosh-accessible volumes on the local server. It also includes the number of open files on each volume and the actual path where the share is located.
TIP: If the path for a particular volume does not fit in the window, as with the Microsoft UAM Volume in the Figure 10.34, you can double-click the volume name and NT will display a window containing the full path to the volume.
When you click a volume from the top window, the bottom window displays all the users attached to that volume, including how long the user has been connected and whether or not the share is in use. The definition of "in use" in this case refers to whether or not the user has file locks in that volume.
If you click a user and click the Disconnect button, NT will ask you to confirm the request. If you click Yes, the user will be disconnected from the selected volume only. If you click the Disconnect All button, all users on that volume will be disconnected. This will have no effect on user connections to other volumes.
You can find get a list of all files that are currently in use by Macintosh clients.
NOTE: More often than not, you will not be able to read the full path of the files listed in this window. If you want to know the full path to a file, you can double-click the file name and NT will display a window containing its full path.
You can use this screen to close a user's access to particular files. This can be done by clicking on a file fork you want to close and then clicking on the Close Fork button. NT will ask you to confirm this action. If you click Yes, the user will be disconnected from the particular file.
However, if you click the Close All Forks button, all files open by Macintosh users on this server will be closed.
Windows NT's Services for Macintosh supports the capability to send alert messages to Macintosh users. This requires a Macintosh client running AppleShare 2.1 or above (built-in to System 7.x), and requires that the client be logged into the server. This differs from standard Microsoft clients, which aren't required to be logged into a server to receive alerts.
NOTE: The NET SEND command and the Server Control Panel applet cannot be used to send messages to Macintosh users. So, if you have Services for Macintosh installed, be sure to send any important server alerts to your Macintosh clients as well.
Alerts can be sent from the MacFile Control Panel. From the MacFile Control Panel applet, simply choose the Users button. This brings up a window that displays all the currently connected Macintosh users, as shown in Figure 10.48.
You can send messages to Macintosh users from the Users button in the MacFile Control Panel.
Simply select the user you want to send a message to and click the Send Message button.
TIP: If you want to send a message to more than one user, you can hold down the control key while selecting additional users.
This will bring up a window where you can enter the message, as shown in Figure 10.49.
You can send messages to the selected users or to all users.
From here, you can also choose to send the message to all the users on the Macintosh local computer. You can enter up to four lines of text. Once you have entered the message, click OK and it will be immediately sent to the selected users.
NOTE: While the current AppleShare client for Macintosh supports sending messages from the server to connected clients, there is no provision for sending messages to clients who are not connected, or from client to server, or from client to client.
As described earlier in this chapter, creator and type information is very important for Macintosh files. This information allows the Macintosh Finder to know what application to launch when a user double-clicks it. It is also used to filter what a user sees when he or she tries to open a file.
Windows NT comes with a set of default mappings, as well as an extensive list of common Macintosh creator and file types.
To view the current mappings, or to set and create new ones, you'll need to use the Associate option from the MacFile menu in the File Manager. The Associate window is shown in Figure 10.50.
The Associate window is used to set DOS extension to Macintosh creator and file type mappings.
The pick list at the top of the screen contains approximately 60 of the most common MS-DOS file extensions.
The scroll list at the bottom of the screen contains almost 70 common Macintosh creator and file types. For instance, you can scroll down and see the Microsoft Word 6.0 documents have creator MSWD and type W6BN. If you want to add new creator and file types, use the Add button. Likewise, you can select an existing entry and use the Delete button to remove it.
Let's take a look at how this works. From the list of MS-DOS extensions, choose BAT. You'll see that files with the BAT extension will be mapped to LMAN/DEXE and are LMAN Executables, as shown in Figure 10.51.
MS-DOS files with the BAT extension are mapped to Macintosh file type LMAN/DEXE.
Now if we wanted to change that, we could simply choose a different creator/type combination from the list and click the Associate button. For instance, if we wanted Macintosh users to be able to double-click MS-DOS batch files and open them in a text editor, we could select the LMAN/TEXT option from the top of the creator/type list and click the Associate button, as shown in Figure 10.52.
Now Macintosh clients will automatically open MS-DOS batch files with a text editor.
Now, from a Macintosh client, all files with the BAT extension will be recognized as text files and can be opened in any program the recognized text files.
So why is it important to establish these associations? Well, normally the Macintosh stores and maintains these all by itself. However, if the file originates on a PC, it does not contain the creator/type information. The Macintosh then does not know what to do with the file. For instance, let's say that you used the Windows version of Microsoft Word 6.0 to create a file and saved it to an NT Server. Now if you went to a Macintosh and used Microsoft Word to look for the file on the NT Server, if the file associations were not created properly, the document would not even show up in the open list on the Macintosh. This is because the Macintosh can't find a valid creator/type for the file. However, with file associations, as long as you named the file with a DOC extension, the Macintosh version of Word would recognize it because NT Server would provide the creator/type information to the Macintosh.
Although you can't set up NT Workstation as an AppleTalk file and print server, you can use an NT Workstation to administer NT Servers running Services for Macintosh. In order to do this, you need to install the AppleTalk protocol on the NT Workstation. In addition to enabling you to use Server Manager to manage Services for Macintosh on NT Servers, there are two other benefits for installing AppleTalk on an NT Workstation:
To install the AppleTalk protocol stack and administer remote NT Servers running Services for Macintosh, follow these steps:
You must configure the AppleTalk zone where you want your NT Workstation to reside.
When the system restarts, the AppleTalk protocol will be fully installed and you will be able to use the Server Manager utility to manage NT Servers running Services for Macintosh.
Additionally, you can use the Add Printer Wizard or the Print Manager to create a local printer that can be used to print directly to an AppleTalk printer on the network.
NOTE: The MACFILE.EXE command-line utility will not be installed on the NT Workstation. If you want to use this utility to administer remote NT Servers running Services for Macintosh, you can copy the MACFILE.EXE executable from an NT Server with Services for Macintosh installed onto the NT Workstation.
When you install Services for Macintosh, you also get a command-line utility called MACFILE.EXE. This utility performs four major functions. While three of these can be done from a graphical front-end, with the MacFile Control Panel applet, or with the Server Manager, the fourth function, FORKIZE, can only be done through the MACFILE utility. Additionally, it's nice to have a command-line tool for appropriate tasks, such as writing batch files.
NOTE: Even if you're not interested in command-line utilities, look at the MACFILE FORKIZE. This command has no graphical equivalent, and deserves careful attention.
One of the additional benefits of the MACFILE command is that it enables you to configure remote NT Servers running Services for Macintosh.
The MACFILE utility is broken down into four basic commands:
The MACFILE VOLUME command enables you to add, remove, or change network-accessible Macintosh volumes.
The syntax for the MACFILE VOLUME command is
macfile volume /add [/server:\\computername] /name:volumename /path:directory[/readonly:[true | false]] [/guestsallowed:[true | false]] [/password:password] [/maxusers:number | unlimited]
macfile volume /remove [/server:\\computername] /name:volumename
macfile volume /set [/server:\\computername] /name:volumename /path:directory [/readonly:[true | false]] [/guestsallowed:[true | false]] [/password:password] [/maxusers:number | unlimited]
Parameters
/add—Specifies that you want to add a Macintosh-accessible volume.
/remove—Specifies that you want to remove a Macintosh-accessible volume.
/set—Specifies that you want to change options on an already existing Macintosh-accessible volume.
/server:\\computername—Specifies the name of the NT Server running Services for Macintosh that you wish to administer. If this switch is omitted, changes will be made to the local computer.
/name:volumename—Specifies the name of the Macintosh-accessible volume you wish to create, remove, of modify. This can be between 1 and 27 characters and should be enclosed in quotation marks if it contains any spaces or special characters.
/path:directory—Specifies the path to the directory to be shared on the AppleTalk network. Only include this when creating a new share.
/readonly:[true | false]—If true, users cannot make changes to any files located on the volume, regardless of additional rights given to them on particular folders within the volume. If false, user access to particular files is determined on a folder-by-folder basis. If this switch is not included when creating a volume, changes to the volume will be permitted (readonly=false).
/guestsallowed:[true | false]—If set to true, Macintosh users can connect to the volume as a guest. If false, users will not be able to connect to the volume as a guest. When creating a new volume, the default is for guests to be able to logon (guestsallowed=true). NOTE:This is independent of the Windows NT Guest user account. For more information on this, see the Understanding Macintosh Guest Logons section from earlier in this chapter.
/password:password—Specifies that users need to enter a password when connecting to this volume. If you don't use this switch, all access control is based on their user account and users will not be required to type an additional password when logging on. Using this option along with /guestsallowed:true, enables you to effectively create a resource with share-level permissions, instead of user-level permissions.
/maxusers:number | unlimited—By using this switch, you can restrict the number of users that can connect to a particular share. If you don't specify this switch when creating a volume, there is no limit placed on the number of users who can connect.
The MACFILE DIRECTORY command is used to set the owner, group, and permission information on a directory in a Macintosh-accessible volume.
The syntax for the MACFILE DIRECTORY command is
macfile directory [/server:\\computername] /path:directory [/owner:ownername] [/group:groupname] [/permissions:permissions]
Parameters
/server:\\computername—Specifies the name of the NT Server running Services for Macintosh that you wish to administer. If this switch is omitted, changes will be made to the local computer.
/path:directory—Specifies the path to the directory in a Macintosh-accessible volume where you want to modify permissions, owner, or group information. Remember, Macintosh file permissions are designated on a per-folder, not a per-file, basis.
/owner:ownername—Specifies the new owner of the folder. If you omit this switch, the ownership will not change.
/group:groupname—Specifies the new primary group for the folder. If you omit this switch, the primary group will not change.
/permissions:permissions—This switch indicated the permissions to be set on the specified folder. With this switch you can set standard Macintosh folder permissions, which include the ability to see file, see folders, and make changes. You can set each of these options for the owner, the primary group, and everyone (also called world). In addition, this switch can be used to designate that the folder cannot be renamed, moved, or deleted. You can specify that the changes should be applied to all subdirectories within the specified directory. This switch is used by specifying a 11-digit string of ones (1) and zeros (0). A one (1) is used to grant the permission, and a zero (0) is used to revoke the permission, following this pattern:
| Position | Permission |
|---|---|
| 1xxxxxxxxxx | Allows the Owner to see files |
| x1xxxxxxxxx | Allows the Owner to see folders |
| xx1xxxxxxxx | Allows the Owner to make changes |
| xxx1xxxxxxx | Allows the Primary Group to see files |
| xxxx1xxxxxx | Allows the Primary Group to see folders |
| xxxxx1xxxxx | Allows the Primary Group to make changes |
| xxxxxx1xxxx | Allows Everyone to see files |
| xxxxxxx1xxx | Allows Everyone to see folders |
| xxxxxxxx1xx | Allows Everyone to make changes |
| xxxxxxxxx1x | Specifies that the directory cannot be renamed, moved, or deleted |
| xxxxxxxxxx1 | Specifies that changes should be applied to the current directory and to all subdirectories. |
The MACFILE SERVER option enables you to change default server configurations, such as the server's name as it appears on the AppleTalk network, guest access permissions, and the maximum number of users.
macfile server [/server:\\computername] [/maxsessions:number | unlimited] [/loginmessage:message] [/guestsallowed:[true | false]]
Parameters
/server:\\computername—Specifies the name of the NT Server running Services for Macintosh that you wish to administer. If this switch is omitted, changes will be made to the local computer.
/maxsessions:number | unlimited—Specifies the maximum number of Macintosh users that can be simultaneously connected to the server.
/loginmessage:message—Specifies a message that will be sent to Macintosh clients when they connect to the NT Server. This is supported by all AppleShare 2.1 clients and greater (includes all System 7 clients). If left blank, no message is sent to clients when they connect.
/guestsallowed:[true | false]—Specifies whether or not Macintosh clients can connect as guests. If set to true, guests are able to connect to Macintosh-accessible volumes. However, you can restrict guest access to volumes on a volume-by-volume basis by using the MACFILE VOLUME command. Additionally, if this switch is set to false, all Macintosh guest access will be denied, regardless of the settings on individual volumes. By default, Macintosh computers can connect as guests.
NOTE: This is independent of the Windows NT Guest user account. For more information on this, see the Understanding Macintosh Guest Logons section from earlier in this chapter.
The MACFILE FORKIZE can be used to join two separate files together into the a single Macintosh file with a data fork and a resource fork. Additionally, it can be used to set the file's creator and type information.
NOTE: The true usefulness of this command is in its capability to set the file's creator and type information. While the capability to join to separate files together into a single Macintosh file is useful, most people will not need it.
macfile forkize [/server:\\computername] [/creator:creatorname] [/type:typename] [/datafork:filepath] [/resourcefork:filepath] /targetfile:filepath
Parameters
/server:\\computername—Specifies the name of the NT Server running Services for Macintosh that you wish to administer. If this switch is omitted, changes will be made to the local computer.
/creator:creatorname—This specifies the program that was used to create the file. When a Macintosh user double-clicks a file in the Finder, the creator information is used to determine what program to start. It can be up to four characters. Every company that writes software for the Macintosh is required to register their creator code with Apple to ensure its uniqueness.
/type:typename—This specifies exactly what the file is. This helps the program called by double-clicking the file to determine how to handle the file.
/datafork:filepath—Specifies the name of the file you want to use as the data fork.
/resourcefork:filepath—Specifies the name of the file you want to use as the resource fork.
/targetfile:filepath—If you are joining two files into a single Macintosh file, this specifies the name of the file you want to create by combining the resource and data forks. If you don't specify the /datafork and /resourcefork switches, this is the file whose information you are modifying. This file must reside on an NTFS volume on the server specified by the /server switch.
If you read through this chapter and the rest of the book, you will catch glimpses of where I point out the limitations of Services for Macintosh. I thought this was important enough for people to understand, however, so I created this section to bring them together in one place.
Some of these limitations are lack of features, and others are just things to be aware of. They are as follows:
This chapter discussed using Windows NT Server as a complete server solution for networks with Macintosh clients. We looked at the core Macintosh services provided by NT Server, including the ability to act as an AFP-compliant file server, as well as providing Macintosh print services, and native AppleTalk routing.
We looked at the structure of a Macintosh file and how it differs from a standard PC file. In addition, we looked at how NT Server provides on-the-fly translation of long file names for Macintosh clients. We continued by looking at the Macintosh AFP permission structure for restricting access to network resources, as well as the differences between a Macintosh guest user and a PC guest user.
The chapter continued with a step-by-step installation guide for Services for Macintosh, including a guide to setting up AppleTalk printing. We also took a look at how and when to set up AppleTalk routing by looking at two common network scenarios.
We also took a close look at the Microsoft User Authentication Module (MS UAM) and how it can be used to strengthen the security of your network. We also saw that the MS UAM has some pitfalls that prevent Macintosh users from performing certain functions.
Next we looked at tools that are used to administer the Services for Macintosh, such as the File Manager, the Administrative Wizard, the MacFile Control Panel applet, the Print Manager, and the MACFILE command-line utility. Included in this discussion was information on remotely administering Services for Macintosh from remote NT Server, as well as NT Workstations.
Finally, the chapter ended with a look at some of the limits of NT Server's Services for Macintosh. While NT provides a robust and powerful server platform for supporting Macintosh clients, it can't do everything and it is important to understand the limitations.
