A 432-page book that simplifies the installation, configuration, and management of Apple's Mac OS X 10.6 Server software. Support Mac and Windows clients for file sharing, email, and directory services; Incorporate a Mac subnet into a Windows Active Directory domain, manage Mac and Windows clients, and configure security options, and more. Click here for more.
Snow Leopard Server for Dummies
By John Rizzo
A 432-page book that simplifies the installation, configuration, and management of Apple's Mac OS X 10.6 Server software. Support Mac and Windows clients for file sharing, email, and directory services; Incorporate a Mac subnet into a Windows Active Directory domain, manage Mac and Windows clients, and configure security options, and more. Click here for more.
Also on this page:
For related information:
Making a connection to Microsoft RAS is easy with Mac OS 8.5's Remote Access control panel. It supports MS-CHAP, a type of PPP authentication, and is compatible with RAS.
However, Macs with earlier versions of Mac OS trying to make a PPP connection to Windows NT RAS often have problems. According to Richard Birchall, a mechanical engineer with Atomic Energy of Canada, Ltd., the problem usually occurs when the NT RAS server has been set to MS-CHAP, For a solution, see the Web page Mr. Birchall has created just for this topic.
However, Macs can use MS-CHAP and Microsoft PPTP protocols by using a NTS PPP (part of TunnelBuilder) from Network TeleSystems, Inc. (see MacWindows Solutions for further info.)
Netopia's site has a page on how to configure Windows NT 4.0 RAS for dial-in use with Timbuktu Pro 32. The page includes step-by-step instructions with screen shots.
When logging in, don't forget to use the correct form: <server domain name>\<user name>
Mac users may not realize that they need to use the backslash (\) as a separator. (Thanks to Christian Pendleton for that reminder.)
Configuring the Ascend MAX TNT talk AppleTalk over PPP
Mike Perbix sent in the following:
We have successfully configured a Ascend TNT Max dial-in system with AppleTalk over PPP ( ATCP), and authentication using a Steel-Belted Radius Server using NT Domain User list.
This problem has been intriguing since the Ascend Manuals had little AppleTalk documentation, and even less ATCP information. A informative Technician at Ascend and a determined consultant working on our behalf got together and has the whole thing working. The reason I submit this is to let other users who may be using the similar equipment environment from having to go through what wee did to get this to work...
Here is a web site the consultant created with all the pert. info.
(Perbix credits Clark Shishido and Julian Y. Koh of the Mac-Mgrs mailing list for pointing him in the right direction.)
Unpredictable logon results can occur when a Macintosh user has matching accounts in more than one Microsoft domain, but does not have equivalent permissions on the Services for Macintosh volume that is being accessed by the logon process. Since permissions are granted based on only one of multiple accounts, users can be denied access or granted access depending upon which account was found first.
Use the Microsoft UAM volume to connect to the Windows NT Server, and then enter your <domain Name\User Name> (for example, DOMAIN2\JSMITH) in the "User Name" box when providing a user name and password. This allows the Windows NT server to validate you in the correct Domain.
The AppleShare 4.x server supports up to 50 volumes with 27 character names or less. The Macintosh Finder was designed to expect no more characters than this. When the Finder looks for a server share, it allocates memory for a string that is 50x27 characters long. When the Finder encounters a server whose shares have a total string length greater than 50x27, the Finder can't handle it and may stop responding.
On a Windows NT server, you can successfully create a few hundred visible Macintosh volumes by giving the volumes very short names, such as A1, A2, B1, B2, and so on. You can increase the number of volumes you can create by minimizing the string length of the volume names.
Matching Windows file name extensions with a Mac type and creator code on an NT Server
Open File Manager, select the 'MacFile' menu, and select 'Associate...'. Enter the file extension and click 'Associate'.
Type and Creator codes are codes assigned to applications by Apple. (See MacWindows Tutorials.) You can find the Type and Creator codes of Mac files using Find File. Windows NT lets you associate Type and Creator codes of files in shared directories so that Word for Windows files, for instance, will open with Word for Mac.
This report has been moved to its own page.
This info is from Microsoft. If you're a registered MS Tech Support user, you can also access the article at Microsoft's site.
Last reviewed: November 11, 1997, Article ID: Q156182
The information in this article applies to:
Microsoft Exchange Server, versions 4.0 and 5.0
Microsoft Windows NT Server, version 4.0
Microsoft Exchange Macintosh client, versions 4.0 and 5.0
A Windows NT 4.0 password cannot be changed from the Microsoft Exchange Macintosh client. The scenario is as follows (this is the same for Banyan Vines TCP/IP clients):
You are using the Microsoft Exchange Macintosh client and attempting to change the Windows NT password by clicking Options on the Tools menu. On the Exchange Server tab, you click Password. After you type all the information and click OK, the following message appears:
After you enter the Apple-Talk zone and click OK, the following message appears:
As a result, the password is not changed.
In order for the Microsoft Exchange Macintosh client to change the Windows NT domain password, the registry must be modified as follows:
WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall Windows NT. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.
1.On the Windows NT Primary Domain Controller (PDC), start Registry Editor, regedt32.exe (regedit.exe in Windows NT 4.0 will not work) to edit the PDC's Registry.
2.Under the HKEY_LOCAL_MACHINE subtree, go to the following subkey: SYSTEM\CurrentControlSet\Control\Lsa
3.Select Lsa to highlight it.
4.On the Edit menu, click Add Value.
5.Make one of the changes listed below, depending on whether AppleTalk or TCP\IP protocol will be used:
For password support using AppleTalk protocol, enter:
Value Name: AppletalkClientSupport
Data Type: REG_DWORD
DWORD Editor Data: 1
For password support using TCP/IP protocol, enter:
Value Name: TCPIPClientSupport
Data Type: REG_DWORD
DWORD Editor Data: 1
6.Restart the primary domain controller (PDC).
7.From Windows NT User Manager for Domains, select a user account of a Microsoft Exchange Macintosh client user. On the Policies menu, click Account. At the bottom of the Account Policy dialog box is the check box "Users must log on in order to change password". Make sure this check box is cleared.
8.If using TCP/IP as connecting protocol, the client must have a hosts file or Domain Name Service (DNS) with entries for both Microsoft Exchange Server and the Windows NT PDC. (The A and CNAME records)
With the above configuration in place, you can now change the Windows NT domain password using the Microsoft Exchange Macintosh Client as follows:
1.On the Tools menu, click Options.
2.On the Exchange Server tab, click the Password button.
3.Type the information and click OK. A message appears stating:
Future log on process(es) to domain resources will use the new password.
Microsoft Windows NT Server 3.5, 3.51, and 4.0 -- Macs can only see 2 GB (or 4 GB) of bigger Services for Macintosh volumes.
Services for Macintosh volumes residing on the NT server that are 2 GB-4 GB in size can sometimes only be seen by Macs as 2 GBs in size. Though not actually a bug, the problem is caused by the way Microsoft configured Services for Macintosh -- Prior to system 7.5, Mac OS did not support volumes bigger than 2018 MB (just under 2 GB, which is 2048 MG). Some versions of Services for Macintosh defaults at restricting the values it reports for total and free space on SFM volumes to 2018 MB, when the actual size of the SFM volume's disk partition is larger.
System 7.5 raised the maximum volume limit to 4 GB, and System 7.5.2 raised it to 2 terabytes. However, 4 GB is the biggest volume size for which the AFP network protocol used by Windows NT SFM will report correct total and free space of a network volume. (Windows 2000 Server fixes this problem.) However, Macs can mount larger network volumes -- the just won't see the correct totoal and free space figures. So, you can mount a 30 GB volume, but the Finder might report "4 GB volume, 4 GB used, 4 GB free space."
To increase the 2 GB volume limit in NT Server, the NT Services registry flag must be edited to raise the default 2018 MB maximum volume size. You'll need to update Mac clients with very old System software to at least System 7.5, or the Finder will crash when trying to mount the SFM volume.
A registry flag controls the maximum volume size and free space reported by the SFM file server. You can raise the maximum reported size for SFM volumes to 4 GB minus 256 (a flag value of 0xFFFFFF00) by creating the SFM volume, then editing the registry entry.
1. Use the Registry Editor (Regedt32.exe) to access the registry entry at:
2. Add 262144 (0x00040000) to the number xxxxx.
3. Stop and restart MacFile to make this change take effect on the Services for Macintosh volume.
In Windows NT 3.51, you can change this value globally to enable all volumes to be 4 GB (or more). To do this, add bit 0x10 to the following section of the registry and every volume will be 4 GB enabled:
ServerOptions: REG_DWORD: 0x13
NOTE: The ServerOptions value has a default value of 0x03. After adding 0x10 to 0x03, the result becomes 0x13. After making this change every volume will be 4 GB enabled.
Users registered at the Microsoft's tech support site can access a similar article on this topic, Knowledge base article number Q120739.
Todd Parkhill points out that Thursby System's DAVE client correctly displays the free space of mounted volumes (50 GB of free space is the largest he's seen.) DAVE implements the Microsoft SMB file sharing client on Mac OS. It does not use the AppleShare client (AFP), and does not access Services for Macintosh, but accesses the Windows file server on NT.
The file icons in a mounted Windows NT Server, Services for Macintosh volume window "jump" around, making it difficult to select them. People also report being unable to hold keep the window in list or icon view. The problem occurs with Mac OS 8.0 and 8.1, though it seems worse on 8.1.
This problem was fixed in Windows NT 4.0 Service Pack 4, along with 16 other bugs.
Before SP4 was released, Microsoft posted an unsupported "Hotfix" for the Windows NT Server 4.0, which you can download from the MS FTP site. The fix comes in an auto-install file called "sfm-fixi.exe" for the Intel version, "sfm-fixa.exe" for the Alpha version. This hotfix also contains fixes for 9 other bugs. Unfortunately, it is known to cause another problem, where aliases on the Mac client pointing to files or directories server volumes open the wrong items. There is no know fix for this "jumping alias" problem.
The previous versions of the Hotfix for the jumping icon problem were called Jump_A.zip and Jump_86.zip. (An older version yet is called Hotfix.zip.) There is no fix for NT Server 3.5.x.
Before posting the Hotfix at it's site in mid-May 1998, Microsoft required you to call Microsoft tech support at 800-936-5900 in the U.S. Microsoft then billed you $195 before you can talk to a technician, but will gave you a refund when it's established this is a known problem. (People who post hotfixes on the web are often asked by Microsoft to remove it.)
With all versions of the hotfix, the old sfmsvr.sys file is replaced with the new one at this location:
You can run the installer or replace this file yourself.
The problem also occurs with UNIX servers, though less frequently. A patch called Netatalk 1.4b2 is available.
Readers have reported the problem on Netware, but we know of no fix at this time.
Billy Eggington reports the problem on a peer-to-peer basis, with Macs running Thursby's DAVE logged onto Windows 95 volumes, but we know of no fix at this time.
There are several things you can do to improve the performance of an NT server for Mac clients. Readers have sent in the following tips:
The next four articles discuss problems of disappearing file icons.
Files on the mounted server volume on Mac clients disappear, but are still visible on Windows clients and from the server. This is an acknowledged Microsoft bug that was fixed with Windows NT Service Pack 3 for Windows NT 4.0. In July of 1997 Microsoft created a "hotfixed" version of Sfmsrv.sys file (available by calling Microsoft technical support). Microsoft recommends rebuilding Macintosh volumes after applying the hot fix. However, Service Pack 4 fixes a variety of bugs with Windows NT 4.0, and is recommended by Microsoft.
Directly below are several methods of recovering files that have disappeared.
2. Microsoft Windows NT 4 Server -- When server crashes, files disappear from mounted server volumes on Macs
One disappearing-icons problem that NT Service Pack 3 doesn't fix occurs when a Windows NT 4.0 Server running Services for Macintosh crashes. After rebooting the NT server, Macintosh users may find that random files are missing from the NT volumes, though the files are visible to Windows 95 users who access the same volumes, but not the Macs, no matter what you do. Running chkdsk or any other disk management tool will not help. Consultant Greg Barry warns NOT to move the files with a Windows 95 PC, or "corruption is guaranteed."
Cause of the Problem:
The AFP volume indexes are stored in RAM on the server and are used by the Services for Macintosh file server. The SFM process manages the indexes for each volume constantly and makes heavy use of RAM for this processing. These indexes are written to disk at shutdown and may be written at other un-documented times. When the server crashes, the indexes are lost and the old ones are read from disk. These indexes are responsible for the contents of the AFP volumes that the user sees. Even when SFM is stopped and started, the files do not come back.
This is a known Microsoft by that was fixed in the June, 1998 hotfix called sfm-fixi.exe, which enables SFM to rebuild the indexes upon restart after a crash. This is the multiple-bug hotfix that includes fixes for 10 SFM Service Pack 3 bugs, including the Jumping icon fix.
Chris Pepper offers this manual approach:
I was able to clear this problem by moving the missing files into a different directory (existing or newly created; could be a subdirectory of the affected directory), and then moving them back, on the server itself. As soon as the files were moved, they showed up on the Mac; they remained visible after moving them back.
Another method of updating the index file:
Jerry Lees sent in a method that he uses to prevent the problem of Mac files disappearing from NT Server. He is Running NT 4 SP 5.
I too have found this to be a problem on my network. I have not done a lot of tracing to find the source of the problem... mainly because I have found a patch to the problem that I can run periodically.
Basically, I have a batch file that runs nightly and renames the files like this:
ren *.jpg *.jal
ren *.jal *.jpg
ren *.htm *.jal
ren *.jal *.htm
And so forth. This forces the index to be updated and rebuilt.
3. Microsoft Windows NT 4 Server -- Recovering files that disappear from mounted server volumes on Macs.
If you don't yet have the sfm-fix hotfix mentioned above, Kevin van Haaren of HNTB Corporation sent us this method of recovering files that disappeared from the Macs but were still visible from Windows machines. This method does not require rebooting the NT server or Mac clients.
Joe Clarke adds that simply recreating the Mac volumes forces a desktop rebuild with all the icons restored. Things that must be addressed after using this procedure are custom volume icon (if any) disappearance, and icon rearrangment.
4. NT jumping icon hotfix created a disappearing icon bug.
Microsoft says that the hotfix for the jumping icons bug (and other bugs) created a new bug on volumes with large numbers of files. With over 10,000 or so files on a volume, the SFM hotfix causes some file icons to disappear from mounted volumes on Macs. Upon rebuilding the Mac volume, the server can occasionally crash.
Microsoft said that NT 4.0 Service Pack 4 fixed this new problem.
There are five occasions when Macintosh clients can temporarily "hang" or freeze (showing the AppleShare "network busy" arrows in the upper left of the screen) when connected to a Windows NT server via Services for Macintosh:
1. Disabling Catsearch.
Disabling Catsearch has been reported to solve two problems:
Problem 1. When a Mac client uses the Find command to search on a mounted Windows NT volume, this causes all of the other Macs connected to the server to lock up temporarily with the AppleShare arrows frozen in the upper left of the screen.
The problem has to do with a bug in Windows NT 3.5.1 and 4.0, which allow the NT server to do the search instead of the Macintosh. The bigger the server volume and the more files and directories it contains, the longer the Macs will be locked up. The Windows NT delays the processing of requests from other Macintosh clients and the Macintosh clients will appear to "hang" while they wait for their request to be processed.
Problem 2: In Windows 2000 Server, this has been releated to Macs getting a Type -54 error message "File is Locked" when trying to save from Quark Xpress (v3.32/4.11).
To disable the feature called CatSearch with a registry edit, you need Windows NT 4.0 Service Pack 3 or later. These updates enable each Macintosh do its own search instead of requiring the server do it.
To disable the feature called CatSearch in Windows NT Server:
For Windows 2000 server, the procedure is the same, but the registry location is this:
For more information, see the Microsoft Knowledge Base article Q158796. (Thanks to Sam Russo, John Stein, and others for alerting us to this solution.)
However, Knowledge Base article Q231274 says that an Applescript that requests a CatSearch can cause the same problem, even with Catsearch turned off. Microsoft recommends not using such an AppleScript, but has no fix.
2. Macintosh clients temporarily hang when connected to a server with multiple Mac volumes. If you do a network trace, Macintosh clients are seen to be issuing the retry calls AfpGetFileDirParms and AfpCloseFork until an exclusive volume lock on the server is released.
According to Microsoft, the technical cause of the problem was in Windows NT:
"Where multiple volumes exist, as file status changes were being processed across various Macintosh volumes, an exclusive and volume-specific lock was being applied during volume change notify processing. In a particular instance, a volume-specific lock was not being released. This lock was released as more volume changes were processed; however, wait times varied.
This is an acknowledged Microsoft bug that was fixed with NT 4.0 Service Pack 3 and 4 (but NOT Service Pack 2). Microsoft changed the code to fix the problem. For more information, see the Microsoft Knowledge Base article Q162189
3. The Macs hang when the server gets busy.
You may not have enough RAM in the Windows NT server. Several readers have reported that upgrading server to 128 MB or 256 MB solved the problem. (See also "Performance Tips" above.
4. Macs can hang for several minutes when a user selects a Services for Macintosh (SFM) volume in the Chooser when an administrator moves a large number of files in what Microsoft calls a "programmatic traversal of a large NTFS directory tree." Examples include a Ntbackup:\*.* or a Dir/s\*.xyz. Mac and Windows network connections can time out and disconnect. This can occur with NT Workstation and Server 3.51 and 4.0.
The problem is a full circular log file, which blocks other NTFS operations and makes NT grind to a halt.
You can edit the registry to prevent the circular log from filling. (If you have Windows NT 3.51, you'll need to upgrade to the current NT 3.51 Service Pack before making the change.)
2. On the Edit menu, click Add Value, and edit the following entry.
Value Name: NtfsDisableLastAccessUpdate
Data Type : REG_DWORD
Data : 1
3. Quit Registry Editor and restart your computer.
The Microsoft Knowledgebase article on this topic is Q150355.
5. Macs hanging during logon to server.
Steve Holmlund first reported that Macs were hanging ("locking up") when logging into NT Services for Macintosh. The NT Server eventually timed out. He tracked down the problem to the Apple Menu Options control panel (which affects the Recent Servers setting in the Apple Menu Items). Holmlund believes the problem is caused by users not logging off before the Mac is either shut down or restarted.
However, Joerg Erdei found that turning of the Apple Menu Recent Server aliases in the Apple Menu Options control panel fixed the problem for him with NT SP3. He also describes the workaround with SP 5 and 6 below.
First Holmlund's description:
Here's what happened:
1. I had created aliases of 3 Macintosh volumes (for student & staff log-ons) living on our NT server and placed the aliases in a folder called Servers. This folder resides on the desktop of all Macs in our building (a mix of G3 266 and 233 MHz machines, the original iMacs and a sprinkling of newer G3's as well... running System 8.1, 8.5 or 8.6). I was having problems particularly with the 266 MHz G3's running OS. 8.1. We have a 100 megabit network, 6 electronic closets running fiber to the main closet where the server is located. Our computers function at either 10 or 100 megabit connections, depending on the NICs installed. We have PC's and printers sharing the same network.
2. When students logged in to the Students alias, SOME of them appeared to be authenticated by the NT server, but then the system locked up. I could see the communication arrows in the top left of the screen flash and then lock. Once this happened to a user he/she was denied access from that computer. The same user however was able to go to another computer and login fine from that machine. AND... another user using a different alias was able to log-on at the offending machine, just fine.
3. The G3's are running OS 8.1 with System Enabler 777 version 1.0 and AppleShare 3.8. After numerous attempts at a solution, I was tipped by Jason Seymour of our CallCenter to start looking at the Preferences/Control Panels/Extensions solution... i.e. take them out of the System folder and methodically reestablish preferences or divide Control Panels & Extensions into halves and take them out, restart, put back those that don't offend and restart again etc.
This time-consuming approach led to the solution. It turns out that a Control Panel, Apple Menu Options, appears to be the culprit. By removing that Control Panel (which affects the Recent Servers setting in the Apple Menu Items), the systems stopped freezing at log-in and the log-ins are functioning.
In hindsight, I believe that the issue is caused by users not logging off before the Mac is either shut down or restarted. It is of primary importance to counsel users to log off in these kinds of network environments.
Joerg Erdei says that with NT SP3, SP6, and SP6a, he found that turning of the Apple Menu Recent Server aliases in the Apple Menu Options control panel fixed the problem for him. Erdei said NT SP5 fixed the problem, but introduced another similar problem.
There is some kind of timeout problem when the Mac tries to actualize its Apple Menu. This happens whenever anything it points to changes. (This is why putting an alias of the partition that holds the System folder in the Apple Menu will slow down the Mac -- there are always changes in the System folder, namely all kinds of temporary files, so the Mac constantly rebuilds the Apple Menu). Polling the server for server directory structures, i.e. for directories the user has no access privileges for, at the wrong moment during logon, seems to produce the "hanging."
I don't see the problem related to "not logging off before the Mac is either shut down or restarted," as Steve Holmlund believes. In both cases the Mac itself logs off the server. It could be due to a crash or force restart while being logged on, but I do not have hard facts supporting this.
There is an alternative way to solve the problem (temporarily) from within the server:
1. Find the directory making problems: In our case users are organized in groups. One group directory contains one subdirectory for each user of that group. Usually only one directory of a user not having problems must be moved out of the group directory to solve the problem for the other users.
2. After that the removed directory can be recreated and all data copied back to it.
Another temporary way to solve the problem on the Mac: type Command-Power to jump in the debugger (should work on all Quadras and PowerMacs), in the debugger window write 'G CHOOSER'. The Finder will quit and open again, everything is fine till the next restart/startup. This trick usually works 2-3x for each user before it looses its "magic".
All this is true with NT4/SP3.
Installing SP5 solved that problem, but another similar problem was introduced:
After logon certain Mac/User combinations slowed down dramatically, taking hours for jobs usually taking seconds: i.e. logging off the server 2-4 hours. The whole time the arrows in the upper left corner indicate network traffic. This was not solvable by deactivating Apple Menu Options or anything mentioned above. I used to stop this behaving by force-quitting the Finder (Command-Option-Shift-ESC). After this the Mac will have no problems anymore till the next restart/startup, after which the same user will have the same problem. It turned out that after force-quitting the Finder one has to:
1. Delete any aliases to the server.
2. Empty the groups' Network Trash folder on the NT server before the next restart to solve the problem permanently.
With SP6a none the above problems have reappeared so far.
UPDATE: On March 21, Joerg Erdei reported the problem reapearing with SP6a. However, his suggested workaround of Disabling "Remember recently used items" in Apple Menu Options does still work with SP6a, as it does with SP6.
August 21, 2000 -- Joerg Erdei updated his experiences. He discovered an Apple TIL document (32027), but comments on it:
Erdei confirms that there is no problem with Mac OS 9. He also reports that the problem also occurs with Windows 2000 Server, and the same workaround fixes it.
Mac OS 8.5 has a compatibility problem with some virus production software that prevents copying files to mounted network volumes, including those of Windows NT Server and AppleShare IP. Basically, this problem occurs with Norton AntiVirus 5.0.2 and earlier and with Virex.
(Other causes of Mac clients to freeze or hang are listed elsewhere on this page.)
The main symptom is that the Mac freezes and eventually report that the Volume has been disconnected. Some readers have reported a hard crash that requires restarting the Mac.
Reader Orlin Damyanov reported additional symptoms with Virex, which was checking the mounted NT.
Symantec has released Norton AntiVirus 5.0.3, which fixes the problem. (But see new problem direct below.)
At this point (Dec 3, 1998), there is no fix for Virex, but Orlin Damyanov discovered a work-around:
In the preferences of the Virex control panel, disable the default function in "File Access" called Scan Files When Opened.
Marcus Reese reports that when he upgraded Virex 5.8 to version 5.9, his Macintosh 9600/300 running Mac OS 8.5 would lock up whenever he tried to copy a file to an AppleShare IP 6.0 server. Turning off the Virex 5.9 control panel in Extension Manager solved the problem.
Damyanov also reports of a virus checker that does not conflict with OS 8.5:
"Norton Antivirus causes similar if not even more serious problems (copying files on the network gives error message just before the end of the copy).This is true not only for NT with SFM but for AppleShare servers as well. The only anti-virus program that I know that has absolutely no problems with 8.5 is Rival 2 3.0.x written by Frederic Miserey according to Univers Macworld (French edition of Macworld, #85, December). But Rival is much less sophisticated and of course is no match for Virex or Norton Antivirus."
Mac OS doesn't ordinarily print to PCL printers. But when you connect a PCL (ie, non-Postscript) printer to an NT Server and share it, a Mac will see it as a LaserWriter Plus V.38. This is because Windows NT Services for Macintosh has a Postscript RIP (raster image processor) that intercepts the job and converts it to a 300 dpi bitmap that will print out on any printer. The RIP emulates a LaserWriter Plus v.38, which means the Mac should be using a LaserWriter print driver. If you try to use HP LaserJet print drivers on the Mac, you may not be able to print to the printer.
Another problem is a shortage of fonts: There are 14 system fonts in Windows NT SFM and the LaserWriter Plus had 33. Microsoft's Fontpack used to be a good tool for getting the best performance of the NT's RIP. Unfortunately, it is no longer available.
You can have a font problem if you use a font (such as Palatino) that was in the original LaserWriter Plus V.38, but is not in the actual printer or in NT. One solution is to avoid such fonts. Mark Short found another solution:
...unfortunately my wife uses Palatino, which the Printer Definition for LaserWriter Plus v38.0 says is resident on the printer.
I finally got sleep deprived enough that I figured out how to make the Mac send the fonts definition instream, so the problem is solved for me. I edited the file:
System Folder/Printer Descriptions/LaserWriter Plus v38.0
and removed the fonts from the list. I tried before doing this to the PPD file, which of course didn't work, it kept pulling in the info from the file above.The trick is to kill it at the source.
Ryan Thomas reminded us of this common problem.
"When you use NT to make available to PCs an AppleTalk printer but *do not* capture it, Mac users see the printer itself and the NT queue in the Chooser. (When you capture it, the printer does not broadcast itself --which is dangerous if your server goes down. And I'd rather have my Macs not use the NT queue anyway.)
"To have the NT queue not show up in the Chooser, but to still make it available to PC users, assign the SFM "Print Services for Macintosh" service a service account, other than SYSTEM, say "MacPrint" (as folks usually do). Then assign the privileges to the print queue such that MacPrint has "No Access" to the printer in question. Stop & Start the Print Services for Macintosh. Then that queue will not show up in the Mac Chooser, while others will continue to do so."
So, you might think, why not just just off MacPrint altogether? The key is " to make available to PCs." Although NT Server and NT Workstation can print to AppleTalk printers, Win 3.x/95/98 cannot without MacPrint running on NT Server.
John Parnaby sent us an alternative approach to identify the MacPrint spoolers:
"Give each printer and NT spool a name that begins with a particular character, thereby controlling the position of the Printers and Spools as they are displayed in the Chooser. We found this helpful.'Real' printers were all named (using a PostScript download) starting with a tilde ~. Spools were all named beginning with a plus symbol +.Thus the spools appeared at the top of the list, the printers at the bottom.
Gary Swick has another idea for dealing with AppleTalk printers that show up twice in the Mac Chooser -- once directly and a second time via NT Server. Using the NT SFM AppleTalk router, he's put the actual printers in one AppleTalk zone, and the NT spools of the printers in another.
This item moved to the NT Service Pack page.
John Wolf found an intermittent problem where certain files would cause Word for Macintosh to lock up when opening them from a mounted NT Server volume. Symantec verified that the cause was Norton antivirus 5.0.3. Fortunately, he found a solution:
"We use Norton Antivirus for Macintosh 5.0.3 and when opening Microsoft Word 98 files from an NT server, Word would occasionally lock up. If an admin logged in, he could open the file fine. It appears that NAV was trying to modify the hidden 'NAV Quickscan 5.0' file at the root level of the server volume and the user didn't have the priviledgesto do so. On a suggestion from Symantec, I removed the file and replaced it with a folder of the same name, and it appears to have done the trick!
"Other users with strange proplems opening files and applications from NT servers (or possibly any server) may want to look at replacing the NAV Quickscan 5.0 file with a folder and see if that helps."
Shane Anglin, Systems Administrator at CNN Interactive, sent us this tip.
"When rebooting a NT Server with Service Pack 3 or less, the NT Server may boot into a undesired Appletalk zone. (Microsoft recognizes this to be a problem, but has no solution for it yet.) To ensure a server boots into the correct zone, do exactly the following:
At Microsoft's Macworld Expo booth on January 7, 1999, MacWindows reader and contributor Nate Caplin showed Microsoft SFM specialists a bug in Windows NT 4.0 Services for Macintosh that Microsoft was not aware of. Caplin, a systems manager at Knight Ridder Tribune, reproduced the bug with a Mac and NT Server PC at the booth. The bug prevents you from deleting a file and folder from the server.
Microsoft says the bug does not occur in Windows 2000, because the problem is located in File Manager, which is not used for SFM administration in Windows 2000. There is currently no fix for NT 4.0.
The problem starts when a Mac user deletes a file from a mounted NT volume, but doesn't empty the trash. Next, an administrator removes the Mac volume while the Mac user is connected to it. The Mac user will get a Type 51 error message: "A device attached to the system is not functioning." From NT Server, the administrator can not delete this file.
DELETING THE FILES
Adam Adamov says he has a method of deleting these files:
"The files will be deleted after you repeatedly connect to the server, place the file from the server in Trash and delete it. If you are the member of group, your file, placed in Trash, will be saved in Network Trash of your group on Windows NT server, instead of in your Network Trash on Windows NT Server."
There are several known issues and conflicts that can cause Windows NT Server 4.0 to come to a crawl, with near 100 percent system usage shown in the Task Manager. Additional, there are networking problems where the server seems to be fine, but file transfers between Mac and NT Server are very slow.
To summarize, the slow server performance issues:
To summarize, the slow file transfer issues:
Other readers have reported other instances of NT slowdown. Web posted these on the NT Unsolved Mysteries page.
Here are the known problems and solutions. First the slow server issues, then the slow network problems:
1. Backing a very large SFM volume, related to Service Pack installation
Coworkers Joseph Haddon and David Dutt reported having trouble backing up a 70 GB Macintosh volume with MS Backup or the Computer Associate's ArcServe. After any backup, performance of the server slowed to a crawl. The only fix was to reboot the server.
Turn off Services for Macintosh and any other services before installing a Service Pack. Microsoft confirmed this problem with Dutt and Haddon.
2. Seagate Backup Exec software breaks Windows NT Server
John Wolf describes it this way:
"Our new problem is the server going to an absolute crawl intermittently. The task manager shows system usage to be pegged at >97%. We go and shut down tasks like Backup Exec 7.2, Mcaffee virus scan and SMS, and the server settles down again. Starting those same processes back up doesn't cause the problem to reoccur right away."
Michael Dexter reports:
The user pointed out that they were using Backup Exec NT 4, SP 2 and before suffers from this exact situation when using tape drives. In my case, it was with the built-in "backup" utility. The machine INDEED grinds to a virtually-unusable halt.
Seagate's Backup Exec software makes some changes to the Registry that causes the server slowdown. Microsoft describes it in Knowledge Base article Q187704 "Server Lockup Receiving Pop-up Messages with Backup Exec, " and recommends changing the Registry settings back.
Richard Pape, a Mac-Windows integrator at Allsysgo, descrives the Registry change:
Seagate isn't much help on this. We have made dozens of call to Seagate and they have done a lot, but haven't solved the problem. Microsoft takes aim at Seagate changing the Registry setting for the number of consecutively running Services. Seagate BU Exec installation program changes the "MaxRequest Threads=16" to "MaxRequest Threads=" Upgrading BU Exec 7.0 to 7.2 does not stop the problem, but changing the Registry settings back to default does.
However, Joshua Chessman adds this:
"Thanks for the info on BackupExec 7.0 and the registry setting. I've been fitting with that for quite some time now. I just did some checking and found that the current version of BackupExec 7.2 (build 1223) we are installing seems to not change the setting from 16. I just checked a freshly installed machine and found that the setting has not been changed."
Another known bug can cause similar NT Server slowdown symptoms. Tina Spisak describes it:
In regards to the server crawl. We were having the problem also on one of our servers. It turned out to be the LexMark Monitor, vers. 3.03. More information is available from Microsoft Knowledge Base article Q175893.
4. Problem with FINDFAST
Scott M. Silver also has a server slowdown problem:
"This happens sometimes when the app FINDFAST starts grinding away. I assume this is some disk indexing tool that makes finding by content fast. I don't know how to turn this off with a UI switch, but I just kill it in the Task Manager when my machines starts to churn."
David Bleuzet has the answer:
In the Control Panel, you're about to find an icon "Fast Finding" (or something similar in English; I have a French version of NT 4.0), so you can manage the indexing.
The slow file transfer problems
5. Check for mismatched duplex settings on switch and NIC, use of autosense
The duplex settings of the NIC in the Windows server and the switch should be the same. You'll have very slow file transfers and printing is one is set to 100/full duplex while the other is set to 100 MB half-duplex. Also to be avoided is setting the switch to force 100/full duplex while having the NIC set to autonegotiate, or autosense. (Dave Brown says "My new Ethernet motto is "autosense is *not* your friend.")
Jeff Lucia sent in this tip for checking to see if you have an Autosense mismatch:Ping the server from another Win NT workstation. Select "Run" from the Start menu, and then type in, "Ping x.x.x.x -t" (use the server address)..this continues to ping the server until you stop it. You should really not drop any packets here (one or two), but if your losing packets every other ping or in bunches, most likely your NIC or the Switch have negotiated a "half / full" relationship which will cause HUGE pauses and all sorts of traffic.
Lucia also discoved that upgrading an NT Service Pack switched his NIC from full duplex to autosensing:After we updated to Service Pack 4, out NIC card settings were defaulted back to "Auto". We have been running "Full" since the initial setup so I assume that NT Service Pack 4 reset it. We had NO issues before I updated so my word of caution is to always verify your NIC settings after a Service Pack update. According to the MIS group @ my clients, NT has some really bad habits with "Auto" turned on, and it doesn't just affect SFM. Their servers are manually set as well because of similar performance problems. They also had an issue with NT Service Pack 4 killing DHCP settings and resetting NIC's to "Auto".
A second issue was due to a crazy conflict with our Cisco Catalyst 3000 switches. For some reason, when we updated the firmware above version 1.13 we would see performance / stability issues copying files. Upgrading to a 5000 switch addressed the problem.
6. Use a separage NIC for the SFM MacsSeveral readers have reported solving slow SFM file transfers by using a separate NIC in the server for SFM:Our company originally had very poor performance using SFM file sharing with Windows NT 4. Our solution was to add another network card to the server and dedicate it to only AppleTalk protocol. The original NIC was left to handle all other protocols. We have not had any performance problems since. (Rich White)
By adding another 10/100 Ethernet card to my NT server and configuring it to "full duplex" mode, any large print jobs spooled by the server have more than doubled in transfer speed to any printer that has a 10/100 Ethernet card in it. I also connected the server's LAN cables to different Ethernet Switches. Not to the same Switch. Large print jobs are just flying off my NT server now. Where before the printers were waiting for the incoming files. (Marcus Reese)
7. Disable spanning tree on switch ports with Macs
John Wolf recommends:If you are putting Macs on switch ports, MAKE SURE to disable spanning tree on those ports. If you don't, faster Macs like G3's will fail to get an AppleTalk address on startup and give you a variety of oddball messages about your network now being available. Luckily I have a (mostly ;-) Mac friendly network admin, and he understood that spanning tree is useless for workstations and turned it off on the 700 odd ports that had it turned on.
John Wolf reports a problem with Seagate's Storage Migrator for Windows NT software. It interfers with Services for Macintosh. Wolf says:
"[It] will cause a 10-15 second pause for all Macs connected to a server that recalls a file from HSM. The only workaround I can see is to use DAVE on the Mac clients."
"This has uncovered some problems with the NT Server SFM (Services for Macintosh), and AppleShare client software. Because MAC services are seen as a common resource with serialized access, if a file open request takes seconds or minutes to complete for a single AppleShare client, threads serving other AppleShare clients can and do get blocked during the retrieval process."
"Until further notice, Seagate Software does not recommend the installation of the Storage Migrator products into a network environment that includes SFM and multiple AppleShare clients."
There are three known causes for the halting of the Services for Macintosh print server when Macs print to it:
1. The problem with LaserWriter 8.6 is described on the MacWindows Mac OS 8.5 page.
2. The problem with the Apple LaserWriter 16/600 PS is described in the Microsoft Knowledge Base article Q152553. It occurs with Macs running Open Transport (which is most Macs today). Eric Marthinsen describes the problem:
"...I set up all of our Mac clients to use the LaserWriter 8.5.1 driver. This still didn't solve the problem experienced with the LaserWriter 8.6 driver. After a period of flawless print spooling, the service would just stop. One difference though was that there were no longer "semaphore timeout" errors in the event log. So, I then installed the AdobePS 8.5.1 drivers and reconfigured our clients to use those drivers. This threw us even further from being able to print efficiently. Now, the service would just hang in the "spooling" state.... We are running Mac OS 8.5.1 and NT Server 4.0 SP4."
3. The old bug in NT 3.5.1 is described in Knowledge Base article Q 140506. It was fixed with NT 3.5.1 Service Pack 4.
Several readers have reported a problem with the driver for 3Com's Gigabit Ethernet NICs (such as the 3C985B-SX) when installed in Windows NT servers. The driver prevents Services for Macintosh from functioning. MS's article Q172152 says "The NIC driver may not contain a section for media type descriptor that is required for Services for Macintosh and the AppleTalk protocol". 3Com says it will fix the problem in later driver release, but can't say when that will be.
John DeMillion came up with a workaround in the form of a Registry edit that fixes the problem:
1. Install the NIC and drivers. ...trying to configure SFM from the Network control panel will result in the message "Unable to read the Appletalk Registry Section".
2. Refer to Microsoft Knowledge Base article ID Q102996, "REG: Network Services Entries, Part 2", which describes the various SFM Registry entries.
3. Manually add or change registry entries as needed for the new NIC as described in sections "APPLETALK PARAMETER ENTRIES", "ADAPTER CARD ENTRIES FOR APPLETALK", and "MACFILE PARAMETERS ENTRIES". A few already exist but need to be changed, and others should be added manually.
4. There's a documentation error for MacFile key "ServerOptions". It says that the default is bits 1,2,3 set to "on" but that's not true. The default is bits 1 and 2 on, but 3 is off, which disallows password saving by users. If you want this feature on, change all three bits to "on".
Note that any changes will not take effect until you restart NT.
Can't save a file twice in a row on SFM.
Erik Wessel reports that under certain circumstances, he can't re-save a file to an NT SFM volume for a minute or so:
I've been having a problem for months now, and it's really getting very annoying. Whenever I am working on any kind of text file which will be accessed from a web site, and test that file through the IIS web server, I can't re-save the file on the SFM volume from my Mac for a random period of time afterwards, from about 10 seconds to at least a minute.
Morten Krogh Andersen found the solution:
This problem is caused by IIS. It caches file handles for at minute, to increase performance. Notepad and Visual Studio can work around this, but most other editors cannot. The solution is a registry edit, described in Microsoft KB article Q191742.
Microsoft KnowledgeBase article Q136300 reports of the NT Event Viewer error IDs 12053 and 12054 created when a Services for Macintosh connection is lost. (Reader Paul Sonntag says the Macs are forced to disconnect.) The article describes how to reproduce the problem. Reader Paul Sonntag describes some of the symptoms:
There seems to be a variety of symptoms from server slow downs to lockouts to crashes... It doesn't seem to matter which SP is running on NT or which MacOS is running on the Mac.
The only fix Microsoft offers is to "make sure you close all files and connections to the computer running Windows NT Server before you shutdown your Macintosh client."
Peter Dodge adds this information:
These [error IDs] are not symptoms of the errors themselves, rather, they are likely to be proximal causes of the errors being generated.
I have seen these "errors" on just about every NT with Mac clients as they are generated anytime a Mac is restarted without dismounting NT shared volumes. Although the event log messages are flagged as errors, they should more accurately be flagged as warnings or informational messages. They result from a connection timeout and do not affect operation of the network.
In short, they can be ignored for the most part (except as a tool in troubleshooting network problems).
You may be able to ignore the warnings, but this doesn't keep the Macs from being forcible disconnected. Paul Sonntag noticed that he doesn't have this problem on his G3 Macs, but does on a pre-G3 model. (All are running Mac OS 8.6.)
There is a known conflict with the Apple DVD player and server volumes set to automatically mount at startup. It occrus with any AppleShare-compatible server volume. With NT, if you have an NT volume set to mount as a registered user (not guest) at startup, the Apple DVD player will claim that you don't have the CD/DVD driver loaded. Apple recommends turning off auto-mounting (in the Chooser), and using a alias for easier mouting.
See Apple TIL 30970.
(Our thanks to Ed Hagihara and John Wolf.)
Derek Dolan noticed that NT Service Pack 5 fixes a bug with Services for Macintosh printing:
I noticed that your Mac/NT tips section didn't cover the bug in SP4's atalk.sys listed in [Knowledge Base article] Q195822. This problem pops up when you have a large number of SFM printers on your NT box.
It causes a ton of semaphore timeout errors in the event log, and then the PrintSFM service crashes and you have to bounce the server. We had a hell of a time figuring this one out here, so any other large print site might want to know about this little monster. FYI: It is fixed in SP5.
Installing BackOffice and Services for Macintosh.
Stephen Baxter noticed that installing BackOffice and Services for Macintosh on an NT server requires a redundant approach. The problem is that the BackOffice installer also installs Service Pack 4. The installer also requires that Services for Macintosh be installed after BackOffice. Unfortunately, this leaves SFM installed with older SFM files than are in SP4. Installing SP4 a second time upgrades SFM properly. Baxter adds some details about his setup:
To be precise it's "BackOffice Small Business Server". It includes NT Server, IIS, Exchange, SQL Server and various other bits and pieces. IIRC, the installer runs through and installs the lot automatically, including all the service packs. Fine for "standard" users, but if you then add features later you have to install SP4 again to prevent this nasty MacFile crash (which for us didn't even give a blue screen, it just hung the server utterly).
Mac users creating icon files on NT that are immovable from Windows clients.
Robin Taylor is a Windows user who accesses Windows NT Servers. So do Mac users running DAVE, which seems to be causing a problem:
Sometimes (not always) when a Mac user modifies files, a file called Icon becomes visible in that folder in my Windows Explorer. I cannot move it or delete it, and it disrupts my attempts to move an entire folder at once (I have to select each single item to avoid selecting the Icon).
When Mac folders have custom icons, they contain an invisible file called "icon." However, this doesn't prevent Mac users from moving the folders. The problem is that the file name of file icon contains a charactor which is illegal in Windows. Patrick Peccatte explains and recommends a fix:
Hidden ICON_ files are created by Services For Macintosh to store the modified icon of a folder when this icon as been modified by a Macintosh. The code of the icon is stored in an alternate stream of the file _ICON called AFP_Resource and the stream AFP_AfpInfo contains Type=icon, Creator=MACS. The standard stream ICON_ which is the only visible from a Windows clients has a nul size.
Due to a Unicode special character at the end of the name ICON_, Windows 95/98 cannot manipulate this kind of file, but Windows NT (both server and workstation) can uncheck the hidden flag and delete them (at least in SP4 or upper): this will remove the particular Macintosh icon set on the folder.
Carl Ketterling of Thursby Software Systems (makers of DAVE) suggests that PC users can use wildcard characters from a DOS shell to move or delete the file:
The reason these [Icon_] files are difficult to manipulate is that the name ends with an unprintable character. Moving or deleting this file from Windows NT poses no problems at all. Windows 95/98 users must be a bit more creative in their access to this file -- possibly by using wildcard characters from a DOS shell (i.e. "del icon?" or "del icon~1").
Laurence suggests using a utility such as File Buddy to delete the invisible (to the Mac user) icon files.
Adam Sonzogni recommends that PC users set Windows to not view hidden files:
[This] has worked for some of my users. He can do this by going into "my computer" and doing the following.
Win NT 4: Click View --> Pptions select the view tab and make sure that you are not showing hidden or system files
Win 98: View --> Folder Options select the View tab and under Hidden Files you will have 3 choices: "No hidden files," "No hidden or system files," and "Show all." You should select the "No system files" option.
NT Server with SFM hanging and blue screening
December 14, 1999 -- Microsoft Knowledge Base article Q242896 discusses a bug in NT Services for Macintosh that corrupts the NT kernel, causing the NT Server to hang. Microsoft has a hotfix available, but only by calling Microsoft Product Support Services.
Chris Lyttle discovered the hotfix when he was tracking down a problem he was having. Lyttle believes the hotfix may solve some of the problems listed on our NT Unsolved Mysteries page:
I have discovered an issue with SFM that took me days, and more than a few rebuilds of my server to track down. While setting up 2 new NT Servers with SFM (to replace our old file servers) we were getting hangs and blue screens whenever Mac clients tried opening files on the server. We finally tracked it down to Open File Manager by St. Bernard Software, though I believe it could also affect other software of this nature. Their tech bulletin describes the problem and gives a MS article (Q242896) that describes it. The hard part was that you had to call MS for the hotfix. In reading through some of the recent problems in NT Unsolved Mysteries I think that some of the described ones could be related to this problem and fix.
Until recently, Windows NT server didn't offer BootP, a thing Thomas Dassel needed for his older Macs. One workaround is SonicDNS and SonicDHCP for Sonic Systems. It worked fine with the Macs, but the Windows laptops moving around the company won't accept a new IP number offered by a Sonic DHCP Server if they previously received an IP number from an NT Server.
The solution: Use the undocumented program Winipcfg.exe (installed together with the TCP/IP Protocol) to force the DHCP client to release it's old IP number.
Another problem is that the Windows IP stack doesn't release the IP number when put to sleep mode (as do Macs). So depending on the lease time, you may run out of IP numbers, because even if the PC has left your zone, the address is still attached to the computer. This tip from Thomas Dassel.
Windows NT Server recently began supporting BootP clients in the DHCP Server. Here is the Readme file from Windows NT Service Pack 3 (12/97):
"This version of Microsoft DHCP Server supports BOOTP clients. BOOTP addresses currently must be reserved in advance by creating an IP address reservation. Future versions of Microsoft DHCP Server will be capable of leasing dynamic addresses to BOOTP clients.BOOTP clients that do not specify the parameter request list option (55) can still retrieve the following options from this release of Microsoft DHCP Server:1 Subnet Mask 3 Router 5 Name Server 12 Host Name 15 Domain Name 44 NetBIOS over TCP/IP Name Server 45 NetBIOS over TCP/IP Datagram Distribution Server 46 NetBIOS over TCP/IP Node Type 47 NetBIOS over TCP/IP Scope 48 X Window System Font Server 49 X Window System Display Manager 69 SMTP Server 70 POP3 Server 9 LPR Server 17 Root Path 42 NTP Servers 4 Time ServerIn order to obtain other options, the client must specify option 55 in the BOOTP request. DHCP Server will return the options in the order listed above. DHCP Server will return as many options as will fit in response packet. "
MacWindows Tutorials contains instructions on setting the IP address reservation.
Thanks to Richard Birchall for sending this information.
Rick Lawsha solved a long-time problem with Mac clients and a DHCP server on Windows NT. Turns out neither Mac nor NT was the problem, but in a CISCO router. A "clear arp" command was what was needed:
We have just solved a long standing problem on our network of several hundred clients. The server is NT 4 and the clients are a mixture of Macs and Windows machines.
The problem: DHCP would pass out IP addresses and the address of the DNS server just fine. Most clients could get on the Internet with no problem.
Randomly, clients could not get out to the Internet. DHCP was working, but clients could not 'get to' the DNS server even though they new the correct IP address. Through trial and error we found that if we manually 'pinged' devices up to the DNS server (PIX box, router and DNS server) we could get it to work. This was successful most of the time.
The solution: Our Cisco PIX box and our CISCO router had drastically different ARP [address resolution protocol] table expire times. The router was keeping it's ARP table much longer than the PIX box. DHCP was passing out new IP's and the router wasn't updating it's tables. The result was that the network thought duplicate IP address were around. We did a 'clear arp' and we changed both the router and the PIX box to have an arp timeout of 600.
Seems to have solved our problems.
Apple's Font Manager Update slows Quark 4.1-NT networking.
February 24, 2000 This tip from Eric Anondson :
Not long ago there was mention from a reader about trouble with Quark Xpress network slowness. I just came onto a new contract job where this was a major complaint. The company had hired a consultant for over $4,000 to come in and diagnose the problem and offer a solution. They spent 4 days in the server rooms seriously analyzing the company's network.
They came back and offered a solution to drop the NT server with SFM and go to a Xinet solution on NT or even better on Unix. They offered to test this setup for a simple $12,000...This didn't sound right so I did my own research and after stumbling through your site came upon a tiny blurb.
Anondson read a reader report that said a problem with Quark and MacServerIP was actually about fonts and other issues. He decide to experiment, discovered that in a setup with Quark Xpress, and MacOS 8.6 w/ Font Manager Update, Quark would slow down dramatically. He continues:
By replacing Font Manager Update with DiamondSoft's Font Fixer for 8.6 the symptoms disappeared. I asked one of the users to demonstrate this slowness. (The consultants never once checked the client setup.) There it was, by clicking from one tool to another Quark would pause for 10 to maybe 60 seconds. Moving their document to their hard drive caused no such pausing. Not normal.
I swapped out Apple's Font Manager Update for Font Fixer for 8.6 and voila... no slowness. I have 30 Mac users jumping for joy and that was all I did. Two Quark users asked me if I did something that made Quark XPress 4.1 go faster, because it works like it used to when they had Quark 3.3. (Just before I got here they finally migrated from 3.3x to 4.1 and from MacOS 8.1 to 8.6)
Windows 95 users dialing into a Mac-based FileMaker Pro database via the IPX protocol have not been able to see hosted files on the LAN. FileMaker Pro Server or FileMaker Pro will not route IPX packets between network adapters, in this case a network adapter and a dial-up adapter, which each have a their own own IPX network address number. Claris has previously said that if you want simultaneously LAN and Dial-Up Networking while using the IPX protocol on the LAN, your only option was to use FileMaker Pro Server for Windows NT.
Steven Blackwell discovered a clever work-around to this FileMaker Pro limitation by not dialing into the File Maker Pro Server at all. Instead, the PCs use Windows 95 Dial-Up Networking to dial into a PPP server that supports IPX and TCP/IP, such as the Sonic System's QuickStream Pro. When connected to a network this way, multiple users can see FileMaker Pro files being distributed in either Apple Talk, IPX, or TCP/IP protocols. FileMaker Pro Server supports all three simultaneously. Macs have had simultaneous remote access to FileMaker via PPP using a PPP client or Apple Remote Access ARA 3.0., but Apple Remote Access for Windows only allows one user at a time. (Remote PCs can also access open peer-to-peer FileMaker Pro files, but the host and the remote user will both have to be using the same protocol, IPX, TCP/IP, or AppleTalk in the case of a Macs.)
Steven Blackwell is President of Management Counseling Services of Alexandria, Virginia. For further information, you can email him him or see his personal Web site or his FileMaker 4 demo site.
The cause of this problem is actually not Windows NT Server, thought it may seem like it. We have two solutions here, the first dealing with switches, the second with HP firmware.
(NOTE: there is a similar-sounding issue with Windows 2000 SP1 SFM Server disappears from Chooser)
Printers or other AppleTalk devices temporarily disappear from the Chooser of users' Macs. The devices may reappear temporarily.
The solution is to disable the Spanning Tree Protocol on an Ethernet bridge or switch port, as described in Apple Tech Info Library article 30922. You can also switch it to fast convergence (known as "portfast" on Cisco switches).
Michael Perbix adds to this:
I can confirm that the PORTFAST option being enabled does solve most problems with Apple networking on Cisco Equipment. There have been a few issues with 6500/5500 using built in 10 Base-T comm slot Ethernet hardware (from factory) with auto negotiation on Cisco hardware. We had to force the network ports to 10 half to get it to work. Adding a third Party PCI driver also helped, and the problem does not seem to exist on newer Macintosh hardware.
September 15, 2000
Warren Smart adds this note:
We had just installed a new Cisco switch and straight away had problems with the Apple Mac's not seeing the zone on the NT4 Server. We tried various different solutions and did finally trace it to the spanning tree or porfast setting's on the Cisco switch. We contacted Cisco and was told that we would have to turn off the spanning tree on all 48 ports in the switch one by one, which we did, all things now seem to be stable, the Mac's can see the zone from the NT4 Server and use AppleTalk protocol.
It might be of interest to know that the switches all seem to be configured with the spanning tree set to "on" as a factory default fine if you use PC's but it would have saved us a lot of work if they had asked us if we where using a mixed network with Mac's.
Solution No. 2
January 22, 2001 --
John Wolf found a fix in an HP firmware update to JetDirect Ethernet:
The posted solution was to turn off Spanning Tree. We have already done that. Spanning tree is off for every port except the ones that actually have routers/switches connected to them. We did that to fix the issues with the G3 and G4 machines that couldn't get AppleTalk addresses on boot. It doesn't fix the printer problem though.
I finally found the solution to all of my printers dropping out of the Chooser for 1-2 minutes when one of them is power cycled.
HP quietly put a fix in the 7.x and later firmware that fixes this. I flashed all our JetDirect Ethernet interfaces up to 8.32, and the problem is gone! As a note to others trying to do this: The older 2550 and 2552 JetDirect cards can be flashed to 8.32, but it is a 2 step process. Flash them to 5.05, then again to 8.32. This process must be done from a PC using Download Manager. From what I have read, once you reach a certain version, you can use the web based WebJetAdmin, probably from a Mac as well.
January 22, 2001
When AppleTalk is not active, to access a Windows 2000 Server a Mac user must enter the server IP address. But, I haven't seen anyone mention that you can also use the NetBIOS name. Thus, if my server were named SERVER1 with an IP of 192.168.1.50, I could access it using the IP address (not user friendly) or I could access it using the SERVER1 name (much more user friendly). I haven't tested this when using the client is on a different subnet.
August 1, 2001 --Jim Smith has a strange problem where Mac files on an NT SFM volume show up many times. To us, it sounds like a problem with the index files, but Smith has restarted the server, which should rebuild the index:
We are running an NT 4.0 SP 6a server for a 95% Mac network. This server has been rock solid without the first problem for almost a year. We are now having a strange problem when searching from a Mac (PC search is fine): the same files show up many (sometimes 50+) times. It started out slow--we would see the same file showing up two or three times in the search results. Now it is becoming a problem. I have restarted many times, run checkdisk a few times, have checked the event viewer (only to see that the desktop database has been rebuilt several times). It does not get better. What's really interesting about this is that it seems only .jpg files are affected. I have tried removing the files that show up multiple times from the server (copied to local Mac, ran Norton, found nothing). Searching when these files are gone yields normal results. As soon as I put them back it happens again (even if I create a new volume and copy back). As far as I know, these files are never used by a PC.
August 3, 2001 -- Paul Hart verified the problem:
We have had the same problem, and have yet to find a solution to this very annoying problem, one way that seems to ease this bug is creating a new share and moving a portion of files into that share, it seems to be when there is large numbers of files.
Patrick Peccatte of SoftExperience (a developer of NT-Mac utilities), recognized the problem and sent us a solution:
As you say, Jim Smith's multiple images problem is very probably a problem with index streams of Macintosh volumes. For each Mac volume, SFM creates an alternate stream called AFP_IdIndex (i.e. MyVol:AFP_IdIndex for a Mac volume called MyVol) which contains image index of all files and folders in the volume. But this index stream is *not* recreated when SFM restarts or when the server reboots. It is only updated by new or modified files/folders when SFM starts and stops. During indexation process, non paginated memory usage greatly increases but it is temporary. Updating index streams by SFM is automatic but probably not bug free. Many users experienced problems such as Jim's one when SFM has running during a long time. So from my point of view it is necessary to regenerate indexes time to time...
If an index stream is corrupted or not exists, a new index stream is generated when SFM starts again. This is the more drastic but efficient way to repair corrupted indexes:
- Macintosh files are not altered because resource forks and Finder information are stored in their own streams, not in volume streams.
- Mac files in network Recycle Bin are lost because hidden folder 'Network Trash Folder' is removed when a Macintosh volume sharing is removed.
- Stream AFP_IdIndex is deleted when a Macintosh volume sharing is removed. It is recreated when SFM restarts because you have redefined the same Mac volume over the same Windows directory. But the reindexation process over a full volume can spent a long time and consume great amount of non paginated memory (be aware for the other services on the same server and alert your users that the regenerated volumes can be not accessible during a long time).
This information is from Peccatte's French-language page "Windows NT et les fichiers Macintosh", in a section called "Les streams associés aux volumes SFM."
These items have been moved to the MacWindows NetWare and Macintosh Issues page.
||Parallels Desktop 5.0 for Mac Run all the applications you need without switching between Windows and Mac OS X! Better integration of Mac and Windows. Supports Windows 7 Aero, with graphics peformance up to 7 times greater than before. Supports Apple trackpad gestures, new Crystal mode, speech recognition, good notebook battery life, and more.|
Other Tips Pages
| Disk Tips | Windows-on-Mac Tips | Peer-to-Peer Tips| keyboard/monitor sharing |
| Main Tips Page |
| MacWindows Home |