"Found 2 identities in the JAMF Keychain."

I should have mentioned...Casper 8.43 running on 10.6.8 server machine with 10.6.8 clients.

JSS 8.52 on a Windows VM.
"Error signing communication - Found 2 identities in the JAMF Keychain."

Above suggestion to re-enroll (sudo jamf enroll) works as suggested.
"Previous (2) JAMF Device Identities found on this machine. Removing..."

I'm seeing the same problem. I moved a few test users to a test JSS, but I get this error:

**$ sudo jamf checkJSSConnection**
Checking availability of https://hostname.domain.com:8443/...
The JSS is available.
**$ sudo jamf policy**
Checking for policies triggered by "any"...
Gathering Policy Information from https://hostname.domain.com:8443//...

There is a problem with your syntax.

     Error: Could not connect to the JSS. Status - 401

Type "jamf help" for more information.

**$**

For obvious reasons I edited the URL to show hostname.domain.com :)

Old JSS and new test JSS are both at 8.62, and the test computer is running latest Mountain Lion OS.

Also we are using FQDN as you can see...old server is Xserve running 10.6.8 and new server is Windows Server 2008 R2...

Don

I saw this quite a bit when re-imaging our lab machines. Like 1 out of every 3... not cool. I was given these 3 potential causes for this issue in our environment.

1 - Entering the wrong JSS credentials when creating a QuickAdd PKG or when typing "sudo jamf enroll -prompt" - a JAMF.keychain will be created regardless of whether or not the device is able to enroll, but the resulting JAMF.keychain will be invalid if the JSS credentials are incorrect.

2 - Some fonts with unexpected character encodings will cause inventory collection to fail out with a 401. To identify: Enrollment will succeed, but the recon will fail. A local inventory in Recon.app will proceed normally at first, but at the end it will display a message including "There was an error submitting the computer to the JSS. The JSS responded with a status of 401." To test/fix: Disable the collection of fonts and try collecting inventory again.

3 - A "sudo jamf manage" is being run twice in rapid succession upon starting up a newly imaged machine. To identify: Typing "sudo jamf recon" in the command line will display a message about finding 2 identities in the device keychain. To fix: Re-enroll the machine to the JSS using Recon or "sudo jamf enroll -prompt". This will eliminate both existing identities for that JSS.

#3 is the the only possible option for me. I wasn't told WHY Casper is trying to do that though...

We are dealing with this right now. 8.61

The image will lay down fine but when it gets to the post flight and tries to enroll it will fail.

You can see it in the log.

Checking availability of the https://casper server
the JSS is available
Downloading the JSS CA Cert
Getting management framework from the JSS...

There was an error
Could not connect to the JSS. Status - 401

I get the same error when I run sudo jamf policy.

The 401 I think has to do with credentials being wrong.

Also of note these machines are being re imaged from before and are not fresh out of the box.

I am thinking it may have to do with that machine record in the JSS having the wrong creds?

Need to add that a sudo jamf enroll will work after the fact on that machine.

Found this.

If a valid username/password is not entered, the response status is 401 -- not authorized.

I seem to be having this issue as well - I pushed a test image to the second hard drive of an enrolled machine, and when it rebooted to that image it could not connect to the JSS. I pushed our QuickAdd.pkg to it, which updated it. Then, after the user booted back to the main drive, the previously enrolled machine suddenly throws the same - 401 error?

Running sudo jamf enroll brought it back again...but I'm wondering now if it's going to drop enrollment again when it's booted back to the test side?

I don't know if it helps, I had clients failing to enroll after imaging. BUT I could get them to enroll manually using recon.

I called JAMF support, and they found the error message "Error signing communication - Found 2 identities in the JAMF Keychain." it turned out the client I used to create my image had at some point been enrolled in the JSS. (which was why two keychains were getting generated.)

So I started over, created a new blank base os with the os installer, and made sure that at no point did it get enrolled in the JSS. With the new image, I did not have the issue.

^^ ^ What version of casper are you guys running ?

The issue was resolved for us in 8.61.

8.62 here.

I'm seeing these random issues and have tried to re-enroll systems but still happens.

I've been seeing this happen more often on new systems or systems that tend to run multiple policies and from the look of it, looks to be related to JAMF keychain. It looks as if the policy runs longer than the keychain will remain open thus giving the error the communication was not signed or un-authorized. If I rerun the same policies all tend to run correctly and subsequent Macs that only need to run one or two policies work with no issue.

I do have the fix for keychain issue that was seen early in 8.6 but this seems to be a whole different beast.

We ran into this as well, possibly due to the image creation process. Our solution was to add the jamf enroll command to the end of our post image script so that the last thing is does is run the "enroll" before flushing cache, etc...then reboots