[ozpass]

Whilst I’m unable to provide a reason as to *why* this works, I can confirm this solves the initial poster’s problem every time for me:

Create an A Name *and* and PTR record for every client on your network, that matches the name of the client computer. I use statically assigned addresses for Mac clients on my Active Directory networks as well, which may also be a factor. There’s a resource kit utility that makes bulk creation of DNS records for Windows 2003 Server DNS a doddle.

[ozpass]

This is the approach that I would use.

However, bear in mind that the Export –> Import approach will only preserve the Usernames and Group Names. You will lose the passwords and any other information such as Windows profile paths, homes etc. (possibly wont present a problem).

You’ll also need to re-create the sharepoints and re-set the ownership of your home folders.

For this reason I have a copy of MacinMind’s Passenger to hand at all my sites, with the necessary scripts to import users with *ALL* relevant info as well as set the relevant file permissions on the home area.

[ozpass]

As Dan states, the solution here was to expand the available disk I/O throughput.

Rather than setup one large RAID array, the solution has been to “multi-home” the home areas around several discrete servers, each with a few fast disks.

I’m yet to complete an OD-only setup so I couldn’t state what kind of capacity you could run per-server with Apple hardware, but with Windows 2k3 Servers (twin Xeon 3.0, 2 X U320 SCSI RAID 0) holding the home areas we can accomodate around 300 busy users per box and still have login times well under a minute.

[ozpass]

I’ve just been able to test this at the site in question, and I’m happy to report that is works FLAWLESSLY.

It provides exactly the solution I was looking for.

Thanks for the assistance, and once again kudos to AFP548.com.

-Austin.

[ozpass]

Yeah, based on what you guys have told me, it would seem to be Passenger (namely my use of it) that’s causing the problem here.

Setting up a test user manually and selecting the “User Home Directory” sharepoint that I created has previously failed… it resulted in the “User Home Directory not in the usual place” (paraphrasing from memory, obviously ) error message. I’m willing to admit that at the time I was changing far too many variables with each revision of my setup in a bid to get things working. Based on your advice I’m fairly confident that I can get it to behave as predicted. I hadn’t realised that I could select multiple users and set the home for them…. that would certainly provide a viable option to me. Likewise I didn’t know that you could sort users in WGM based on the comments field. I had been using UID as a means of differentiating my user groups i.e. using 1000-1999 for “Intake00”, 2000-2999 for “Intake01” etc.

If you can suggest a way that I can get automounting to create Home Folders based on username rather than shortname then I think that I can achieve what I require here.

Thanks so much for all your advice…. AFP548.com is head and shoulders above anything else in the Macintosh tech community. You put Apple’s own mailing lists and forums to shame. Keep up the good work!

[ozpass]

I think I dig what you’re saying, and it’s what I’ve tried… suspect I may be missing something.

I create the share “intake00” or whatever. I add it as an LDAP Network mount (User Home Directory type). When I add the path to it as a Server URL in Passenger, however, it doesn’t automount (instead mounting “Macintosh HD” as home and creating a folder “99” in the root of said drive).

I’ve even tried adding the full automount path in the Server URL in Passenger, too…

../Network/serverDNSname/Intakexx/Username

And it still refuses to automount (in this instance generating some error about the users “Home Directory” not being in the usual place…)

I’m certain it’s something really simple that I’m missing… frustrating to be so close to a result!

-Austin.

[ozpass]

Thanks for your help!

I’ll give it a whirl tomorrow.

-Austin.

[ozpass]

Hehe – oops, forgot to log in… needless to say, that last post was me.

[ozpass]

That sounds like what I’m after. What am I missing?

[ozpass]

Have you tried disabling “digitally signed communications” on the Windows Server?

In Administrative Tools –> [Domain Controller Security Policy] –> Local Policies –> Security Options

AND

Administrative Tools –> [Domain Security Policy] –> Local Policies –> Security Options

Set the following entries to “Disabled” before rebooting the server (or doing a POLICY /secrefresh doo-dah)

Domain member: Digitally encrypt or sign secure channel data (always)
Domain member: Digitally encrypt secure channel data (always)
Domain member: Digitally sign secure channel data (when possible)

Microsoft network client: Digitally sign communications (always)
Microsoft network client: Digitally sign communications (if server agrees)

Microsoft network server: Digitally sign communications (always)
Microsoft network server: Digitally sign communications (if server agrees)

I can’t claim to have had the *specific* problems that you’re describing, but the above has always helped when connecting to SMB shares from OS X to the point where I use them as default settings whenever an OS X client is involved.

Hope it helps,
Regards,
Austin.

[Author]

Posts