I have an app PKG file to deploy as a Policy in Jamf Pro. The app requires a certificate be placed on the Keychain and some System Extensions be configured. I can deploy the certificate and extensions as part of a Configuration Profile. Is there a way I can deploy both to a user's Mac so that they will have them at about the same time?
Solved
Linking a Configuration Profile and Policy
+3Best answer by ljcacioppo
Thanks. I agree the cert and extensions can be on a machine first. I would like, once a machine has the cert and extension, for it to then trigger getting the app.
You could create a smart group based on if the computer has the configuration profile that you are deploying for the cert/system extension and scope the pkg to that
+17There is no harm in the certificate and system extension being on the machine before the pkg. As long as the computer is in scope for both, I would have those deploy before the pkg personally.
+3There is no harm in the certificate and system extension being on the machine before the pkg. As long as the computer is in scope for both, I would have those deploy before the pkg personally.
Thanks. I agree the cert and extensions can be on a machine first. I would like, once a machine has the cert and extension, for it to then trigger getting the app.
+17Thanks. I agree the cert and extensions can be on a machine first. I would like, once a machine has the cert and extension, for it to then trigger getting the app.
You could create a smart group based on if the computer has the configuration profile that you are deploying for the cert/system extension and scope the pkg to that
+6You could create a smart group based on if the computer has the configuration profile that you are deploying for the cert/system extension and scope the pkg to that
This is what I've done for an application that requires the configuration profile to be installed prior to the app installation.
+3This is what I've done for an application that requires the configuration profile to be installed prior to the app installation.
Thank you both. I am trying this now. I think the only drawback is there is a delay until the computer is added to the Smart Group, but this sounds like the best option.
+24Thank you both. I am trying this now. I think the only drawback is there is a delay until the computer is added to the Smart Group, but this sounds like the best option.
Yes, there will be a delay, since profiles won't auto trigger an inventory collection. It's not like a policy where you can add in a way for inventory to be collected at the end of the deployment.
There aren't any good ways to get around that issue unfortunately.
+35Yes, there will be a delay, since profiles won't auto trigger an inventory collection. It's not like a policy where you can add in a way for inventory to be collected at the end of the deployment.
There aren't any good ways to get around that issue unfortunately.
Actually, my experience is that devices do populate in a Smart Group checking for Profile Identifier fairly quickly after the profile drops and do not require a recon at all.
I just tested myself by creating a test profile that dropped settings for Software Update. I installed on one machine, grabbed the profile identifier, and then created a Smart Group with criteria "Profile Identifier is" and the identifier. I then scoped an additional machine to the profile. The second machine showed up in the Smart Group shortly after the profile installed on the device.
YMMV, but I would test that. We use that method for deploying SentinelOne and other packages that require profiles in place first.
Actually, my experience is that devices do populate in a Smart Group checking for Profile Identifier fairly quickly after the profile drops and do not require a recon at all.
I just tested myself by creating a test profile that dropped settings for Software Update. I installed on one machine, grabbed the profile identifier, and then created a Smart Group with criteria "Profile Identifier is" and the identifier. I then scoped an additional machine to the profile. The second machine showed up in the Smart Group shortly after the profile installed on the device.
YMMV, but I would test that. We use that method for deploying SentinelOne and other packages that require profiles in place first.
Dear Stevewood,
Greetings!
We are stuck in this automate step here, where we need to push the sentinelone 2 X profiles to MAC first before installing the agent.
Can you help us with the smart group configuration steps we need to use in order to automate this which checks for 2 profiles first before pushing the agent to end PC.
BR
Amar
+35Dear Stevewood,
Greetings!
We are stuck in this automate step here, where we need to push the sentinelone 2 X profiles to MAC first before installing the agent.
Can you help us with the smart group configuration steps we need to use in order to automate this which checks for 2 profiles first before pushing the agent to end PC.
BR
Amar
Sure. I always use the Profile Identifier for Smart Groups since that should not change unless the profile is deleted and a new one is created. Where the name of the profile can be changed and that could affect Smart Group membership (ask me how I know... ;-) ).
- Deploy the profiles you need to watch for to a test machine. This is a test device that is enrolled in Jamf Pro.
- Go to the device record in Jamf Pro and look at the list of Configuration Profiles installed on the device.
- Copy the Profile Identifier for each of the profiles you are watching for:
- Create a Smart Group that looks for the presence of the profiles (you can create one group to look for both profiles, or two groups; one for each profile). The criteria is Profile Identifier:
- Use the Smart Group(s) as scope for your SentinelOne Policy.
This will give you a positive group, meaning all devices that have the profile.
In the above example that Smart Group criteria would be looking for devices that have my Jamf Connect license profile installed.
Hope that helps
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.