- MACOS YEARS USED RUNONLY TO DETECTION UPDATE
- MACOS YEARS USED RUNONLY TO DETECTION PRO
- MACOS YEARS USED RUNONLY TO DETECTION LICENSE
- MACOS YEARS USED RUNONLY TO DETECTION MAC
But to scope it to the prestage enrollment, we have smartgroups. The configruration profiles are scoped directly to the prestage enrollments. The first link you sent, its exactly wat is configured from our side. It works really well for us in our environment. There is also a test mode with this script that you can use as you build it out to see what everything will look like. It also doesn't rely so much on 'daisy-chaining' policies together, which works, but it eliminates steps, which I appreciate. I think it was easier to setup, plenty easy to customize, and takes a lot fewer policies and one less config profile. The setup I prefer to use for Jamf Connect notify is this one: It's also possible that the script that you have executing via that config profile has an authchanger command in it that may or may not be running. This is so that authchanger is correctly set, at the correct time, and so that the script can be located and executed. In there, there is a separate Config Profile for DEP Notify. In your configuration profile, do you have a command in there to change authchanger? If so, I would encourage you to look through this blog post written by Sean Rabbit.
MACOS YEARS USED RUNONLY TO DETECTION MAC
It's possible it is a coincidence and the Mac checked in with APNS at roughly the same time you run the Inventory Update.
MACOS YEARS USED RUNONLY TO DETECTION UPDATE
So running an Inventory Update on the device shouldn't force MDM communication since Inventory Information is something that uses the Jamf Binary. I ask because Configuration Profiles work via the MDM communication channel and don't rely on the Jamf Binary. Is there a smart group that the configuration profile is applied to? If so, would the test computer no longer be within scope given the smart group criteria? Now I will build everything back from only one Configuration back to three :)
MACOS YEARS USED RUNONLY TO DETECTION LICENSE
for the license - 1 for the connect configuration 1 for the authchanger. We had sooner also 3 configurations like you described.
I will try here to push an configuration only for authchanger -connect -reset and hope that this will solve the issue. haven't removed the wrong scoped configuration and started today with the Notify window. So It looks that some MacBooks from problem 2. And also here I pushed the Jamf CONNECT Update. After this (maybe one hour later) I unscoped this MacBooks because I started thinking that this will give some problems. Jamf CONNECT MacBooks which I scoped to the Jamf CONNECT DEPNotify configuration (and in this one we have the autchanger -Notify). The combination of this two steps inititated the DEP Notify procedure once again on all already enrolled MacBooksĢ. After I was finish with the Configuration I also pushed the jamf CONNECT update from 2.11 to 2.14 through the jamf CONNECT integration in jamf PRO. only with the DEPNotify Enrolled MacBooks - I updated yesterday the configuration with the TenantID because the information from Microsoft and Jamf. But from the last experience I see, that this doesnt exactly do what I was thinking.įor the moment I was able to reproduce this issue on a TestMachine.ġ. In my DEP policys, which are triggered I already have the "autchanger -reset". I thought exactly the same and am in the process to try.
I would suggest creating a policy as I mentioned above and seeing if you can get them back to using the Jamf Connect login window, or at the very least, the macOS login window. Sounds like they might be stuck on using 'authchanger -notify' still since nothing has come along to change that, which I think is part of the process outlined in setting up DEP Notify. There is no authchanger command in any of my profiles (Because I use Jamf Connect Notify, the Beginner Script by Joel Rennich), but when Jamf Connect is first installed, I believe it automatically changes authchanger for you (at least it does for me). Using these two policies allows me to keep the Jamf Connect profiles (I have three - one for the license, one for the menubar, and one for the login window) applied to the machine the entire time and I can essentially toggle them on/off as I wish.
It has the same payload and uses nearly the same command "authchanger -reset -jamfconnect" The second policy is 'Set AuthChanger to Jamf Connect Login Window'. It has a Files & Processes Payload, and I use the Execute command to run "authchanger -reset" The first policy is 'Set AuthChanger to macOS login window'.
MACOS YEARS USED RUNONLY TO DETECTION PRO
I do this via policy and actually, I have two policies setup in Jamf Pro for me to use with testing any time I need it. Once authchanger is set, you need to manually set it back and forth unless a new plist does it, otherwise it'll keep the old setting.
0 kommentar(er)
