iChat not inherting MCX settings

[lasvegasgamer]

Hello everyone,

I’m a Mac tech at a University; we locally deploy new Macs using DeployStudio and I need to set a Jabber account up to image. I figured I would use a mcx store, based on the DSLocal instructions I found on this site.

I’ve got it setup and it works, It forces my Dock to stay on the right and I can get iTunes to disable the Music Store but iChat wont take the settings i’m putting in com.apple.iChat (we’re doing this on SL)

iChat wont take, it still loads the wizard and the accounts aren’t listed. I’ve attached the xmnc store;

Anyone have any ideas?

BTW, I’ve just stumbled upon the site and it’s a great resource…thanks to everyone involved!

[code]
dsAttrTypeNative:mcx_settings:


mcx_application_data

com.apple.dock

Forced


mcx_preference_settings

orientation
right

mcx_targets

user-managed

com.apple.iChat

Forced


mcx_preference_settings

XMPPAccountToMerge

AllowSelfSignedSSL
1
AutoDiscoverHostAndPort
0
Description
CWRU IM
LoginAs
[email protected]
ServerHost
im.case.edu
ServerPort
5222
ServerSSLPort
5223
UseKerberos5
0
UseSSL
0

mcx_targets

user-managed

com.apple.iChat.Managed

Set-Once


mcx_preference_settings

XMPPAccount

AllowSelfSignedSSL
1
AutoDiscoverHostAndPort
1
Description
CWRU
LoginAs
[email protected]
ServerHost
im.case.edu
ServerPort
5222
ServerSSLPort
5223
UseKerberos5
1
UseSSL
1

mcx_targets

user

com.apple.iTunes

Forced


mcx_preference_settings

disableMusicStore

mcx_targets

user-managed

[/code]

[legsak1mbo]

This sounds similar to the problem that I’m having getting mail prefs setup (albeit in an AD/OD environment). It was fine on 10.5.6 but 10.5.8 and 10.6 don’t seem to play anymore.

See here https://www.afp548.com/forum/viewtopic.php?showtopic=25308 for my issue.

[Stephen Buckley]

Same here, System profiler is reporting the MCX as expected. iChat is resolutely ignoring these settings. I’ve read elsewhere that I might have more luck on a completely new pristine user account on a pristine new OS install, and even then only the once,. I’ve yet to test this, but it doesn’t really help me as I would like to deploy this to lots of existing users. I suppose it might point out exactly what’s being modified when it does work, so there is maybe a chance something can be prodded into making this work reliably.

Server 10.6.3 client 10.6.3, in AD/OD magic triangle. No testing with 10.5 clients.

Sigh, and I was so happy when I discovered I could deploy iChat account settings via MCX

[joshtidsbury]

We’re experiencing the same issues as well. Very frustrating. We’re hoping to escalate the issue soon. I suspect it’s one of those things that works in an OD based environment, but not when the user records are coming in from the AD side.

Josh

[JonThompson]

Same problem here. Fresh server install, fresh OD user. Pure OD. The fun bit is that the com.apple.iChat.managed preference file is even created. It just doesn’t get loaded by iChat.

I have the same issue with iCal MCX as well.

[joshtidsbury]

I forgot to mention that we have the issue with iCal as well. That’s very interesting to hear that it’s an issue in a pure OD environment as well. I wonder what environment it actually works in then? 🙂

In 10.5 we were able to use the iChat managed prefs without issue, but never got iCal working. Now, neither work.

As in your case, the files are created on the client, but they are outright ignored by the applications.

Have you filed a bug report? I’d like to have the report numbers for reference when we go through our reps to help lend some more weight to the issue. The more institutions who are frustrated by this that Apple is aware of, the better.

Thanks!

[Stephen Buckley]

Thanks for confirming that it’s a problem in pure OD environments also. Saved me having to cook up a test environment. I don’t think its an OD/AD, directory or MCX issue per se. As has been pointed out already the MCX settings are being propagated, updated in exactly the way they should be, what appears to be the problem is that iChat (and apparently iCal and Mail) in 10.6.x don’t respect these settings.

My hunch is that it’s either a common problem in the way that these applications are parsing their preference files and omitting to incorporate the MCX supplied settings or, that the new manifests for the 10.6 versions of these apps are wrong and are writing keys that don’t mean anything to the applications.

We are in the process of raising this as a support issue with Apple, I’ll report anything useful we get back to this thread, it doesn’t appear to be getting much attention thus far though, perhaps Apple have lost interest in these slightly less magical and revolutionary technologies.

[JonThompson]

Do you have a bugreporter number that you can share so we can report it as well? Mine is 8156439

[M.Ramsay]

I am having the same issue with iChat not taking the MCX settings assigned to it. Any updates?
10.6.4 Server (Xserve3,1)
10.6.4 Clients (MacBook5,2)

[mosen]

i wrote a really long post about trying to find out why this is happening, but it got marked as spam 🙁 So time to write another really long post, I hope it will get some people engaged in the problem, or at least provide some information.

I can’t get either iChat or iCal MCX settings to apply in any 10.6 environment – I don’t know if anyone has? I’m trying to find out
why this is happening (if it’s a common thing).

I’m comparing how ManagedClient.app acts between 10.5 and 10.6 to get an idea of why it is happening, and i’m starting to understand the underlying
design behind the ManagedClient.app. For any plist which relies on formatted strings/variable substitution or some other interaction with a system framework, the ManagedClient acts as a ‘post compositor’. The MCXCompositor still resolves the composition of preferences from computer accounts, user accounts etc, but the ManagedClient must transform the cached composition to the end result.

The first thing i did was turn on debug output for ManagedClient. This doesn’t seem to be documented in a lot of places (found it in a textbook), so I’ll repeat here:

[code]sudo defaults write /Library/Preferences/com.apple.MCXDebug debugOutput -2[/code]

This gives you a /Library/Logs/ManagedClient/ManagedClient.log which prints each Post Compositing function as it happens, and some of the variables it is using.
Also note that you can force the postcompositing steps to happen if you use:
[code]sudo /System/Library/CoreServices/ManagedClient.app/Contents/MacOS/ManagedClient -f ‘-u ‘[/code]

Particularly interesting is the debug information regarding the iChat post compositing section:
[code]
MCX -postCompositeiChat
MCX -updateUseriChatDomainWithUsername found user prefs for com.apple.iChat.Jabber
MCX -updateUseriChatDomainWithUsername, found iChatAccount
MCX -ApplyFormatToStringKey, changedString:(null) for key:LoginAs
[/code]
It seems to look like the variable substitution isn’t happening at all with ApplyFormatToStringKey, which i guess is just something like [NSString stringWithFormat:] iirc.

The same goes for iCal on my system.. the login name doesn’t get post-processed. I end up with a composited iChat preference and the loginname doesn’t seem to have been applied to the ‘%@’ formatting variable. This might be a common symptom, or just my machine. Regardless – it needs troubleshooting.

I tried the same thing on a Mac OS X 10.5 Server virtual machine using Local MCX preferences for iChat. I know that the post composition step must be different because the preference filename and preference keys differ for iChat managed preferences. In 10.6 the manifest produces a key XMPPAccountToImport in …iChat.plist, but in 10.5 it produces a key XMPPAccount in …iChat.Managed.plist. iChat works fine on 10.5 of course.

Interestingly enough, neither iChat.app on 10.6 or 10.5 reference their corresponding managed keys (XMPPAccountToImport/XMPPAccount) it seems. It doesn’t look like they call objectForKey: for either of these. From this I could say that either the key gets transformed or, iChat’s binary never attempts to read this key and therefore some other process is responsible for adding the account.

Anyway I’m going to keep tracing through ManagedClient until i find the section where MCX is applied from XMPPAccountToImport.

[mosen]

OK,

I’ve found the exact plist configuration that ManagedClient SHOULD produce, but doesn’t. I have no idea why ManagedClient is stopping halfway through postCompositeiChat, but i will try to debug it.
Here’s an example of what iChat expects.

I will just post the jabber account configuration at the moment. And there are slight differences in the AIM and SubNet plists (they use a different GUID and key/value structure). (They should be less frequently requested configurations)

Managed accounts should be transformed by ManagedClient from the “XMPPAccountToImport” dictionary into the following structure, inside com.apple.iChat.Jabber.plist

Root -> ManagedAccounts (Dictionary) -> 00000000-0000-0000-0001-000000000001 (Special GUID name for managed account dictionary) -> Contents of XMPPAccountToImport (key/values)

To make it clearer: lets say you load ManagedClient into workgroup manager. You edit iChat-10.6 and make a new accountInfo key. You would get the default values of ichat.apple.com for everything. What com.apple.iChat.Jabber.plist should look like in this case (If ManagedClient.app actually converted XMPPAccountToImport into ManagedAccounts entries):

[code]
ManagedAccounts

00000000-0000-0000-0001-000000000001

AllowSelfSignedSSL
1
AutoDiscoverHostAndPort
1
Description

LoginAs
%@@ichat.apple.com
ServerHost

ServerPort
5222
ServerSSLPort
5223
UseKerberos5
1
UseSSL
1

[/code]

I omitted the ActiveAccounts and Accounts keys for brevity.

When you launch iChat on 10.6 it will attempt to use this ‘%@@ichat.apple.com’ account, and fail (of course!). The important thing is that the transformation process undergone by ManagedClient is understood.

What this means now is that we can either attempt to debug ManagedClient, to find out why it’s bailing (the first thing i can see is replacing LoginAs with NULL.. that doesn’t seem like it would work well).. ORR option #2 is that we move away from ManagedClient and develop a script which actually does the same thing (read MCX cache, swap some variables, write iChat dictionary).

I will keep trying to identify the original problem though – as that is the cleanest method.

[mosen]

Hehe, sorry im flooding this topic now 🙂

There are two separate methods for creating the ManagedAccount present in ManagedClient.app.

[MCX_PostComposite(WildcardPrefs) updateiChatDomainWithUsername:withGUIDKey:] and
[MCX_PostComposite(WildcardPrefs) updateUseriChatDomainWithUsername:withGUIDKey:withHome:]

They use different GUIDs for the dictionary name under ManagedAccounts (00000000-0000-0000-0001-000000000001 and 00000000-0000-0000-0001-000000000002 respectively)

I’m not sure why these 2 methods exist. If i had to guess it would just be computer vs user domain preferences. So either GUID is safe to use when creating a custom plist entry.

[mosen]

I have been working on iCal now.. I’ve discovered that unlike iChat (which converts a plist to its expected format), iCal
reads in the iCal.managed.plist, checks for accountsToImport, and creates the calendar with CalendarStore framework (I think…). The API seems private?

I can’t currently get iCal ManagedClient settings working in either 10.5 or 10.6.. so It’s a little hard to test at the moment, but im working on it 🙂

[mosen]

OK well, this post is turning into my blog now.. but it is the same topic (MCX not working under 10.6):

In iCal 10.6, the settings are composited by MCXCompositor and then ManagedClient will apply string formatting so you get a dictionary with real account names instead of the %@ placeholder.

Unlike iChat, iCal does not process a plist into another plist, but reads the prefs file so that it can interact with the API to create our managed account.

iCal is looking for a key “accountsToImport” as a part of its preferences. iCal calls [[NSUserDefaults standardUserDefaults] objectForKey:@”accountsToImport”].
I assumed wrongly that if a key was present in the user domain (~/Library/Preferences/com.apple.iCal.plist:accountsToImport), that iCal would read it. Strangely enough we get a null result if you try to use that .plist file for imported accounts.

With a hunch, i used the host domain (/Library/Preferences) and objectForKey actually returns the NSDictionary!! There’s something seriously wrong here because theoretically it should be able to load preferences from the user domain.

PS. I was wrong in identifying ManagedClient as a separate process to MCX.. ManagedClient (10.6) = MCXD (in 10.5).

[mosen]

iCal Update:

What the iCal manifest specifies, and what iCal actually tries to import are two VERY different things. I would say that ManagedClient should perform the transformation from the manifest form, to the form iCal can understand – but it doesn’t (on my system).

And here are the differences in key name (/Library/Preferences/com.apple.iCal.plist):

[b]accountsToImport / 00000000-0000-0000-0000-000000000000[/b]

[b]manifest -> ical expects[/b]
CalDAVDisplayName -> FullName
Use_Kerberos_Key -> Kerberos
CalDAVPrincipalURI -> PrincipalURL
Description -> Title

I had an iCal account that was automatically created using these keys that ical expects, combined with the manifest keys.
Upon launching a second time it has disappeared, and iCal no longer wants to read the file – so I am working on how to ‘reset’ ical (might be SyncServices).

[Author]

Posts