Most organizations like to configure OneDrive to automatically sign-in with the user’s credentials. However, this doesn’t always work when multi-factor authentication (MFA) is enabled for their accounts – this may be intentional/unintentional due to MFA targeted to All Cloud Apps (the common example that I loathe, but I’ll come back to that another time…), or it may be targeted just for the sake of protecting OneDrive in general. Either way, it would be nice to get OneDrive to still do its thing in this scenario.

You could of course look at adjusting your Conditional Access policies… perhaps you can grant access based on the device being Compliant (and still require MFA if it is not compliant). You could also look implementing Windows Hello for Business to help with some MFA-related prompts, however in some cases that is not an option – with this mind, how else can we ensure OneDive is configured for the end-user?

Custom solution

From an administrator perspective, we can of course track devices remotely with the OneDrive Sync Reports. When it comes to the end-users however, how do we make sure they are setting up OneDrive when they first get their system?

We can force them with a prompt upon login, of course. Here’s a PowerShell script that will create a Run key for the default user profile; you’ll want to assign this to devices so that it deploys during Autopilot (feel free to wrap it as a win32 app if you want to strictly track it via ESP):

If you create an intunewin with this oneDrive_SignIn.ps1 script, your install command and detection rule should be the following:

INSTALL COMMAND: powershell.exe -executionpolicy bypass .\oneDrive_SignIn.ps1

DETECTION RULE: File - C:\Windows\LaunchOneDriveWithCurrentUser.cmd

Once the user is configured in OneDrive, the next time the .cmd file runs at log on, it will determine that the Run registry value is no longer needed (and it will run: reg.exe delete HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v LaunchOneDriveWithUser /f)

One interesting thing to note – with this scenario, the user will technically see the option to enable or disable Known Folder Move (KFM). This may seem bad, but the good news is your policy enforcement of KFM will still take effect regardless of what the user selects. You can verify this by enabling the end-user notification when KFM is complete.

And that’s it. The review of Conditional Access and/or Windows Hello for Business configurations would be the first path to explore, but I like to test these workarounds when changes can’t be easily made in certain environments. Enjoy!