<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Onedrive on Eriteach | Microsoft Cloud Tech</title><link>https://blog.eriteach.com/en/tags/onedrive/</link><description>Recent content in Onedrive on Eriteach | Microsoft Cloud Tech</description><generator>Hugo -- 0.155.1</generator><language>en</language><copyright>2024-2026 Robel Mehari. All rights reserved.</copyright><lastBuildDate>Sat, 20 Jun 2026 23:30:07 +0200</lastBuildDate><atom:link href="https://blog.eriteach.com/en/tags/onedrive/index.xml" rel="self" type="application/rss+xml"/><item><title>OneDrive Moving to onedrive.cloud.microsoft: What Admins Should Check First</title><link>https://blog.eriteach.com/en/posts/onedrive-cloud-microsoft-domain/</link><pubDate>Wed, 17 Jun 2026 00:00:00 +0000</pubDate><guid>https://blog.eriteach.com/en/posts/onedrive-cloud-microsoft-domain/</guid><description>OneDrive moves to onedrive.cloud.microsoft from July 2026. Review allowlists, Tenant Restrictions, proxy rules, and URL-based policies before users see errors.</description><content:encoded><![CDATA[<h2 id="the-problem">The Problem</h2>
<p>Microsoft is moving OneDrive web experiences from the old tenant-specific OneDrive URL pattern to the unified <code>onedrive.cloud.microsoft</code> domain.</p>
<p>The message center notice shared by M365 Admin says rollout starts in early July 2026 and is expected to complete by late June 2027. Existing OneDrive links continue to work, and the old and new domains will exist side by side.</p>
<p>That sounds simple. But this is exactly the kind of change where the Microsoft service is fine and the local admin controls create the error.</p>
<p>If a tenant has URL-based allowlists, proxy rules, browser controls, Conditional Access App Control, or custom tools that assume <code>contoso-my.sharepoint.com</code>, users may see sign-in loops, blocked pages, broken previews, or confusing helpdesk tickets when the browser starts showing <code>onedrive.cloud.microsoft</code>.</p>
<h2 id="environment">Environment</h2>
<p>This post is written for Microsoft 365 admins managing OneDrive, Entra ID, Microsoft Intune, Defender for Cloud Apps, network filtering, and browser policies.</p>
<p>The important distinction is this:</p>
<table>
  <thead>
      <tr>
          <th>Area</th>
          <th>Expected behavior</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>User-facing OneDrive web URL</td>
          <td>Users may start seeing <code>onedrive.cloud.microsoft</code></td>
      </tr>
      <tr>
          <td>Existing links and bookmarks</td>
          <td>Continue to work</td>
      </tr>
      <tr>
          <td>SharePoint storage URL</td>
          <td>Still uses the SharePoint/OneDrive backing URL pattern</td>
      </tr>
      <tr>
          <td>Microsoft Graph and official APIs</td>
          <td>No URL-pattern change expected</td>
      </tr>
      <tr>
          <td>Custom tools parsing browser URLs</td>
          <td>Need review</td>
      </tr>
  </tbody>
</table>
<h2 id="what-i-checked-first">What I Checked First</h2>
<p>I would not start by changing every policy. I would first search for anything that explicitly references the old OneDrive host pattern.</p>
<p>Examples:</p>
<ul>
<li><code>*-my.sharepoint.com</code></li>
<li><code>contoso-my.sharepoint.com</code></li>
<li><code>sharepoint.com/personal/</code></li>
<li>hardcoded OneDrive browser URLs in scripts, apps, documentation, or proxy rules</li>
</ul>
<p>The risk is not that OneDrive storage stops working. The risk is that a security or network control written around the old browser URL blocks the new trusted Microsoft domain.</p>
<h2 id="policies-that-can-conflict">Policies That Can Conflict</h2>
<p>These are the controls I would review before rollout reaches users.</p>
<table>
  <thead>
      <tr>
          <th>Control area</th>
          <th>What can break</th>
          <th>What to check</th>
      </tr>
  </thead>
  <tbody>
      <tr>
          <td>Firewall, proxy, DNS filtering, SSL inspection</td>
          <td><code>onedrive.cloud.microsoft</code> is blocked or inspected differently</td>
          <td>Allow <code>*.cloud.microsoft</code> where Microsoft 365 traffic is allowed</td>
      </tr>
      <tr>
          <td>Microsoft Edge URL allow/block lists from Intune</td>
          <td>Browser blocks the new URL even though the service is valid</td>
          <td>Check <code>URLAllowlist</code>, <code>URLBlocklist</code>, and any managed extension rules</td>
      </tr>
      <tr>
          <td>Defender for Cloud Apps / Conditional Access App Control</td>
          <td>Session control, reverse proxy, or app recognition behaves differently</td>
          <td>Test OneDrive browser access with the new domain and existing session policies</td>
      </tr>
      <tr>
          <td>Tenant Restrictions v2</td>
          <td>Cross-tenant or proxy-header rules do not account for the new cloud domain</td>
          <td>Confirm TRv2 proxy/header path does not block <code>cloud.microsoft</code> endpoints</td>
      </tr>
      <tr>
          <td>Defender for Endpoint web content filtering / indicators</td>
          <td>Custom URL indicators block or fail to classify the new domain</td>
          <td>Search custom indicators and category exceptions</td>
      </tr>
      <tr>
          <td>Purview DLP / Endpoint DLP browser restrictions</td>
          <td>Upload/download controls depend on allowed service domains or browser context</td>
          <td>Test sensitive file upload, download, and external sharing flows</td>
      </tr>
      <tr>
          <td>Third-party CASB, SWG, or secure browser tools</td>
          <td>Tool recognizes SharePoint URL but not <code>onedrive.cloud.microsoft</code></td>
          <td>Confirm Microsoft 365 app definitions are updated</td>
      </tr>
      <tr>
          <td>Custom scripts and internal portals</td>
          <td>Code parses the browser URL to find user/site/path</td>
          <td>Move to Microsoft Graph or supported APIs instead of URL parsing</td>
      </tr>
      <tr>
          <td>Helpdesk documentation and phishing training</td>
          <td>Users distrust the new URL</td>
          <td>Update user-facing guidance before rollout</td>
      </tr>
  </tbody>
</table>
<h2 id="the-fix">The Fix</h2>
<p>My preferred approach is a small readiness check, not a big policy rewrite.</p>
<ol>
<li><strong>Inventory references</strong> to old OneDrive URL patterns in Intune, proxy, firewall, CASB, DLP, browser policies, and internal documentation.</li>
<li><strong>Allow the new Microsoft cloud domain</strong> where Microsoft 365 web traffic is already allowed. Microsoft specifically calls out <code>*.cloud.microsoft</code> in the admin recommendation.</li>
<li><strong>Avoid parsing browser URLs</strong> in automation. If a script or app needs OneDrive data, use Microsoft Graph or a supported API.</li>
<li><strong>Pilot with test users</strong> before changing tenant-wide controls.</li>
<li><strong>Test common workflows</strong>:
<ul>
<li>open OneDrive in browser</li>
<li>open a shared link</li>
<li>access a file from another geo, if applicable</li>
<li>upload and download a sensitive file if DLP is used</li>
<li>access OneDrive through managed Edge</li>
<li>access OneDrive through the corporate proxy/VPN path</li>
</ul>
</li>
<li><strong>Update helpdesk notes</strong> so users are not told the new URL is suspicious.</li>
</ol>
<h2 id="practical-validation-checklist">Practical Validation Checklist</h2>
<p>Use this as a simple admin checklist.</p>
<ul>
<li><input disabled="" type="checkbox"> <code>onedrive.cloud.microsoft</code> opens from a managed device.</li>
<li><input disabled="" type="checkbox"> Existing <code>*-my.sharepoint.com</code> links still open.</li>
<li><input disabled="" type="checkbox"> Proxy/firewall logs do not show blocks for <code>cloud.microsoft</code>.</li>
<li><input disabled="" type="checkbox"> Edge Intune URL policies do not block <code>cloud.microsoft</code>.</li>
<li><input disabled="" type="checkbox"> Defender for Cloud Apps session policies still apply as expected.</li>
<li><input disabled="" type="checkbox"> Tenant Restrictions v2 behavior is tested, if used.</li>
<li><input disabled="" type="checkbox"> DLP and sharing flows still behave correctly.</li>
<li><input disabled="" type="checkbox"> Helpdesk and user guidance mention <code>cloud.microsoft</code> as a trusted Microsoft domain.</li>
<li><input disabled="" type="checkbox"> Any custom OneDrive tooling uses Microsoft Graph or supported APIs, not browser URL parsing.</li>
</ul>
<h2 id="what-changed">What Changed</h2>
<p>The change is mostly visual for users and architectural for Microsoft. For admins, the work is governance cleanup.</p>
<p>The safest message to users is simple:</p>
<blockquote>
<p>OneDrive may show a new Microsoft domain: <code>onedrive.cloud.microsoft</code>. Existing links still work. Do not approve sign-ins or downloads from lookalike domains, but this exact Microsoft domain is expected.</p>
</blockquote>
<h2 id="what-to-watch-out-for">What to Watch Out For</h2>
<p>The most likely failures are not from OneDrive itself. They come from controls that were written too narrowly.</p>
<p>Watch especially for:</p>
<ul>
<li>explicit allowlists containing only <code>sharepoint.com</code></li>
<li>browser URL policies in Microsoft Intune</li>
<li>proxy rules that treat <code>cloud.microsoft</code> as unknown</li>
<li>Defender for Cloud Apps policies scoped by URL pattern instead of app/session behavior</li>
<li>DLP or secure browser tools that need updated Microsoft 365 app definitions</li>
<li>internal tools that split OneDrive URLs to extract user or site information</li>
</ul>
<p>If something breaks, check network/security policy logs before assuming a OneDrive outage.</p>
<h2 id="related-links">Related Links</h2>
<ul>
<li>M365 Admin message summary: <a href="https://m365admin.handsontek.net/onedrive-transitions-cloud-microsoft-domain/">https://m365admin.handsontek.net/onedrive-transitions-cloud-microsoft-domain/</a></li>
<li>Microsoft Learn: cloud.microsoft domain: <a href="https://learn.microsoft.com/en-us/microsoft-365/enterprise/cloud-microsoft-domain?view=o365-worldwide">https://learn.microsoft.com/en-us/microsoft-365/enterprise/cloud-microsoft-domain?view=o365-worldwide</a></li>
<li>Microsoft 365 URLs and IP address ranges: <a href="https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide">https://learn.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide</a></li>
<li>Microsoft Learn: Tenant Restrictions v2: <a href="https://learn.microsoft.com/en-us/entra/external-id/tenant-restrictions-v2">https://learn.microsoft.com/en-us/entra/external-id/tenant-restrictions-v2</a></li>
</ul>
]]></content:encoded></item></channel></rss>