This policy trigger is already being run

Looks to me like your AD_ComputerName_Mismatch script may have a bug in it and is hanging; so it stays running, then you run it again and get this error. Post that script if you can (please use the >_ button) and we'll help diagnose further.

Great, thanks! Here it is, as requested, @thoule.

#!/bin/sh

#!/bin/bash



####################################################################################################

declare -x appName="AD_ComputerName_Mismatch"

declare -x appVer="1.0"

declare -x appAuthor=""

declare -x appDepartment=""

declare -x appDate="27-Feb-16"

declare -x appUpdate="27-Feb-16"

declare -x templateLastModified="27-Feb-16"

####################################################################################################

#

# Copyright (c) 2015, JAMF Software, LLC.  All rights reserved.

#

#       Redistribution and use in source and binary forms, with or without

#       modification, are permitted provided that the following conditions are met:

#               * Redistributions of source code must retain the above copyright

#                 notice, this list of conditions and the following disclaimer.

#               * Redistributions in binary form must reproduce the above copyright

#                 notice, this list of conditions and the following disclaimer in the

#                 documentation and/or other materials provided with the distribution.

#               * Neither the name of the JAMF Software, LLC nor the

#                 names of its contributors may be used to endorse or promote products

#                 derived from this software without specific prior written permission.

#

#       THIS SOFTWARE IS PROVIDED BY JAMF SOFTWARE, LLC "AS IS" AND ANY

#       EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

#       WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE

#       DISCLAIMED. IN NO EVENT SHALL JAMF SOFTWARE, LLC BE LIABLE FOR ANY

#       DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES

#       (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;

#       LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND

#       ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

#       (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS

#       SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

#

####################################################################################################

#

# ABOUT THIS PROGRAM

#

# NAME:     AD_ComputerName_Mismatch.sh

#   

# SYNOPSIS: Script to match device names to record found in Active Directory.

#   

#

# DESCRIPTION:  Query Active Directory for name assigned to binding for the device and

#               compare to the name found in ComputerName, HostName, and LocalHostName.

#

####################################################################################################

#

# HISTORY:

#           - Created 27-Feb-16

#

#

# CHANGE LOG

#

#     Date          Version          Description

#--------------------------------------------------------------------------------------------------

#

####################################################################################################

#Script logging

####################################################################################################



if [ -d /Library/Logs/JAMF ]; then

    echo "Logging directory already exists."

else

    /bin/mkdir /Library/Logs/JAMF

fi

declare -x logFile="/Library/Logs/JAMF/com.casper.$appName.log"





# sends all standard output and standard error to log file.

exec >> $logFile

exec 2>&1



####################################################################################################

#

# DEFINE VARIABLES & READ IN PARAMETERS

#

####################################################################################################



computerName=`scutil --get ComputerName`

HostName=`scutil --get HostName`

adName=`dsconfigad -show | grep "Computer Account" | awk '{print $4}' | rev | cut -c 2- | rev`</``



####################################################################################################

#Script Tag:  Creates a time and date stamp for the execution of this script.

####################################################################################################



echo "-------------------------------------------"

printf "Start: $(date)

"

printf "Program name: $appName

"

printf "ProgramVersion: $appVer

"

printf "Author: $appAuthor

"

printf "Development Department: $appDepartment

"

printf "Program Creation Date: $appDate

"

printf "Program Modification date: $appUpDate

"

printf "Client serial number: $(ioreg -d 2 -c IOPlatformExpertDevice | grep "IOPlatformSerialNumber" | sed 's/        "IOPlatformSerialNumber" = //' | sed 's/"//g')

"

printf "Client name: $(hostname)

"

echo "-------------------------------------------"



####################################################################################################

# SCRIPT CONTENTS 

####################################################################################################



if [ $HostName == $computerName ]; then

    echo "Computer name matches"

else

    scutil --set ComputerName $computerName

    scutil --set HostName $computerName

    scutil --set LocalHostName $computerName

    computerName=`scutil --get ComputerName`

    echo "Computer name has been set to $computerName"

fi

I don't see any major issues, but a couple thoughts. You are setting adName, and never using that variable. And I'm not used to seeing declare -x or printf commands in Bash too often... Also, 'ComputerName' is a user friendly name like "Mike's Macbook Pro". If you try to set the HostName or LocalHostName to that, it may balk at you. LocalHostname and HostName has limitations, I think. Like no spaces or non-basic characters. Perhaps that's what's happening? Does the script run fine locally?
Todd

p.s. I have a habit of using the full path for tools like scutil (/usr/sbin/scutil) to avoid $PATH errors later.

@thoule I can certainly clean it up so no unused variables are being declared but wanted to first try running from a test machine. When I ran it locally (downloaded the shell script from my JSS, added the "*.command" extension to the filename), I received the below error.

If I run the following commands via Terminal locally or from an SSH session, I can see where the mismatch occurs. Typically after receiving the updated name from the JSS via the first policy, the mismatch is with the HostName. This first part merely shows me that state of things.

sudo scutil --get ComputerName
sudo scutil --get LocalHostName
sudo scutil --get HostName

I then correct the name(s) on an as needed basis but again, typically, it is only the HostName that needs to be updated.

sudo scutil --set ComputerName "newname"
sudo scutil --set LocalHostName "newname"
sudo scutil --set HostName "newname"

I ran the script, both locally and from Casper Remote, and couldn't get it to fail. To run locally I created a text file named "test.sh", pasted your script in, then ran:

sudo chmod 755 ./test.sh

sudo ./test.sh

I do see an issue in the JSS Script Editor, it doesn't like something with the quoting in line 99. Atom and TextWrangler don't see a syntax issue, so I don't know what is throwing the JSS for a loop.

Note the syntax color:

And now when I comment out line 99:

Ok, so maybe it's not hanging script then. I would start with a reboot to clear all processes. What do you see in /var/log/jamf.log when the second script is supposed to start? Does it say 'Executing policy 'Reset Hostname, localhostname'?

I might also add some log output at the beginning of that script just to see if it's getting invoked.

@thoule Here's what I get when running the policy from the machine. I simply open Terminal and enter "sudo jamf policy" to kick-off the check-in.

Fri Mar 04 11:36:23 dmtest-14648-r1 jamf[7055]: Checking for policies triggered by "recurring check-in"...
Fri Mar 04 11:36:26 dmtest-14648-r1 jamf[7055]: Executing Policy Reset Computer Name...
Fri Mar 04 11:36:26 dmtest-14648-r1 jamf[46]: Network state changed, checking for policies...
Fri Mar 04 11:36:26 dmtest-14648-r1 jamf[7055]: Set Computer Name to dmtest-14648
Fri Mar 04 11:36:27 dmtest-14648 jamf[7144]: Checking for policies triggered by "networkStateChange"...

So to me, it doesn't appear that it's running the second policy at all. It's worth noting that the second policy also still shows as "pending" when looking in the logs. Pardon for being naive but what do you specifically mean when you say to "add some log output in the beginning of [the] script?" Still relatively new to scripting so appreciate a little more :)

What happens if you manually trigger the policy on the target machine?

If the policy runs then there the manual trigger isn't getting called correctly in your first policy.

If it doesn't find a policy to run then the issue is with your second policy.

sudo jamf policy -event NameChange

@Josh.Smith @thoule I neglected to mention that in my testing, this very thing worked. As for this specific, most recent case, it also worked as well. Please find the screen capture below (please ignore the blank field next to "submitting log to..." as I manually removed our JSS link)!

@sepiemoini In your second screenshot the manual trigger call returns an error "This policy trigger is already being run...".

If you you do the following, do you still get the same error in the log or is it different?
1. Flush the policy logs for both policies
2. Reboot the test Mac
3. Rerun the policy

The problem in line 99 is likely in the sed command. Its doing sed 's/"//g' but the double quote within the sed command is probably being seen as a literal open quote and there's no closing one at the end of the line.
You can escape it with a backslash, but here's a better way of grabbing the serial number from ioreg. I use this code all the time in my scripts.

ioreg -rd1 -c IOPlatformExpertDevice | awk -F'"' '/IOPlatformSerialNumber/{print $4}'

The eliminates 2 pipes for grep and one sed command with a single awk to get the same info.
You might still need to escape that double quote within the awk field separator section with a backslash to prevent it from being seen as a literal open double quote. I haven't tested that so I don't know.

Edit: Also, adName can be shortened to:

adName=$(dsconfigad -show | awk '/Computer Account/{print $NF}')

@Josh.Smith @thoule No such luck, more of the same! I rebooted and flushed both policies and re-ran. Note that running the manual "sudo jamf policy –event NameChange" from the local machine worked perfectly (again).

Last login: Fri Mar 4 13:23:50 on console
dmtest-14648:~ administrator$ sudo jamf policy
Password:
Checking for policies triggered by "recurring check-in"...
Executing Policy Reset Computer Name...
Computer name (dmtest-14648-r1) does not match the record in the JSS.
Set Computer Name to dmtest-14648-r2
Running command jamf policy –event NameChange...
Result of command:
This policy trigger is already being run: root 1092 2.5 0.2 2508352 19152 s000 U+ 1:24PM 0:00.29 jamf policy

Running Recon...
Retrieving inventory preferences from <JSS_URL>...
Finding extension attributes...
Locating applications...
Searching path: /Applications
Locating hard drive information...
Locating accounts...
Locating package receipts...
Locating software updates...
Locating printers...
Locating hardware information (Mac OS X 10.11.3)...
Gathering application usage information...
Submitting data to <JSS_URL>...
<computer_id>832</computer_id>
Submitting log to <JSS_URL>
dmtest-14648:~ administrator$ sudo scutil --get ComputerName
dmtest-14648-r2
dmtest-14648:~ administrator$ sudo scutil --get LocalHostName
dmtest-14648-r2
dmtest-14648:~ administrator$ sudo scutil --get HostName
dmtest-14648
dmtest-14648:~ administrator$ sudo jamf policy -event NameChange
Checking for policies triggered by "NameChange"...
Executing Policy Reset HostName, LocalHostName...
Running script AD_ComputerName_Mismatch...
Script exit code: 0
Script result: Logging directory already exists.
Submitting log to <JSS_URL>
dmtest-14648:~ administrator$ sudo scutil --get ComputerName
dmtest-14648-r2
dmtest-14648:~ administrator$ sudo scutil --get LocalHostName
dmtest-14648-r2
dmtest-14648:~ administrator$ sudo scutil --get HostName
dmtest-14648-r2
dmtest-14648:~ administrator$

Here's the JAMF log:

Fri Mar 04 13:24:02 dmtest-14648-r1 jamfj742]: Checking for policies triggered by "networkStateChange"...
Fri Mar 04 13:24:07 dmtest-14648-r1 jamfj990]: Checking for policies triggered by "startup"...
Fri Mar 04 13:24:10 dmtest-14648-r1 jamfj1092]: Checking for policies triggered by "recurring check-in"...
Fri Mar 04 13:24:12 dmtest-14648-r1 jamfj1092]: Executing Policy Reset Computer Name...
Fri Mar 04 13:24:12 dmtest-14648-r1 jamfj47]: Network state changed, checking for policies...
Fri Mar 04 13:24:12 dmtest-14648-r1 jamfj1092]: Set Computer Name to dmtest-14648-r2
Fri Mar 04 13:24:13 dmtest-14648-r2 jamfj1217]: Checking for policies triggered by "networkStateChange"...

Anything else you'd recommend trying?

@sepiemoini I'm jumping in a little late to this discussion, but I've got a question and one suggestion. My question is, is there a specific reason you're calling another policy from a check in trigger? I see that you're running sudo jamf policy which calls the check-in trigger, and then it tries to run your custom policy trigger. I have a feeling this is the main issue, although I'm not entirely sure why. It seems like the -event called policy is being seen as an "event", same as the check-in "event" that is called before it, and it likely can't call another one while one event policy is already running.
Can you try swapping out -event with -id and putting in the policy ID instead to see if that works better? You can find the policy ID by opening it in the JSS and looking at the address in your browser. It will between the id= and an & symbol. So something like "https://your.jss.address:8443/policies.html?id=<idnumber>&o=r"

I think I see it now....the error says "jamf policy" is already being run.

    Running command jamf policy –event NameChange...

    Result of command:

This policy trigger is already being run: root             1092   2.5  0.2  2508352  19152 s000  U+    1:24PM   0:00.29 jamf policy

See below. The commands look identical, but they are calling different triggers. The first one was copied and pasted from MS Word, the second was typed in. There is a difference in the "-" character, and since the Word version of "-" isn't recognized, the first one is running "jamf policy" and ignoring the rest of the command.

$ sudo jamf policy –event test2

Checking for policies triggered by "recurring check-in" for user "username"...

No policies were found for the "recurring check-in" trigger.



$ sudo jamf policy -event test2

Checking for policies triggered by "test2" for user "username"...

No policies were found for the "test2" trigger.

Manually delete the "-" in the policy and type a new one...if I'm right then it should work.

@Josh.Smith I owe you a lot of beer. Many thanks! I can't believe it was THAT easy.

Ah.. the old autocorrect a dash to en-dash issue. Man, I hate that! :)

@sepiemoini I'm glad it it is working, it's always nice to get something fixed before the weekend!

@mm2270 nice gif!

@Josh.Smith @mm2270 I am, however, getting this on the first four clients.

Executing Policy Reset Computer Name (Part 1)...
Running command jamf policy -event NameChange...
Result of command:
sh: jamf: command not found
Running Recon...

Any thoughts? The second policy never kicks off :(

UPDATE: added "sudo" to the command but still return the same error.

Executing Policy Reset Computer Name (Part 1)...
Running command sudo jamf policy -event NameChange...
Result of command:
sudo: jamf: command not found
Running Recon...

Put the full path in to the jamf binary. Or, do you happen to have clients that haven't received the new jamf binary and location yet by any chance? You can do something in the script to locate the jamf binary's location and use that.

JAMF_BINARY=$(which jamf)

$JAMF_BINARY policy -trigger NameChange

@mm2270 I just checked and a user who received the same "sudo: jamf: command not found" error has the most up to date jamf 9.81binary--the same as our production JSS.

I am not sure how to incorporate the below code since the "sudo jamf policy -event NameChange" is being reference as an execute command in the Files and Processes payload. Where would you recommend updating the below code?

JAMF_BINARY=$(which jamf)

$JAMF_BINARY policy -trigger NameChange

@sepiemoini you can chain those together in the Execute Command box:

JAMF_BINARY=$(which jamf) && $JAMF_BINARY policy -event NameChange

That should do it. Basically, the "which jamf" will locate the jamf binary and pass it to the next part of the line, to execute the policy call.

Try putting this into the Run Command:

JAMF_BINARY=$(which jamf); $JAMF_BINARY policy -trigger NameChange

Can't confirm if that will work, but it should I think.

Edit: What @stevewood said, same idea, slightly different approach. Also note that I wrote -trigger and not -event, but these are interchangeable flags, they will do the same thing. "-trigger" is the old name that I'm having a hard time breaking from.

@stevewood @mm2270 @Josh.Smith Thanks for the great feedback! I edited the Execute Command (Files and Processes payload) in the first policy tried the following:

JAMF_BINARY=$(which jamf) && $JAMF_BINARY policy -event NameChange

And got the following for all 4-5 clients that ran the policy already:

Executing Policy Reset Computer Name (Part 1)...

Running command JAMF_BINARY=$(which jamf) && $JAMF_BINARY policy -event NameChange...

Result of command:

Running Recon...

Note that the second policy, as stated above, never runs.

UPDATE: trying sudo /usr/local/bin/jamf policy -event NameChange instead of the above since this worked locally when I established an SSH connection to one of the scoped machines. IT WORKKKKKS!!!

@sepiemoini You do not need the sudo if you are placing that in the Execute Command box. That string will be run as the root user already.

Another point I would make, is that your script starts with:

!/bin/sh

!/bin/bash

It shouldn't ! - it should be just:

!/bin/bash

(or just #!/bin/sh) but not both…
However seems to work anyway - even though having both is technically incorrect.