We've followed all the instructions for setting up InTune integration with our Jamf Server on both sides. When I run the self service policy to get a Mac registered in InTune, it goes through all the steps until it gets to the JamfAAD.app where it basically stops. I've let it sit with the spinning gear for an hour with no progress at all. Here's the screenshot:
When I click on More Details, here's what it says:
Has anyone else encountered this? What app is it trying to get? Could this window be any more vague?
Have you deployed the Company Portal app to the Mac? Have a look through this thread - https://www.jamf.com/jamf-nation/discussions/28426/jamf-intune-intergration-issues - this should point you in the right direction.
Yes. The Company Portal is installed before running the registration policy. We actually get through the portal registration part but at the very end it pops up that window telling us to "Get the app". The Conditional Access setting on the Jamf Server passes the test when I click test. I'll look through that thread to see if there's any parallels, but upon a quick search I don't see anything about "get the app".
Not sure what the get the app is for.
We just got a few machines setup and the 3 main pieces are
Try this command in terminal window without using Sudo :
/Library/Application Support/JAMF/Jamf.app/Contents/MacOS/JamfAAD.app/Contents/MacOS/JamfAAD -verbose gatherAADInfo -disable-cache-read
above command will re-open Jamf AAD for registration again, once registration finished successfully, you will able to access MS office apps like one note, MS Teams, one drive etc..
Did you have company portal deployed through self service or just by installing it?
Were these machines already setup with company portal in the past?
We saw an issue where there were a lot of things left over after deleting company portal before installing it through self service. We had to go through the users library folder under Application Support, Containers, Group Containers, Keychain, Preferences and deleted everything related to company portal. After that it all worked fine.
If you go under conditional access in Jamf settings and test it, does it test out properly?
@bjhobbs What's the difference between installing (not registering!) Company Portal with Self Service or just a deployment policy? (or even manually download)
I guess, only the Intune register process have to be run from the Self Service (which itself starts Company Portal for registering).
But I also saw this "Get the app" message on a device last week. I don't remember how I fixed it (I had to kill the process). In these cases we always run a "Company Portal cleaning" script followed with the Intune registering again. This helps most of the time.
btw does anybody knows if Microsoft supports a "mixed" mode of BYOD Macs (not managed by Jamf) and Jamf managed Macs (with Intune Integration) on the same Intune tenant?
We have both Jamf unmanaged and managed Macs which are registered in Intune and everything works so far. But last week one of our BYOD Macs (which was never managed by Jamf) got a similar Conditional Access message window as above, but with the following text:
And after the user pressed "Enrol now" he was redirected to our Jamf Pro server, which should not happen. But why does Intune get the Jamf URL from the Jamf Connector for a unmanaged (BYOD) Mac?
We've made some progress, but are still stuck. We discovered that Netskope is blocking the Macs from registering with Intune. We have proven that if we disable Netskope on our Macs, the registration is successful and works as advertized. Unfortunately, we don't know how to fix it while keeping Netskope installed. Our Netskope administrator has hit a dead end on figuring out how to permit the traffic to flow freely. Has anyone else registered their Macs with Intune while Netskope is installed?
To help our Netskope admin understand the communication between our Macs and the various servers involved, I drew up this Intune Parallelogram. If it's accurate, feel free to use it yourself.
Hi @AVmcclint ,
I'm not sure if you have seen a resolution to this, but we have been working with Netskope to diagnose this as well. It looks like a certificate pinning issue that might be mitigated by setting a process based exception for "Company Portal" on Macs. The app will be added for default bypass in the near future. This did work in our case, but your's could differ.
Hey, I know this is a very old thread but would you be able to share details of how you or your team set up the "Cert Pinned App"? Ive tried every which way but Intune check-in and app deployments keep failing while Netskope is enabled.
A lot has changed since the original post. The one thing we have in place now specifically for macOS is to not decrypt the SSL from "login.microsoftonline.com". This allow(s)ed the systems to properly enroll in the Microsoft Intune Integration from Self Service.
For the cert pinning side, they excluded certain apps from being redirected through the proxy (at the time)
Just one more recent note on this, we also needed to set up an exception for "JamfAAD". We recently upgraded to Jamf Pro 10.15.1, and this process became an issue too. "Jamf Native macOS Connector" is what the dialog reported as the application.
@dmueller Could you elaborate on setting up "an exception for JamfAAD"? Is that an exception in Netskope or somewhere else? To get our setup to work, our Netskope admin essentially had to whitelist every external address that dealt with O365. It turned out that Netskope was getting in the way of a LOT of O365 communications - not just Intune enrollment.
Hi @AVmcclint , Sure thing. We had to apply the same process based exception as we did for "Company Portal" to "JamfAAD" in Netskope. I'll get you more detail on this if you like. For your O365 issues, I'm curious as to what you're seeing. We have just started some heavier testing, and these gotchas might be good to be aware of. We will be excluding the Azure auth domains from the proxy, but if you're still seeing issues after all of your whitelisting, I'll relay this to the team that is trying to bring this into our environment.
In our case it was caused by Netskope getting in the way. I had our Netskope administrator work with Netskope to get it working. Unfortunately I don’t remember what specific changes needed to be made. If you aren’t using Netskope then it could be some other tool that sits between the users and the outside world: proxy, firewalls, web filters….???
If I recall correctly, we may have had to turn off SSL decryption for the following: login.microsoftonline.com, login.microsoft.com, login.windows.net. I would definitely recommend reaching out to your Netskope admin and Netskope support as they should be able to help out.