Win2K Server, OS 9, OS X, and XServe

G

Go3iverson

Registered
Hey all,

This may be a bit of a mouthful, but I'm sure some people out there have experience that can help in this "issue"...

So, I work for a major publishing company. We have an all PC network running W2K Advanced Server on mostly Compaq hardware. Our clients are about 45% Mac/55% PC, depending on the day of the week and how a department feels.

We have two domain controllers, both with complete replicated Active Directory, DNS, etc. I am right at the end of my Panther testing, as I'm hoping we can evolve from OS 9 to OS X. I'm sure I don't have to explain why this is in our plans!

So, my Macs are doing all types of neat-o tricks. They get their authentication from Active Directory and are bound to the Active Directory domain. This is good. We have single sign on via Kerberos "working". This is one issue we're experiencing. I can use the Network part of the Finder to navigate around our network *until* I try to connect to a share that was shared out to Macintosh users, which has the Microsoft UAM share on it. Now, we did try removing the UAM share, but the share still asks for username and password. Its pretty ironic, if you think about it, all the shares we don't intend Mac users to get into, they *could*, but the ones we want them to use, they can't, possibly due to the UAM.

Now, that isn't a huge issue, as the OS 9 users are used to having to log into all of their shares. The other small issue is Entourage X for the Mac users. Ok, it now has Exchange support, which is good, though group calendars are still not supported, we can deal. Has anyone found a way to get that application to simply get its settings and login information from the Active Directory plugin? If you read the contents of the plugin, all of the directory information is in there, as is the user information, and the Exchange server information as well. The issue is in the fact that the Entourage X application continually tries to set up your password into a local Keychain, which is all well and good for the time being, but the second the users use their new Active Directory integration to change their password, as they need to, the Keychain is out of date and becomes an issue.

Now here's the big one!

Ok, so for years, all of the OS 9 users have connected to the Windows 2000 Server using File Services for Macintosh. No problems, besides for the service crashing and the slow transfer speeds. Well, most, if not all, Mac users never put extension types on the ends of their files. Never been a problem. From what I've read, that implementation of AppleTalk, isn't a true AppleTalk and actually changes the file to a Windows/Microsoft file. This isn't a big problem, if the Mac connects back using the same File Services for Macintosh, but the problem is the resource fork isn't supported in any other connection type. Mac OS X logs in using CIFS or SMB and all of a sudden, any document that was uploaded using the File Services for Macintosh on Mac OS 9 without file extension becomes viewed as a UNIX Executable that cannot be run on OS X properly.

One solution is leaving our OS X clients using AppleTalk, which we rather not do, because of the speed limiations and instability of the service on the Windows server. Also, since they are logging in via AD, they get their user share with a SMB connection, which, of course, doesn't support the resource fork either, but does seem to move faster than the File Services for Macintosh. Another suggested solution is to download all the files using the File Services for Macintosh to a Mac OS X machine and then uploading them again using CIFS/SMB. That, of course, would take forever and a day, as its the better portion of a full TB right now.

That leads me into my next question. Beyond soloving this on the current server platform, does anyone here have experience with XServe/OS X Server? I have experience with the software, but that was on a primarily Linux network supporting both Macs and PCs, so there wasn't much issue there. Now, on my test OS X Server, I have it bound to Active Directory and I'm able to read all the users and groups. I've had relative success deploying images from it, though Adobe CS doesn't seem to transfer quite right. I'd love to be able to set up Mac Computer Accounts on my OS X Server and start managing desktops that way. (Anyone know what type of Directory Node I want to use for that? The only directory services we have are Active Directory, which won't quite cut it with Macintosh Computer accounts, as far as I know). Now, I'm guessing we wouldn't have this file problem moving all user accounts, Mac and PC onto an XServe. The PC users can still connect via SMB/CIFS as they normally would and the Macs could use AFP. Is this a good idea? I mean, instead of downloading a TB of data and then uploading it again, we could just download it and keep it on that hardware and share it back out. I don't know of any issue of OS X (UNIX) supporting both Macs and PCs off the top of my head.

So, now that I've gone on and on, does anyone out there have anything to add? Any help is greatly appreciated!

Thank you!
 
Just an idea :)

Maybe you could have both CIFS/SMB and AppleTalk active for a while and use that to copy the folders and files from the AppleTalk shares over to the CIFS/SMB shares. This should convert the resource fork representation and the files should be accessable in the CIFS/SMB shares afterwards.

Something like:
1) Make both an AppleTalk and CIFS/SMB share for the same shared directory on your Windoze server.
2) Copy everything from that share to your local OS X disk using AppleTalk.
3) Wipe the shared directory on the Windoze machine, i.e. go to the Windoze and trash the directorie's contents entirely.
4) Copy everything back from your local OS X disk to the shared directory, this time using CIFS/SMB.
5) Repeat for every shared directory on your Windoze you have to convert.
 
That was a suggestion and a valid one, the only issue with it is moving that near TB of data back and forth while we're looking to deploy the OS as soon as Tuesday this week.

Thank you for the suggestion, it is a very worthwhile suggestion! :)

Any other ideas or advice out there? Lets here it! Its your time to shine! ;)
 
We have netatalk running on Linux. It creates hidden directories named like .AppleDouble and others to duplicate the resorce fork functionality. As the netatalk source code is available, chances are good that one could get hold of the inner workings of these hidden directories and the structures below it. Hard work, anyway.

Then you have the Windoze File Services For Mac which probably have their own mechanism to honor the resource fork stuff. Maybe they are using the NTFS Multiple Data Streams, but who knows the underlying format?

Last, you have Mac OS X. I assume the mysterious .DS_store hidden files are meant to contain the resource fork info. However, I have never seen any documentation about that.

So your only chance to make the transition until Thursday without copying the files would be to convert the resource fork info on your Windoze from one proprietary format to another without knowing any detail about the encoding. How would you do that?

If Thursday is your goal, I would better start copying the files right now. Chances are good that you get through in time :)
 
Ok, so, I do have an Athlon64....came in handy, since we have the day off for the holiday, of course I'm recreating my network at home! ;)

So, I created a document on my Mac and had it save in Word directly to the PC without a file extension using CIFS connection. It showed up as a blank, white document. Double click still inked it to Word on the Mac, though.

Since Word is native to PC, I switched to Quicktime, created a dummy QT document and saved it to my desktop. Dragged it over to the PC and the Mac views that puppy perfectly with full icon, despite having no extension. I disconnected, came back, still works. Item of note, the PC had no clue what the document was, despite having Quicktime installed. It was a generic icon to it.

To view hidden files, I launched WS_FTP LE and navigated to the share and didn't see the .DS_source, but I did find the .DS_Store. It appears to have listings of all documents in the share, though I didn't notice my "Untitled 3" QT document.

If I keep looking, I noticed three documents at the top.

"_Art Final #2.mov"
"_Quicksilver 2 copy"
"_Untitled 3"

Those were three documents made on the Mac that were transferred over using CIFS. The first two were created the other evening in a back up. The first being a large .mov file, the second being a folder that I created on the PC via the Finder. The last is my test Quicktime document. If I investigate these documents by telling my FTP client to view the documents, I find one line of unreadable garbage, except for "MooVTVOD" dead center, on my Untitled 3 and on my Final.mov. Obviously, this is a resource document created to designate proper file handling for the OS X side, since my OS X machine can view the Untitled 3 as a QT document, but the PC has no clue what it is, since it was not labeled properly for its use. When I look at my OS X created folder, we see a "/" in stead of the MooV, obviously designating it as a directory of the parent folder.

Now, I don't have any Apple File Service here to see how that handles, but we already know that copies a resource fork to designate what application should handle it.

Additionally, I never remember anyone mentioning on the PC side that they couldn't open the improperly named documents. I think this is where the File Services for Macintosh. It was suggested to me that, since this wasn't a real AppleTalk service, but simply Microsoft's version of it (that was said here and prior in other discussions, so bravo to all you knowledgable Mac people out there!), that it also creates the document in a native PC format, but adds their own version of Apple's resource fork to allow their own quasi proprietary version of AppleTalk to transfer it properly. The irony is, now that Apple has taught its OS to speak native Windows via CIFS, the Apple machines continue to find ways to transfer a resource with the document to allow their clientel to continue use of the document, but since the PC depends on that extension for proper handling, there is no back up mechanism on the PC side to allow it to identify the document.

That sum it up? ;)

Thanks for the help! Any additional is still welcome! Hopefully a thread like this could really help people in their cross platform integration needs.
 
That's a pretty slick app. I haven't downloaded it, being that I don't have the hardware around my OS X Server anymore, though the bare drive looks mighty nice on my desk. This looks like a good solution, but that would require us to store the user data on an OS X Server of some nature, which its not at the moment, though the more I read, the better it sounds as far as being able to supply native support for multiple platforms.

My buddy Dave has added some additional ideas. As a makeshift solution, connect to the same share twice simultaneously. One connection via AFP, using the Microsoft implementation of services for Macintosh and the other using CIFS/SMB, since we don't have any NFS services at the moment, we'll ignore that. Then simply drag the directories/files/folder across the desktop from the AFP share to the CIFS/SMB share. Question being, will OS translate on the fly as the file is being copied.

This still leaves one hole: The PC still won't understand the document without the extension. One idea is to use Perl to use the resource forks in the ._ files to go through the list of transferred documents and concatenate the document types on the end of each file name.

This isn't a bug in OS X, but rather a shortsighted view in the implementation of File Services for Macintosh, as far as I can see, but feel free to correct me if I'm wrong. If Apple hadn't included CIFS, SMB, and NFS capabilities in their OS, allowing it to connect to anything, anywhere, anytime, without any limitations, everyone would still use the Microsoft implementation and no one would be the wiser to the fact that the forks' availability was dependant on either using Windows itself, or using the Mac File Service (MFS from now on) which appeared to be a native Mac fork for years. Now that the Mac has evolved, it becomes apparent that the way Microsoft has handled the Mac transfers for years doesn't allow the Macs to actually move to a Windows native connection type, like CIFS.

Don't get me wrong, this was a very slick job of programming by Microsoft. Knowing that Mac users, especially pre X, didn't bother with extensions (I know I didn't for years) and that the Windows OS wouldn't be able to understand the document, they found a way to support Macs in a "native" fashion as well as being able to keep their Windows machines in the know of understanding these documents. This also allowed Microsoft to claim that their server software could natively support multiple OS's, which, of course, everyone wants in a server OS.
 
Go3iverson said:
My buddy Dave has added some additional ideas. As a makeshift solution, connect to the same share twice simultaneously. One connection via AFP, using the Microsoft implementation of services for Macintosh and the other using CIFS/SMB, since we don't have any NFS services at the moment, we'll ignore that. Then simply drag the directories/files/folder across the desktop from the AFP share to the CIFS/SMB share. Question being, will OS translate on the fly as the file is being copied.
Click to expand...

This will work. It is similar to what I initially suggested, btw. This method will also funnel the data through a Mac client, although it will not require the intermediate storage on the OS X disc. You will end up having both resorce fork representations on your Windoze (requires double the disc space).

Let us know what you finally did, I'm really interested :)
 
Well, we're still considering our data storage solution first. We have to find out if Microsoft added SLP into their File Services for Macintosh. If they did, AFP will run at full speed and we can just use that. If they didn't, well, we don't want to use AppleTalk speeds, so this implementation starts become MUCH more relevant.
 
For those interested and those that can help me take this a step further....

So I have my OS X clients bound to Active Directory. We still have OS 9 clients for the time being. All users have been adding extensions to their documents, in theory at least.

Would this be better than using a straight OS X -> Active Directory integration...

We've had some creeping issues here and there. One in particular being Safari asking for a mysterious Keychain password that just can't be satisfied, so is this possible:

We have our Active Directory for all of our accounts, passwords and authentication. We then integrate an XServe with OS X Server as an Open Directory Master(?) and bind it to Active Directory and set it up to, when a authentication is requested or a password is changed, to look back at Active Directory? This way the OS X clients can have managed desktop and roaming profiles even, but *NOT* have to rely on AD for anything but just being able to log in.

Is this possible?

Know of a better way?

Know how to stop keychain?

All help is appreciated! :)
 
WOW!! im glad i found this forum, and this thread.

first, i too work for a large multinational ad agency, and we have a large enough mac population that its just big enought to be a constant thorn in my side. unfortunatly, anyone in the graphics industry will attest that macs earn 99% of your income, so they are obviously here to stay. my job is network administrator, and i handle server builds and communication, and their day to day managment across our 11 site WAN in the US. appleshare is all our file servers, since about 75% of our mac population is still system 9 (is that how you say it? i just started on a mac yestereday).

so anyway, there are 3 other guys on my NOC team, and we all know just enough about a mac to be dangerous. whenever there is a problem concerning macs and how they operate in our windows environment, we just reboot server, restart the mac file/print services, etc. email gets to be even more of a pain, as we are a lotus notes shop. were in the middle of a migration from 5.0.12 to 6.x.x, and we have one site that the macs just crash their domino client for no reason.

so far were refusing to install Mac servers. i think it has to do with the fact that our HP/Compaq servers all have the insight manager agents, so i know ahead of time when hardware is nearing failure, etc. so, were always going to be a windows shop, servicing macs.

an even greater delimma i face is that face that mac users are the most artsy people in computing. they fscking LOVE their funny characters. they HATE when their directory is down with the rest of the ones that begin with "S", so they use all thes characters that are often not valid windows characters, to make their files/folders appear first (is scrolling down really that big of a pain??). since as noted above, the MS implemetation is appletalk is decidedly piss poor, this lame excuse of a protocol just allows them to name files and folders what ever they like, circumventing the SMB handshake and rule sets for files and folders, and seemingly writing directly to the filesystem with no reguard for the fact that a windows computer often needs to open that worddocument named '_new client pitch/ideas§§storyboardsڤڤ.doc'

so, we have about 20-25% of our macs now on OSX, but they are all still using appletalk. i have decided to switch from a x86 laptop to a mac to do all my day to day computing/administration at the office. i figure the "Know thy enemy" is the direction for me at this point. i confiscated a 1999ish 450mhz g4 cube and installed 10.3.3 on it friday, and spent a little time poking around. got the MS remote desktop connection, so at least i can get on our DC to manage users and sites, etc. Lotus notes is going to be fun, but i figure the only way for my team to get anywhere with out mac problems, is to physically use macs.

i did have one triumph yesterday tho, with SMB protocol to a server that has no appletalk, i tried to create a folder like my example above, and it returned back the error that i could not use such characters. 1 down, how many to go?

ultimatly, whats my goal here? rid my life of the thorn called appletalk.

again, thanks for this forum! im sure it will be a huge help to me!

Jonathan
 
You must log in or register to reply here.
Back
Top