JamfConnect Notify (DEPNotify) - Welcome to your new MAC!!!!!

user-aQJDmstwxD
New Contributor

Through testing Notify I seem to have got my Mac stuck in an infinate loop... It never completes from the attached image.

I manually installed a custom pkg with a post install script to activate the jamf notify machanism however I dont this it ingested the Notify script to tell it what to do. So now it is stuck here. I have tried reboot several times to no avail. Can someone help me recover from this?
b0108a60b4c64669a08b87c7dbae73cf

26 REPLIES 26

Tribruin
Valued Contributor II

Try cmd-ctrl-x. That should exit the screen.

Or, if you have SSH access, login to the computer and issue the command echo "Command: Quit" >> /var/tmp/depnotify.log

This is a lifesaver....now if I could just figure out how to get past reticulating splines again.  My script won't advance past this screen

sam-sand
New Contributor III

@user-aQJDmstwxD you're likely seeing the reticulating splines again message due to the pkg that is being deployed in the Pre-stage not being a signed pkg. (Reference Package Signing)

Though, I have found an easier alternative, that seems to be maybe even a little more consistent, which is DEP Notify and the DEP Notify beginners script. You'll certainly need to read the comments throughout the script and the documentation before using, and it may seem intimidating at first as I think it's around 850 lines or so, but it's worked great for us. It also runs after the user first logs in, has a test mode option, and several other options within it. That can be found here.

sam-sand
New Contributor III

meant to tag @JureJerebic as well

We're trying to avoid using both Jamf Connect Notify as well as DEPNotify, just becomes way too confusing. I've reached out to Jamf Customer Success on how to properly sign the packages.

sam-sand
New Contributor III

Yeah, you really should only use one. We, instead of using what I know to be the original DEP Notify (what you see in the original post), use the Notify Beginner script mentioned above which kicks off via the 'enrollment complete' trigger in the Jamf Pro policy. It's honestly way easier to use and make changes versus using the signed package option in a prestage. This allows allows for your Pre-Stage to be even more lightweight.

The instructions for signing the package are also mentioned/linked in my above comment.

sam-sand
New Contributor III

@McGinn ever get your script figured out? 

@sam no, just now getting around to looking at all of this again.  I created a new script and manually put it in the location and im still having this issue.  About to jump ship on Jamf Connect Notify and just use DEPNotify as I have had no issues with that in the past.  I don't know if i want to have to re-build a package every time I want to update this script.

sam-sand
New Contributor III

I guess DEPNotify is no longer the cool thing. We still use it, because I don't have time to setup swiftDialog (the new, cool thing), and DEPNotify still accomplishes what we need it to.

It's really easy to update your script in the Jamf Pro script repo that DEPNotify uses. Honestly, it's the way to go when compared to JC Notify, IMO.

If you're interested in swiftDialog: https://snelson.us/2022/06/setup-your-mac-via-swiftdialog-1-2-1/

 

Best of luck!

Thanks, I’ll check this out for sure!

JureJerebic
Contributor

@McGinn did you ever find it out?

@JureJerebic No still no progress. I created a new script but have the same problem.  I understand how to sign a package and have that all setup.  I am test and locally placing the script file with a computer thats already enrolled/setup with Jamf Connect....still can't stop reticulating splines...again!

 

What kind of permissions do you have on your script file?

Are you still using Jamf Connect Notify or have you switched over to DEPNotify

JureJerebic
Contributor

For what it's worth, I figured out that in our case it was the case of the Jamf Connect Assets package not being signed properly in Composer. After I signed it properly and deployed it, the Notify screen and script work perfectly.

Jacek_ADC
Contributor II

Hello Guys, 

anoyone an idea for me:

yesterday I scoped our configuration profile for the DEP Notify DEP to macbooks they dont have any script installed (but they have jamf CONNECT installed but without the DEP Notify configuration). This was a mistake from my side. Then I unscoped the configuration. But the MacBooks which received the wrong configuration now starts with the DEP Notify window and stay hanging every time. When i check this MacBooks the doesnt have the configuration for DEP Notify anymore. They have the first configuration without the script path and without the autchanger -notify.

I really dont know anymore how to solve this.

I appreciate for any help

sam-sand
New Contributor III

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. 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. 

 

The first policy is 'Set AuthChanger to macOS login window'. It has a Files & Processes Payload, and I use the Execute command to run "authchanger -reset"
The second policy is 'Set AuthChanger to Jamf Connect Login Window'. It has the same payload and uses nearly the same command "authchanger -reset -jamfconnect"
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.
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).

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. 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.



Jacek_ADC
Contributor II

Hi sam-sand

THX for your fast answer. I thought exactly the same and am in the process to try.  In my DEP policys, which are triggered I already have the "autchanger -reset". But from the last experience I see, that this doesnt exactly do what I was thinking. 
For the moment I was able to reproduce this issue on a TestMachine. 

So we have two specific issues:

1. only with the DEPNotify Enrolled MacBooks - I updated yesterday the configuration with the TenantID because the information from Microsoft and Jamf. 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. The combination of this two steps inititated the DEP Notify procedure once again on all already enrolled MacBooks

2. Jamf CONNECT MacBooks which I scoped to the Jamf CONNECT DEPNotify configuration (and in this one we have the autchanger -Notify). After this (maybe one hour later) I unscoped this MacBooks because I started thinking that this will give some problems. And also here I pushed the Jamf CONNECT Update.

 

So It looks that some MacBooks from problem 2. haven't removed the wrong scoped configuration and started today with the Notify window. I will try here to push an configuration only for authchanger -connect -reset and hope that this will solve the issue.

 

We had sooner also 3 configurations like you described. 1. for the license - 1 for the connect configuration 1 for the authchanger. Now I will build everything back from only one Configuration back to three :)

sam-sand
New Contributor III

Isn't there a fourth configuration profile that you are using? One the sets authchanger to -notify and has the script path to run the script (whether or not the script is there)? 

It is kinda of sounding like that Configuration Profile is still applied to the machines, and so then it kick overs to the Notify window and the script of course doesn't run, therefore authchanger is never told to switch back to Jamf Connect login (or macOS login).

It looks in the first test, that a policy with autchanger -reset -jamfconnect works

No we do not have a fourth configuration, but on my Testmacbook I unscoped the configuration and the configuration stayed on the macbook until i have run a jamf recon.


sam-sand
New Contributor III

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?
I ask because Configuration Profiles work via the MDM communication channel and don't rely on the Jamf Binary. So running an Inventory Update on the device shouldn't force MDM communication since Inventory Information is something that uses the Jamf Binary. It's possible it is a coincidence and the Mac checked in with APNS at roughly the same time you run the Inventory Update.
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. In there, there is a separate Config Profile for DEP Notify. This is so that authchanger is correctly set, at the correct time, and so that the script can be located and executed. Here is that blog post: https://www.jamf.com/blog/zero-touch-deployment-with-jamf-pro-and-jamf-connect/

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. 

The setup I prefer to use for Jamf Connect notify is this one: https://gitlab.com/Mactroll/DEPNotify/-/tree/master/

I think it was easier to setup, plenty easy to customize, and takes a lot fewer policies and one less config profile. It also doesn't rely so much on 'daisy-chaining' policies together, which works, but it eliminates steps, which I appreciate. 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 works really well for us in our environment.

I hope one of those two links helps!

I really appreciate for your help :)

The first link you senthttps://www.jamf.com/blog/zero-touch-deployment-with-jamf-pro-and-jamf-connect/ , its exactly wat is configured from our side.

This works very fine. 

The configruration profiles are scoped directly to the prestage enrollments. But to scope it to the prestage enrollment, we have smartgroups.

 

My first try was also with depnotify, but I was unable to configure it.

 

Here is my script:

#!/bin/bash

#Variable List:
JAMFBIN="/usr/local/bin/jamf"

# Notify Mechanism:
# Change the default text displayed to the user
echo "Command: Image: /usr/local/Connect_Notify_Script/Logo_Farbig.png" >> /var/tmp/depnotify.log
echo "Command: MainTitle: Welcome to Adcubum!" >> /var/tmp/depnotify.log
echo "Command: MainText: Welcome to your new Mac.\\nSit tight as we do some basic setup to get you ready for success.\\nYou can see the status of the setup on the progress bar below." >> /var/tmp/depnotify.log

# Update the user of the status of the onboarding
echo "Status: Installing Jamf" >> /var/tmp/depnotify.log

# Check the path of the Jamf client binary.  If not present yet, wait 2 seconds and
# check again.
until [ -f $JAMFBIN ]
do
        echo "Status: Waiting on Jamf" >> /var/tmp/depnotify.log 
        sleep 2
done

# Notify the user that we will let Jamf Pro take over at this point
echo "Status: Passing command and control to Jamf Pro" >> /var/tmp/depnotify.log

# Call a custom trigger named "JamfConnectLoginInstalled" to start the onboarding 
$JAMFBIN policy -event JamfConnectLoginInstalled

Screenshot 77.jpgScreenshot 76.jpgScreenshot 75.jpg

don't be confused about the multiple connect, authchanger profiles. They were created today for fixing this issue. 

I think, that while updating jamf connect app, the authchanger will be checked and written new. I tested today with multiple configuration profiles and never had any issues after the reboot until I updated jamf connect app. 

 

I am testing from my homeoffice and I do not have any special firewall. 

sam-sand
New Contributor III

Do you have the following in the AuthChanger config profile under the "com.jamf.connect.authchanger" Preference Domain?

<?xml version="1.0" encoding="UTF-8"?>

<plist version="1.0">
<dict>
<key>Arguments</key>
<array>
<string>-reset</string>
<string>-JamfConnect</string>
<string>-Notify</string>
</array>
</dict>
</plist>



When I was using this, I had an extra Config Profile, that had the above plist info set, and my script path outlined (Titled "Jamf Connect - Run only once at Launch"). This was done so that when DEP notify was finished, and the Mark Initial run as complete ran, Inventory would update and would then add the computer to a new smart group, that was scoped to the regular Jamf Connect Login window Config Profile, and the same smart group would be excluded from the "Jamf Connect - Run only once at Launch" Config Profile. Otherwise that config profile will set authchanger as you can see above.

I'm wondering if you're missing the Run only once at launch config profile that Sean outlines in that blog post. That Config Profile should only be used during this process due to those above authchanger settings.

So when using the process outlined in Sean's blogpost, I had four Config Profiles - "JC - Run only once at launch", "JC Menubar", "JC Login Window", and "JC License".



Good Morning :)

Yes, i checked the blog now once again and I am also wondering, why I missing the Run only once at launch. I was thinking the same way yesterday as I was looking for an solution for the future. So I need to change my Notify Policys a bit. I just started yesterday :)

For my understanding:

Is it enough to reset all failed macbooks now with autchanger -reset and let it for the future or is it better to reset and set for jamf connect with authchanger -reset -jamfconnect?

Before we had (except the issues described here) authchanger -reset -jamfconnect on all MacBooks before we started with Notify. And each MacOS Update the user had to enter his credentials while the MacOS was updated. So maybe in the middle of the OS update procedure and the login mechanism on the macbooks works faster now after I tested yesterday the authchanger -reset.

So for me its important to know it for the future than I prefere to not run once in the same problems like yesterday :)


@sam-sand wrote:

Do you have the following in the AuthChanger config profile under the "com.jamf.connect.authchanger" Preference Domain?

 

<?xml version="1.0" encoding="UTF-8"?>

<plist version="1.0">
<dict>
<key>Arguments</key>
<array>
<string>-reset</string>
<string>-JamfConnect</string>
<string>-Notify</string>
</array>
</dict>
</plist>

 

 

yes I have this in the configuration profile, which is scoped to the Notify PreStage MacBooks.
Screenshot 81.jpg

and after that, this configuration profile stays on the machines. 

Your inputs helped me very well. And I really learned a lot the last two days about jamf CONNECT and Notify

Thank you very much




 

sam-sand
New Contributor III

I think you've narrowed down your issue. I would ensure you get the fourth Config Profile for Jamf Connect created (the run once profile more specifically), and then set it up in such a way that the Config Profile gets removed after it runs, as the authchanger plist seems to be causing an issue for you.

A user needing to enter in their password for a software update is standard on Monterey and I think even Big Sur. It's an Apple thing. It might be more specific to Apple Silicon, I can't exactly remember as most of our devices are Silicons running Monterey, so it's just expected. 

As for how you should be setting authchanger is up to you and your team. Including the -jamfconnect piece allows for the Jamf Connect login screen to work, which is what we want in our environment and why we pay for it. You can enable passthrough authentication as well, which enables the password used at the FileVault authentication screen (if FV is being used) to authenticate through the Jamf Connect login window for the user - this is also a preference for you and team to decide.

Something else that might be helpful would be reaching out to Customer Success to see if they can help you, or set you up with a quick run down of Jamf Connect and your different options. When we implemented Jamf Connect, we purchased some Professional Services time, and honestly it's one of the best decisions we've made. Our Pro Services engineer was fantastic, knew a ton, and helped us improve our setup tremendously. It's because of him I know more Jamf Connect settings than ever before, which has played a role in this chat thread as well.

Best of luck @Jacek_ADC . I hope the new configuration goes smoothly!

Yes, the issue is now solved.

I dont mean the password in the OS  before updating the OS. I mean after this step, when the MacBook is in the update procedure (black screen) the jamf CONNECT (IDP) Window appears and the user has to login. If he dont do this, the update do not continue.

I asked on jamf support about my question for the reset argument.

 

The idea with Customer Success is fine. We had also the professional service and we paid also for it two years ago, But our experience was not so great. 
And a lot of thins has changed in this time. But i will ask if somebody can take a look on it.

Thank you once again for your help and time

Jacek_ADC
Contributor II

Anyone know the path to the authchanger file on the macos?