I'm probably going to sound like a Microsoft bigot, but oh well. I'm really not, I'm just in the boat that OSS is not the best solution for every job. Before extending the AD schema, make sure the attributes you're looking for aren't already there somewhere. Extending the schema is usually a last resort type of solution. If you are going to undertake expanding the schema, spend the money on the books. The best way to deal with windows clients is to run a real Active Directory server. Usually you want to have at least two Active Directory servers so you have a backup. If you're running on a SAN and using virtual machines, you can probably safely get away with no backup DC. The actual Windows Active Directory is not really for the authentication, Samba, LDAP, etc. can do that just fine. It's the group policy features that will keep you same when managing Windows clients, and to my knowledge group policy has not been fully duplicated in any 3rd party solution. On the Linux side of things, I use the pam winbind module to authenticate active directory users on my Linux servers. It is very slick and requires no special setup on the Windows AD servers and minimal configuration on the Linux machines. If I was asked to implement a mixed environment, I would have to go with Active Directory. A better solution for dealing with Windows clients simply does not exist. From there, a Mac server running Open Directory in Active Directory integrated mode can provide authentication to Macs, and optionally Unix clients as well. I don't see a need for a Unix/Linux/BSD/Solaris/whatever server as long as the Mac server can handle it, and as long as your flavor of Unix uses pam and the windbind pam module works, you may not even need NIS. Linux servers for the user's home directory would be ideal. I've got my Linux servers configured to create home directories automatically the first time an AD user logs in, and it works well. There could be room for putting some users on a Windows file server. Volume Shadow Copy can be quite useful for things like code and other documents that change frequently. Distributed File System when you're dealing with multiple branch offices via WAN links, but need to share a set of files with all locations. I have my software distribution share in a DFS that is replicated to file servers at the actual locations. It's saved me plenty of time to update an application installation once instead of multiple times. I've been underwhelmed by samba in Mac OSX. On the Mac OSX client OS, it's rather useless. The Mac OS X server platform is much better, but if you want to do anything with samba that isn't supported by the GUI tools you're best bet is to put that configuration into it's own file and add an include line in the smb.conf. The downside of Active Directory is the licenses you have to buy from Microsoft, but if you're organization will be using Exchange you'll already have to buy the required licenses. Lastly, if you're implementing a new AD, go with Windows Server 2003, and go with 2003 native mode. (All domain controllers must be Windows Server 2003 or above.) AD in Windows Server 2003 is a vast improvement over Windows 2000's AD. If you're in a Windows 2000 AD, I highly recommend the upgrade. Having delt with NT4 domains as well as Windows 2000 and Windows 2003 native domains, I would not want to go back from Windows 2003. I hope that was helpful on some level... :-) -- Andrew S. Zbikowski | http://andy.zibnet.us SELECT * FROM users WHERE clue >0; 0 rows returned