Oh bugger after a bit more digging looks like casper cant handle this,

https://jamfnation.jamfsoftware.com/featureRequest.html?id=45

How have other people got around this issue with runonce for specific users groups on multiple machines..

Looks like ill just convert it to a ongoing script, If it slows down my login ill have to change it to apply to user template then self delete for the office one , dont know what ill do about the admin one yet

#!/bin/bash



if [ ! -f /Users/$3/Library/SetOfficeUsername.txt ]



then



    echo "Setting Up Office for logged in User"

    /usr/libexec/PlistBuddy -c "set 14\\\\UserInfo\\\\UserName $3" /Users/$3/Library/Preferences/com.microsoft.office.plist

    UserName=$3

    FirstName=`dscl /Active Directory/AUTUNI/All Domains -read /Users/$3 FirstName | sed 's/FirstName://'`

    LastName=`dscl /Active Directory/AUTUNI/All Domains -read /Users/$3 LastName  | sed 's/LastName://'`

    FullName=`dscl /Active Directory/AUTUNI/All Domains -read /Users/$3 RealName | sed 's/RealName://'`

    Initial1="$(echo $FirstName | head -c 1)"

    Initial2="$(echo $LastName | head -c 1)"

    Initial="$Initial1""$Initial2"

    CompanyType="AUT University"

    /usr/libexec/PlistBuddy -c "set First Name $FirstName" /Users/$3/Library/Application Support/Microsoft/Office/MeContact.plist

    /usr/libexec/PlistBuddy -c "set Last Name $LastName" /Users/$3/Library/Application Support/Microsoft/Office/MeContact.plist

    /usr/libexec/PlistBuddy -c "set Name $FullName" /Users/$3/Library/Application Support/Microsoft/Office/MeContact.plist

    /usr/libexec/PlistBuddy -c "set Initials $Initial" /Users/$3/Library/Application Support/Microsoft/Office/MeContact.plist

    /usr/libexec/PlistBuddy -c "set Business Company $CompanyType" /Users/$3/Library/Application Support/Microsoft/Office/MeContact.plist

    touch /Users/$3/Library/SetOfficeUsername.txt

else

    echo "User has been configured before"



fi



exit 0

only way I would think of to run this action is using launchd.

Create a LaunchAgent item and point to the script that gives the admin rights (which I would not recommend for the managed environment)

script should determine the logged in user is not already in admin group80. then run.

You can use Lingon to create launchd items. It is pretty staright forward.

Launchd works well for this but remember that a Launch Agent runs under the user's account. He won't be able to run a script to give himself admin privileges.

A Launch Daemon can run at login just as well and give the user the privileges he needs.

Use this to help determine whether the member is a member of the local admin group:

/usr/sbin/dseditgroup -o checkmember -m userName admin

I stand corrected. Launch Daemon is the way to go.

I have to stand corrected myself. RunAtLoad for a Launch Daemon wouldn't run at login for the user.

A different way of doing this would be to use an Extension Attribute to get a list of local admin users:

dscl . read /groups/admin GroupMembership

Then apply a policy to add the login user to the admin group if he's not a member of the result of the EA.

Be sure to re-inventory the machine to update the EA with the name of the newly added user.