upgrade from casper 8.62 to casper 9.0 - issue 2 - No MCX Profiles migrated, at all

acdesigntech
Contributor II

I have a series of issues I'm running into in my upgrade testing from JSS 8.62 to JSS 9.0. I'll post each issue separately for sanitys' sake. FOr this series of issues: an "upgrade" is actually installing JSS 9 on a test server, restoring a 8.62 DB, then launching the WebApp to upgrade tables. I did not do an inplace upgrade since we are going to migrate server platforms and start from v9.0 on the new server.

Issue 2 - no MCX profiles migrated, at all. This one is pretty cut and dried - no Managed Preference Profiles migrated into v9.0. JAMF KB https://jamfnation.jamfsoftware.com/article.html?id=338 article states that only MCX settings that are not in a profile or are specified to be Manually entered will not migrate. Many of my MCXs were built from templates provided in JSS 8.62. This has not been my experience. I have tried the migration twice with the same results.

8 REPLIES 8

mm2270
Legendary Contributor III

Same issue here, doing the same with our development server and upgrading to 9. No Managed Preferences migrated.
I have to say that the KB article they posted on this is a disappointment. Its wholly insufficient to state that some items may not make it over with zero instructions or guidance on what someone might do to get around this. It just says, "it may not work" and offers no workaround. And it doesn't state that the issue may also lead to ALL Managed Preferences being lost in the upgrade, although that has happened to us and several others based on posts here. Our TAM also confirmed it may lead to this happening.

Finally, see this thread, post from @begood: https://jamfnation.jamfsoftware.com/discussion.html?id=8106
I was able to replicate the disappearing Profile issue he outlines to the letter. I had a test profile fully saved, added some settings, clicked Save, got an error and *poof*, the whole profile is gone. So there's more broken with Managed Preference than just items being lost during the upgrade apparently.

acdesigntech
Contributor II

Our TAM is saying that the entire MCX table is getting dropped on migration if there are ANY custom settings. :( JAMF support did offer the suggestion to upgrade to 8.7 first, then upgrade to 9.0 from there and it seems people have gotten better results doing it that way, but I haven't gotten to test that yet.

mm2270
Legendary Contributor III

Well, I'd like to believe that, but we were on 8.71 before the test upgrade and it didn't help us get our MCX settings over, so I'm not so sure being on 8.7 will help much. Good luck though when you try that. I'll be interested to hear how that goes for you.

hkim
Contributor II

Same here going from 8.63 to 9. I find that the order of how the database is being upgraded matters a lot though trying to make it seem like an "in place" upgrade as much as possible. So if you have a 8.63 database, you need to install 8.63 in your test environment, make sure that goes well (had to do a mysql dump instead of using the Database util because that just kept throwing errors), and then from there upgrade to 9, and then wait the in our case 8 hours for the database to update to v9 tables.

acdesigntech
Contributor II

I had wondered if the "in place" approach would work better, however I don't have much intent to do this once we migrate servers from our aging Xserves to a Windows VM. JAMF really needs to fix the entire process.

For testing purposes though, I really would like to see if we get any better results doing it the inplace way. That might be my project for tomorrow.

acdesigntech
Contributor II

Ok, so the profiles migrated once 9.01 was put in place and another restoration of the 8.62 database. My problem now is that only a single MCX is in scope for a particular Mac, even though the scoping on the MCX has not changed, and the group membership for that Mac has also not changed (I checked a second test client as well, this one meeting all of the same criteria as the first, and NO MCX profiles are in scope for it).

Is anyone else experiencing this: MCX profiles are now migrated over, but are not scoping correctly?

mm2270
Legendary Contributor III

We won't be able to do a new test upgrade against 9.01 until later this week, so we'll check if we see anything like this and report back.
While I'm glad the Preferences are coming over successfully now, I'm a little disappointed there isn't a fix in place for MCX settings using custom values. We have quite a few set up like that, so it looks like we'll need to recreate these post upgrade. Not really looking forward to that.

I'll also need to see if creating a new Managed Preference profile sticks after adding items in and saving. Hopefully they aren't being deleted anymore

acdesigntech
Contributor II

FWIW - I am seeing a lot of these types of things in our MCX profiles after the upgrade:

Level
Level at which to apply the preference. Most manual settings only work when applied at user-level or user-level enforced
User-level at every login
Value.GlobalPreferences AppleShowScrollBars

interspersed with:

Open Safe Downloads Automatically
Level
Level at which to apply the preference
User-level enforced
Open Safe Downloads Automaticallycom.apple.Safari AutoOpenSafeDownloads
TRUE to automatically open downloaded files that are of certain well-known safe types , such as images , PDF and text documents , etc.
True 
False

It looks like the latter is how Casper 9 likes to show the MCX setting, and the former is .... I don't know. Looks like a non-custom stting to me in 8.62 - though it does say that "Most manual settings only work when applied at user-level or user-level enforced" once you get into Casper 9.01:

Display Name:   Always show scroll bars
Description:    Always show the scroll bars in Finder. 10.8 only.
Apply Setting To:       User level at every login   
Domain:  ~/Library/Preferences/.GlobalPreferences
Key:     AppleShowScrollBars
Value:  Always

Guess sometimes it can't come over cleanly?

I think this one was created manually in the sense of uploading the plist to the JSS.