Change Enrolled account

[ImAMacGuy]

Whats the easiest way to get a smartgroup of the machines enrolled with the wrong user name. I don't see a way to do a smartgroup off that.

[Chris_Hafner]

How do you define "wrong user name"?

[ImAMacGuy]

sorry, I was using a quickadd package that added our main local admin account, and it was overwriting the jss account. So under Managed, they are showing the wrong account/username. As I try to push people more towards using Self Service - those with the local admin account as the managed account are having problems.

[luke_j_nelson]

You'll might just have to make a Static Group based off an Advanced Search. That's the only way I see how to do it. You'd think they could just add the Managed field into the smart group criteria. Feature request?

[JPDyson]

Blast the entire environment with a QuickAdd :)

[Chris_Hafner]

Agreed. They need to be recon'ed again, whether or not you use recon itself, quickadd or a policy.

[mm2270]

We do this today with an Extension Attribute script that pulls the management account for the Mac using the Casper API. From there we have a Smart Group using something like "Management Account | Is Not | adminacct"

Those Macs then get a QuickAdd.pkg pushed down to them that uses the proper Casper service account as its management account.

While you could blast a QuickAdd out to all your managed clients, keep in mind that since JAMF changed the enrollment process embedded in the QuickAdd's to do an "enroll" and not a plain recon, you may get those Macs running policies all over again. That's one of the side affects that can happen when a Mac gets re-enrolled, which may or may not be an issue for you.

Edit: @luke.j.nelson- there already is a feature Request for this-
https://jamfnation.jamfsoftware.com/featureRequest.html?id=833

[rtrouton]

With regards to a re-enrollment possibly triggering policies to run again, that's a good argument for having your policies being ultimately tied to an Extension Attribute, the presence of an installer receipt or something else that's independent of the policy logging.

If the policy run is tied to an EA's status report, or an installer receipt being there / not being there, there's less worry about policies running again when you don't want them to.

[mm2270]

@Rich, Yeah it is a good argument for tightenning up all policies to prevent those kinds of iussues. It isn't always proactical to do this, but it could be considered best practice. I simply wanted to make sure John knew that re-running policies could occur in some cases when a Mac gets re-enrolled. We've been bite by it before, so just trying to save some hassle for others.

That said, I still don't see the necessity of running a QuickAdd against all clients just to correct what may be a small percentage of machines that aren't in compliance. If JAMF would allow us to build a Smart Group against the management account used instead of just Managed or Not Managed, this would be an easy fix. For now, we'll continue to use our EA to gather that data and scope the policy that way.

[rderewianko]

By doing a re-enrollment, do you loose the saved filevault keys on each machine?

[rderewianko]

Got a response from Jamf on this, as long as the database is the same, the filevault keys will not change.

[rderewianko]

Got a response from Jamf on this, as long as the database is the same, the filevault keys will not change.