jamfHelper 'fs' no longer displays over 10.9 loginwindow

[robo]

Previous to 10.9, we were able to hide/lockout the login screen by running jamfHelper with '-windowtype fs' via a LaunchAgent with its LimitLoadToSessionType property set to 'LoginWindow'. This was great for allowing a bunch of policies run on a new or rebuilt machine, before allowing the user in.

Unfortunately, with 10.9, it appears that jamfHelper's 'fs' graphics are hidden at the loginwindow. jamfHelper is clearly running, and one is blocked from entering password text to log in, but visually the login screen looks normal.

I notice that the ARD LockScreen.app (/System/Library/CoreServices/RemoteManagement/AppleVNCServer.bundle/Contents/Support/LockScreen.app/Contents/MacOS/LockScreen) still works fine at the login window if you run it with the right launchd SessionType, but it isn't as flexible as jamfHelper in terms of what it can display, so we'd rather be using jamfHelper here!

Has anyone else run into this issue, and found a workaround?

Thanks,
Robin

[franton]

It's old but it still works. http://rsug.itd.umich.edu/software/ihook/

That's what we use.

[robo]

Sorry - how does iHook help here?

[mm2270]

@robo, I just wanted to chime in that I'm seeing the same issue, sort of. In my case, it looks like it won't really load jamfHelper at the loginwindow at all, even when using the LaunchAgent with LimitLoadToSessionType set as you have. I can see that its trying to load something as the loginwindow temporarily disappears to a grey screen, but after a few moments it returns to the loginwindow as normal.

Also like you, I'm able to get the ARD LockScreen.app to show properly with this method. Apple has apparently made it nigh on impossible to get anything to run at the Login Window unless its one of their own applications. Very frustrating!

As far as LockScreen and flexibility, I can kind of get it to mimic some of how jamfHelper works by backing up the Lock.jpg image in a shell script and using sips to copy and convert another image into the same location with the same name, so "Lock.jpg". I found you can even format it as a png file to support transparency but still call it Lock.jpg and LockScreen.app respects it and uses it. The output in your shell script will complain that you're using the wrong file extension, but it still works.

The problem I'm running into is that for some reason with LockScreen up, I can't have the Mac install all available Software Updates. It tries, but fails to download the updates and exits. Without the LockScreen up, the same softwareupate -i -a or similar command works perfectly. Only difference is one has LockScreen running and the other does not, so having it up/running causes the installs to fail. And since we can't use jamfHelper anymore, I'm flat out of ideas on how to lock the LoginWindow while installing updates. Ugh! Sometimes Mavericks is a giant pain in the butt.

[gachowski]

Robin,

This is currently working for me in X.9.2

## Lock down the login window
icon="/Users/Shared/CTGDIR.jpg"
/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper -
    windowType fs -icon $icon -fullScreenIcon &

[jcompton]

This issue has to do with Apple's security frameworks, socket connections, etc. I won't go into it too deeply. In a nutshell - if you are setting at a computer and running the command from the terminal - it will work (of course you will not be able to stop it unless you hard reboot or login from a remote system). If you send the command over ARD - it "should" work. (Apple allows its own software to make the socket connection as a system level privileged helper, but I digress). However, if you are logged in via ssh from another system - it will not work. And if you run it as a policy, it will not work.

What will work -- send a package to client that installs a launch agent at /Library/LaunchAgents and a script. The script will then be able to successfully deploy jamfHelper at loginwindow. Have your script run jamfHelper, then run the policies (jamf -policy "custom trigger"), then delete itself and the LaunchAgent, then reboot.

In this example, you would install "com.mycompany.runScriptsAtLoginWindow.plist" to /Library/LaunchAgents and "runScriptsAtLoginWindow.sh" to /Library/Application Support/My Company/bin

Example Launch Agent --

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict> <key>KeepAlive</key> <true/> <key>LimitLoadToSessionType</key> <array> <string>LoginWindow</string> </array> <key>Label</key> <string>com.mycompany.runScriptsAtLoginWindow</string> <key>ProgramArguments</key> <array> <string>/Library/Application Support/My Company/bin/runScriptsAtLoginWindow.sh</string> </array> <key>RunAtLoad</key> <true/> <key>UserName</key> <string>root</string>
</dict>
</plist>

[loceee]

I going a little crazy on why I can't get this to work any more either (probably sleep deprived). My patching system was using this same technique and it was working fine. Not sure why it's stopped.

Seems launchd is just refusing to load the launchagent.

-- bootstrap setup function would write out the launchagent, copy the script to the local drive, and unset and autologin.

bootstrapSetup()
{
# write out a launchagent to call bootstrap helper
cat > "$bootstrapagent" << EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.github.munkiforjamf.junki-bootstrap</string>
    <key>RunAtLoad</key>
    <true/>
    <key>LimitLoadToSessionType</key>
    <string>LoginWindow</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Library/Scripts/junki.sh</string>
        <string>''</string>
        <string>''</string>
        <string>''</string>
        <string>--bootstraphelper</string>
    </array>
</dict>
</plist>
EOF

    # set permissions for agent
    chown root:wheel "$bootstrapagent"
    chmod 644 "$bootstrapagent"
    # copy the script to local drive
    cp "$0" /Library/Scripts/junki.sh
    chown root:wheel /Library/Scripts/junki.sh
    chmod 770 /Library/Scripts/junki.sh
    # unset any loginwindow autologin
    defaults write /Library/Preferences/com.apple.loginwindow autoLoginUser ""
    secho "bootstrap setup done, you need to restart"
}

the bootstraphelper function locks the loginwindow, spawns the --bootstrap policy and then just updates the loginwindow message with output from the bootstrap, until the agent is removed (hence bootstrap is done)

bootstrapHelper()
{
    # junki bootstrap helper
    #
    jamf policy -trigger bootstrap
    # message for loginwindow
    echo "running a recon..." > /tmp/junki-loginmessage.tmp
    while [ -f "$bootstrapagent" ]    # whilst the agent exists, we are in bootstrap mode
    do
        newmessage="$(cat /tmp/junki-loginmessage.tmp)"
        if [ "$message" != "$newmessage" ]
        then
            message="$newmessage"
            displaymsg="$computername
            $msgbootstrap

            $(date "+%H:%M:%S"): $message"
            killall jamfHelper
            "$jamfhelper" -windowType fs -description "$displaymsg" -icon "/System/Library/CoreServices/Installer.app/Contents/Resources/Installer.icns" &
            sleep 2
        fi
    done
    rm /tmp/junki-loginmessage.tmp
}

the bootstrapUpates function (called by the bootstrap policy) runs the bootstrap loop... recon, install updates, recon, restart until all updates are done.

bootstrapUpdates()
{
    spawnScript
    jamfRecon
    jamfPolicyUpdate 
    installsavail=$(defaults read "$prefs" InstallsAvail)     # check if updates are avaialble

    while [ "$installsavail" == "Yes" ]
    do
        installSoftware
        if [ -f /tmp/.junki-restart ]
        then
            secho "restarting now!"
            rm /tmp/.junki-restart
            reboot &
            return
        fi
        # we will either reboot and pickup again at loginwindow
        # or run another update and install loop
        jamfRecon
        jamfPolicyUpdate
        installsavail=$(defaults read "$prefs" InstallsAvail)
    done

    # no more updates stop boottrap
    secho "All updates installed, bootstrap complete!"
    sleep 8
    rm "$bootstrapagent"
    rm /Library/Scripts/junki.sh
    killall jamfHelper
}

[mm2270]

Looks like the just released 9.31 may have addressed this issue. Form the release notes:

JAMF Helper Fixed in v9.31: [D-006667] Fixed an issue that prevented JAMF Helper messages from being displayed at the login window if the message is configured to display in full screen mode.

FWIW, even using the LaunchAgent method outlined by jcompton above is/was not working for me when talking specifically about Mavericks. The procedure works perfectly in 10.8 or lower, but with Mavericks, it is stubbornly refusing to display a full screen jamfHellper message. If its true this was fixed in 9.31, I can't wait to try it out! Thanks JAMF!

[robo]

Can anyone running 9.31 confirm that this is fixed (on 10.8 and/or 10.9)?

[robo]

To answer the above, I tested by extracting the newer jamfHelper.app from the 9.31 JSS installer, and (running on a system that otherwise has a 9.24 version JAMF framework) it does now work as it used to on both 10.8 and 10.9. Yay!

(If anyone's interested the MacOS helper apps are in 'ROOT/bin/' and can be accessed by unzipping the ROOT.war file if you don't want to actually deploy the Tomcat webapp)

[dbrodjieski]

I'm still having a hard time getting this working in 10.9. I've upgraded the JSS to 9.32, and have tried to get the jamfHelper screen to show up at loginwindow using a launchAgent, launchDaemon, even the post-flight script in a payload-free package.

The 'LimitLoadToSessionType' key set to 'LoginWindow' doesn't seem to play nice either. When trying to manually load a launchAgent or launchDaemon with this key, it says 'nothing found to load'.

In various tests, it seems to kind of work after I type in a username and password... where the jamfHelper screen will show up, but that defeats the purpose of having the screen come up after imaging.

Just wanted to see who has had luck with this, and see if there was another trick to get this working.

[robo]

@dbrodjieski: Can you post the LaunchAgent plist and (if you're using one) the script to run jamfHelper?

AFAIK this will not work with a LaunchDaemon, nor manually (unless using more launchd trickery than I know of). You will need to use a LaunchAgent with the LoginWindow session type, and let launchd run it when the loginwindow session starts.

[dbrodjieski]

@robo: So I reviewed my launchAgent and script.. it turns out it was working, but it was very delayed in showing up. I think it's due to how my image was made, and what else it's doing on first boot. If I let the Mac sit idle for 3-5 minutes, the jamfHelper window eventually appeared. I'm doing some more research, and I think I'm having better luck now. Many thanks for the response.

[loceee]

I think this bug might be back again post 9.65... anyone else seeing any problems?

[loceee]

9.63->9.65 this changed.

Seems like this so far.... calling jamfHelper binary directly from a launchagent is working for me.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.github.patchoo-deploysetuploginlock</string>
    <key>RunAtLoad</key>
    <true/>
    <key>LimitLoadToSessionType</key>
    <string>LoginWindow</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Library/Application Support/JAMF/bin/jamfHelper.app/Contents/MacOS/jamfHelper</string>
        <string>-windowType</string>
        <string>fs</string>
        <string>-description</string>
        <string>Mac is provisioning. Do not interrupt or power off.</string>
        <string>-icon</string>
        <string>/System/Library/CoreServices/Installer.app/Contents/Resources/Installer.icns</string>
    </array>
</dict>
</plist>

but having it launched within another script, which is a "helper", which USED to work 9.63 has stopped working.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.github.patchoo-bootstrap</string>
    <key>RunAtLoad</key>
    <true/>
    <key>LimitLoadToSessionType</key>
    <string>LoginWindow</string>
    <key>ProgramArguments</key>
    <array>
        <string>/Library/Scripts/patchoo.sh</string>
        <string></string>
        <string></string>
        <string></string>
        <string>--bootstraphelper</string>
    </array>
</dict>
</plist>

from system.log

Mar  4 19:37:02 000c297d2738 WindowServer[170]: 3891612: App jamfHelper cannot order in untagged windows before login.
Mar  4 19:37:04 000c297d2738 WindowServer[170]: 3891612: App jamfHelper cannot order in untagged windows before login.

[loceee]

Actually, it's launches once, then it doesn't start again once it's killed. Leaving the loginwindow open during deployment. Ughhh.

https://github.com/patchoo/patchoo/blob/master/0patchoo.sh#L1714

It's awful strange.

[loceee]

Fixed, bug in Patchoo that didn't exhibit until 9.65. Not sure why it ever worked. :)

[emily]

I think this may be happening to us now, but both of the machines I've seen it on are 10.10.2. When running the install the fullscreen lock is only the background; the menubar and dock still appear. No messages come up. And you have to hard-power the machine to get it back up. I can't seem to figure out what the problem is. I wonder if the latest security update has anything to do with it?