Chapter 16 - How Services For Macintosh Works

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

The two main services for Services for Macintosh clients are File Server for Macintosh and Print Server for Macintosh. The file server enables Macintosh users to access files stored on the computer running Windows NT Server. The print server enables Macintosh users to print to any printer connected to the computer running Windows NT Server and to spool print jobs for AppleTalk printers such as the LaserWriter.

This chapter explains how these services work. It also explains how Macintosh users gain access to the computer running Windows NT Server and how security applies to Macintosh users. For instructions on how to administer and manage these services and the other tools added to Server Manager and Control Panel, see Chapter 21, "Working with Macintosh-Accessible Volumes."

How Files Are Shared

With SFM, both PC users and Macintosh users can easily share files stored on the server. Shared files appear as expected to PC users and to Macintosh users. For example, when an MS-DOS user views these shared files, the filenames follow the MS-DOS standard naming convention, whether or not they were created that way by a Macintosh user. When a Macintosh user views the files, they appear as Macintosh files, like files on the Macintosh client itself or on Macintosh servers running AppleShare.

How Shared Files Appear to Users

On a computer running SFM, files are stored in shared* *directories or in Macintosh volumes. For a file to be accessible to PC clients, it must be in a shared directory (or in a subdirectory of a shared directory). Each server can have one or more shared directories. Each shared directory on a server is assigned a unique share name, which is sometimes referred to simply as a share.

With SFM, Macintosh users cannot automatically gain access to all shares. To make a directory—and consequently its subdirectories (which may or may not be shared on the Windows NT system network)—available to Macintosh users, the administrator must designate the directory as a Macintosh-accessible volume.

Note Some PC users are familiar with the terms volume and volume labels as they relate to a hard disk partition. In this manual, however, a volume is either a directory designated as both a share and a Macintosh-accessible volume (meaning that both types of clients can gain access to the files in the volume) or a directory available only to Macintosh users on the network. There is one exception to this convention: when CD-ROM or Compact Disc Filing System (CDFS) volumes are mentioned.

Within a directory that is both a share and a Macintosh-accessible volume, networked PC users see directories and files. In fact, this is what is actually stored on the server's hard disk. To Macintosh users, the volume appears to contain Macintosh files and folders (the Macintosh equivalent of directories). When Macintosh users browse through the files available on the server, they see icons that represent each file and folder.

Macintosh files and folders can have Macintosh filenames, including long names and names containing spaces and other characters. They are not limited to the 8.3 naming convention of the file allocation table (FAT) file system used with the MS-DOS system and some OS/2 computers. The file server and the NTFS translate the names so that users can see them.

How SFM Stores Files

Understanding how Macintosh files work is helpful in understanding how SFM and Windows NT Server present files to both PC and Macintosh users.

Each Macintosh file has two parts, or forks: a data fork and a resource fork. The data fork contains the actual data of the file. The resource fork contains Macintosh operating system information about the file, such as code, menu, font, and icon definitions.

When a Macintosh file is shared on a computer running SFM, the two forks are saved in a single NTFS file.

How Filenames Are Translated

There are two types of filename translations to consider when running SFM:

• How Macintosh filenames are maintained and presented to various users 

• How the longer NTFS names (more than 32 characters) are presented to the Macintosh user

When a Macintosh user creates a file or a folder on the server and gives it a name, SFM checks it for illegal NTFS characters. If the filename contains illegal NTFS characters, File Server for Macintosh replaces the illegal characters. Otherwise, the original Macintosh name is the same as the NTFS name. Macintosh users see the name as it was created. Windows NT Server users will see the same name, with illegal characters—if any—replaced.

After the file server has replaced illegal NTFS characters, Windows NT Server takes over the file-translation process. Names that are too long for MS-DOS users are shortened to six characters, a tilde (~), and a unique number. Extensions are preserved. For more information about this process, refer to Appendix E, "How Filenames Are Translated," and to the Windows NT Server Concepts and Planning Guide.

 

For example, in a directory and volume called MACFILES, Windows NT Server and Macintosh users see a sample file as File Made by Macintosh. When MS-DOS users view the contents of the MACFILES directory, however, they see the short version of the filename: FILEMA~1. More examples follow:

• Files Made By Macintosh (Old) is translated to the following:

  FILEMA~2 

  This prevents duplicate filenames if FILEMA~1 has already been created.

• MARCHSALES.Sales Report.XLS is translated to the following: 

  MARCHS~1.XLS

  Notice that the extension (.XLS) has been retained. The last period in a name is recognized by NTFS as signaling the extension.

Windows NT users creating long NTFS filenames (up to 256 characters) should name files with 31 characters (the Macintosh limit) or fewer so that Macintosh users can readily decipher the filenames. If an NTFS name is longer than 31 characters, Macintosh users will also see the short name.

Here is a quick summary:

• A file created using the FAT file naming convention appears as created to NTFS users and Macintosh users alike. 

• A file created using the 31-character limit of the Macintosh system appears as created to NTFS users. MS-DOS users see a short name. 

• A file created using the NTFS 256-character limit appears as created to Macintosh users if it is 31 characters or less. Otherwise, it appears in the shortened form to both MS-DOS and Macintosh users.

Note Because MS-DOS users refer to files created by Macintosh users by the translated short names, you might want to instruct Macintosh users to give the FAT standard names (eight characters, and an optional period and three-character extension) to files and folders that will also be used by MS-DOS users. This prevents MS-DOS users from having to decipher short names.. (For files that only Macintosh users or Windows NT clients will use, Macintosh users can freely use long filenames and folder names.)

Configuring Macintosh-Accessible Volumes

With Windows NT Server, you can share directories on the server in any combination. For example, you can share a single directory twice with two different share names, and you can share a directory with one share name and then share a subdirectory of that directory with another share name.

However, different rules apply when you use SFM to configure Macintosh-accessible volumes. You cannot configure two directories in the same directory tree as volumes.

This means that you cannot do the following when configuring Macintosh-accessible volumes:

• Configure a single directory twice as two different volumes. 

• Configure a directory as a volume if it exists anywhere in the directory tree under another directory configured as a volume. 

• Configure a directory as a volume if one of its subdirectories, or any subdirectory of one of its subdirectories, is configured as a volume.

For example, consider the directory tree shown in the following illustration. If you configure the DATA1993 directory as a Macintosh-accessible volume, you cannot configure the JANUARY, FEBRUARY, or REPORTS directories as Macintosh-accessible volumes.

 

The only other directory that can be designated a volume is Data 1992. 

All Macintosh-accessible volumes must be on an NTFS partition or a CDFS volume. (The CDFS volumes are, by design, read-only.) The number of volumes visible to the user is determined by the length of the volume names, which must all fit in a buffer in order to be displayed. (The size of the buffer is determined by an underlying AppleTalk protocol.) Volume names can have a maximum of 27 characters. Try to strike a balance between clearly naming volumes so that users can identify them easily and keeping the names short so that all of the volume names can be displayed.

Note To determine the number of Macintosh-accessible volume names that can be displayed, use this formula:

N * (M+2) <=4624

where N is the number of volumes and M is the average length of the names in bytes.

Printing

With SFM, users gain three major printing benefits:

• Macintosh users can print PostScript jobs to non-PostScript printers directly connected to the computer running Windows NT Server. To the Macintosh user, these printers appear like the standard LaserWriter. 

• PC users can send print jobs to PostScript printers on the AppleTalk network. PC users can also check print jobs from their clients. 

• Macintosh and PC print jobs are spooled before they go to the printer. So, Macintosh and PC users can both send jobs to the printer and then continue working at their computers. This means that users don't have to wait for their jobs to print before using their computers to do other tasks or wait for a printer to be available. 

 

Capturing AppleTalk Printers

When you set up a printer on the AppleTalk network to be used with SFM, you can specify whether SFM will capture the printer—that is, prevent the printer from accepting print jobs from any source other than the print server. Capturing, in essence, gives Windows NT Server administrators complete control over the printer.

If a printer will be used exclusively by Windows NT Server, Microsoft recommends that you capture it. Doing so ensures that users don't accidentally bypass the print server and send print jobs directly to the printer or reset the printer, which might cause spooler problems. You'll also avoid "LaserPrep Wars." (For more information on avoiding LaserPrep Wars, see the next section.)

Note that if a source other than the print server prints jobs on the printer, you should not capture the printer. For example, you would not capture printers if you were using Apple LaserShare™ (which provides spooled printing for Macintosh clients) or if you were using a minicomputer that sends print jobs from minicomputer users to the printer.

If a printer is not captured, and both Windows NT Server and another source send jobs to the printer, no jobs will be interrupted; however, while the printer is printing a job from one source, it will appear busy to the other sources.

For information on capturing AppleTalk printers, see Chapter 21, "Working with Macintosh-Accessible Volumes."

Avoiding LaserPrep Wars

With some AppleTalk networks, a condition known as LaserPrep Wars causes slow printing performance. SFM solves this problem.

LaserPrep Wars occur when a network has Macintosh clients that use two or more versions of Chooser Packs, which include a PostScript preparation file (also called a LaserPrep file) and a PostScript driver. A printer can use only one version of the LaserPrep file at a time. When a Macintosh user sends a print job to the printer, the Macintosh checks for the printer's version of the LaserPrep file; if the printer currently has a different version than the Macintosh client uses, the Macintosh client sends its version of the LaserPrep file along with the print job, and it instructs the printer to load that file as the printer's resident LaserPrep file. Because Macintoshes with different LaserPrep file versions send print jobs to a printer, different versions of the LaserPrep file are loaded and unloaded on the printer.

Performance problems result because the printer must load and unload versions of the LaserPrep file and then print a startup page each time a different LaserPrep file becomes resident. This can also reduce the life cycle of the printer.

For example, suppose a Macintosh user whose client uses Chooser Pack version 6.0 sends a document to the printer. The LaserPrep version 6.0 file is made resident on the printer. Then, if the next document sent to the printer comes from a client using Chooser Pack version 7.0, the printer must reset, load LaserPrep 7.0, and print a new startup page before printing the document.

SFM solves the LaserPrep Wars problem by sending the LaserPrep file with each job. This extra effort actually improves overall performance: The printer never has to spend time making a LaserPrep resident or printing a startup page.

Note that for printers on an AppleTalk network, LaserPrep Wars are guaranteed to be avoided only if the printer is captured. If the printer is not captured, users who send print jobs directly to the printer, bypassing the print server, can initiate LaserPrep Wars.

LaserPrep Wars are always prevented when printers are attached directly to a computer running Windows NT Server that is set up with SFM.

Network Security

With Windows NT Server and SFM, network security is enforced for Macintosh users in the same way it is enforced for PC users. SFM translates user identification, authentication (passwords), and permissions so that the integrity of the server is maintained regardless of the type of client used. The following sections explain how network security applies to Macintosh users and cover the following topics:

• Windows NT Server user-account restrictions for Macintosh users 

• Password protection, including guest logons from Macintosh clients 

• Translation of Windows NT Server file permissions to Macintosh-style permissions 

• Macintosh-accessible volume passwords 

Windows NT Server Accounts for Macintosh Clients

SFM uses the same user accounts database as Windows NT Server. Therefore, if you already have Windows NT Server accounts created for the people who will be using Macintoshes on the network, you don't need to create additional accounts. You must create accounts only for users who don't already have accounts on the computer running Windows NT Server and SFM.

One aspect of Windows NT Server user accounts, the user's primary group, applies only to SFM. The user's primary group is the group the user works with most, and it should be the group with which the user has the most resource needs in common. When a user creates a folder on a server, the user becomes the owner. The owner's primary group is set as the group associated with the folder. The administrator or owner can change the group associated with the folder.

Passwords

Macintosh users are logged on to a computer running Windows NT Server in one of three possible scenarios:

• As a guest 

• As a user with a clear-text password 

• As a user with an encrypted password

Guest Logons

Using SFM, you can set up guest logons, which allow users without accounts to log on to the server using a Macintosh. You can specify what access to resources guest logon users have; administrators typically grant guest users fewer permissions than users who have accounts on the server. If the guest logon option is enabled, the server always approves the logon request without requiring a password.

For information on setting up guest logons, see Chapter 22, "Managing the File Server."

Clear-text Passwords

Clear-text password protection is part of the AppleShare client software on Macintoshes. It provides less security than encrypted password protection because the passwords are sent over computer lines and can be detected by sniffers—network monitors that can look for passwords. Moreover, the AppleShare passwords can be no more than eight characters in length. Clear-text password protection is offered for Macintosh users who use the standard AppleShare client software or System 7 File Sharing.

Encrypted Passwords

An encrypted, or encoded, password is more secure than a clear-text password. Windows NT Server encodes passwords and stores them so that they cannot be directly stolen from the client itself. Encrypted passwords can be up to 14 characters in length. SFM offers encrypted passwords to Macintosh clients.

For more information about security, see Chapter 21, "Working with Macintosh-Accessible Volumes" and the Windows NT Server Concepts and Planning Guide.

Permissions

Access to network files and directories is controlled with permissions. With the Windows NT security system, you specify which users can use which shares, directories, and files, and how they can be used. The Macintosh-style permissions differ in that they can be set for folders (directories) only—not files.

The set of permissions available for PC users differs from the set of permissions available for the Macintosh. SFM automatically translates permissionsso that permissions are enforced for both PC and Macintosh users.

The Windows NT Server Administrator account always has full permissions on SFM volumes.

Types of Permissions

PC users and administrators use Windows NT permissions. Macintosh users set Macintosh-style permissions on the folders they create.

In Windows NT, new files and new subdirectories inherit permissions from the directory in which they are created.

Macintosh files inherit the permissions set on folders. Any Windows NT permission specified for a file will be recognized by the File Server for Macintosh, even though the Macintosh user won't see any indication in the Finder that these permissions exist. The Macintosh has the following four types of permissions for a folder:

• See Files, which lets a user see what files are in the folder and read those files 

• See Folders, which lets a user see what folders are contained in the folder 

• Make Changes, which lets a user modify the contents of files in the folder, rename files, move files, create new files, and delete existing files 

• Cannot Move, Rename, Or Delete, which prohibits these actions on a folder

A Macintosh user cannot give these permissions to multiple users and groups. Instead, permissions can be assigned to three categories of user, as shown in the following screen:

 

• Owner The user who created the folder. 

• User/Group Similar to the Windows NT Server group associated with the folder. Every folder on a server can have one group associated with it at any one time. The group can be a special group like users or administrators, or it can be any other group on the server. 

• Everyone All other users of the server, including user accounts with guest access.

The Macintosh security scheme is based on the idea that every folder on a server falls into one of three types: private information (accessible only by the owner of the folder); group information (accessible by a single workgroup); and public information (accessible by everyone).

For example, consider a folder containing information that all members of a certain group should see, but that only one person can change. The person allowed to change the information should be the Owner of the folder and should have See Files, See Folders, and Make Changes permissions. The workgroup that uses the folder should be the Group associated with the folder and should have only See Files and See Folders permissions. Because no one else needs to see the folder's contents, the Everyone category should not be selected.

Although a folder's owner will often be a member of the group associated with the folder, this need not be the case.

With both Macintosh-style and Windows NT Server-style permissions, users' access to folders can be defined differently for each directory and subdirectory within a directory tree. For example, you could give a user See Files, See Folders, and Make Changes permissions for one folder, only the See Files permission for a subfolder of that folder, and no permissions at all for another subfolder.

How File-Level Permissions Are Handled

With Windows NT Server, PC users can assign permissions separately for each file within a directory. The Macintosh, however, does not support file-level permissions. When a file has file-level permissions, those permissions apply to Macintosh users only if the permissions are more restrictive than those assigned for the directory that contains the file.

For example, if a Macintosh user has See Files, See Folders, and Make Changes permissions for a directory (which appears as a folder), the user can read and make changes to files in the directory. However, if that user has only Read permission for any particular file in that directory, the user can only read that file. Because of the Read file-level permission, the user cannot make changes to the file.

Translating Permissions

SFM translates permissions so that those set by a PC user are translated into the equivalent Macintosh permissions, and vice versa. When a PC user sets permissions for a directory, or when a Macintosh user sets permissions for a folder, permissions are translated according to the following table:

Windows NT permissions	Macintosh permissions
Read	See Files, See Folders (or both)
Write, Delete	Make Changes

The following guidelines apply:

• When a PC user sets Read permissions on a directory or file, users will have both See Files and See Folders permissions when using a Macintosh. 

• When a PC user sets Write and Delete permissions on a directory or file, users will have Make Changes permission when using a Macintosh. 

• When a Macintosh user sets See Files or See Folders (or both) permissions, the user will have Read permissions when using a PC.

• When a Macintosh user sets the Make Changes permission, the user will have Write and Delete permissions when using a PC. 

Note Permissions set within the Macintosh behave differently than those set from within Windows NT Server, including Macintosh-style permissions. From the Macintosh, a right assigned to everyone overrides more restrictive rights set on the owner or a group. From Windows NT, permissions assigned to everyone do not override permissions set on the owner or group.

Setting Permissions from a Macintosh or a PC

A folder's owner can set permissions for the folder. Both the folder's owner and the server administrators can also use a PC to set Windows NT permissions for folders on the server. The folder's owner can set permissions for the directory (folder) from a PC because the owner of every directory (folder) has the Windows NT P (Change Permission) permission for that folder.

And after SFM is started, Administrators can also use File Manager to set Macintosh-style permissions for any directory within a Macintosh-accessible volume, including the volume root directory.

Volume Passwords

SFM provides an extra level of security through Macintosh-accessible volume passwords. A volume password is a password you assign to a Macintosh-accessible volume when configuring it. Any Macintosh user who wants to use the volume must type the volume password. PC users do not need to know the volume password to access the directory that corresponds to the Macintosh-accessible volume. Volume passwords are case-sensitive.

Volume passwords are optional; when you create a new Macintosh-accessible volume, the default is to have no volume password.

Note Because of a constraint with the System 6 and 7 Finder, you cannot automatically mount a volume with a volume password at startup or by double-clicking an alias. You also cannot automatically mount a volume if the user originally connected to the volume with Microsoft Authentication. For more information on Authentication, see Chapter 18, "Setting up Services for Macintosh."