Skip to main content

Hi,

since monday, we have a weird issue. We have two clients, who re-enrolled themselves automatically. One on monday, one on tuesday. We tried to find similarities, but the only thing we found is, that the IDs are close together (44 & 46). Both MacBooks are in use and haven't been restarted for some day. So the re-enrollment appears to be totally random. "Last Enrollment" gets set to the actual date.

Could this maybe has something todo with the "MDM Profile Expiration Date"?

jamf.log:

 

 

 

Mon Jan 09 10:18:48 MBP0110 jamf[8235]: Removing existing launchd task /Library/LaunchDaemons/com.jamfsoftware.task.bgrecon.plist... Tue Jan 10 08:34:27 MBP0110 jamf[10088]: The SSL Certificate for https://XXX.jamfcloud.com/ must be trusted for the jamf binary to connect to it. Enrolling computer... Tue Jan 10 08:34:32 MBP0110 jamf[10107]: Skipping trustJSS command... Tue Jan 10 08:34:35 MBP0110 jamf[10107]: Error creating user: An account with the user name jadmin already exists. Tue Jan 10 08:34:35 MBP0110 jamf[10107]: The device certificate was created successfully. Tue Jan 10 08:35:00 MBP0110 jamf[10107]: Removing existing launchd task /Library/LaunchDaemons/com.jamfsoftware.task.bgrecon.plist... Tue Jan 10 08:35:01 MBP0110 jamf[10107]: Enforcing management framework... Tue Jan 10 08:35:02 MBP0110 jamf[10107]: Enforcing scheduled tasks... Tue Jan 10 08:35:02 MBP0110 jamf[10107]: Removing existing launchd task /Library/LaunchDaemons/com.jamfsoftware.task.1.plist... Tue Jan 10 08:35:02 MBP0110 jamf[10107]: Adding launchd task com.jamfsoftware.task.1... Tue Jan 10 08:35:03 MBP0110 jamf[10107]: Updating daemon settings Tue Jan 10 08:35:04 MBP0110 jamf[10107]: Flushing the /Library/Application Support/JAMF/tmp directory was successful Tue Jan 10 08:35:05 MBP0110 jamf[10107]: Removing existing launchd task /Library/Application Support/JAMF/tmp/com.jamfsoftware.task.policy.plist... Tue Jan 10 08:35:05 MBP0110 jamf[10107]: Removing existing launchd task /Library/Application Support/JAMF/tmp/com.jamfsoftware.task.launchSelfService.plist... Tue Jan 10 08:35:05 MBP0110 jamf[10107]: Enroll return code: 0 Tue Jan 10 08:35:06 MBP0110 jamf[10579]: Checking for policies triggered by "enrollmentComplete" for user "XXX"...

 

 

 

 

I do have the same issue since this morning, two users had a random re-enrolment, triggering the whole enrolment workflow. 
I also tried to look for similarities but except an uptime of more than 10 days there's nothing (no close IDs like your case). 

You might be running into PI-110355. "When sending an MDM Profile renew command to computers enrolled via a PreStage enrollment with Enrollment Customization settings configured, Jamf Pro unexpectedly reinstalls the jamf binary as well."

I know this is an older thread but just wanted to add our solution to this should someone search for the same problem.

We have also seen computers re-enrolling due to PI-110355 so I have changed our enrollment workflow to include the creation of a check file at the end called "/Users/Shared/.PrestageSetupDone". An extension attribute in Jamf will then look for this file and add the computer to a smart group. So now we have a smart group containing all the computers that have completed the Enrollment Complete triggers including our DEPNotify workflow. This smart group is then excluded from the PreStage Enrollment workflow which means that if a computer gets told to re-deploy the Jamf binaries by the Renew MDM Profile bug at least now the user will not be bothered by our DEPNotify workflow where applications are installed and the subsequent restart. I've tested this several times and if the machine is erased either manually or using Erase All Content and Settings and then re-enrolled through PreStage Enrollment the computer's inventory will be refreshed in Jamf cleaning out the "PrestageSetupDone" extension attribute and correctly triggering the enrollment workflow including DEPNotify.

I know this is an older thread but just wanted to add our solution to this should someone search for the same problem.

We have also seen computers re-enrolling due to PI-110355 so I have changed our enrollment workflow to include the creation of a check file at the end called "/Users/Shared/.PrestageSetupDone". An extension attribute in Jamf will then look for this file and add the computer to a smart group. So now we have a smart group containing all the computers that have completed the Enrollment Complete triggers including our DEPNotify workflow. This smart group is then excluded from the PreStage Enrollment workflow which means that if a computer gets told to re-deploy the Jamf binaries by the Renew MDM Profile bug at least now the user will not be bothered by our DEPNotify workflow where applications are installed and the subsequent restart. I've tested this several times and if the machine is erased either manually or using Erase All Content and Settings and then re-enrolled through PreStage Enrollment the computer's inventory will be refreshed in Jamf cleaning out the "PrestageSetupDone" extension attribute and correctly triggering the enrollment workflow including DEPNotify.


Hello
We have been experiencing this behaviour very randomly too. It has become very annoying to me and our users.  The first sign from our users is VPN no longer connects (User Certs are gone).  On the Jamf side everything looks great but the user has no profiles or certificates.
Our SVP just had another experience where the device re enrolled the binary. Profiles were not removed and the MDM cert did not update or was removed. The device shows the MDM renewal date from when the Mac was first deployed (14 months ago). 
I have an ongoing ticket with Jamf Support about this.

Terms & ConditionsCookie settingsAccessibility statement