[getalong]

Glad to hear s_jobs post re: jumpers did the trick.

A few side notes re: ADMs – an unnamed Apple Enterprise Support Engineer dropped me a few little tid-bits about their “server-grade” drives…
– They perform extensive burn-in testing (I believe ~1000 hrs)
– Apple applies their own firmware to the drives
– They ensure each drive comes from a different batch (to minimize risk of an entire “bad batch” of drives).

This may not sound like a big deal, but the cost to perform these additional controls may explain a [i]little[/i] more about their higher price.

[getalong]

I’ve run into this same scenario (10.4.11 Server and Win 2003 Server R2).

I thought it might be due to the fact that I’m using both GigE ports (second is used for Xsan client), but I can confirm that “en0” is set at top of SysPrefs/Network priority list.

FYI: Forward/reverse DNS records are working. I have un/bound Directory Access multiple times. I’m getting krb5.keytab entries, but cannot seem to successfully join Kerberos Realm (KDC from AD).

[getalong]

To follow up; the posting I was recalling is from Philip Rinehart over at MacEnterprise.org.

He’s posted a Python script to change the default timeouts, but you might be able to use the defaults command, too.

[getalong]

Just chiming in here, because my MacBook Pro users have extenuating login times with AD (no OD) and some have first.lastname accounts. Although legacy users were set up like “jdoe” and new users are first.lastname, I’ve seen this occur in both user formats.

I have perused the varied posts/responses re: “slow login times”, and most point to DNS records (some to active network connections).

My users have Mobile AD accounts (initially bound from OS X 10.4.6), so credentials are cached and out of office login times are (mostly) bearable. This seems like a matter of changing the default time out for login lookups? I remember seeing a post about changing this setting somewhere (could have sworn it was AFP548)–anyone else?

[getalong]

I know this post is old, and my reply is slightly off-topic, but this is the only place I’ve found this exact dscl error message–however, I’m not trying anything with iChat.

I just NetBoot/Restored a brand-new MBP 15 C2D, and after binding this MBP to our AD, I get the same results posted: dscl into local machine, cd to /Active\ Directory/All\ Domains/Users/, ls lists all AD users, BUT when I try to read any users, I get…

dscl[228] *** My Uncaught Exception: ([DSoDataList initWithDir:value:] value is not a valid NSString nor NSData)

As I said, this is the same error jdyck mentioned. Did you figure it out?

This is the third machine I’ve bound to AD (from this NetRestore image), and the first one to have this problem. I’ve attempted to Unbind/Bind (again), reinstall 10.4.9 Combo (desparate) with no resolve.

For the sake of time, I’m gonna Netboot this puppy again, and see hope for the best.

[getalong]

In case you didn’t already find this out, Server Admin > AFP > Settings offers you a “Logon Greeting” field. However, SMB/Windows does not offer anything. Seems like more of a Mac-type of feature, as most of my Windows users just want to get to the files/folders. Anyways…

[getalong]

Just thought I’d throw may hat in here, too. I have various obstinate users still doing Spotlight searches across various servers, which seems to precipitate our XS AFP crawling–often SBODs on the client machines (an added “bonus”). I’m sure to lose my job if I have to stop/start AFP or reboot servers.

You see, I inherited users who decided to throw all their archived design work into Xsan, which they would then search via Spotlight to find older files. Needless to say it didn’t take long for that concept to break–now I’m the one to blame that it doesn’t “just work”!

I was looking at “Disabled/Asleep” AFP status as the initial cause, but I think you’re correct: it seems to be caused by various/mupltiple Spotlight searches on network shares. I have a mix of XS G5 (non-Universal) and Xeons–all running 10.4.9. Anyone had luck copying/modifying /etc/rc.server to non-Universal 10.4.9? Also, what level of logging have you set on your AFP servers?

Perhaps the Spotlight server process on 10.5 Leopard hints at Apple’s ultimate solution to this growing issue. Hopefully, they’ve come to realize they really are in the enterprise market–whether or not Apple’s marketing group wants to admit it.

[b]P.S. big thanks to jpbuse for relaying the /etc/rc.server tip![/b]

[getalong]

My users haven’t reported this delay w/ same set up as Niels, but I have noticed two issues pertaining to 10.4 mobile accounts thusfar (hence, I’m replying here–please don’t flame me).

Issue 1: User wakes or powers up their MBP, plugs into our office GigE network, but loginwindow shakes w/ repeated attempts.
Frequency: Three users have experienced this situation over the last 4 months–one user was able to login, but with a brand new user account.
Notes: Seems only to affect previously/recently cached AD logins, as I was able to login with other AD accounts in each case.
Resolution: Login with local admin account (you have one, right?); Verify troubled user’s local home dir exists (at /Users/*), and back it up somewhere (to be safe); Launch NetInfo Manager, and look for multiple entries for troubled AD user; Determine which of these accounts has less user attributes (usually indicates the bogus account); Delete suspect user account (still in NetInfo Manager, mind you); Hold your breath and logout… attempt to login w/ user’s AD account, then verify user data is in-tact.

Issue 2: Successive clicking of loginwindow’s “OS X Version/Serial Number/Date & Time/IP Address/Network Accounts Availibilty..” field consistently gives Spinning Beachball (for up to 5-10 minutes), then permits use of usernam/password fields.
Frequency: At least five Macs (both desk/laptops) have experienced this issue.
Notes: Must be mobile accounts bound to AD; Can occur with OR without active network connection(s); Once Spinning Beachball disappears, you can trigger it again by repeating steps.
Resolution: Safe Boot, manually clear caches (or use Tiger Cache Cleaner, etc.). Presumably, something in the mobile account’s cached credentials is getting hosed, hence why Safe Boot resolves (until issue sneaks up on you later 😯 ).

Sorry for the novella. I should probably submit this to RADAR, instead of here. Oopsie…

————————————————————————–
Several Certifications later…

[Author]

Posts