Skip to main content
Solved

Don't allow apps to re-open at login in 10.9?

  • November 30, 2013
  • 14 replies
  • 27 views
A
Forum|alt.badge.img+8

We have some generic account used by different people, like a "student" account that is used by all of our elementary students. If a user opens a ton of apps, logs out and doesn't uncheck the "Re-open windows when logging back in" option, all of these apps would open the next time someone logged in with this account.

In 10.7 and 10.8, we avoided this by having a policy that runs at every logout and deletes the user's loginwindow byhost pref file (~/Library/Preferences/ByHost/com.apple.loginwindow*). This file contains the data about which apps need to be re-opened.

Even though the pref seems to be doing the same thing in 10.9, deleting it at logout doesn't appear to be sufficient to not allow the apps to re-open. If the machine is rebooted it appears to work but not if it's just logged out. I haven't been successful in determining where else the data is getting stored... it's almost like it's caching it somewhere outside of the user's folder.

Anybody run into this and/or have any ideas?

Best answer by andrew_stenehje

I'm able to do this by refreshing the pref cache. This script does the trick:

#!/bin/sh
################

# Remove pref file that contains last opened data
/bin/rm /Users/*/Library/Preferences/ByHost/com.apple.loginwindow.*

# Clears the pref cache
/usr/bin/killall cfprefsd

    14 replies

    A
    Forum|alt.badge.img+8
    • andrew_stenehje
    • Author
    • Contributor
    • Answer
    • February 12, 2014

    I'm able to do this by refreshing the pref cache. This script does the trick:

    #!/bin/sh
################

# Remove pref file that contains last opened data
/bin/rm /Users/*/Library/Preferences/ByHost/com.apple.loginwindow.*

# Clears the pref cache
/usr/bin/killall cfprefsd
    J
    Forum|alt.badge.img+7
    • jimlee
    • Contributor
    • February 21, 2014

    Couldn't you just capture the com.apple.loginwindow.plist file with the settings applied and do a FUT/FEU?

    A
    Forum|alt.badge.img+8
    • andrew_stenehje
    • Author
    • Contributor
    • February 21, 2014

    Interesting thought...

    K
    Forum|alt.badge.img+1
    • kswiedikon
    • New Contributor
    • March 31, 2014

    I do this by running:

    /usr/bin/defaults write com.apple.loginwindow TALLogoutSavesState -bool false
    A
    Forum|alt.badge.img+8

    @kswiedikon Do you run that as an ongoing logout script? I like that better than the other solution.

    K
    Forum|alt.badge.img+1
    • kswiedikon
    • New Contributor
    • April 1, 2014

    I run it as a login script (once at every login as a LaunchAgent).
    The result is, that the "re-open windows when logging back in" option is not automatically checked at logout.
    The problem: a user is able to re-check the option again manually in logout dialog

    bentoms
    Forum|alt.badge.img+35
    • bentoms
    • Hall of Fame
    • April 1, 2014

    We do that via MCX.

    This is applied @ login, so even if a user ticks it. It's unticked at next login.

    K
    Forum|alt.badge.img+7
    • krusej23
    • Contributor
    • June 16, 2014

    @bentoms Could you attach a screenshot of your mcx preference? I have tried this but it doesn't seem to work. I'm assuming I don't have something in the preference correct. Thanks!

    russeller
    Forum|alt.badge.img+16
    • russeller
    • Valued Contributor
    • June 16, 2014

    @krusej23][/url I'm not sure how @bentoms][/url does it. I had to manually create a Managed Preference under "Login Window". See below....

    external image link

    K
    Forum|alt.badge.img+7
    • krusej23
    • Contributor
    • June 16, 2014

    This apparently doesn't work at the computer level? We don't have users in our JSS so how would it work since it only works at the user level?

    russeller
    Forum|alt.badge.img+16
    • russeller
    • Valued Contributor
    • June 16, 2014

    @krusej23 As far as I know you can still apply user-level MCX to local accounts. The Managed Preferences would get applied to the account during login. If you are using JSSv9 you can limit the Managed Preferences to a specific user(s) or exclude certain local or LDAP users/groups. If you need to troubleshoot the issue, you can force jamf to compose the managed preferences with:

    jamf mcx -username name-here

    You can also check dscl to see what mcx-preferences applied:

    dscl . -mcxread /Users/name-here
    K
    Forum|alt.badge.img+7
    • krusej23
    • Contributor
    • June 16, 2014

    We just want to apply it to all computers in our district. If I set the scope to all computers and have the preference setup like you have it then it should work right?

    S
    Forum|alt.badge.img+12
    • sean
    • Contributor
    • June 17, 2014

    We manage mcx through AD, but if the mcx needs to be applied at user level, then I believe in Casper you set the mcx to user level and then scope this mcx to all of your computers. The OS will realise this is a user level mcx and apply appropriately.

    I'm not currently in a Casper environment, so if someone wants to deny/confirm.

    Q
    Forum|alt.badge.img+8
    • Qwheel
    • Valued Contributor
    • December 2, 2021

    Sorry to bring back the dead here guys perhaps someone can weigh in.

    I have a profile applied to a number of devices that does successfully untick the box for each user.

     

    I am however still having a large build up of services on devices which are cleared at system restart. But if the device submits an inventory update, it breaks the device on JAMFcloud.

    i.e Recons fail if the device has over 10000 services already listed on the JSS

    sudo launchctl list | wc -l 

    Returns a count of active services so I’m currently trying to catch a device via ARD with escalating service counts.

    I’m pretty stuck on what to do about it though.

    It was in my understanding that logout hooks are deprecated? So wasn’t using them - should I give it a go?

    it’s specifically loginwindow and security.agent services that are listed.

      Terms & ConditionsCookie settingsAccessibility statement