After you have FSM installed and configured, you'll find that you can't do anything with it until you create some MAVs. The following list illustrates the general process:
Each of these steps is covered in the sections that follow.
Windows 2000 offers two slightly different ways to create new MAVs. The first way is already familiar: you can use the Create Shared Folder Wizard to create a new Windows share, making it visible to Macintosh (or NetWare) clients when you create it. Alternatively, you can create a MAV for an existing Windows share by using the wizard to create a new Macintosh-only share pointing to the same item.
To launch the Create Shared Folder Wizard, open the Shared Folders snap-in, right-click Shares in the Shared Folders tree, and choose New File Share. The Create Shared Folder Wizard appears as shown in Figure 23-13. Note that the Apple Macintosh check box is no longer unavailable; to create a new MAV on top of the new share, all you have to do is select that box. Optionally, you can edit the Macintosh-visible share name in the Macintosh Share Name field, but the wizard supplies a reasonable default name for you.
Figure 23-13. The Create Shared Folder Wizard.
There's one caveat to this process. You cannot create a MAV inside another MAV. For example, let's say that you create a share and a MAV at the root of an NTFS volume on drive F. You can create a Windows share on F:\Downloads, but you can't create a MAV there, because you can't nest them. For this reason, Microsoft recommends not creating MAVs at the root level of your drives; instead, create MAVs individually for the relevant folders at the lowest point in the folder hierarchy that you want to serve as the root for a MAV.
When you click Next in the wizard, you'll see the standard share permissions selection window. The default permissions on new shares are pretty scary: if you create a combined MAV/Windows share, the Everyone group gets Full Control on it, and if you create a MAV-only share, all Mac OS users get the Macintosh equivalent. You'll usually want to restrict things a bit more than that.
The most important fact to understand about FSM's permission handling is this: the Mac OS supports access controls only on folders, not on files. FSM does a good job overall of translating between Windows 2000 and Mac OS permissions, but it can't do anything to overcome this limitation. As a workaround, FSM automatically applies the permissions of the parent folder to its child files and subfolders.
Windows users can assign permissions on each file in a folder, but Mac OS won't honor them. This defeats the whole purpose of file-level security, so FSM implements an inelegant, subtle, but useful workaround. File-level permissions apply only if they're more restrictive than permissions on the file's enclosing folder. For example, let's say that you assign the Everyone group Full Control rights on a MAV named Contracts. You then change the permissions on one file, Big-deal.doc, so that the Everyone group has Deny:Write and Allow:Read permissions on that file. A Macintosh user who attaches to that MAV will be able to open the folder and the file. As far as Mac OS is concerned, the user will have full access to the file, but the server won't honor any write requests. If you open the file, edit it in Microsoft Word, and try to save it, you'll get an error—the server won't allow you to have write access to the file.
The next detail to understand is who gets access by default. As mentioned earlier, when you create a new MAV the default is to give the Everyone group Full Control permission on the entire MAV. Members of the Administrators and Server Operators groups can manage the FSM service itself, and users with Administrator privileges on the server always have Full Control over all files in the MAVs on that server.
Apple's permission scheme groups user data into three categories: private data (only the owner can use it), group data (only members of a single group can use it), and public data (everyone can use it). Although this is conceptually easier to understand than the Windows 2000 permissions scheme, it's also a lot less flexible. In the classic Mac OS, you can assign permissions on objects using only these three categories; there's no way to do things like give multiple workgroups access to a single file inside a folder. One nice feature of this approach is that the owner doesn't have to be a member of the group that has permissions on the folder.
Another difference is that Windows 2000 automatically assigns permissions by inheritance (at least when the Allow Inheritable Permissions From Parent To Propagate To This Object check box is selected, which is the default); Mac OS allows folders to inherit permissions or not, as the folder owner sees fit. Each folder in a hierarchy can have different permissions. For example, it's common to give users Read-Only access to the root of a shared disk and then give them Read/Write permission to folders they need to access.
The third, and perhaps most critical, major difference between the two systems is the way the Everyone group behaves. In Windows 2000, permissions given to the Everyone group don't trump permissions assigned to specific individual or groups, but in the classic Mac OS they do. This means that you need to be careful about assigning Everyone permissions on the Mac OS side, because they might not behave as you expect.
The Macintosh permissions themselves are also quite a bit different from Windows 2000 permissions. Classic Mac OS users can assign a total of five permissions to folders they own:
How do these permissions map to Windows 2000 permissions? The Windows 2000 Read permission equates to the See Files permission and the See Folders permission on the Macintosh side. The Windows 2000 Write and Delete permissions each equal the Make Changes permission on the Macintosh side. These mappings are two-way; if a Macintosh user grants Everyone the See Files and See Folders permissions on a MAV, that's the equivalent of giving the Windows 2000 Everyone group Read permission.
You can give permission to an arbitrary number of groups in Windows 2000—any object can have a virtually unlimited number of different permissions assigned to it. On the Macintosh side, however, each object can have only one set of groups assigned to it. FSM bridges this conceptual gap by designating one Windows 2000 group as the primary group for an object. Although other groups might have permissions that they can use from Windows clients, only the primary group gets access rights on the Macintosh side, using the User/Group permission slot that Mac OS uses. You set the primary group by setting the group that has permissions on the folder on your Windows 2000 Server.
Although anonymous access is the norm for Web servers, it's not always desirable for file, print, or application servers. Strictly speaking, the Guest account isn't anonymous, but as a practical matter it doesn't give you the same ties between a known account name and a person that regular accounts usually do.
If you want to allow guests to access your FSM volumes, you can do so in one of two ways: you can force classic Mac OS clients to use the Windows 2000 Guest account, or you can force them to use the Mac OS Guest account, which uses the Windows 2000 Guest account on the server. (See "Allowing Macintosh OS Guests" later in this chapter for more details about this approach.) Which approach is best? The Mac OS Guest feature lets users click a Guest button in the Chooser and log on without providing a user name or password, whereas the Windows 2000 account requires you to disseminate the password for your Guest account. Because you probably don't want anyone other than Mac OS users to use your Windows 2000 Guest account, the Mac OS Guest account is the better solution for most applications. No matter which approach you take, be sure to set appropriate permissions on your MAVs so that guests can only see and modify what you want them to.
Enabling the Guest account can be a serious security liability. Only enable it if the advantages are significant and you're willing to accept the substantial security risk.
Regardless of whether you choose the Macintosh or Windows 2000 Guest account, you need to perform some preliminary steps to make guest access work:
If you're using the Mac OS Guest account, open the Properties dialog box for the MAV you want guests to access and make sure the Guests Can Use This Volume check box is selected. This setting has no effect if you're requiring users to log on with your Windows 2000 Guest account.
If you pause or stop the FSM service before enabling the Windows 2000 Guest account, you can use the Guest account, once enabled, on another Windows machine to connect to the share and double-check that your permission settings are as you expect them.
Using Private Volumes
You can create a volume that no one except its owner can see. This is a good way to allow users to set up shares so that they can get to their files from Macintosh or Windows machines without allowing access by anyone else. It's particularly handy for administrators, because you can use this feature to set up a share of useful tools or reference material that's accessible—to you—from anywhere on your network.
To create a private volume, set the Macintosh permissions so that only the owner has access; set the User/Group and Everyone permissions to None. Users see the MAV in the list of available shares after they log on to the server, but the private volume is unavailable, and users won't be able to mount it unless they get the owner's name and password.
The AppleShare protocol provides some additional security features that you can set on a per-share basis. You access all of these features through the Properties dialog box of an individual MAV. To display this window, shown in Figure 2314, right-click the MAV of interest in the Shared Folders snap-in and then choose Properties. The interesting area is the SFM Volume Security area (SFM stands for Services for Macintosh), which isn't present in the Properties dialog box of a Windows-format share.
Figure 23-14. The Properties dialog box for a MAV.
The Password field in the SFM Volume Security area allows you to assign a case-sensitive password to individual volumes. Mac OS users have to provide that password and have access permissions for the items they want to use; Windows users don't need the volume password. The volume password provides an additional level of security because users who don't have the password can't connect to the volume at all. Without a volume password in place, users can connect to the server and see items for which they have See Folders and See Files permissions, even if they can't open or change them.
Some earlier versions of Mac OS don't allow users to save volume passwords so that volumes can be mounted automatically; however, all versions of Mac OS since version 8 (circa 1996) do allow it, so don't count on volume passwords to add much security for users who save them.
When you mount a standard CD-ROM on your system, it remains Read-Only no matter what permissions you might have assigned the files and folders on it. FSM gives you a similar option: by selecting the This Volume Is Read-Only check box in the SFM Volume Security area, you can mark a volume as Read-Only. This setting overrides any permissions a Mac OS user has. When this setting is in effect, Mac OS essentially treats the entire volume as though it were locked.
As mentioned earlier, the Mac OS Guest account and the built-in Windows 2000 Guest account are very different animals. Regardless of what permissions (if any) you grant to the Windows 2000 Guest account, you can still choose to make your MAVs available to Mac OS guests by selecting the Guests Can Use This Volume check box in the SFM Volume Security area of the MAV's Properties dialog box. However, if you disable the Windows 2000 Guest account, selecting this check box has no effect, because when a Mac OS user chooses to log on as a Mac OS guest, FSM maps that request to the Windows 2000 Guest account. Because the Guest account is disabled by default in Windows 2000 Server, Advanced Server, and Datacenter Server, Mac OS guests can't mount MAVs unless you take action to reenable the Guest account, which you should do only if you're willing to accept the security risk.
As discussed earlier in the chapter, FSM takes care of translating between Windows 2000-style extensions and Mac OS type and creator codes. It does this using a set of registry values (stored in HKLM\System\CurrentControlSet\Services \MacFile\Parameters\Type_Creators) that contains the type and creator codes you've defined, and a separate list (under HKLM\System\CurrentControlSet \Services\MacFile\Parameters\Extensions) that ties an extension to an entry in the type/creator list. FSM uses these mappings to establish a type and creator code for a file so that Mac OS clients see the appropriate icon, and get the expected behavior, when they work with files on a MAV. Files with extensions that don't map to a type/creator pair in these databases get a generic icon and creator that tells Mac OS that they're plain text files. This probably isn't what you want for most files.
FSM includes an extensive set of mappings, but there are three circumstances under which you might need to modify them. The first is that some of the mappings are ancient—Microsoft includes mappings for programs like Symantec's MORE and Lotus 1-2-3 that haven't been sold for the Macintosh in five years or so—and you might need to update them. You might also find that you don't like the default mapping for a particular file type. As an example, StuffIt (the Mac OS equivalent of WinZip) has two versions: a full version and a decompress-only version called StuffIt Expander. The default FSM mapping binds StuffIt files to the full version, which most users won't have, so it makes more sense to tie that extension to StuffIt Expander instead. The final situation in which you might need to edit these mappings is when you need to add a file type that FSM doesn't know about. Because the version as shipped isn't aware of a number of very common extensions (including .BMP, .GIF, .JPG, .PNG, .HTM, and .JS), this is probably the most common problem you'll encounter.
To edit these associations, you use the File Association tab of the File Server For Macintosh Properties dialog box (Figure 23-15), which you can display by opening the Shared Folders snap-in, right-clicking Shared Folders, and choosing Configure File Server For Macintosh from the shortcut menu. The layout of this tab is a little confusing until you understand how it works. The top portion of the tab (including the Files With MS-DOS Extension box and the Associate button) is where you choose the extension for which you want to create an association. The With Macintosh Document Creator And Type area lets you view and edit the Mac OS types and creators that are available to make associations with.
The overall process is simple, but there are some variations along the way, depending on why you're editing the associations. The first step is to add a new type and creator pair; you need to do this when you're adding a new extension or mapping or revising an existing one (as there's no way to edit a type/creator pair once it's in the database). To add a new pair, click Add and then supply the creator, file type, and description you want it to use. You can select an existing creator or file type or enter a new one. If you need to look up the type or creator for a file, you'll have to do it on the Macintosh side, using a utility like ResEdit or More File Info. After you've entered the information, the new type/creator pair appears in the list.
Once you've added the new type/creator pair, you can attach it to an existing extension or add a new extension and attach the Mac OS information to it. To link an existing extension with a type/creator pair, select the pair in its list and then select the matching extension from the Files With MS-DOS Extension list and click Associate. To add a new extension, type it into the Files With MS-DOS Extension box and then click Associate to create it and tie it to the selected type and creator combination.
Figure 23-15. The File Association tab of the File Server For Macintosh Properties dialog box.
Mac OS users who are connected to a MAV won't see the updated association information until they log off and remount the volume.
To delete an association, select the type and creator item in the list and then click Delete. FSM asks you to confirm your command, because removing a type and creator pair removes it and any associated extensions from the registry.
Occasionally, you need to send a message to your users to tell them something important—so important that you don't want to wait for it to go out in e-mail. You might be notifying them that something is (or is going to be) down for maintenance, that the building is on fire, or that Michael Jordan is coming back from retirement (again). In Windows 2000, you use the Server Manager to send messages to users who are connected to a server; for Mac OS clients, you use the Sessions tab of the File Server For Macintosh Properties dialog box (Figure 2316). Sending a message is trivial—you type it into the Message box and click Send. All Mac OS users who are logged on to your server when you send the message see a pop-up window with your message in it.
Figure 23-16. The Sessions tab of the File Server For Macintosh Properties dialog box.
As a bonus, the Sessions tab shows you how many users (listed as Sessions) are logged on to your server, how many file forks are open, and how many files are locked because they're open. Although this is occasionally interesting, it's no substitute for the Macfile Server performance object, which you can monitor using the performance monitoring tools discussed in Chapter 33.