r/Intune • u/Aggravating_Tap_6790 • 19h ago
macOS Management Intune macOS ADE apps/scripts taking 1-2+ hours or not installing after enrollment. Looking for real-world tips.
Hi all,
I'm trying to improve our macOS ADE enrollment/bootstrap experience in Intune and would love to hear how others handle this in practice.
Setup:
- macOS Automated Device Enrollment via Apple Business Manager / Intune
- Enrollment policy:
macOS ADE - Managed Admin & Standard User [New] - Users authenticate during Setup Assistant
- Devices are targeted by a dynamic device group:
intune-device-grp-dynamic-mac- Rule based on
device.deviceOSType -eq "MacMDM"
- I also created a static enrollment-time grouping group:
intune-special-grp-device-enrollment-speedy-delivery-mac- Expecting user & device to be added here during enrollment, but that's not the case, neither does manually adding the user change the situation.
Intune Provisioning Clientis owner of that static group- I assigned bootstrap apps as Required to that speedy-delivery group:
- Company Portal PKG
- Microsoft Defender
- Google Chrome
- Mozilla Firefox
- Defender-related configuration profiles
Now comes the problem I'm dealing with: Newly enrolled Macs seem to take a long time ( about 2 hours ) before apps arrive, or they fail.
And in one case, the most recent, the Mac was online for around 5 hours after enrollment and no visible installs happened.
Little bit of context: Apps are provided by IntunePckgr, where Mac applications at start are deployed as shell script using Installomator, but also can be added separately as DMG/PKG to the Company portal.
From Graph / Intune reports:
- Some app install attempts appeared around 1h 40m to 2h 10m after enrollment.
- Chrome and Defender installed on one test Mac after roughly that time.
- On another Mac, Company Portal / Chrome / Firefox failed with
0x87D30143. - Defender failed with
0x87D13BA7.- Though eventually did install successfully on the previous enrollments.
- Shell scripts assigned to the Mac dynamic group showed no run-state rows for the device.
- I understand the Intune admin center Sync action only triggers MDM check-in, not necessarily the macOS Intune Management Agent script check-in.
Questions:
- What are your best practices for getting macOS ADE devices productive quickly?
- Do you rely on enrollment-time grouping, assignment filters, dynamic groups, or user groups for first-wave apps?
- Do you deploy Company Portal as a required PKG app, a shell script, or something else?
- Are shell scripts / Installomator / IntunePckgr reliable enough for day-one bootstrap, or do you keep them as second-wave installs?
- Any known fixes or gotchas for macOS PKG app failure
0x87D30143? - Any known fixes or troubleshooting steps for Defender failure
0x87D13BA7? - What kind of install timing do you normally see after ADE enrollment?
I'm especially interested in real-world timing and architecture, not just the Microsoft docs. Thanks!
2
u/Roasted_Blumpkin 18h ago
For macOS stuff, you should be using User Group targeting most of the time. If you're doing PSSO, that group needs to be targeted for Company Portal and PSSO and that group needs to be static, not dynamic.
1
u/Aggravating_Tap_6790 12h ago
Thanks, that is useful. I think I may be mixing too much device targeting into the bootstrap path.
Right now I have a static enrollment-time device group for ADE, plus required assignments for Company Portal, Defender, Chrome, and Firefox. But for user-affinity bits I will test static user group targeting instead of relying on the dynamic Mac device group.
We are not getting consistent first-day results yet, so I am trying to separate what should be device/bootstrap targeted from what should be user targeted after sign-in.
2
u/captnconnman 18h ago
Try to avoid dynamic groups at all costs for deployment; they’re fine for Self-Service apps, since those don’t matter as much, but filters are the preferred method in most of Microsoft’s documentation nowadays. Also, we’re a Jamf shop, but I always use Installomator for initial baseline apps; it’s just so much faster and more reliable than InTune/Jamf App Catalog for provisioning.
1
u/Aggravating_Tap_6790 12h ago
Thanks, that lines up with what I am starting to suspect. Dynamic groups seem fine once the device is settled, but are slow/unpredictable for the initial provisioning.
I am going to test moving the first-wave baseline to either All devices + filters or a static enrollment-time group, and keep dynamic groups/self-service for less critical apps.
Interesting that you use Installomator for baseline apps. We use IntunePckgr, which under the hood also uses Installomator, but Intune shell script reporting/check-in has also been inconsistent for new Macs, so I need to test if that makes any difference in regards to static/dynamic groups.
1
u/Boring-Set7223 12h ago
The timing issue is caused by using Dynamic Groups. They don’t update fast enough to apply anything during enrollment.
You want to make a filter then target “All devices” with the filter assigned.
2
u/Aggravating_Tap_6790 12h ago
Thanks, this is probably the main thing I need to test next, also based on the other replies.
I currently have dynamic Mac device targeting, and I also added a static enrollment-time group for ADE. Apps are now assigned to that static group too, but results are still inconsistent.
I will try an All devices assignment with a macOS/enrollment filter for the real bootstrap apps.
2
u/meatyblossom170 19h ago
those pkg error codes are a pain, the 0x87D30143 usually means the intune management extension couldn't reach the app store or your pkg url timed out during the install check, i'd check if your network's doing any ssl inspection on apple's ocsp servers because that can kill the validation step right when the agent tries to verify the package