Service Pack 4 was one of the more major service pack releases. It fixed a lot of bugs, but also seemed to generate more problems with Macintosh clients than did the subsequent Service Pack 5 and Service Pack 6.
If you are experiencing problems that you can trace to a Service Pack, please let us know.
Service Pack 4 links:
Service Pack 5:
Service Pack 6:
Service Pack 6a:
Service Pack 6a was the final Service Pack for Windows NT 4.0, released in December of 1999. Users who have SP6 installed can upgrade to SP6a via a hotfix, available for x86 and Alpha processors. Service Pack 6a addresses a problem with Lotus Notes and other Winsock based applications that prevents connecting to the server. There are also some Y2K fixes.
(For more general tips and information on Windows NT Server and Macs, see the MacWindows Server Tips page and MacWindows NT Unsolved Mysteries page.)
In October 1998, Microsoft released Windows NT 4.0 Service Pack 4. You can download it from the Microsoft FTP site or from the Microsoft web site. Microsoft Knowledge Base article Q150734 has a complete list of the all the bugs fixed in SP4. There's also a rather long SP4 readme file at the MS FTP site, and a "what's new" web page.
Service Pack 4 includes 17 bugs fixed in Services for Macintosh, including the jumping icon problem..It has been over a year since Service Pack 3 has been released, and Microsoft has released dozens of unsupported "hot fixes" since then. (The most recent Hotfix addressed 10 problems.) We don't know if Service Pack 4 fixes the "jumping alias" problem caused by the last hot fix. If you know the answer to that, please let us know.
Other enhancements in SP4 include security fixes and support of Windows Media Technologies (Netshow Services and Windows Media Player). SP4 also seems to have caused some problems, which we've collected on this page.
Here are the Macintosh-specific fixes in SP4 (The Q numbers are Microsoft Knowledge Base articles that describe the problem):
Q157032 Services for Macintosh May Cause STOP 0x0A During High
Q158396 Explorer Hangs When Creating a New Folder On a MAC Volume
Q164023 Fix for Gethostbyname() IP Address Order on Local Multihomed Mac
Q171989 Windows NT Services for Macintosh May Not Start in Desired Zone
Q172003 Macintosh Change Password Fails on Down Trusted Domain PDC
Q172511 Stop 0x0000000A w/ Services for Macintosh & McAfee Anti-Virus
Q177644 Commenting Macintosh File Changes Date and Time Stamp
Q178364 Macintosh Clients See Files on WinNT Server Constantly Moving
Q180716 SFM Fails to Accept Associations with Two-Character Extensions
Q180717 SFM: File Date and Time Stamp Change with Get Info
Q180718 SFM: Disconnect Macintosh Clients before Dismounting Volume
Q184229 Copying Files to a Macintosh Volume Changes Date and Time Stamp
Q191285 Services for Macintosh Index Corruption on Large Volumes
Q161644 STOP 0x0000000A Sfmsrv.sys When Copying File to Mac Volume
Q162189 Macintosh Clients May Hang Temporarily with Multiple Mac Volumes
Q164138 Files in Macintosh Volume Disappear from Macintosh Clients
Q158796 Macintosh Clients Connected to WinNT Server Appear to Hang
Virtual PC incompatible with NT SP4. Connectix has confirmed a problem that prevents users from logging on to Windows NT with Service Pack 4 installed. Reinstalling doesn't help. John Malm of Connectix Quality Assurance wrote:
"At this time we recommend customers NOT install this service pack. We are investigating the cause and hope to find a solution. At this time we don't know if it is Virtual PC or the service pack that is causing the problem.
"If a user has valuable data and has already installed the Service Pack 4, mount the drive image as the D drive and copy the data to the new C drive (that doesn't contain Service Pack 4)."
Reader David Moneypenny first reported the problem to us. His description of the problem is similar to what other readers have reported:
"When I install the 128-bit SP4, I can't log in after the reboot. I get an error that says the NetLogon Service isn't running. The message is correct, as far as it goes. It is not running because I can't run it--I'm on a standalone box that is a member of a Workgroup, not a Domain. I've redone the whole deal several times, with the same results each time."
Moneypenny had been running Windows NT 4.0 Workstation SP3 on Virtual PC on a G3 266 MiniTower.
We will let you know if Connectix comes up with a solution.
NT SP4 and FileMaker Pro Server. Daniel Waldburger of Switzerland reports a problem with Service Pack 4 and FileMaker Pro 3 Server.
"The clients (running a FileMaker runtime or the complete version) don't see the local host; we have to type the IP address of the FM server to log on."
Waldburger discovered he could fix the problem by removing Service Pack 4 and running NT 4.0 with Service Pack 3.0, the last SFM fixes from Microsoft (sfmfixi.exe). The FileMaker host then becomes visible again.
NOTE: Microsoft has acknowledged this as a problem. Service Pack 4 cuts the UDP-signal send from Filemaker for contacting the Server. Fortunately, FileMaker Pro Server NT 3.0v4 Updater fixes the problem.
However, on June 8, Francois Morin reported that the problem reappears with NT Service Pack 5:
"Since I Installed SP5 on a Windows NT 4.0 Server, the old problem with visibility of FileMaker Pro Server (3.0v4) databases come back again. All FileMaker clients (Mac or PC) can't see the server on local network. I must specify the IP address on the server on each machine (lot of fun with 100 computers). The last version of FileMaker Pro for Windows (4.1) seem to have a bug with the retention of IP address of server, even if I check option: Remember this IP address and I type the IP address of the server. If a close FileMaker 4.1 and reopen it, the IP address is not in the list (but the second attempt to add the IP address is always successful)."
NT SP4 breaks OPI image server links. Mark Clark reports a problem with InterSep by ArchType (now Bitstream), and OPI server used to swap in high resolution images in PageMaker 6.5 (Mac) and Quark XPress. (Low-resolution images are used before printing.) Clark uses an AlphaServer 2000 4/275 with 256 MB of RAM. The problem:
"The installation of Service Pack 4 caused all links in PageMaker documents (and some Quark documents also) to be lost. Restoring volumes from backup had no effect. Quark finds the links with a little help. All PageMaker links must be recreated from scratch."
NT SP4 doesn't fix known printing problem. Mark Clark also points out that Service Pack 4 failed to fix a known printing problem (described in Microsoft Knowledge Base article Q147347) that generates an error message saying that SPOOLSS.EXE has failed during a print job. For Clark, this happens 2 to 10 times a day. He always follows Microsoft's recommendation of throwing away temporary spool files (.SHD and .SPL files ) and restarting the spooler.
Shared volumes become unshared.Bruce Bayne has this problem:
"I recently loaded SP4 on my office server and have found that when the server is shut down and restarted the volumes that were Mac shares are no longer shared. Going into File Manager and resharing them solves the problem, but if the server is shut down again the shares go away."
January 3, 2000 --
Andrew Jacobs reports the same problem:
I'm having the same trouble that Bruce Bayne was having with his NT server running SFM. Yesterday, I installed SP5 onto our NT server, restarted, and all of my SFM shares were gone. I set them back up successfully and they are completely operational until I restart, at which point they go away.
This is a vanilla install except for enabling the SFM.
Is there any fix for this or has it been isolated at all? Running with SP3 w/ the SFM hotfix it's fine. I had this same trouble 8 months ago when I tried to upgrade it so SP4. Should I try SP6a?.
I tried your suggestion with no success. The share was at the root level (f:\macvol) so I moved it to f:\directory\macvol, reshared it and experiences the same results.
General Installation Problems. A reader (who didn't wish his name to be used) had problems installing Service Pack 4:
"I had disastrous results w/ SP4 on an NT Enterprise Server. Thank God it was a test machine... Not completely sure of the exact sequence of events (and I'm NOT willing to try it again unless I have a spare week or two), but I believe this is what I did:
- Was currently running SP3, IIS3, a non-MS FTP deamon. All was fine.
- I installed NT Option Pack per directions (quite complex and convoluted)
- All was still OKI
- Installed SP4... all hell broke loose. Services failed to start, were unstartable manually, frequent blue screens with rolling information, auto-restart would not work.
- Tried uninstalling SP4 with even worse results.
Finally ended up wiping the disk by booting from a DOS disk, fdisking my drive, reformatting the drive and reinstalling everything BUT SP4 and have been stable since.
Too bad MS doesn't have a "unified" NT Server CD available with all the current and compatible pieces included. On the other hand, this is what keeps me in business and my family fed."
However, Hood Gardner points out that Windows NT 4 Service Pack 4 makes some irreversible changes to the security structure of the system it's applied too. Microsoft Knowledge Base article Q196603 describes some of the changes and mentions that "previous versions of certain files cannot access Windows NT system security information after Service Pack 4 is applied." The article describes how to remove Service Pack 4 if needed.
Miramar posts PC MacLAN patch for Win NT 4 Service Pack 4. November 23 -- Miramar Systems has an NT Service Pack 4 patch for its PC MacLAN AppleTalk software for Windows NT for users who want to install Microsoft's NT Service Pack 4.
Installing NT 4 Service Pack 4 and PC MacLAN. December 28, 1998 -- A Miramar Technical Note advises that Service Pack 4 must be installed on the server before installing PC MacLAN. With SP4 installed, you can then install the most current version of PC MacLAN and the ATPP_sp4.exe patch, which makes PC MacLAN and SP4 compatible. Installing SP 4 to a machine already running PC MACLAN will cause the machine to hang.
NT Service Pack 4 and Omnis database apps. November 23 -- Alain Stouder sends the following:
"We experienced some problems with our NT4 users who installed Service Pack 4, they couldn't execute our Omnis-based applications properly while Macintosh and Windows 95/98/NT4 SP3 users were not experiencing this problem. Omnis Software created a fix for this."
128-bit version NT Service Pack 4 crashes with SFM. December 17, 1998 -- Reader and network administrator Sunny Le reports that the 128-bit version of NT Server 4.0 Service Pack 4 can crash under some conditions when Macs to file transfers to Services for Macintosh volumes.
"We encountered a critical problem while performing file transfers across our Macintosh/NT4 environment using the 128-bit version of Service Pack 4. It appears that the 128-bit security feature of SP4 results in tremendous overhead while performing file transfers from Macintosh computers to shared NT volumes. This causes the NT computer to terminate Services for Macintosh and either crash (blue screen) or reboot. None of the Macintoshes running OS 8.5 and 7.6.1 do not require rebooting, however.Downgrading the NT server to the 40-bit version of Service Pack 4 allows us to transfer files without any problems."
Le said he saw the same happen (128-bit SP4 doesn't work, but 40-bit SP4 does) with 160 MB RAM in the server and with 64 MB RAM.
Windows NT 4 w/SP4 128-bit version.
Macintosh Power PC w/OS 8.5
Macintosh w/OS 7.6.1
Disappearing files. February 4, 1999 -- Gary Swick had a problem of some files disappearing when he installed Service Pack 4 on his NT servers. Turns out the problem wasn't NT4, but a corrupted index file.
"We've got a couple of NT servers, IBM 325s running Microsoft cluster server, with a big RAID attached to them. They've been updated to Service Pack 4, NT4.
"Today I found that I couldn't see any files on the Macintosh client that were written to them by a PC. It's the exact same file path for the Mac volume and the NT share. We didn't have this problem with Service Pack 3. I suspect it's a configuration problem, and not directly related to Service Pack 4, but it's still a mystery."
"Turns out we had a corrupt index file. We deleted the Mac volume and recreated it, which forced it to create a new index file. That fixed the problem.
"We've had some problems with those servers, specifically with the Adaptec SCSI connectors and the Artecon Raid controllers. When the Raid controllers go out, it takes out Mac File Services, and we've had to stop and restart it. I think one of the times we did that the index files became corrupt.
"The interesting part of this is we never saw any problems reading or writing files from the Mac when Mac File Services was running. It was only when we started looking for files not written through AppleTalk that we noticed the problem."
Service Pack 4 and large files. February 5, 1999 -- Mike Colgate reports:
"Read the article on the problems with MS Service pak 4.x and Mac's. We were having fits trying to get large files on the server from the Mac's. The big blue death was striking every time. We removed Service Pak 4 and....everything is working great."
Problems with find file. February 5, 1999 -- Our Server Tips page shows how to prevent Macs from crashing during a find file by disabling catsearch on the server, but Siraaj Rashada reports that their server is crashing with SP4:
"Our NT admin upgraded to SP4 over the weekend and the find file hangs and server crashes have been so frequent that productivity has significantly decreased. Is there any thing else he should do besides the disabling the catsearch=1?"
SFM Stops responding to Macs. February 18, 1999 -- Rob Ward reports a problem with NT Service Pack 4 where Services for Macintosh stops responding after a few hours of operation. The problem goes away when he back-tracks to Service Pack 2, and returns upon reinstallation of SP4. He's rebuilt the Mac volumes to no avail, and says he's seen the problem mentioned at other places on the Internet:
"I have an NT4 server with an 8gb compressed Mac volume on a RAID 5 array using a Dell PERC Raid controller. The server is also my PDC. After installing SP4, SFM will stop responding after a few hours of operation. We have to stop the Mac file server service and stop the AppleTalk device, then restart the File services. After that the Macs can access the volumes for a few more hours before the server kicks them off and we have to shut down the services and restart them again. The Event View never shows any errors. The Macs are running OS 8.1 and one is running 8.51.
"We have tried deleting the volumes and recreating them with no luck. I have also tried uninstalling SFM and reinstall from my NTS SP2 distribution CD and that will get SFM going again... at least until I re-apply SP4. I have browsed the MS newsgroup server and have found one or 2 others with the exact same problem. Several have reported the problem to MS but have not gotten any fixes from MS yet.
"Since the problem seems to be sporadic I am trying to find the commonalties. I have a Dell PE2300, with 128mb RAM, and 18gb RAID array (8gb is partitioned for SFM and is a compressed volume) It is our PDC and our file server (with about 60 clients). I only have 5 Mac users accessing the server the rest are PCs or Windows Terminal Server Users. The only other service the server is running is WINS."
There is a known conflict between Windows NT Sevice Pack 4 the Intel EtherExpress 8/16 that prevents Mac clients from accessing SFM files. It's described in Microsoft Knowledge Base article Q216878. Microsoft says that "Modifications made to Ndis.sys after SP3 broke functionality in Windows NT Server 4.0, which ignored Apple Macintosh broadcasts."
Microsoft has a fix for Ndis.sys, but has not posted it. You need to call Microsoft to get it. Going back to Service Pack 3 will also fix the problem
Thanks to Brian Mark for bringing this to our attention.
NT Workstations get odd message with SFM
April 1, 1999. Erik.Schils writes:
Maybe this is usefull for others so here's my solved mystery. After upgrading our NTworkstations to SP4 they all got a mesage when users logged into the domain that their local profile was newer then the one on the server...
Not a big problem but annoying. I tried everything. All servers had SP4, reinstalled workstations, ...
After 3 weeks I found it: I stopped the services for Mac on the server and the mesage disappeared on the NTworkstations. I turned the SFM back on and got back the profile message.
I move the profile directory to a non-mac share. Mesage disappeared.
On April 2, Schils wrote to clarify:
I think my previous mail was not very clear. Sorry for that. Stopping and starting SFM does NOT help. Stopping the SFM removes indeed that annoying 'Your local profile is newer than ....' -message. But this is no solution because you need the SFM. That's why I moved the NTprofile to a share that was not a Macvolume. This solved the problem.
Therefore I think that the problem only occurs when your NTprofile is stored on a Mac-share on the server. It seems that the files on a Macshare are treated differently than those on a normal NTshare. Maybe they get a different time-stamp. Moving it to a standard NTshare was the solution to this mystery. Maybe the files on a Macshare get a timestamp without the seconds? Does anyone have more experience with the time-stamp handling of SFM? This could be the reason why the profile on the server will always be older than the local one.
TIP: Problem and solution with NT SP4 Y2k installation.
June 3, 1999 -- Paul James Brain, a systems integrator in Dublin, Ireland, had problems installing Windows NT Service Pack 4 Y2K (SP4 Y2K.exe). The problems disappeared only when he installed ntsp4i.exe after SP4Y2k.exe.:
As a reseller that specializes in supplying Server solutions to the Graphics Arts community. So were interested when SP4 was released.
When SP4 Y2K.exe was installed and not winntsp4i.exe on top of an SP3 install we found that when a Mac client via AppleTalk attempted to Write to the NT server, NT would 'blue screen' with a 0x00000000A error, then reboot. Only when SP4Y2k.exe followed by ntsp4i.exe was installed would normal operation resume. (You cannot apply only the y2k fixes as the system will become so unstable as to be unusable )
To date we have noticed no adverse effects of SP4 installed in this order with any of our Mac clients and our users include newspapers pushing many thousands of large TIFF files through the NT servers per day. The Scrolling of directory information has ceased and also the frequency of 'blue screen' has all been eliminated (on sufficiently powerful systems ). Also, when using NT SP4 on Dual/Quad Pentium II/III/Xeon systems , we have had no problems.
On June 4, Brain added a note about Service Pack 5:
When SP5 was installed on top of NT 4.0 SP3 with SFM hot fixes , the system reverted to the condition seen [above], where the y2ksp4.exe was installed and not ntsp4i.exe, where when copying files from a Mac client to the NT server resulted in a Blue screen. This is a major cause for concern for us as all our customers are working on SP3 with MAC Hot fixes or SP4. So we will not install SP5 until we know exactly what it does to systems.
Microsoft Knowledge Base article Q240374 reports a bug in Windows NT Services for Macintosh (NT 4.0 Service Packs 1-through-5) when creating a folder on a Macintosh volume using Windows Explorer. The bug:
When you create a new folder in Windows NT Explorer under a Services for Macintosh (SFM) volume, the folder "New Folder" is created, and you are then able to type a name for this folder. However, when you try to rename the folder, the name reverts back to "New Folder" after a few seconds.
Microsoft does not yet have a fix for this problem.
Rob Newberry of Group Logic, the developer of the ExtremeZ-IP AFP-over-IP software for NT, has sent us an explanation of what is happening with this bug. Newberry believes the bug was introduced with NT Service Pack 4, and that the problem originates in Explorer and not Services for Macintosh or ExtremeZ-IP. Here is his exlanation:
August 31, 1999
I wanted to clarify the issue that was mentioned today on MacWindows regarding the problem with creating a new folder and renaming it, and the odd behavior exhibited by Explorer.
I've been tracking this issue for a long time. I believe it has to do with what happens when a new folder is created. Both SFM and ExtremeZ-IP (and perhaps other programs) wait a short amount of time before responding to the newly created file or directory, at which point they create an "AFP_AfpInfo" stream that is attached to the file or directory. I think the fact other programs do this confuses Explorer and causes it to exhibit this behavior.
I believe that this behavior was actually introduced in Service Pack 4, and is a consequence of a different bug that was supposed to be fixed in that release. That bug is documented in Microsoft's knowledge base item [Knowledge Base article] Q158396.
Since I do not have any knowledge of Microsoft's code (though I might have an opinion :-), I can only speculate that the problems are related. They may in fact be completely unrelated problems. Nevertheless, my testing and investigation indicate that the problem lies in Explorer and not SFM or ExtremeZ-IP.
We are continuing to track this issue, however, and if we find that ExtremeZ-IP is at fault, or even that there is a way to work around the behavior, we will release an updated ExtremeZ-IP for our customers.
Director of Fajita Technology
Group Logic, Inc.