OneDrive for Business sync issues on EntraID devices - When "sorry" just doesn't cut it..

-
 

While working on a customer's Azure tenant, I came across an issue that I hadn't seen before. I was configuring the Intune tenant to provision Windows 11 devices using Autopilot. As part of the configuration, OneDrive for Business was also included to manage and secure user data. However, after provisioning a device, I soon started seeing issues with OneDrive failing to sync. I will only see a pop-up window displaying the message 'Sorry, OneDrive can't add your folder right now. Please contact support.'. Not really helpful. There was nothing in the Entra sign-in logs, so ruled out conditional access policies as the root cause. I also had the relevant licenses assigned so I ruled that out as well. Then I recalled that there was something similar in relation to Outlook mailbox device management setting which could interfere with Intune device management policies. Something that I also blogged about which you can check out over here. Not really like for like, but it led me in the right direction as I started to suspect that there may be something similar setup in SharePoint that could be causing this behavior. Like a legacy policy of some some sort, just like the EXO for mobiles and as it turns out, there are some settings in the SharePoint admin portal, one setting in particular, that can cause this behavior on Windows devices.

SharePoint OneDrive Sync settings

Back in the day, when most organizations were managing Windows endpoints with domain identity, the sync of OneDrive files could only be restricted to devices joined to specific domains. if you navigate to SharePoint admin Center > Settings, you will see OneDrive Sync at the bottom.



However, now that more and more organizations are adopting cloud first strategy and moving to cloud only identity for the endpoints, this sync setting can cause all kind of problems. For demonstration purposes, I added random GUID values to force the sync against a specific domain.


This obviously leads to sync issues on Entra ID joined devices, so how can one go about configuring the sync on cloud only devices without compromising on the security? The answer lies in the conditional access policy.

Conditional Access policy to manage access against Microsoft 365 Apps\OneDrive for Business

1. Sign in to the Microsoft Entra admin center.

2. Select Protection > Conditional Access.

3. Select Policies > New policy to create a new policy.

4. Create a new policy and specify the intended targeted users\groups\roles.

5. Under Target resources, select All resources or just Office 365.

6. Under Network, you can configure locations as needed.

7. Under Conditions > Device Platforms, include Windows and under exclusions, exclude all other OS platforms.



8. Under Conditions > Filter for devices, use an include filter to filter out Company owned devices. This way all non company owned\unmanaged Windows devices will get targeted for the conditional access policy.


9. Lastly, under Grant, select the Block action.


10. Enable the policy, but don't forget to test for it in 'Report-only' mode first.

End User Experience

Once the OneDrive sync setting from SharePoint is removed in favor of the conditional access policy, the OneDrive sync will start working again.



However, when the user tries to access from a non-corporate owned managed windows device, the access to OneDrive as part of Office 365, will get blocked. To emulate this behavior, I used in-private browsing to access OneDrive through Office online. Since the device registration state will be missing in this scenario, EntraID will pick this up as a non-corporate unmanaged windows device.


This can also be verified in the Entra sign-in logs.



That's it for now. Thanks for reading..

Reference:

Comments

Post a Comment

Popular posts from this blog

How to force escrowing of BitLocker recovery keys using Intune

-
Image
Every now and then it so happens that BitLocker recovery keys do not escrow in AAD. The usual culprits are incorrect BitLocker policies and\or the device hardware configuration failing to meet the minimum requirements. The other scenario and something I recently experienced is when everything is setup right and still the recovery key doesn’t escrow in AAD. As I understand, this can happen if the escrow process got interrupted the first time due to network or local devices related issues and the process could not resume. To circumvent this issue, one can simply push a PowerShell script to the devices to force the escrow of the recovery keys to AAD. Here is a script to do so. try{ $BitlockerVol = Get-BitLockerVolume -MountPoint $env:SystemDrive         $KPID=""         foreach($KP in $BitlockerVol.KeyProtector){             if($KP.KeyProtectorType -eq "RecoveryPassword"){              ...
Read more

Prevent users from running certain programs or applications on Windows endpoints using Intune

-
Image
  When it comes to blocking or preventing users from running an application on Windows devices, one normally uses App locker policy, Windows Defender Application Control and not so new but pretty useful method called Defender Vulnerability management within Microsoft 365 Defender Portal. A recent question on the Tech Community Microsoft forum prompted me to look for all possible alternatives. I started reminiscing over the legacy GPO policies and that is when I stumbled upon the policy  Don’t run specified Windows applications  located under User Administrative Templates - The policy setting does come with its own caveat - " This policy setting only prevents users from running programs that are started by the File Explorer process. It does not prevent users from running programs, such as Task Manager, which are started by the system process or by other processes. Also, if users have access to the command prompt (Cmd.exe), this policy setting does not prevent them from st...
Read more

Fixing Tamper Protection Blob Error 65000 using Microsoft Intune

-
Image
I recently encountered an issue with enabling Tamper protection as part of the implementation of Defender for Endpoint in one of customer's tenant and considering how unusual the behavior was and how I didn't encounter this before, I decide to blog my experience. If you have been battling with the same issue, then this blog may just help you. There are multiple ways to enable Tamper protection as part of MDE. One can enable at a tenant level using Defender portal or do it using Intune. I normally choose the Intune, especially when dealing with endpoints to maintain uniformity with other Defender policies being managed by Intune. However, in this particular instance, the issue started cropping randomly on some endpoints where tamper protection would not enable and throw an error code 65000, as show below. Additionally, the status in Defender will report as Unknown instead of reporting Active or something else like EDR in block mode to suggest that Defender Antimalware is running...
Read more