Steven Major

Q: Profile Manager 5.1 Enrolled Clients Placeholders Only

I'm having an interesting problem with Server 5.1 and Profile Manager. After updating, when I enroll computers they are showing up as Placeholders only. Has anyone else seen this? As of yesterday, enrolling them works as expected prior to the update.

 

Even downloading the Trust Profile and logging into My Devices and downloading the profile, then installing, yields the same result.  The Activity section never shows the usual "Enrolled" profile that I'm accustomed to.

 

Our imaging workflow has not changed except that 10.11.4 is auto-updating, but we've not seen an update cause this.  I will try a vanilla 10.11.3 image we used before tomorrow.  I'm fairly certain, however, that one of us successfully enrolled a 10.11.4 machine this morning right before we did the server update.  By all accounts, including the logs, the server update was successfully.

 

Fortunately, we've learn hard lessons about Apple's server updates over the years so we run it as a VM. I'm rolling back to 10.11.3/Server 5.0.11 as I type.

Posted on Mar 22, 2016 2:20 PM

Close

Q: Profile Manager 5.1 Enrolled Clients Placeholders Only

  • All replies
  • Helpful answers

Previous Page 2 of 3 last Next
  • by Robinson Nuñez,

    Robinson Nuñez Robinson Nuñez Mar 23, 2016 11:52 AM in response to Steven Major
    Level 1 (13 points)
    Servers Enterprise
    Mar 23, 2016 11:52 AM in response to Steven Major

    Same issue here.

     

    I'm getting very inconsistent behavior. Newly enrolled devices get the placeholder treatment.

    If I enroll a Mac that was previously enrolled, they don't get profiles or update info from the server

    Macs previously enrolled and with the enrollment profile (before updating to 5.1) work normally

     

    UPDATE

     

    After renewing push certificate I'm able to update info on previously enrolled devices. I'll try deleting the placeholder and re-enrolling.

     

    Robintosh

  • by Steven Major,

    Steven Major Steven Major Mar 23, 2016 12:00 PM in response to Robinson Nuñez
    Level 1 (44 points)
    Mar 23, 2016 12:00 PM in response to Robinson Nuñez

    Yes, we see that as well.  Previous devices that still have an entry work.  It is only new devices.  Thanks everyone for chiming in!  Hopefully Apple addresses this soon, did anyone speak with Apple?  We have a service rep for the university but he's out on the road and can't be reached.

  • by jeffzimmm,

    jeffzimmm jeffzimmm Mar 23, 2016 12:15 PM in response to Steven Major
    Level 1 (8 points)
    Servers Enterprise
    Mar 23, 2016 12:15 PM in response to Steven Major

    WOW, I was just about to post about this. Here's my log when I try to enroll a device. Notice the URLs--the correct URL for the device is ##.##.##.38. When things start to go wrong, the log starts mentioned ##.##.##.165. I checked my DHCP and there's nothing of consequence on .165. Is ProfileManager getting confused about the correct URL of my device?

     

    1:: [650] [2016/03/23 14:04:45.863] <192.168.1.38> Time since script start: 23406us [https://ourserver.org/devicemanagement/api/device/mdm_checkin]

    1:: [650] [2016/03/23 14:04:45.863] <192.168.1.38> >>> Processing PUT mdm_checkin

    0:: [650] [2016/03/23 14:04:45.865] <192.168.1.38> checkin: "CheckOut"

    1:: [650] [2016/03/23 14:04:45.870] <192.168.1.38> Found target Mac: <'Name of Mac'[3518]>

    1:: [650] [2016/03/23 14:04:45.924] <192.168.1.38> <<< Sent Final Output (0 bytes) - PUT mdm_checkin

    0:: [650] [2016/03/23 14:04:45.924] <192.168.1.38> Completed in 84ms | 200 OK [https://ourserver.org/devicemanagement/api/device/mdm_checkin]

    1:: [648] [2016/03/23 14:05:02.158] <192.168.1.38> Time since script start: 4927us [https://ourserver.org/devicemanagement/api/device/auto_join_ota_service]

    1:: [648] [2016/03/23 14:05:02.158] <192.168.1.38> >>> Processing POST auto_join_ota_service

    1:: [648] [2016/03/23 14:05:02.161] signerIndex = 0, signStatus = 1

    1:: [648] [2016/03/23 14:05:02.682] <192.168.1.38> <<< Sent Final Output (6385 bytes) - POST auto_join_ota_service

    0:: [648] [2016/03/23 14:05:02.682] <192.168.1.38> Completed in 528ms | 200 OK [https://ourserver.org/devicemanagement/api/device/auto_join_ota_service]

    1:: [261] [2016/03/23 14:05:05.227] <192.168.1.38> Time since script start: 18993us [https://ourserver.org/devicemanagement/api/device/auto_join_ota_service]

    1:: [261] [2016/03/23 14:05:05.228] <192.168.1.38> >>> Processing POST auto_join_ota_service

    1:: [261] [2016/03/23 14:05:05.230] signerIndex = 0, signStatus = 1

    1:: [261] [2016/03/23 14:05:05.512] <192.168.1.38> <<< Sent Final Output (12354 bytes) - POST auto_join_ota_service

    0:: [261] [2016/03/23 14:05:05.512] <192.168.1.38> Completed in 303ms | 200 OK [https://ourserver.org/devicemanagement/api/device/auto_join_ota_service]

    1:: [42246] [2016/03/23 14:05:11.793] <192.168.1.38> Time since script start: 4888us [https://ourserver.org/devicemanagement/api/device/mdm_checkin]

    1:: [42246] [2016/03/23 14:05:11.793] <192.168.1.38> >>> Processing PUT mdm_checkin

    0:: [42246] [2016/03/23 14:05:11.795] <192.168.1.38> checkin: "Authenticate"

    1:: [42246] [2016/03/23 14:05:11.824] <192.168.1.38> <<< Sent Final Output (0 bytes) - PUT mdm_checkin

    0:: [42246] [2016/03/23 14:05:11.824] <192.168.1.38> Completed in 35ms | 200 OK [https://ourserver.org/devicemanagement/api/device/mdm_checkin]

    1:: [41016] [2016/03/23 14:05:20.945] <192.168.1.165> Time since script start: 5162us [https://ourserver.org/devicemanagement/api/device/mdm_checkin]

    1:: [41016] [2016/03/23 14:05:20.945] <192.168.1.165> >>> Processing PUT mdm_checkin

    0:: [41016] [2016/03/23 14:05:20.947] [FILTERED]

    0:: [41016] [2016/03/23 14:05:20.951] <192.168.1.165> EXCEPTION: 403 Forbidden - No pending device for checkin_token 'b7ba5898-ca6c-4f1e-b598-d002931e62ec' at

        #0 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/ta rget.php(349): DieForbidden('No pending devi...')

        #1 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/md m_checkin.php(59): Target_for_checkin_request(Array, true)

        #2 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/db .php(396): _checkin_transaction(Array)

        #3 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/md m_checkin.php(173): PerformInTransaction('_checkin_transa...', Array)

        #4 {main}

    1:: [41016] [2016/03/23 14:05:20.952] <192.168.1.165> <<< Sent Final Output (14 bytes) - PUT mdm_checkin

    0:: [41016] [2016/03/23 14:05:20.952] <192.168.1.165> Completed in 12ms | 403 Forbidden  [https://ourserver.org/devicemanagement/api/device/mdm_checkin]

    1:: [262] [2016/03/23 14:05:20.967] <192.168.1.165> Time since script start: 4868us [https://ourserver.org/devicemanagement/api/device/mdm_connect]

    1:: [262] [2016/03/23 14:05:20.967] <192.168.1.165> >>> Processing PUT mdm_connect

    0:: [262] [2016/03/23 14:05:20.972] <192.168.1.165> EXCEPTION: 403 Forbidden - Device not found for CN 'b7ba5898-ca6c-4f1e-b598-d002931e62ec' at

        #0 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/ta rget.php(395): DieForbidden('Device not foun...')

        #1 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/md m_connect.php(20): Target_for_incoming_request(Array)

        #2 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/db .php(396): _connect_transaction_1(Array)

        #3 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/md m_connect.php(128): PerformInTransaction('_connect_transa...', Array)

        #4 {main}

    1:: [262] [2016/03/23 14:05:20.973] <192.168.1.165> <<< Sent Final Output (14 bytes) - PUT mdm_connect

    0:: [262] [2016/03/23 14:05:20.973] <192.168.1.165> Completed in 10ms | 403 Forbidden  [https://ourserver.org/devicemanagement/api/device/mdm_connect]

    1:: [650] [2016/03/23 14:05:21.069] <192.168.1.165> Time since script start: 5400us [https://ourserver.org/devicemanagement/api/device/mdm_checkin]

    1:: [650] [2016/03/23 14:05:21.069] <192.168.1.165> >>> Processing PUT mdm_checkin

    0:: [650] [2016/03/23 14:05:21.071] [FILTERED]

    0:: [650] [2016/03/23 14:05:21.075] <192.168.1.165> EXCEPTION: 403 Forbidden - No pending device for checkin_token 'b7ba5898-ca6c-4f1e-b598-d002931e62ec' at

        #0 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/ta rget.php(349): DieForbidden('No pending devi...')

        #1 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/md m_checkin.php(59): Target_for_checkin_request(Array, true)

        #2 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/db .php(396): _checkin_transaction(Array)

        #3 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/md m_checkin.php(173): PerformInTransaction('_checkin_transa...', Array)

        #4 {main}

    1:: [650] [2016/03/23 14:05:21.075] <192.168.1.165> <<< Sent Final Output (14 bytes) - PUT mdm_checkin

    0:: [650] [2016/03/23 14:05:21.075] <192.168.1.165> Completed in 11ms | 403 Forbidden  [https://ourserver.org/devicemanagement/api/device/mdm_checkin]

  • by Robinson Nuñez,

    Robinson Nuñez Robinson Nuñez Mar 23, 2016 12:25 PM in response to Steven Major
    Level 1 (13 points)
    Servers Enterprise
    Mar 23, 2016 12:25 PM in response to Steven Major

    Seems to be solved.


    After renewing push certificate everything seems very much normal. Deleted placeholder, re enrolled, PM updated info, distributed profiles and all worked as expected.

     

    Cheers

     

    Robintosh

  • by magician300,

    magician300 magician300 Mar 23, 2016 12:29 PM in response to Robinson Nuñez
    Level 1 (0 points)
    Mar 23, 2016 12:29 PM in response to Robinson Nuñez

    Robinson - can you refresh those of us who are having a mental block on what you mean by push certificate?  Specifically, what needs to be renewed?

  • by Robinson Nuñez,

    Robinson Nuñez Robinson Nuñez Mar 23, 2016 12:38 PM in response to magician300
    Level 1 (13 points)
    Servers Enterprise
    Mar 23, 2016 12:38 PM in response to magician300

    Sure. Server App. Select the server in the sidebar. Settings section. Wait for settings to fully load (you will see Service Data Loading...)

    Make sure Notifications (APN) are on. Press Edit Apple ID, then Renew. Enter Apple ID credentials.

     

    Best

     

    Robintosh

  • by magician300,

    magician300 magician300 Mar 23, 2016 2:28 PM in response to Robinson Nuñez
    Level 1 (0 points)
    Mar 23, 2016 2:28 PM in response to Robinson Nuñez

    Appreciate the steps - thank you.  Unfortunately it didn't work for me as I'm still seeing the issue but hopefully Apple will address it sooner rather than later.

  • by jeffzimmm,

    jeffzimmm jeffzimmm Mar 23, 2016 3:11 PM in response to magician300
    Level 1 (8 points)
    Servers Enterprise
    Mar 23, 2016 3:11 PM in response to magician300

    Same here.

  • by KurtF,

    KurtF KurtF Mar 23, 2016 8:45 PM in response to Steven Major
    Level 1 (25 points)
    Mar 23, 2016 8:45 PM in response to Steven Major

    I'm having this issue as well and don't use APN.  I tried starting it but it didn't make a difference.  The problem remains for me when deploying the images. They get stuck when importing the trust and enrollment profiles.

  • by specsavers,

    specsavers specsavers Mar 24, 2016 1:22 AM in response to Robinson Nuñez
    Level 1 (4 points)
    Mar 24, 2016 1:22 AM in response to Robinson Nuñez

    After renewal of the APN Certificate, we still have the same issue. Both with 10.11.4 and server 5.1 and rolling back to 10.11.3 and server 5.0.15, makes no difference.

     

    Setting up a complete new server from clean installs results in the same problem. Really does continue to look like a Apple-side issue.

  • by Bosco1983,

    Bosco1983 Bosco1983 Mar 24, 2016 1:54 AM in response to specsavers
    Level 1 (61 points)
    Servers Enterprise
    Mar 24, 2016 1:54 AM in response to specsavers

    Mine was fixed by magic this morning - didn't change anything.

  • by imathijs,

    imathijs imathijs Mar 24, 2016 2:05 AM in response to Bosco1983
    Level 1 (4 points)
    Mar 24, 2016 2:05 AM in response to Bosco1983

    I can confirm. Issue seems to be fixed without changing anything. Still wonder why...


    Found a topic on Jamf with the similar thing: https://jamfnation.jamfsoftware.com/discussion.html?id=19266

  • by magician300,

    magician300 magician300 Mar 24, 2016 6:41 AM in response to imathijs
    Level 1 (0 points)
    Mar 24, 2016 6:41 AM in response to imathijs

    It looks like the issue has been "magically" corrected - I can confirm that now I can successfully enroll machines via manually and with DeployStudio and the Automatic Enrollment step.  I wonder if we'll ever hear what the actual problem was?  Hmm.

  • by Steven Major,Solvedanswer

    Steven Major Steven Major Mar 24, 2016 7:10 AM in response to magician300
    Level 1 (44 points)
    Mar 24, 2016 7:10 AM in response to magician300

    Same here. It seems to be working again.

  • by Apple@Work,

    Apple@Work Apple@Work Aug 2, 2016 6:30 AM in response to Steven Major
    Level 1 (4 points)
    Aug 2, 2016 6:30 AM in response to Steven Major

    Having the same issue here. I can get the new device to be a placeholder via profile installs but nothing else. The error I am seeing is machine says it cannot reach the SCEP server. Port 1640 is open and working and I had no issues before upadting to OS X 10.11 and Server 5.1. I am close to not trying to solve this type of problem and moving to a different MDM solution that does not break every time an update is done or provides so little researchable content to problem solve from. Any reco's on a good MD for small businesses (meaning not expensive)?

Previous Page 2 of 3 last Next