Windows Server 2008 drops the ball for Mac compatibility

Recently I've been faced with the task of helping somebody with a network of Mac computers, that have Windows servers. They have both Windows Server 2003 and Windows Server 2008, and are looking to migrate and upgrade to Windows Server 2008 across the board. Unfortunately, we've run into a roadblock which has turned into a huge headache with the file servers. We've discovered that Services for Macintosh that has been on Windows Server for over a decade and a half, is being mysteriously dropped in Windows Server 2008.

Reading around on this subject, and you will find that everybody says to use Samba. This sounds all well and good, however it just has too many problems and flat out doesn't work reliably. When connecting from any Macintosh (running Leopard, Snow Leopard, doesn't matter) to the Windows 2008 server using Samba, we've encountered various permissions issues. The worst problem is with creating and saving files in Adobe CS3/CS4 applications, where users can open files but not save them, and need to save with a new file name. None of these problems happened before when accessing the shares on Windows Server 2003 that had Services for Macintosh installed. So, we are faced with 3 possibilities: Stay on Windows Server 2003, pay for an expensive 3rd party software package to run on top of the Windows file servers that will enable Apple AFP (Apple Filing Protocol), or look at using Linux with the netatalk service. From experience, netatalk on Linux is rock solid, and fully supports Apple AFP flawlessly. It's an amazing piece of software, and this wouldn't be the first time that Linux has picked up the slack that Windows left hanging behind. But unfortunately in this situation, there's the issue of training the local IT personnel to use the Linux server. At the moment, we are not sure which path to take, so for now they will continue using Windows Server 2003 for Mac file sharing.

Why would Microsoft simply drop a feature like this? Especially when there is no solid solution to replace it? If they want customers to use Windows Server, then wouldn't they want it compatible with everything else? I've seen that other services were also dropped with Windows Server 2008 as well, like services for Netware. I can understand that, but I don't understand why Services for Macintosh were dropped, considering Apple's increasing market share and Macs becoming more and more common.

Talkback

I believe that this behaviour may vary between Mac OS versions (Leopard and Tiger are different) but the reason SFM was dropped is that it's old technology that's been superseded. SFM had been in maintenance mode since NT and is replaced by NFS (supported in Mac OS X) (http://blogs.msdn.com/b/sfu/archive/2009/06/24/removal-of-technology-services-for-macintosh-sfm.aspx). NFS doesn't support alternate data streams, so you're only supposed to need SFM rather than NFS if you have apps looking for resource forks, but I wouldn't have expected something as recent as CS3 to need those... have you raised a call with PSS to see what's happening?
M
Simon Bisson and Mary Branscombe 24 June, 2010 20:31 Reply

I suspect that the very reason we're having these difficulties is because we are using Samba. Considering AFS is the native protocol, it seems that even today it's still flawless and works much better. NFS might be something to try, though, although like you mentioned, resource forks cannot be supported. Thanks!
apexwm 24 June, 2010 21:59 Reply

After a little more research with Apple, I've discovered that AFP (over TCP/IP) still seems to be the preferred protocol for Mac OS X clients (above Tiger), when setting up file sharing on Mac OS X servers. AFP over Appletalk is no longer recommended and supported above Tiger, but TCP/IP is. Apple recommends only using the SMB protocol when working with Windows clients. However in this case, we are in the reverse situation, where the clients are Macs and the servers are Windows. So, knowing this, I return to my question in my original statement back to Microsoft... why was the native AFP protocol dropped completely (with Services for Macintosh)? As I mentioned, Linux (with the netatalk service) still supports it fully, and in fact it works very well and I'm sure is still used quite a bit. Netatalk itself is still actively being developed which tells me this is probably the case. I've used netatalk for over 13 years, even back in the day as an Appletalk router, and over that time it's always worked very well. I definitely see why Mac OS X supports NFS, probably because of it's distant Unix roots and also to be compatible with Unix file servers. But from what I can gather, Microsoft went out on its own limb and just dropped the AFP protocol just because.
apexwm 25 June, 2010 21:45 Reply

Apple's page that defines supported file sharing protocols:

http://docs.info.apple.com/article.html?path=ServerAdmin/10.6/en/fse71ee115.html

An additional interesting note that they mention in the above reference page: "However, NFS doesn’t provide AFP features that Mac OS users are accustomed to, such as Spotlight searching, native ACL, and extended attribute support.". So I think NFS is out for us.
apexwm 25 June, 2010 21:57 Reply