[AMSR]

Try this:

1. Bind the computer:

/usr/sbin/dsconfigad -f -a “ComputerID -u “WindowsAdmin” & “WindowsPassword” -lu “localAdmin” -lp “localPassword” -domain “your.domain.com” -ou “OU=YOUR,OU=CONTAINER,DC=domain,DC=COM”

2. Set your other prefs for the AD plugin:

“/usr/sbin/dsconfigad -lu “localAdmin” -lp “localPassword” -alldomains disable -groups “Domain Admins,Enterprise Admins,My Cool Group”

3. Set your hostname and computer name:

scutil –set LocalHostName “ComputerID”

scutil –set ComputerName “ComputerID”

4. Add the AD to your authentication path:

dscl /Search -create / SearchPolicy CSPSearchPath

dscl /Search -append / CSPSearchPath /Active\ Directory/All\ Domains

Hope that helps

AMSR

[AMSR]

Those Windows servers cannot host 1000s of OSX home directory connections simultaneously. Typically, when PC server vendors say "home directory" they mean a drive that mounts on the desktop for users casually to copy personal files to. In OSX, the home directory is a live connection to the server and can be very large (multiple GB) and has to handle responsively thousands of files per user at the same time. This is a continuously accessed share for the whole time a user is logged in. Any slight hiccup in this will cause users problems.

Likewise, in windows, they do this roaming profile thing that kind of syncs back and forth on login/logout, so windows "homes" and profiles really aren’t the same as what you do in OSX, thus you can get many more connections on for "windows homes". I think if you really sized your servers appropriately for real network homes, you would be in the same ballpart as with the XServes.

Id go with XServes/XRAIDS, bind them into your AD, and serve your homes via AFP. Bind your clients to AD as well, and your users will authenticate to AD, but make an AFP connection to the Xserve as they log in to get their home. You can even keep OD around to manage preferences on your clients at the same time as having them authenticate to AD. Just bind the clients to both directories (but make sure to list AD first in directory access).

[AMSR]

There were fixes that went into 10.3.9 to help address this. It seems also that creating file structures with hundreds/thousands of files that need to be listed when you hit the directory exacerbates this. As does setting options in the Finder such as “Calculate all folder sizes” etc…

[AMSR]

The reason is because your clients are bound to both AD and OD, both which push Kerberos config files to your clients. Sometimes they get along and both realms make it into your edu.mit.Kerberos file, and sometimes they are out of sync, and one wins over the other.

See:

http://docs.info.apple.com/article.html?artnum=300765

Also, you really don’t need to have either of your OD master/replica bound to AD. You can manage the user accounts from a client workstation that is bound to AD, and it will cause your servers less headaches. They don’t seem to like to be both bound to AD and providing LDAP services at the same time.

[AMSR]

Try preferreing a domain controller and see if that helps.

[AMSR]

There is a complete description of what to back up in OD in the OSX Server manual that deals with OD.

[AMSR]

The attributes for homeDir might not be readable to the computer accounts. You might try “delegating” control to “Domain Computers” to have read access to “computer objects”, and “user objects” and their corresponding attributes. If you upgraded from NT, didn’t select “allow pre windows 2000 access”, or are just plain not allowing read access to those attributes, the AD plugin will not be able to read them.

[Author]

Posts