Profile Manager Can't Sync To One Device

Thank you for the reply.

Client and server time is synchronized. Client actually gets it's time from the server.

Upon enrolling the device... there is a server side error:

Sep 1 12:08:34 server.company.com ReportCrash[10525]: failed

looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls.

Sep 1 12:08:34 server.company.com ReportCrash[10525]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0

Here is the stream:

Sep 1 12:08:32 server.company.com xscertd[10518]: Received connection from 10.0.0.220:50603 Sep 1 12:08:32 server.company.com xscertd[10518]: Received request from 10.0.0.220:50603 Sep 1 12:08:32 server.company.com xscertd[10518]: Processing request from 10.0.0.220:50603 of /scep/?operation=GetCACaps... Sep 1 12:08:32 server.company.com xscertd[10518]: Returning response with code 200 to 10.0.0.220:50603 Sep 1 12:08:32 server.company.com xscertd[10518]: Received connection from 10.0.0.220:50604 Sep 1 12:08:32 server.company.com xscertd[10518]: Received request from 10.0.0.220:50604 Sep 1 12:08:32 server.company.com xscertd[10518]: Processing request from 10.0.0.220:50604 of /scep/?operation=GetCACert... Sep 1 12:08:32 server.company.com xscertd[10518]: Returning response with code 200 to 10.0.0.220:50604 Sep 1 12:08:33 server.company.com kdc[52]: AS-REQ _ldap_replicator@server.company.COM from 127.0.0.1:53316 for krbtgt/server.company.COM@server.company.COM Sep 1 12:08:33 --- last message repeated 1 time --- Sep 1 12:08:33 server.company.com kdc[52]: Client sent patypes: REQ-ENC-PA-REP Sep 1 12:08:33 server.company.com kdc[52]: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ Sep 1 12:08:33 server.company.com kdc[52]: AS-REQ _ldap_replicator@server.company.COM from 127.0.0.1:52283 for krbtgt/server.company.COM@server.company.COM Sep 1 12:08:33 --- last message repeated 1 time --- Sep 1 12:08:33 server.company.com kdc[52]: Client sent patypes: ENC-TS, REQ-ENC-PA-REP Sep 1 12:08:33 server.company.com kdc[52]: ENC-TS pre-authentication succeeded -- _ldap_replicator@server.company.COM Sep 1 12:08:33 server.company.com kdc[52]: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 Sep 1 12:08:33 server.company.com kdc[52]: Requested flags: forwardable Sep 1 12:08:33 server.company.com xscertd[10518]: Received connection from 10.0.0.220:50605 Sep 1 12:08:33 server.company.com xscertd[10518]: Received request from 10.0.0.220:50605 Sep 1 12:08:33 server.company.com xscertd[10518]: Processing request from 10.0.0.220:50605 of /scep/?operation=PKIOperat... Sep 1 12:08:33 server.company.com xscertd[10518]: Received PKCSReq from 10.0.0.220:50605 Sep 1 12:08:34 server.company.com xscertd[10518]: Request from 10.0.0.220:50605 succeeded, returning Success status Sep 1 12:08:34 server.company.com xscertd[10518]: Returning response with code 200 to 10.0.0.220:50605 Sep 1 12:08:34 server.company.com ReportCrash[10525]: DebugSymbols was unable to start a spotlight query: spotlight is not responding or disabled. Sep 1 12:08:34 server.company.com ReportCrash[10525]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls. Sep 1 12:08:34 server.company.com ReportCrash[10525]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0 Sep 1 12:08:34 server.company.com ReportCrash[10525]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls. Sep 1 12:08:34 server.company.com ReportCrash[10525]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0 Sep 1 12:08:34 server.company.com ReportCrash[10525]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls. Sep 1 12:08:34 server.company.com ReportCrash[10525]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0 Sep 1 12:08:34 server.company.com ReportCrash[10525]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls. Sep 1 12:08:34 server.company.com ReportCrash[10525]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0 Sep 1 12:08:34 server.company.com ReportCrash[10525]: failed looking up LS service ( scCreateSystemService returned MACH_PORT_NULL, called from SetupCoreApplicationServicesCommunicationPort, so using client-side NULL calls. Sep 1 12:08:34 server.company.com ReportCrash[10525]: LaunchServices/5123589: Unable to lookup coreservices session port for session 0x186a0 uid=0 euid=0 Sep 1 12:08:34 server.company.com xscertd[10518]: Failed sending RemoveKeyFromKeychain command to com.apple.xscertd.helper: Connection interrupted Sep 1 12:08:34 server com.apple.launchd[1] (com.apple.xscertd-helper[10519]): Job appears to have crashed: Segmentation fault: 11 Sep 1 12:08:35 server.company.com ReportCrash[10525]: Saved crash report for xscertd-helper[10519] version 53 to /Library/Logs/DiagnosticReports/xscertd-helper_2012-09-01-120835_server.crash Sep 1 12:08:35 server.company.com ReportCrash[10525]: Removing excessive log: file://localhost/Library/Logs/DiagnosticReports/xscertd-helper_2012-08-31-123821_server.crash Sep 1 12:08:35 server.company.com php-fpm[3963]: DMX-EXT: signerIndex = 0, signStatus = 1 Sep 1 12:08:35 server.company.com xscertd[10518]: Received connection from 127.0.0.1:52989 Sep 1 12:08:35 server.company.com xscertd[10518]: Received request from 127.0.0.1:52989 Sep 1 12:08:35 server.company.com xscertd[10518]: Processing request from 127.0.0.1:52989 of /scep/?operation=GetCACaps... Sep 1 12:08:35 server.company.com xscertd[10518]: Returning response with code 200 to 127.0.0.1:52989 Sep 1 12:08:35 server.company.com xscertd[10518]: Received connection from 127.0.0.1:52990 Sep 1 12:08:35 server.company.com xscertd[10518]: Received request from 127.0.0.1:52990 Sep 1 12:08:35 server.company.com xscertd[10518]: Processing request from 127.0.0.1:52990 of /scep/?operation=GetCACert... Sep 1 12:08:35 server com.apple.launchd[1] (com.apple.xscertd-helper): Throttling respawn: Will start in 7 seconds Sep 1 12:08:42 server.company.com xscertd-helper[10531]: Starting xscertd-helper/1.1.0 (MacOS X Server) Sep 1 12:08:42 server.company.com xscertd[10518]: Returning response with code 200 to 127.0.0.1:52990 Sep 1 12:08:42 server.company.com kdc[52]: AS-REQ server.company.com$@server.company.COM from 127.0.0.1:49294 for krbtgt/server.company.COM@server.company.COM Sep 1 12:08:42 --- last message repeated 1 time --- Sep 1 12:08:42 server.company.com kdc[52]: Client sent patypes: REQ-ENC-PA-REP Sep 1 12:08:42 server.company.com kdc[52]: Need to use PA-ENC-TIMESTAMP/PA-PK-AS-REQ Sep 1 12:08:42 server.company.com kdc[52]: AS-REQ server.company.com$@server.company.COM from 127.0.0.1:59038 for krbtgt/server.company.COM@server.company.COM Sep 1 12:08:42 --- last message repeated 1 time --- Sep 1 12:08:42 server.company.com kdc[52]: Client sent patypes: ENC-TS, REQ-ENC-PA-REP Sep 1 12:08:42 server.company.com kdc[52]: ENC-TS pre-authentication succeeded -- server.company.com$@server.company.COM Sep 1 12:08:42 server.company.com kdc[52]: Client supported enctypes: aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1, arcfour-hmac-md5, using aes256-cts-hmac-sha1-96/aes256-cts-hmac-sha1-96 Sep 1 12:08:42 server.company.com kdc[52]: Requested flags: forwardable Sep 1 12:08:42 server.company.com kdc[52]: TGS-REQ server.company.com$@server.company.COM from 127.0.0.1:53267 for host/server.company.com@server.company.COM [canonicalize] Sep 1 12:08:42 server.company.com kdc[52]: TGS-REQ server.company.com$@server.company.COM from 127.0.0.1:56209 for ldap/server.company.com@server.company.COM [canonicalize] Sep 1 12:08:42 server.company.com xscertd[10518]: Received connection from 127.0.0.1:52999 Sep 1 12:08:42 server.company.com xscertd[10518]: Received request from 127.0.0.1:52999 Sep 1 12:08:42 server.company.com xscertd[10518]: Processing request from 127.0.0.1:52999 of /scep/?operation=GetCACaps... Sep 1 12:08:42 server.company.com xscertd[10518]: Returning response with code 200 to 127.0.0.1:52999 Sep 1 12:08:42 server.company.com xscertd[10518]: Received connection from 127.0.0.1:53000 Sep 1 12:08:42 server.company.com xscertd[10518]: Received request from 127.0.0.1:53000 Sep 1 12:08:42 server.company.com xscertd[10518]: Processing request from 127.0.0.1:53000 of /scep/?operation=GetCACert... Sep 1 12:08:42 server.company.com xscertd[10518]: Returning response with code 200 to 127.0.0.1:53000 Sep 1 12:08:42 server.company.com xscertd[10518]: Received connection from 127.0.0.1:53001 Sep 1 12:08:42 server.company.com xscertd[10518]: Received request from 127.0.0.1:53001 Sep 1 12:08:42 server.company.com xscertd[10518]: Processing request from 127.0.0.1:53001 of /scep/?operation=PKIOperat... Sep 1 12:08:42 server.company.com xscertd[10518]: Received GetChallengePassword from 127.0.0.1:53001 Sep 1 12:08:42 server.company.com xscertd[10518]: Request from 127.0.0.1:53001 succeeded, returning Success status Sep 1 12:08:42 server.company.com xscertd[10518]: Returning response with code 200 to 127.0.0.1:53001 ==> /Library/Logs/ProfileManager/php.log <== 0::Sep 01 13:08:42.519 [3963] <10.0.0.220> No signing certificate specified, unable to sign. 0::Sep 01 13:08:42.519 [3963] <10.0.0.220> Completed in 7373ms | 200 OK [https://server.company.com/devicemanagement/mdm/ota_service.php]

And eventually server side

Sep 1 12:20:50 server.company.com ProfileManager[10572] : @@@ DemandCommand.execute: PGError: ERROR: could not serialize access due to concurrent update : UPDATE "devices" SET "last_profile_send_time" = '2012-09-01 19:20:50.177983' WHERE "id" = 39 @@@ Sep 1 12:20:50 server.company.com ProfileManager[10572] : @@@ Retry #1 of command #2827 due to database transaction failure.... @@@ Sep 1 12:20:50 server.company.com ProfileManager[10572] : >>>DemandCommand.execute: #.extend_task(PushSettings,39,devices) Sep 1 12:20:50 server.company.com ProfileManager[10572] : ** has_many_polymorphs: Warning; not all usage scenarios for polymorphic scopes are supported yet. Sep 1 12:20:50 server.company.com ProfileManager[10572] : Task.create_task: changed_profiles=[""], count=1 Sep 1 12:20:50 server.company.com ProfileManager[10572] : ProfileCache.update: cache=#, updated_at = 2012-08-31 03:36:00 UTC Sep 1 12:20:50 server.company.com ProfileManager[10572] : Task.create_task: Created task #8719 'UpdateInformation' (prio:50) for

To me... the server database looks like its having trouble inserting/updating this particular devices row due to a prior failed transaction... I don't know how to clear this out. Restarted Profile Manager, server, and client.

Any ideas?

This appears to be related to the actual user account.

-- Having the problem user login to another managered computer still fails to deploy the user's group profile settings

-- Having a known good user login to the problem comupter reveals that the good user is able to receive their group profile settings.

Notes:

-- there are no individual user settings for this profile

-- the user's profile appears identical to all other users

-- I'm guessing I am going to have to delete the user and re-add them... but I have no idea why this would be necessary

So now another user is experiencing the same problems.

I have tried to re-enroll the user and the user's device, and now their group profile will not sync... despite seeing "succeeded" messages in the task log and an acknlowedment in the system.log of the client.

Is anybody else experiencing tempermental behavior with Profile Manager... our impression is that it does not consistently deploy settings... and is somewhat silent on explaining why a deployed setting has failed.

Perhaps it's a configuration error on our end... but we find it odd that it works for "most users most of the time." We do not feel comfortable using this in production.

Server

==> /Library/Logs/ProfileManager/php.log <==

0::Sep 04 18:57:28.712 [53282] <10.0.0.204> {LogException (common.php:239)} EXCEPTION: 400 Bad Request - Unable to authenticate request at

0::Sep 04 18:57:28.712 [53282] <10.0.0.204> #0 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/db .php(372): _checkin_transaction(Array)

0::Sep 04 18:57:28.712 [53282] <10.0.0.204> #1 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/ch eckin.php(124): PerformInTransaction('_checkin_transa...', Array)

0::Sep 04 18:57:28.712 [53282] <10.0.0.204> #2 {main}

1::Sep 04 18:57:28.712 [53282] <10.0.0.204> {SendFinalOutput (common.php:246)} Sent Final Output (16 bytes)

1::Sep 04 18:57:28.712 [53282] <10.0.0.204> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - /devicemanagement/mdm/checkin.php

0::Sep 04 18:57:28.712 [53282] <10.0.0.204> {SendFinalOutput (common.php:246)} Completed in 20ms | 400 Bad Request [https://server.company.com/devicemanagement/mdm/checkin.php]

Client

Sep 4 16:13:03 sales.local mdmclient[2728]: *** ERROR *** [Agent:1062] Unable to proceed with connection to: https://server.company.com/devicemanagement/api/device/connect (com.apple.mdmconfig.mdm) because don't have valid MDM AuthToken

Two potential workarounds for a user not receiving profile manager group settings (when other users in the same group are):

One:

-- Server App ... User ... Click Problem User ... Edit User ... "-" / delete the "Group" from the User account... Save.

-- Optional step... stop Profile Manager

-- Server App ... User ... Click Problem User ... Edit User ... "+" / add the "Group" back to the User account... Save.

-- Start Profile Manager if you stopped it earlier

Two:

-- Delete the User in Server app entirely. Add the User back (making them a member of their old groups).

-- This option is messy if you have OpenDirectory replica's (and or mail server's, calendar servers, etc)

---- I had to manually move the mail back to the user's new guid

-- (Note: export / delete / re-import from Workgroup Manager of the user account did not work)

Update:

Scratch option two above... after deleting the entire user... rebuilding mail... testing the account on a test workstation... and confirming all profile settings deployed... the error came back... and the user was unable to receive group profile settings due to a "don't have valid MDM AuthToken" error.

(I can still confirm that option one above has helped with users who fail to get the group profile but do not have an MDM AuthToken error... removing the group from the user.. then adding it back is a quick and easy test that is still beneficial in other use cases)

Actual Possible Culprit & Workaround:

As it turns out... this user had an additional short name configured in his profile... this appears to be the culprit.

For example... say your organization follows the naming convention of "first letter first name" combined with "full last name"... Frank Galikanokus would become "fgalikanokus". This would make the user's email address fgalikanokus@yourcompany.com.

For client relations and ease of use... it may be beneficial to have an email alias of "frankg@yourcompany.com"

This was configured via an additional short name alias ... see Workgroup Manager... or right-click -> Advanced upon the user name in the server app.

I realized after deleting and recreating and retesting everything... that everything worked... and then as the last step... I added back the users additional email alias "frankg"

The additional short name appears to be causing the bad MDM AuthToken. Removing the additional name allowed the group profile manager payload to deploy.

Additional Side Notes:

Mountain Lion no longer supports multiple "forward" addresses via the Workgroup Manager or the Server App (as they used to in Snow Leopard in Lion). These forwards appear to only work if they are true postfix aliases. It appears additional short name configuration are not fully compatible with profile manager... and therefore I would recommend staying away from additional short name aliases all together for mail (and stick to postfix aliases).

I have another post detailing all the many other problems we have faced with Profile Manager here:

-- https://discussions.apple.com/thread/4254271?start=0&tstart=0