Laptop not checking in?

[acamare10]

I have a policy to push some new printers we installed after login and startup . I have tested and it seems to be working. On this one specific user her laptop has not "checked in" or had an inventory update since early march. I have tried restarting multiple times to see if the policy pushes but I see nothing in the logs. Why hasn't the laptop checked in or had an inventory update since March? Could that be part of the issue as to why the policy is not pushing?

Thanks 

[mm2270]

Yes, it's likely the reason the printer hasn't been deployed to this Mac is because it's not checking in, especially if the trigger for that printer deployment is set to Recurring Check In. You can test to see if the communication from the Mac to Jamf Pro is broken (or working) by running some commands in Terminal directly on the Mac, if you have physical access to it.

For example, do a sudo jamf recon to start with, which should force an inventory collection on it. If you get a failure, then post back with the results. If it says something like "Device Signature Failure", it means the communication between client and server is broken and the device will likely need to be re-enrolled to fix it.

[acamare10]

Thanks I will try that out. The user used migration assistant to transfer their data to the new laptop. By any chance could that have something to do with the check in and inventory issues?

[mm2270]

In terms of Migration Assistant, was only user data transferred over, or was the entire device migrated? If the latter, does the last check in time you see in Jamf Pro match up with the date of the migration if you have that info? Generally speaking you really want to avoid using Migration Assistant, especially when talking about moving an entire device over. The Mac needs to be enrolled in Jamf Pro directly, not by any means of migrating files over. That just won't work. So, it's certainly possible this is the cause, but it's hard to say for sure without more details on when this happened and how it was done.

[acamare10]

Got it I will look for that info. From what I see the last check in does correspond with the time of the migration assistant. So if the new laptop was already enrolled in jamf pro before the migration assistant happened could that have caused an issue?

[mm2270]

Yes it's possible. Only because it's hard to know exactly what gets moved over during the migration assistant process, and it might have moved over some files, preferences or other items that overwrote what was already there from a healthily enrolled device and caused a communication break between Jamf and the Mac.

[acamare10]

What would be the best way to fix this issue and reestablish communication with jamf and the macbook?

[mm2270]

Well, first I would confirm that the communication is broken. There are other reasons a Mac might stop checking in or running new policies, although one of them I'm thinking about would have been cleared up when it was rebooted, so it's not highly likely it's still talking to Jamf but is being stopped by some other factor.

Once you determine it's broken, you will have to make some decisions on the best way to fix this.

High level, the device must be re-enrolled into Jamf, as if it was a new machine, or unenrolled and re-enrolled perhaps. How you do that may depend on how it was enrolled in the first place. If it was just user initiated enrollment, i.e., navigating to https://your.jamfserver.url/enroll or something like that, then you can repeat those steps to get it enrolled again. You may, as I said a moment ago, might need to first unenroll it before going thru that step.

If it was enrolled using Apple's automated device enrollment, then you might need to wipe the Mac and have it go through the Setup Assistant again for enrollment.

You could also try using the profiles command to initiate the enrollment again:

sudo profiles renew -type enrollment

The above is used for DEP/ADE and will in most cases, initiate the devices MDM enrollment again to "renew" it, as the command indicates.

[acamare10]

I will explore the options. For the sudo profiles renew -type enrollment command I would need to input that into terminal?

[steve_summers]

@acamare10 , yes.  To continue what @mm2270 was saying, you would need to enter that command into Terminal.  When you do, you should let the end user know that their computer will "re-walk through" your staging process (if you are using pre-stage enrollments) and that will cause the computer to set things up as if the machine was a newly staged device.  I have our L1 and L2 service desks use that command frequently and one complaint is that it resets the Dock to what a new Mac shows.  So if the end user has icons setup a certain way, they'll lose them, which can be a pain. 

[acamare10]

Got it. I noticed that when testing. It seemed to work and the laptop was checking in. Other than that the user will not lose any data or files saved?

[mm2270]

No data should be lost, unless you had some kind of odd policy re-run that did something to the user accounts. Assuming that isn't the case, then they should be fine.

[acamare10]

Sounds good. I tested by using migration assistant on a spare computer and it worked. I ran the command and it started to check in again and the printer policy went through and added all the printers. No data was lost. 

[steve_summers]

@acamare10 , no.  The user will not lose any data or files saved.  Just things on the dock may get reset.  It's always a good idea though to give your PreStage Enrollment workflow a look-over every once in a while to ensure things stay setup the way you expect.  I just don't want to say universally that you'll be fine but you have some workflow I'm not aware of.  Let us know how you get along.  :-)

[acamare10]

Sounds good. I tested by using migration assistant on a spare computer and it worked. I ran the command and it started to check in again and the printer policy went through and added all the printers. No data was lost.