We have used Jamf now for about 6 years and think it has been stable and good (earlier on-prem, now Jamf Cloud). We currently have around 1,000 Mac computers and 3,000 mobile devices. We are in the middle of changing platforms, we are leaving Novell in favor of AD with Office 365.
Those who are changing platforms, networks, etc. are thinking about whether they should have Mac, iOS devices, Android and PC under the same management tool. In this case it would be about Intune. Of course, this is not a good option for us in the Apple world, not something we would look forward to in any way. Jamf works well for us and we are satisfied.
I would need some help with what is best to lift to convince my other colleagues to keep Jamf and not move everything to Intune. Which points/functions are important to highlight in order to convince the colleagues?
In the long term, we had also intended to implement Jamf Connect or something similar to authenticate against Azure. How does it actually work? Can you log in to any Mac and a local account is created if authentication is successful or do you always have to create a local account first before you can log in at all?
Tanks in advance.
It's a heavy lift to move MDM. Very time consuming and there is hands on work that has to be done to each and every device. iOS devices will have to be wiped. Now I would make a case for moving if you are gaining 20% feature set compared to what you are, but you will be going backwards.
Single pane of glass is a lie - you can't take action on all platforms the same way. Use something like ServiceNow for inventory management, MDMs are for device management - there is a difference.
You don't use a hammer to drive a screw. Use the right tools for the job.
Jamf Connect can behave like a bind, but it is not bound to a DC - therefore it's not exactly a network account like you are used to. From what I understand, you can't make a just in time account on the Mac pulling from the IDP as you would with a bound to AD Mac. That said, in our case it's one user per device that's it - unless its a department device in which we just make the local account and they sign in to Jamf Connect (we have very few of these).
Good luck! We have been having the same fight against Workspace One for a while - so far we are winning. WS1 is WAY behind Jamf Pro.
Thnaks for your post. How does it work with all apps you have in Jamf? Can you move the to Intune? What about all scripts - bash and AppleScripts? Do you store Mac apps in the cloud or on-prem? What about Apple Classroom, does it work with Intune?
You have to rebuild all the policies. Your packages will need to be signed as unlike JAMF, Intune does not sign packages it deployed. You will need an Apple developer account to be able to sign your packages. New task sequences and work flows will be needed to deploy packages as Intune just works differently. Same goes with scrips, you will need to manually move them, and build the task sequences to make them deployable. JAMF connect will work fine with intune, you just need to manually build everything out and maintain it. I’m not sure about JAMF School.
Honestly I suggest doing some research on Microsoft learn and technet sites. After you get a handles on the basics you should try to build out Intune for yourself and validate if it’s viable for your organization. This will give you a much better idea of the pros and cons.
Retooling and retraining is a big and cost sync. As well as intune does not have anywhere near the amount of automation that JAMF has which is another hidden cost.
Those are the big things I would point out. JAMF is Apple First and Apple Only, and JAMF does everything they can to make it work well. Microsoft does not give macOS a passing thought. Intune still cannot manage Rapid Security Responses which was introduced 10 months ago if you want to go a security route.
Lastly, changing MDM platforms is no easy tasks. The most hands off method is to reinstall macOS, though through heavy touch it is possible to migrate without reimaging. iOS/iPadOS you must reimage, to treat the devices as BYOD.