← PS C:\Blog\rksolutions> cd ..

OneDrive Open at Login on macOS: Why It Stopped Working

· 5 min read ·
Intune M365 Automation

A user on a freshly enrolled Mac reports that their files are not syncing. You check the device: OneDrive is installed, the configuration profile landed, and the Open at login setting is sitting right there in your Settings Catalog policy, set to True. You reboot the Mac to be sure. OneDrive does not open at login until the user launches it by hand.

The profile is fine. The setting applied. It just does not do anything anymore. OneDrive’s OpenAtLogin managed preference has been deprecated since sync app 24.113 and is a no-op on current builds - yet macOS baselines everywhere still set it and assume OneDrive launches at login. Even Microsoft’s own end-to-end guide for macOS endpoints still tells you to set Open at login: True. And the setting that looks like the obvious replacement - a Managed Login Items profile - can’t do the job either, for a reason worth understanding on its own.

This post is a snapshot of behavior I verified on-device in July 2026, on OneDrive sync app 26.113 and macOS 26.x. Re-check the referenced pages against your own builds before rolling anything out.

Table of Contents

The setting every baseline still ships

For years, making OneDrive start automatically on a managed Mac was one managed preference - Microsoft Office > Microsoft OneDrive > Open at login in Intune’s Settings Catalog:

<key>OpenAtLogin</key>
<true/>

Microsoft’s OneDrive for Mac deployment documentation now carries this note on the setting:

“The OpenAtLogin setting will be deprecated with Sync app 24.113. Please refer to Background services to configure the appropriate profile for enabling OneDrive to start automatically when the user logs in.”

The background is macOS 13 (Ventura): Apple moved login items and background services under Background Task Management (BTM), the framework behind the “Login Items & Extensions” pane in System Settings. Since then, OneDrive listens to the macOS login item system instead of its own preference. The pref still applies cleanly - defaults read will happily show you OpenAtLogin = 1 under /Library/Managed Preferences - it just no longer does anything. Nothing errors, nothing reports non-compliant, the profile shows green in Intune. OneDrive simply is not there after login.

One important scoping note: Macs that have been in use for a while do not show this. Their login item was registered long ago - back when the pref still worked, or the first time the user flipped the toggle - and that registration persists across OneDrive updates and reboots. This is purely a fresh-enrollment problem, which is exactly why it slips through: the longtime devices in your pilot group look fine while every newly provisioned Mac comes up wrong.

Managed, allowed, and still disabled

The deprecation note points at the “Background services” profile as the replacement, and that is where the second trap sits. That profile is a Managed Login Items payload (com.apple.servicemanagement) - typically an allow rule for Microsoft’s team identifier UBF8T346G9 - and on my baseline it was already deployed.

So: managed preference applied, Managed Login Items rule applied, and OneDrive still absent from System Settings > General > Login Items & Extensions after enrollment. Time to ask BTM itself, with its forensics tool sfltool:

% sfltool dumpbtm | grep -A8 "Name: OneDrive Launcher"
                 Name: OneDrive Launcher
       Developer Name: Microsoft Corporation
      Team Identifier: UBF8T346G9
                 Type: login item (0x4)
          Disposition: [disabled, allowed]
    Bundle Identifier: com.microsoft.OneDriveLauncher

(Output trimmed; the exact field layout varies a little between macOS builds. The Disposition line is what you are after.)

That disposition line is the smoking gun: [disabled, allowed]. The profile did its job - the item is allowed, the user cannot toggle it off, no nag notification. But it is still disabled, because nothing ever enabled it. Two different flags, owned by two different parties.

Allow is not enable: the BTM mental model

This is the mental model that makes the whole thing click, and it applies to far more than OneDrive:

On macOS Ventura and later, an MDM profile approves login and background items - it never enables them.

Apple’s MDM documentation describes the Managed Login Items payload as making an item “automatically approved”. What the payload does not contain is any mechanism to register a login item the app has not registered itself. Registration goes through Apple’s SMAppService API, and that call has to come from the app side, in a user context.

Layer Who controls it What it does
OpenAtLogin managed preference MDM (Settings Catalog) Nothing on sync app 24.113+ - deprecated no-op
Managed Login Items profile (com.apple.servicemanagement) MDM Allows the item: locks it on, hides the nag. Cannot enable it
SMAppService registration The app itself, as the user Actually enables the login item

Under the old model, OneDrive registered its own launcher because the pref told it to. Under the new model, it registers the login item when the user flips the toggle in OneDrive’s preferences - and on a freshly provisioned Mac, nobody has flipped it. Every layer the MDM admin controls is green, and the one layer that actually starts the app is untouched.

The fix: /createloginitem, as the signed-in user

Microsoft closed this gap in OneDrive 26.027 with two command-line arguments that programmatically register or unregister the login item:

# Register OneDrive as a login item
open -a OneDrive --args /createloginitem

# Unregister OneDrive as a login item
open -a OneDrive --args /removeloginitem

These are fire-and-exit commands: OneDrive performs the registration and immediately terminates without launching the full sync client. On my test device, /createloginitem flipped the BTM disposition from [disabled, allowed] to [enabled, allowed], and it persisted across a reboot.

Two constraints matter for deployment:

  • OneDrive 26.027 or later, macOS 13 or later. Older sync builds do not know the argument (and pre-24.113 builds still honor OpenAtLogin anyway).
  • It must run as the signed-in user. open -a targets the user’s GUI (Aqua) session. Run it as root or another local account and it fails - on my device, running it as the local admin produced a blunt Unable to find application named 'OneDrive', even though the app was right there in /Applications.

Deploying it: a ready-made Intune script

You could deploy the one-liner as-is, but on real fleets the timing is against you: the script can land before OneDrive does, the installed build can be too old, and a recurring Intune script should not keep poking OneDrive after the job is done. A guarded, idempotent version is published in Microsoft’s Intune My Macs repo as scr-app-108-onedrive-openatlogin.zsh, which:

  • No-ops until OneDrive is installed - handles the enrollment race, and means OneDrive does not need to be a required app. The script self-heals whenever OneDrive lands, by any install path.
  • No-ops below 26.027 - older builds still honor the legacy pref, so the script stays out of the way rather than launching the full app.
  • Runs the enable exactly once - a per-user marker file makes every subsequent scheduled run a cheap no-op that never re-launches OneDrive. Delete the marker to force a re-run.

Deploy it under Devices > macOS > Shell scripts with Run script as signed-in user = Yes, execution frequency every 15 minutes, 3 retries. The cadence exists purely to win the enrollment race; once the marker is down, it costs nothing.

Keep your Managed Login Items profile alongside it: the script enables the login item, the profile is what stops the user from disabling it again. You want both halves.

Verifying on a device

After the script has run for the signed-in user, check the BTM disposition (works without sudo for your own session):

% sfltool dumpbtm | grep -A8 "Name: OneDrive Launcher"
                 Name: OneDrive Launcher
       Developer Name: Microsoft Corporation
      Team Identifier: UBF8T346G9
                 Type: login item (0x4)
          Disposition: [enabled, allowed, notified]
    Bundle Identifier: com.microsoft.OneDriveLauncher

[enabled, allowed] is the healthy end state: enabled by the registration command, allowed (and locked) by the profile. OneDrive now shows up in Login Items & Extensions with the toggle greyed out, and it opens at login on the next reboot without anyone touching anything. One reading tip: OneDrive also registers developer-group (0x20) and app (0x2) entries that can legitimately show [disabled] - the login item entry, type 0x4, is the one that matters.

What this does not fix

Login-item registration gets OneDrive launched at login. It does not remove the one-time first-run experience: the user still signs in once, and macOS still asks the user to enable OneDrive’s File Provider the first time. That consent is an Apple user-privacy gate - no MDM payload, profile, or script automates it, by design. Budget for it in your onboarding communication instead of hunting for a setting that does not exist.

Conclusion

If your macOS baseline sets OneDrive’s Open at login and you are on a current sync build, that setting is doing nothing - and the Managed Login Items profile that the deprecation note points you toward can only allow the login item, never enable it. The only mechanism that actually enables it is OneDrive’s own /createloginitem command (26.027+), run as the signed-in user - deployed most easily via the ready-made scr-app-108 script in the Intune My Macs repo.

The broader lesson travels beyond OneDrive: on macOS Ventura and later, Background Task Management splits login items into an allow flag the MDM owns and an enable flag only the app (in user context) can set. Any baseline that assumes a profile alone gets an app running at login is making a bet that Apple has already voided. Audit yours with sfltool dumpbtm - [disabled, allowed] is the tell.

References

← back to all posts next: macOS LAPS vs. Intune Password Compliance... →
PS Select-String -Pattern
↑↓navigate ↵open escclose