Q: Managed Settings missing in Profile Manager after upgrade to Server 3

It is good to know the data is still there somewhere. I did try those commands and it set everything back to the way it was right after the upgrade. However, it is still failing in the same place as before and not importing devices. It seems like the database needs to be updated to allow for a certain fields character size to allow a correct import if I am reading the log correctly.

Yes, you are correct. Unfortunately, there is no opportunity to make that change to the database schema because the new database is created and migration follows immediately after that in the same process.

So, if you don't mind, you can try a slightly "larger hammer" with this command:

sudo psql -U _devicemgr -d device_management -h /Library/Server/ProfileManager/Config/var/PostgreSQL -c "update devices set \"InstalledApplicationList\" = NULL;"

And the run the same re-migration command as before. (This command just erases ALL of the data that might be causing problems. The prior one only targeted ones that contained Adobe CS3 apps, but there must be something else, too, so this will eliminate all possible sources of this particular issue, at least.)

I've found that my migration failure has to do with existing enterprise applications... Truncating the ios_applications table results in the users and such being successfully migrated... However, applications are NOT migrated.  I have my server disconnected from the internet, but if I didn't, I would expect that the applications would be pulled from the devices next time they phone home, so don't do this in production!

It seems that there is a duplicate key issue:

ERROR: duplicate key value violates unique constraint "eapps_unique_ident" DETAIL: Key (unique_identifier)=(com.yourcompany.App) already exists.

This error surfaces during the EnterpriseApp portion of the migration.  Unfortunately, the wipedb.sh script calls a binary that performs the migration, otherwise I'd play with this some more and figure out why the clashing is taking place.  I'm going to leave this one to Apple to fix.

@mscott_mdm: I have to tell you, you're a life saver.  I thought I was going to have to go around to 224 different laptops and have them re-enroll.  Clearing out the database entries you suggested enabled Profile Manager 3 to import my settings successfully.

Thank you SO much!

That was it. So the final solution was to kill that one app that was still hanging out and everything came back agian! Happy Days are here again!

Thanks,
Paul

Looks like I spoke too soon.  Although after running the commands posted by mscott_mdm above, I was able to see all of my enrolled devices in Profile Manager again, upon inspection of the logs after issuing the command to update all devices, I get tons of log entries in the Profile Manager Device Server log that look like this:

1::Oct 29 13:40:25.241 [90019] <10.0.10.122> {LogElapsedTime (common.php:74)} Time since script start: 214us [https://server_url_obfuscated/devicemanagement/api/device/checkin]

1::Oct 29 13:40:25.241 [90019] <10.0.10.122> {require_once (mdm_checkin.php:11)} vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv - PUT checkin

0::Oct 29 13:40:25.241 [90019] <10.0.10.122> {require_once (checkin.php:13)} checkin: 'TokenUpdate'

0::Oct 29 13:40:25.242 [90019] <10.0.10.122> {LogException (common.php:426)} EXCEPTION: 403 Forbidden - old enrollment scheme not supported at

0::Oct 29 13:40:25.242 [90019] <10.0.10.122> #0 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/ta rget.php(204): DieForbidden('old enrollment ...')

0::Oct 29 13:40:25.242 [90019] <10.0.10.122> #1 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/md m_checkin.php(61): Target_for_checkin_request(Array, true)

0::Oct 29 13:40:25.242 [90019] <10.0.10.122> #2 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/db .php(393): _checkin_transaction(Array)

0::Oct 29 13:40:25.242 [90019] <10.0.10.122> #3 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/md m_checkin.php(140): PerformInTransaction('_checkin_transa...', Array)

0::Oct 29 13:40:25.242 [90019] <10.0.10.122> #4 /Applications/Server.app/Contents/ServerRoot/usr/share/devicemgr/backend/php/ch eckin.php(13): require_once('/Applications/S...')

0::Oct 29 13:40:25.242 [90019] <10.0.10.122> #5 {main}

1::Oct 29 13:40:25.242 [90019] <10.0.10.122> {SendFinalOutput (common.php:433)} Sent Final Output (14 bytes)

1::Oct 29 13:40:25.242 [90019] <10.0.10.122> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - /devicemanagement/mdm/checkin

0::Oct 29 13:40:25.242 [90019] <10.0.10.122> {SendFinalOutput (common.php:433)} Completed in 1ms | 403 Forbidden  [https://server_url_obfuscated/devicemanagement/api/device/checkin]

Looks like I may have to re-enroll every device after all, unless someone has a better suggestion.

I am running into the same problem. I can see them in the database and can click them. But I can't send a push notice to them unless I reenroll them. I also noticed I can't search them either I just get an error telling me to reload.

jeddhor & Paul,

Are these Macs or iOS devices (or both)? If just one, have you been able to test the other type?

Thanks.

I hvae both and have the same problem on both. If I reenroll them they are fine. If I try to push new profiles the all devices profile pushes but Groups don't push until I reenroll the phones.

Paul, can you confirm that you're seeing the same "403 Forbidden - old enrollment scheme not supported" messages in your /Library/Logs/ProfileManager/php.log file? I think I might know why OSX devices might have this happen, but I can't understand why iOS devices would hit this particular error.

Thanks.

In my case, we have 224 MacBook Pros and one iPad (2nd Gen).  The iPad updates fine; the MacBook Pros do not.  All of the MacBook Pros are currently running Mountain Lion -- we haven't upgraded to Mavericks yet due to some compatibility issues with VMWare Fusion (which most of our developers use).  The iPad is running iOS 7.

I tried the command that should have deleted all the applications and reran the migration process. However, I had the same failure. Looking at the log, it appears that the SQL command to delete the InstalledApplicationList did not actually delete the list of applications, even though it reported that it updated 10 records.

When I tried to migrate the profile data after running the delete command (in the form to delete all applications listed) I still saw the applications listed. Note that in my case, the problem application is the adobe license manager installed on an OS X system. Does that command really remove the listed applications??

Eric,

Do you only have 10 devices enrolled? If so, that command did its job, but you might be experiencing a different issue. Are you seeing "value too long for type" errors in /Library/Logs/ProfileManager/migration_tool.log? If not, then you're probably having a different issue. I'd need to see the first "EXCEPTION:" line in your migration_tool.log file, and the 50 or so lines immediately before it to be able to offer any advice.

Thanks.

I have about 10 devices enrolled

It is the value too long because of the Adobe License Manager:

    Identifier :   com.adobe.adobe_licutil

    Name :         adobe_licutil

    ShortVersion : Adobe License Utility 6.0.0.114 (BuildVersion: 6.0; BuildDate: Tue Apr 03 2012 18:00:00)

    Version :      Adobe License Utility 6.0.0.114 (BuildVersion: 6.0; BuildDate: Tue Apr 03 2012 18:00:00)

    ——————————————+———————————————————————————————————————————————————————————————— ————————————————————————

0:: [2253] [2013/10/23 10:35:59.368] [1;7;31mEXCEPTION:[0;31m  Postgres <-[PGConnection executeSQL:withParams:] (/SourceCache/RemoteDeviceManagement/RemoteDeviceManagement-848.17/Compiled/Fra mework-Models/Postgres/PGConnection.m:432): "Postgres error 22001 (ERROR:  value too long for type character varying(63)

    )">

All the previous lines are correct information about the applications installed.

Doesn't the command you listed previously delete the installed application information from the table? That is what I thought it did at any rate…. If I can remove the version information, that would probably resolve the issue.

Did you use the "larger hammer" command from the top of this page? (Also copied below for reference.) I can't see how that wouldn't work. I had a similar command—on the previous page—which included a WHERE clause that tried to only target certain devices, but that wasn't specific enough.

sudo psql -U _devicemgr -d device_management -h /Library/Server/ProfileManager/Config/var/PostgreSQL -c "update devices set \"InstalledApplicationList\" = NULL;"