Tips September 22, 2005 at 9:50 pm

ADmitMac vs. Tiger

Thursby’s ADmitMac is a full-featured SMB/CIFS client that contains a lot of great features to hook Mac OS X into an Active Directory infrastructure. Be aware, though, that there is a downside involved. Thursby chose to implement a different method of handling resource forks on non-AFP filesystems than Apple uses in its samba-based SMB client. Basically, Thursby’s method takes advantage of multi-fork-savvy filesystems (like NTFS) whereas Apple’s doesn’t.

The upshot of this is that if you have two Mac clients, one using ADmitMac and the other using the "stock" SMB client, both accessing an SMB share, neither will be able to see resource forks saved by the other system. This is no big deal for some files (notably those with a known DOS-style 3-letter filename extension like ".doc" or ".xls"), but it can make other files completely unusable. For example, Eudora files rely on the type/creator codes in the resource fork; without the resource fork, Eudora doesn’t know what to do with the various files.

I quizzed a Thursby engineer on this incompatibility, and he pointed out that their DAVE product, which was the first SMB client for Macintosh, used this method because it adhered to Microsoft’s Services for Macintosh standard. They are simply carrying on the tradition of doing it the Microsoft-recommended way.

This incompatibility is a huge issue that Thursby seems reluctant to address. Thursby’s implementation may be superior to Apple’s on technical grounds; nonetheless, they need to either convince Apple to do it their way, or change ADmitMac (or at least offer an administrative option) to do it the Apple way. As it stands now, unless sysadmins go with an "all or none" approach to ADmitMac in their organization–now and into the foreseeable future–they’re asking for trouble. That’s an expensive prospect.

No Comments

  • I’m glad that .DS_Store is now optional on network volumes as it isn’t required by anything to be able to use a directory. It’s just icon and placement data.


    Breaking my server to save yours.

    Josh Wisenbaker
    http://www.afp548.com

  • The problem with that is that Active Directory schema changes are rather
    permanent. 2003 allows you to ignore them, but once you change an Active
    Directory schema, restoring from backup, or reformatting and reinstalling are the
    only ways to undo them.


    John C. Welch Writer/Analyst
    Bynkii.com Mac and other opinions
    jwelch@bynkii.com

    • Even though people talk a lot about the irreversibility of schema changes, most
      organizations don’t seem to care, or don’t realize that a large number of apps
      already do this with AD.

      Exchange alone has some 400 schema mods that it does, plus a lot of other
      software that uses AD for authentication will do the same, they just might not
      be so up front about it. They are much more

      Apple has registered the OIDs that they are using now, so the impact of a
      schema mod, even if you stop using the Apple attributes is very minimal.


      Changing the world, one server at a time.

      Joel Rennich
      http://www.afp548.com

      • A number of 5000+ machine sites have gone down the road of schema
        extension to support collections of 100-1000 OS X systems. I’ve worked with
        and talked to big hi-ed places and large corporate environments that have done
        this.

        You’re right, that it’s not always easy. A lot depends on the management and
        the admin staff, but there are organizations out there that are happy to do
        things like this.


        Changing the world, one server at a time.

        Joel Rennich
        http://www.afp548.com

Leave a reply

You must be logged in to post a comment.