All went well with my self service upgrade. I had accidentally had the policy set to "Install" instead of "Install from Cache", but the result was just a longer wait while the installer package downloaded. Once it completed the install, i logged in with my standard user and ran thru the setup process which asked for iCloud credentials(which i skipped) and that was it. Everything was pretty seamless. All hidden accounts are still there. I'm pretty pleased with this result. Should make updating all my users pretty straight forward.
One 'gotcha' i found so far is related to ADPassMon which requires the enablement of assistive devices. In Mountain Lion, this was located in System Preferences > Accessibility > Enable access for assistive devices (checkbox). In Mavericks, it is under System Preferences > Security and Privacy > Privacy > Accessibility (access is granted per app). I have yet to find the plist associated with these settings since fsventer isn't providing any direct clues.... WIll post back as I learn more.
@denmoff - You mentioned your self service update was successful, what JSS version are you running?
@josaxo - I think you're going to come up empty looking for a plist for those Accessibility settings. It seems this is yet another one of the items Apple has moved into an SQLite database file, just like Location Services items and a few other things (although I'm not really sure where this particular db is even stored yet). I ran into this same thing when working with the Mavericks developer previews, but I couldn't really mention it b/c of the NDA.
As you found, every application that tries to control the GUI needs to be authorized now by the user, at least the first time, to be added into the list. I understand this makes the OS more secure, and that's a good thing overall, but this trend of Apple moving this stuff into these db files is concerning to me, because it makes manipulating and controlling them on an enterprise level considerably harder. (Apple not thinking about the enterprise - shocking!!) There may be a way to script it, but I don't get the feeling its going to be easy.
@mm2270 wrote:
(Apple not thinking about the enterprise - shocking!!)
Well, Apple did mention "enterprise" at least once during their announcement. ;)
Don
This is the error I get on my test MBP running 10.8.4. Casper is 9.2
Executing Policy OS X 10.9 "Mavericks" Installer...
Installing Install OS X Mavericks.InstallESD.dmg...
Preparing for in-place OS upgrade...
Cannot detect version of OS X Installer. Must be 10.7 or later to deploy it as an upgrade.
Closing package...
Blessing i386 OS X System on /...
Creating Reboot Script...
@josaxo I'm running JSS version 9.2. Upgraded OS X 10.8.5 to Mavericks.
My sub 500 management account survived the upgrade on two systems that I've upgraded from 10.8 to 10.9.
I also had to reinstall JAVA afterwards.
I am testing the upgrade with an external drive running off USB 3.0. The internal drive is already 10.9 and FileVaulted. When the policy runs everything looks good but it just kicks me back to the login window. I think it has to do with the USB external SSD. I have a Mac Mini I can try.
"When the policy runs everything looks good but it just kicks me back to the login window. "
Batting about .800 on the upgrade to Mavericks. This is happening on a number of our Macs and this what I'm seeing in the logs -
Executing Policy Upgrade OS X...
[STEP 1 of 1]
Installing InstallESD.dmg...
Error: The package "InstallESD.dmg" could not be mounted (no mountable file systems).
Blessing in-place OS upgrade directory...
/OS X Install Data is not a directory
I have not opened a ticket at this time since I wanted to see if anyone else was having the same issue first.
Corbin
I've had good success so far (no failures yet), but only tested doing 10.8.x --> 10.9. I also used teh createOSXInstallpkg so I could eliminate the icloud portion at reboot and have java reloaded.
@corbin3ci
We perfected the automated method using createOSXInstallpkg by of course creating our custom installer.
Found same issue like you did on running our custom installer directly using jamf install policy. So took the installer wrapped it up using Composer into a DMG which will hide it in the OS (IE /var/.hiddenOSX or something like that).
Create an extension attribute to read the existence of the OSX install pkg and announce to user that they can install 10.9 via Self Service or you can tie it to a policy which can trigger a bash script to silently install the pkg from hidden location, delete installer pkg, and reboot the Mac so it begins the upgrade.
This is much simpler overview of what we have going on but it circumvents using the jamf binary to install the pkg and also gets rid of all the failures you are seeing.
@donmontalvo, you mentioned about the hidden admin account getting hosed. Has this happened to you before? I just set up 10.9.1 upgrade via Self-Service and after a successful OS install, my hidden admin account is completely missing from the client. My local admin account is still there, but the hidden account named "admin" is no longer present and Casper Remote fails on every attempt to authenticate.
@cstout][/url This had something to do with UID for hidden accounts being reset to 500> making them visible. Is the home directory there for your admin account?
@donmontalvo, The home directory is now missing and when I attempt to send any command from Casper Remote to this client the system.log shows:
Feb 19 08:39:48 COM-FinalTest sshd[6916]: Invalid user admin from 10.3.4.191
Feb 19 08:39:48 COM-FinalTest sshd[6916]: input_userauth_request: invalid user admin [preauth]
Feb 19 08:39:49 COM-FinalTest sshd: unknown [pam][6918]: in od_record_create(): failed: 13
Feb 19 08:39:49 COM-FinalTest sshd: unknown [pam][6918]: in od_record_create_cstring(): failed: 13
dscl shows no record for my hidden administrative account which is titled "admin." I verified on another managed 10.9.1 system that the admin account is residing properly in /private/var/admin. I ran the quickadd package again to see if that would build out the admin account again and it didn't. The strange part is that this computer is continuing to report to the JSS without issue. I don't know how that's possible if the management account is missing.
Edit: The issue is caused by an incorrect invitation string being used for the enrollment script. I created a new QuickAdd package and pulled the invitation string, updated my script, and everything is working properly. I'm one of the lucky few that is still experiencing a failure to recon properly after imaging so I rely on a script to initiate the process.
So question,
Looking for the best practice to trigger the policies to install after it runs the upgrade? I want to set a few things to run after the upgrade completes but wanted to see what others were doing to trigger this.
Gabe Shackney
Princeton Public Schools
