I recently tried setting Apple Business Manager for our ≈20 people SME.
The first step was "Domain Lock/Capture" which takes over all Apple accounts for a specific domain.
I've never had a worse experience from Apple.
The process is buggy, filled with foot-guns and dead ends. It expects huge amounts of work from users who have had their account for more than a few weeks and are expected to remove a lot of their personal data before their account can be migrated (e.g. do you know how to delete all your Health data?). The process is also impossible to cancel.
Phone support was par for the course, e.g. tickets escalated to the abyss, suggestions to restore workstations to factory settings, etc.
The domain lock process was an absolute fiasco at our company. I think this could work if you did this at the time your company launched, but the moment you have employees who have Apple IDs tied to their work email that aren't from the Business Essentials system you are stuck in an impossible-to-mange place.
There are several cheap MDM solutions for Apple devices that I would rather pay for than be dependent on this. (We've used SimpleMDM and love them.)
I'm currently in that hellish process too... I don't know how to get out of it. Did you know that your employees will be forbidden from downloading from the App store once you launched that migration? It's a nightmare
Apple and MDM has always been a shit show. In the days as recently as Ventura (last time I tried it), MDM bypass was as simple as "null route 4 DNS entries during install process, remove null routing after install complete, and never be bothered by it again". This is on Apple Silicon. With no workarounds or anything, upgrades work all the way up to Tahoe.
Like really Apple, that's your device "locking"? I could test activate my work Mac with my personal Apple ID while doing this, no alarm bells, nothing, effectively "It's your laptop now".
MacOS used to be excellent for a short period of time when Fleetsmith existed. Then Apple purchased Fleetsmith around 2020 and killed the product not long after.
Fortunately around the same time, JamF ended the practice of the mandatory Jamf JumpStart (£5K fee), which finally made Jamf a feasible option for the company I was in at the time.
Of course there is a kill switch. This is one of the key features of an MDM/endpoint manager. You won't be able to sell one without it. It's also built in to apple's management protocol (which most endpoint management systems leverage) and in activesync.
You just have to secure it properly. Have limits to how many one admin can wipe etc. But trust me every company with managed IT assets has this capability. Often even in BOYD scenarios! Stryker just failed to secure access to it properly and to set sensible limits.
However, the feature isn't very effective in the field. It's very unlikely for an attacker to be smart enough to bypass the password on a stolen Mac which is needed to connect it to WiFi, yet at the same time be dumb enough to connect it to the unfiltered internet so it can receive the wipe command. The overlap between these sets of people is almost zero. We do fire a wipe at every stolen computer but I doubt it ever actually happens. If it ever happens it'll be a total end user fail (like writing the password on a post-it with the laptop)
Either you will lose it to a common thief who won't be able to breach the login (99% of cases), or to a really targeted adversary who has cellebrite or something similar and won't connect it to the internet ever again. This is still the most risky scenario because if someone like that steals it, there's bound to be something really valuable on it.
In practice this is something more suited to mobile devices.
It can be done that way, but it is definitely not the norm. Businesses will generally “purchase” (many for €0) apps in ABM that are to be used for business purposes and push those to devices, the user can then use an Apple ID to download any other apps they want for personal use.
If they’re using Managed Apple IDs they will have no access at all to the app store and won’t be able to download their own apps anymore. IT department will have to buy and assign any apps that anyone needs, even the $0 ones that only 1 person needs.
Yep. Truly horrid policy. Where I work our issued iPhones suck to use without App Store access; no Bitwarden was the killer for me personally. Everyone I checked with uses their personal email/Apple ID instead of the MAID, and there's a sword over your head if you ever accidently copy/paste something from internal emails to something like Notes which has iCloud sync (we're semi serious about leaker). Absolute failure of an MDM setup by Apple.
MDM can restrict pasteboard from managed apps to non-managed apps, as well as allowing iCloud sign-ins but restricting which iCloud services are allowed.
It's an absolute failure of the MDM server administrator for allowing such things, not on Apple.
I haven’t. Did have issued laptops that were company managed but I basically didn’t use and, in any case, I like many others reinstalled a clean operating system image and did my own support.
At most decent sized companies with a cyber security and network admin team, this is probably the fastest way to get disconnected from the internal corporate network with no way to reconnect.
I always seem to end up with local admin at the bigger places I've been at because I'm so annoying with onboarding and requesting access to download development tools.
I was talking about domain capture. If you own my apple ID just because I used the company email to register it, I will definitely consider sueing you.
Just on a personal note, tying your personal devices to your work email account is a very silly thing to do. Even if it's your company you could be locked out of your company email account at any time (HR grievance, SEC investigation, hostile takeover...) Losing access to your devices and not being able to access things like reset emails at the same time would not be fun.
This was a big pain in the ass for me to figure out. I ended up using the free version of Mosyle and hiring someone on Fiverr to help me figure out how to get the licenses assigned to our managed devices.
The Domain Capture process cannot be canceled once it’s started. It’s also not required, unless by your company policy.
The point is to make sure there’s not a mess on the other end when you enforce SSO for MAIDs.
Apple’s documentation for ABM and ABE is atrocious, but they do manage to document a bunch of footguns, just poorly and in seemingly bizarre places.
For example, ABE doesn’t support MDM migration (either as source or destination), despite the fact that the feature launched with macOS/iOS/iPadOS 26 and is supported by other MDM solutions.
And you cannot push custom config profiles with ABE which declare a non-Apple preference domain. Utter nonsense.
If you’re using the full ABM-with-ADE and MDM stack, it’s expected that you push apps to employees.
You can also use Munki to make apps available to users. You can just push only Munki via MDM if you want, and let it manage app installs and self service installs for you. There are caveats.
I did not. If I had known what would happen when we tried this we would have skipped the process entirely. Our staff (roughly 125) was so confused and it wasted a lot of time communicating about it, then trying to roll it back, etc.
> I think this could work if you did this at the time your company launched, but the moment you have employees who have Apple IDs tied to their work email that aren't from the Business Essentials system you are stuck in an impossible-to-mange place.
I had the same thing happen but with Microsoft. A friend and I had started a small consulting business and were using Google Workspace, but I needed a Microsoft account to interact with a client. I made one with my business email. None of us knew any better, but I couldn’t connect with our client’s Microsoft setup because it was a personal account. So I went to set up a business account. It was a whole fiasco and the only way I could really fix it was create an alias and use that for Microsoft.
That's why Enterprise vendors try so hard to get startups using their stuff. Lock-in is so strong. I can't imagine having a working system at a 100 person company and then trying to migrate to something else unless the current situation was truly awful.
> the moment you have employees who have Apple IDs tied to their work email that aren't from the Business Essentials system you are stuck in an impossible-to-mange place
So give all the employees an email alias they can use to create a new Apple ID for this purpose?
> I think this could work if you did this at the time your company launched
This should not be a surprise. Greenfield services have not existed long enough to resolve edge cases that inevitably arise while integrating existing operating models already in use.
My point was trying to fit a new company with no barnacles into an existing process model will always be easier than retrofitting an existing company model full of edge cases the service never had to engineer around
Not really sure why you made that point only to wave it away later saying it's always been broken regardless
Employee needs to download Microsoft Remote Desktop (sorry, Windows App) that is only distributed through App Store.
Employee does not trust the company having access to everything else in their personal iCloud account - photos, mails, messages, calendar, reminders, etc.
Employee registers a new Apple ID with company email, as it would be only used for downloading one single app.
I think the idea is that it happens before they lock the domain as a business. Before that, if you have an email address you can create a personal account with it.
I wanted to evaluate it for MDM purposes so I applied for an ABM account for a company I work for, got soft-approved, created an entirely new Apple ID (as required by the ABM), used it to log on a test device I intended to manage, then sort of forgot about it while awaiting for Apple to conclude their hard-approval for the ABM account creation.
Apple was supposed to contact the business owner to verify company details and finalize the process over the next few days, but they never did.
30 days later they canceled the ABM company account and deleted all the associated users along with the Apple ID which I used to log into a testing device, which now became a fairly expensive paperweight.
I had very little expectations about the experience and I was still disappointed.
This is exactly what I would have expected from an Apple "business" offering. Apple's whole shtick is to take away most of your choices so that they can focus on the limited number of things they still allow you to do. Businesses need the opposite of that.
Businesses will show up needing integrations with multiple existing third party (often legacy) systems with inherent complexity and then want something that allows them to manage that complexity since it can't be eliminated. It's not really possible in that context to have the experience people otherwise expect Apple to provide, and the thing Apple normally does will often make it worse by removing choices you may have needed in order to make interaction with a third party system less of a pain.
FWIW, my experience doing this process for a ~130 person org last year was pretty painless compared to other Domain Claims I've initiated for other SAAS vendors (Docusign in particular), and MDM nightmares (expired JAMF certificates, I'm looking at you).
We had to do it as ppl had made personal Apple accounts using our domain, meaning if they logged in with such an account and left, their iPhone magically transformed into an expensive, elegant paperweight. Due to a setting in our previous MDM we were unable to migrate data cleanly using Apple Biz Manager without committing to use ABM as our MDM (we couldn't) so we told people to "move it yourself following these detailed instructions, otherwise it can't be migrated." Regarding personal data like health on company-managed devices, I certainly don't share that type of info with my employer, and make it clear to staff that it's not our responsibility to migrate such data.
Can you expand on this, specifically how it compares with jamf? It is a direct competitor to jamf right? Essentially Apple vying to eat their lunch right?
Yes, as an IT professional at a company where a few people have insisted on using Macs, the ABM workflow is by far the most frustrating, half baked product I've had the displeasure of using. People love to complain about Entra/Azure AD, but ABM is another level of obtuse.
We use Apple Business Manager. Locking a domain is not a requirement if you're just doing basic MDM, I'm pretty sure. (I also had a negative experience with it, so we didn't use it and everyone just uses their personal apple IDs). Is it no longer possible to skip this step in setting up the account?
In any serious business, you don't want people to use their personal Apple IDs: that could lock their company provided devices for ever when they leave, you also don't want to buy them apps that you won't be able to re-use when they leave, ...
Maybe Something to do with Family Purchase Sharing. I didn’t realize when I bought an audio book it would appear in my dad’s library. Kind of embarrassing. Apple’s help pages make it sound very opt in but I think there are bugs where libraries are merged by default. Some say on a quiet night you can still hear Bono singing “sexy boots”…
Same here, I never even got in. I never managed to get in. My account is good enough to take my money for other things but somehow I can't manage to onboard into the damn thing so that I can actually manage devices for my company. I just gave up in the end. Couldn't get it done.
I'll try again next month see how far I get with this. This needs to be way simpler than it currently is. Hopefully they fixed a few things there.
It's completely impossible for a 60k employee shop too yeah. They also want you to rearrange the azure ad the way Apple wants. Also impossible for us.
And we have like 20k or so users with manually created Apple IDs on their company email and every one of them has to be manually resolved. It's a joke.
Genuinely curious, what were the Apple mail service issues for you?
I hate gmail and have had zero issues with my @Mac.com email in 20+ years, that I’ve noticed. Thanks
Lots and lots of missing messages. That was the big one. Anything from a SaaS just never arrived, like tickets, notifications, etc. I had random IMAP authentication failures too.
I have had the misfortune of having to get D&B numbers (for various Apple things). I believe is the source for lead lists where you start to get dozens to text and phone spam calls per day. Do not pay hundreds of dollars for this if you can at all avoid it.
Definitely avoid unless you are distributing a consumer application through the dominant app stores (App Store and Google Play) ~globally, in which case you may not be able to avoid (or avoiding will be just as much work).
Google and Apple require it for lots of mobile apps targeting certain consumer segments because some countries (eg: Brazil, IIRC? don't quote me on that) have chosen to use D&B as a qualified unique identifier of business legitimacy and it requires exposing personal information of your company's leadership to them.
I also organised this process at work, and it went rather well, (300ppl 10 year old), but of course no one had health data connected under the company domain, thats a crazy idea and it’s probably good apple enforces that to be deleted / moved / disentangled.
It is also clearly described how to move an account that is used privately to a different domain / mail.
you only need to do the domain lock part if you plan to use MAIDs. For 20 people you probably didn't need to do that, at least not at the same time as the rest. You can do it as a later step, not the first step.
Ohh we had a similar experience with Google Cloud. Added our organization and Domain into their Auth system and suddenly all users were migrated into a (invisible / transparent) workspace and could no longer use their calendar or google drive as the workspace had no free usage like you have on a normal free tier.
some years ago i tried this setup for a german company with a special char in its name („ä“) and failed because Apple was not able to match it against DUNS. It took months of support to get it done.
Our recent (ongoing) experience with Apple Business Manager is just as bad. With no reason or contact they've sent "we can't verify so we've disabled your account because you don't meet the requirements". We ring support and they tell us to try again with no additional information. We then get "we can't verify so we've deleted your accounts" with no information. "Amazing" "experience".
This is also after they've verified us (and our DUNS number) for app signing and distribution. We already have a verified account in another service of theirs!
Our company has been using Intercom for customer support for the last 7 years.
We went through several pricing changes but the bottom line always remained that pricing was usage-based.
Over the weekend, we received an email noticing us that:
- we would be forcibly migrated to seat-based pricing
- the change would happen automatically in 30 days
With our current usage of their product, this will result in us paying 3 to 4 times our current expenditure.
I'm old enough to have been through several rug pulls like this, but the magnitude of the change imposed on us and the very short notice definitely stand out.
Since these forced migrations are being rolled out quietly without any public announcement, it seems worth giving this a little due publicity. If your company hasn't yet received such an email, and you're on an old plan, this is likely coming at you fast.
I would welcome recommendations for alternative usage-based customer support solutions. We are considering moving to AWS Connect. It has usage-based pricing, and my experience with AWS gives me some confidence they will not be turning their pricing over its head any time soon.
Actually, since the RN team unbundled RN and handed maintenance of non-core libraries (e.g. filesystem, keychain, gestures...) to community maintainers, a lot of these libraries have lacked maintenance, and could really use more maintainer time.
The following example comes to mind. react-native-fs is the most popular lib for filesystem I/O. From Android 10's release in Sep 2019 until Feb 2022, all file overwrite operations on Android 10 and later would result in the file getting corrupted if the new file was smaller than the pre-existing one. Related issue: https://github.com/itinance/react-native-fs/pull/890
That's a very long 2 year and a half.
My intuition to explain this situation is that the intersection of these two is very small:
- orgs using RN, and thus willing to maintain it
- orgs staffed with experienced Java/Kotlin or ObjC/Swift developers with the good understanding of native Android/iOS APIs needed to maintain RN libraries
The nouveau project need to guarantee that anyone working on the relevant new features to hasn't had access to the Nvidia leak, to make sure the resulting implementation is a clean-room one [1].
No, and I'm not sure why the article suggests that. Under US copyright law it's best to avoid this like the plague and continue attempting a clean-room implementation.
Not a chance. Think it was either the reactos or wine project used to have processes in place to check people weren't submitting codes from the win2k leaks either.
The roadblock for nouveau is that the chipset won't allow the clocks to be set to performant frequencies unless the NVIDIA-signed binary firmware blob is uploaded.
Replacing the firmware blob too is kinda the point of the driver. Now, if also the signing key were in the dump, people could finally sign their own firmware blobs. It's probably not legal to facilitate that in any way, but how can it be proven if you don't distribute any homegrown blobs?
Edit: even if the Nvidia blob were used, it would (i) be a big departure from Mesa architecture and infrastructure and (ii) it would be illegal to distribute it. Nvidia could also introduce an arbitrary amount of protocol madness to make accessing the firmware blob as difficult as possible.
The other points still stand. And it's possible there is also a legal reason that prohibits taking apart the driver. In any case, it would defeat the purpose of having an open source driver.
> In any case, it would defeat the purpose of having an open source driver.
Not really. Having a closed-source on-card firmware blob but linking it with an open source kernel-side driver would have so many benefits, first of all not needing to depend on NVIDIA to keep up with upstream changes and stuff breaking at every kernel, xorg or whatever upgrade.
I have to admit I don't understand the relationships between SecureBoot, the Power Management Firmware and the kernel well enough to exactly say why it doesn't work.
Probably makes it harder for them, in the future any time Nvidia claims they took something from the leak they potentially have to prove in court that they didn't.
For what it's worth, Starship also does this(https://starship.rs/config/#command-duration), with the possibility to only trigger notifications for tasks running more than N seconds.
A good approach used in industrial/embedded applications: use a read-only root volume. If you don't write to your SD, you don't wear it out and have no risk of file system corruption either. It's quite a lot of work though, since most packages assume they're installed on a writeable file system.
TestPass helps outdoor companies connect with outdoor enthusiasts by making their equipment easily available for test runs and rental. We solve logistics, scheduling, or payment so brands don't have to. We're already profitable and work with major brands (Scott, Cannondale, Specialized, Petzl...) across 25 countries.
// You:
a Lead Software Engineer to take ownership of engineering, and a Full-Stack JavaScript Engineer to work and learn alongside. Both positions require proficiency in building and maintaining modern full stack Javascript web applications. Both positions are onsite in Paris, France, and allow some remote work.
The ideal candidate for Lead Software Engineer will also have:
-experience running small-to-average engineering teams and the desire to take a manager role, shaping the culture, tools and processes, and training younger colleagues.
// Stack:
Microservices-based architecture, ES2017, Node+Express, GraphQL, AngularJS, Mongo+Mongoose, Heroku, Sentry,… We maintain a RaspberryPi-hosted embedded version for our clients who use TestPass away from cellular (e.g. mountain glaciers!).
Next: React/Vue, tests+CI, embedded app overhaul
// Team:
We're a 4-person team in Paris, France, half of which works remotely: 2x Full-Stack JS, 1x Product Manger, 1x CEO. We have a fast product delivery pipeline and strive to grow an efficient, sane and sustainable work environment with proper work-life balance. Team includes a former pro mountain biker, and a former employee #2 of Stootie (300k MAU, 11M€ raised). Frequent opportunities to travel to outdoor-related destinations (e.g. Swiss Alps, French Riviera, US Rockies) where we attend & support sports/outdoor events on a regular basis. Benefits include 5 weeks paid vacation and full health benefits
// Interview process:
Phone call / coffee [30 min] >> Interview [2 hrs] + small assignment >> Onsite w/ team [half-to-full day]
TestPass helps outdoor companies connect with outdoor enthusiasts by making their equipment easily available for test runs and rental. We solve logistics, scheduling, or payment so brands don't have to. We're already profitable and work with major brands (Scott, Cannondale, Specialized, Petzl...) across 25 countries.
// You:
a Lead Software Engineer to take ownership of engineering, and a Full-Stack JavaScript Engineer to work and learn alongside. Both positions require proficiency in building and maintaining modern full stack Javascript web applications. Both positions are onsite in Paris, France, and allow some remote work.
The ideal candidate for Lead Software Engineer will also have:
-experience running small-to-average engineering teams and the desire to take a manager role, shaping the culture, tools and processes, and training younger colleagues.
// Stack:
Microservices-based architecture, ES2017, Node+Express, GraphQL, AngularJS, Mongo+Mongoose, Heroku, Sentry,… We maintain a RaspberryPi-hosted embedded version for our clients who use TestPass away from cellular (e.g. mountain glaciers!).
Next: React/Vue, tests+CI, embedded app overhaul
// Team:
We're a 4-person team in Paris, France, half of which works remotely: 2x Full-Stack JS, 1x Product Manger, 1x CEO. We have a fast product delivery pipeline and strive to grow an efficient, sane and sustainable work environment with proper work-life balance.
Team includes a former pro mountain biker, and a former employee #2 of Stootie (300k MAU, 11M€ raised).
Frequent opportunities to travel to outdoor-related destinations (e.g. Swiss Alps, French Riviera, US Rockies) where we attend & support sports/outdoor events on a regular basis.
Benefits include 5 weeks paid vacation and full health benefits
// Interview process:
Phone call / coffee [30 min] >> Interview [2 hrs] + small assignment >> Onsite w/ team [half-to-full day]
The first step was "Domain Lock/Capture" which takes over all Apple accounts for a specific domain.
I've never had a worse experience from Apple.
The process is buggy, filled with foot-guns and dead ends. It expects huge amounts of work from users who have had their account for more than a few weeks and are expected to remove a lot of their personal data before their account can be migrated (e.g. do you know how to delete all your Health data?). The process is also impossible to cancel.
Phone support was par for the course, e.g. tickets escalated to the abyss, suggestions to restore workstations to factory settings, etc.
Be warned.
reply