Posted on 08-28-2013 12:29 PM
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.
Posted on 08-28-2013 01:00 PM
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.
Posted on 08-28-2013 01:47 PM
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.
Posted on 08-28-2013 03:06 PM
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.
Posted on 08-29-2013 08:54 AM
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.
Posted on 08-29-2013 09:06 AM
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.
Posted on 09-03-2013 11:10 AM
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?
Posted on 09-03-2013 11:45 AM
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
Posted on 09-03-2013 11:57 AM
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.