Has anyone figured out a way to suppress Maps, iBooks and Photos in El Capitan yet? In previous releases Apple has copied/moved the com.apple.dockfixup.plist, unless it is being done some other way.
I use dockutil to create a custom dock and throw it into the user template before anyone logs in so that everyone at least starts out with the same dock that they can modify as they wish -- but those three apps seem to be added by Apple after the fact via some new mechanism.
I suppose I could write a policy to run once and have dockutil remove those apps, but you run into scenarios where maybe a user has modified their dock explicitly from the default to have, say "Photos" in it, and in that case we wouldn't want to remove it, since they want that. What we want is to just have a way to control the default dock the user gets after a light-image -- it was working in Yosemite.
Macintosh management makes me constantly feel like I am writing a virus.
we only apply this when we image for the first time if the users want to change it afterwards it is up to them. the only thing we have done to change the dock after is with the office issue I described since the dock icons point to a different location in 2016 from 2011 and we did not want a ton of "why doesn't this work" calls just because the icons they were used to were not pointed to the right link.
I'm running into this now, I don't recall any issues during beta. I have Maps and Photos being added at the end of the dock. I have always edited the dockfixup and the defaults file in the Dock.app in /System. Not sure how these are being added just yet. Be nice to still know.
Ahh I am forgetting! I forgot they moved the dockfixup! I'll be editing these and clearing them out!
I use dockutil to populate the dock shortly after a user logs in for the first time, doesn't seem to present too many issues except the dock disappears and reappears shortly after first login.
I did find on 10.11 that I had to delay another few seconds compared to 10.10 otherwise results were inconsistent.
@jbarnes - yep that's what we're seeing at the moment too.
We're not using dockutil but we're getting the same result.
At the end of our docks we're seeing Maps, Photos, and iBooks reappear at the end of the dock. We're suspecting com.apple.dockfixup.plist is doing this. As you mention, SIP is preventing us from modifying both the dockfixup and default plists.
Sigh. We had a package that would overwrite the System default.plist during deployment - so every new user that logged in would receive the custom dock. If we ever needed to reset their dock (if they modified it or whatever), we could just delete the local plist and call the KillAll Dock command. If we ever needed to update the default dock we just updated the plist in the package, redeployed, and ran the defaults delete / KillAll Dock commands. Life was great in Mavericks and Yosemite!! Thanks to SIP this no longer works in El Capitan and beyond. :( Reference to what we used to use: Dock Master
We may try @Look 's method of delaying the script before it applies - as we are seeing inconsistent results as well (some get the exact dock, some get the dock + the extra apps as mentioned).
Unfortunately, even after you set the dock once, these extra apps Maps, Photos, and iBooks are re-appearing after a reboot / logging back in. It's not ideal to keep resetting the dock every log in. Hmmmm, frustrating.
We may also have a look at @jrrhodes suggestion too. But this won't work for every scenario we have.
Here's my solution (if you could call it that) as a login script. Please excuse the hacky OS version handling, bash doesn't do floating point and I didn't want to figure out the crazy way you're actually supposed to deal with that. We put dockutil on the machine as part of a package in imaging, so it's already on there. This script does something the first time it realizes it is running in El Capitan, then leaves evidence so that if users add these apps back to their dock later, we don't touch them. At least, until the next release.
Also note checking to see if cfprefsd is running -- on a user's initial login, they are often in a state where the OS is doing things but is not displaying them a GUI they can work with (for instance, a user sitting at a 'do you want to log into iCloud prompt after an OS upgrade.) That's a state where dockutil doesn't function, so since the .dockfixupec file hasn't been created, the script will run again at the next login.
#!/bin/bash # Dockfixup now protected by SIP in El Capitan, have to do this at first login OSXVERSION=$(sw_vers -productVersion) echo $OSXVERSION sleep 20 if [ ! -e /Users/$3/.ut/.dockfixupec ]; then # if dock isn't active, try again another time if ! pgrep -q cfprefsd; then exit 0 fi echo "anti-dockfixup has not been run yet" if [ $OSXVERSION == "10.11" ] || [ $OSXVERSION == "10.11.1" ] || [ $OSXVERSION == "10.11.2" ] || [ $OSXVERSION == "10.11.3" ] || [ $OSXVERSION == "10.11.4" ] || [ $OSXVERSION == "10.11.5" ] || [ $OSXVERSION == "10.11.6" ] || [ $OSXVERSION == "10.11.7" ] || [ $OSXVERSION == "10.11.8" ] || [ $OSXVERSION == "10.11.9" ] then echo "os version is greater than 10.10" # if the dockfixup file evidence isn't there, and the version is el capitan, neutralize dockfixup measures. we'll need to do this again when 10.12 comes along dockutil="/Library/Application Support/UT/bin/dockutil" sudo -u $3 "$dockutil" --remove "Maps" --no-restart sleep 1 sudo -u $3 "$dockutil" --remove "Photos" --no-restart sleep 1 sudo -u $3 "$dockutil" --remove "iBooks" --no-restart sleep 1 # if we're suddenly in el capitan, this is the first the computer has seen of it and it replaced the default dock with the el cap one, so we should reconfig it sudo killall cfprefsd killall Dock # leave evidence if [ -d /Users/$3/.ut ]; then touch /Users/$3/.ut/.dockfixupec else mkdir /Users/$3/.ut touch /Users/$3/.ut/.dockfixupec fi fi fi
Even after using dockutil script given to remove the apps we're finding the test system is STILL adding Maps, Photos, and iBooks back on to the dock. The script above works of course, but these apps return after a reboot.
We suspect there's something funky happening on this particular test machine - which has received an OS X upgrade Yose -> El Capitan. Going to wipe and install El Cap fresh and re-test.
Other systems that have been Installed fresh with El Cap are not experiencing this issue.