THIS should give you guidelines on how to demobilize accounts for Jamf Connect... I think following the guideline hyperlinked is the intended process..
The demobilization based on the guideline is a login process, instead of rebooting..
THIS should give you guidelines on how to demobilize accounts for Jamf Connect... I think following the guideline hyperlinked is the intended process..
The demobilization based on the guideline is a login process, instead of rebooting..
Yes, i am following that guide but it really doesnt specify, how that mechanism works.
I dont see a setting on the configuration profile to demobilize "on log in" , rebooting requires you to log in, right?
I am only applying this CP to demobilize , then via a smart group from the ext attribute, "no mobile account" it kicks off the Jamf Connect install. That can be set to run at logon since its a policy. and then it applies our Full Jamf Connect Configuration Profile and Jamf connect license.
I obviously can specify in a message to the end users to Make sure you log out and log back in, not Reboot. But again, I really want to automate this process and a force reboot to demobilize via the CP not a custom script would be great.
Thank you for your reply.
Yes, i am following that guide but it really doesnt specify, how that mechanism works.
I dont see a setting on the configuration profile to demobilize "on log in" , rebooting requires you to log in, right?
I am only applying this CP to demobilize , then via a smart group from the ext attribute, "no mobile account" it kicks off the Jamf Connect install. That can be set to run at logon since its a policy. and then it applies our Full Jamf Connect Configuration Profile and Jamf connect license.
I obviously can specify in a message to the end users to Make sure you log out and log back in, not Reboot. But again, I really want to automate this process and a force reboot to demobilize via the CP not a custom script would be great.
Thank you for your reply.
I'm not sure I understand the issue here... Following the guideline literally defines the mechanism of how the demobilization works.. Once you configure the setting on Jamf Connect, it states the demobilization happens in the background after the user logs in... You can track progress via EA(Extension Attribute)
Yes, i am following that guide but it really doesnt specify, how that mechanism works.
I dont see a setting on the configuration profile to demobilize "on log in" , rebooting requires you to log in, right?
I am only applying this CP to demobilize , then via a smart group from the ext attribute, "no mobile account" it kicks off the Jamf Connect install. That can be set to run at logon since its a policy. and then it applies our Full Jamf Connect Configuration Profile and Jamf connect license.
I obviously can specify in a message to the end users to Make sure you log out and log back in, not Reboot. But again, I really want to automate this process and a force reboot to demobilize via the CP not a custom script would be great.
Thank you for your reply.
Particularly this part
I'm not sure I understand the issue here... Following the guideline literally defines the mechanism of how the demobilization works.. Once you configure the setting on Jamf Connect, it states the demobilization happens in the background after the user logs in... You can track progress via EA(Extension Attribute)
The scenario is, when its applied, we are rebooting, which is what , to me , is the preferred method and its not demobilizing (sorry if i was not more clear on the issue). And after reboot is technically logging in but it doesnt demobilize after any of the reboots.
Again, trying to automate this, and forcing a reboot vs. a log off to me is preferred.
Has anyone out there actually facilitated this in their organization and possibly automated it? Or did you have your end users follow a step by step process?
Has anyone out there actually facilitated this in their organization and possibly automated it? Or did you have your end users follow a step by step process?
Working through this now because we are trying to demobilize.
Working through this now because we are trying to demobilize.
We ended up getting through this, but I wouldn't say it was fun. The challenge for us was to do all the steps within an accepted timeframe for the end users with notifications of "the next step" and the reboots needed. We ended up creating a recon policy and scoped specific smart groups it would get to the next step within the 15 minute policy check interval, without this, the next step could end up happening the next day because that would be the next time the device would inventory. Hope that makes sense.
