Skip to content
DoctorDO
Demo

Delivery Optimization diagnostics for Microsoft Intune

Know where your updates and apps came from, and why.

DoctorDO reads what Windows already records about Delivery Optimization on each device you manage with Intune. It shows where each download came from and what’s stopping devices sharing content. Where a setting is to blame, it gives you the Intune policy to fix it.

Open the demo portalSee how it worksThe demo is ContosoAI, a fictitious company with 46,000 devices. Its figures are modelled, not computed from collector reports. There’s no sign-in and nothing to install.

Nothing is a black box. The collector is PowerShell, with one C# helper whose source is in the module, and the infrastructure is Bicep applied by PowerShell and Node scripts, all written to be read by your security team before you deploy. The repository is private during the preview and will be public. How to review it

Measure

Where your updates and apps came from, on one page.

Delivery efficiency, the bytes that peers and Connected Cache delivered in place of the HTTP source, and a map of every site, all for the last 30 days.

  • Bytes by source for the estate, each site, and each device
  • The findings to fix first, the most serious at the top
  • Each change to a setting, whether by Intune, Group Policy, or locally, marked on the trend on the day it was first seen
See it in the demo
Works withMicrosoft IntuneWindows Update for Business reportsMicrosoft Connected CacheMicrosoft Entra ID

The problem

Windows keeps the evidence. Reading it, device by device, is the hard part.

Built for the Intune administrator who has been told the WAN is full and has to show which devices filled it, and why.

Reduce bandwidth

Find the WAN traffic that should have stayed local.

Delivery Optimization is meant to keep updates, apps, and Microsoft 365 content on your own network.1 When it doesn’t, no error appears. The bytes come from the internet instead, and DoctorDO shows how many, device by device and site by site.

  • Every byte by its five sources: the HTTP source (usually Microsoft’s CDN), Connected Cache, and LAN, group, and internet peers
  • A company goal, and every site and device judged against it
  • The sites short of the goal, ranked by what they would keep local
  • Whether each policy change helped, with the trend shaded where efficiency rose or fell
  • What stops devices sharing: Wi-Fi client isolation, blocked peer ports, proxies that inspect TLS, and uploads turned off
  • Where a Connected Cache server would pay off, with an estimate of what it saves
See it in the demoLearn: Firewall rules

Faster app and Autopilot deployments

Stop apps and new devices waiting on the internet.

Win32 apps, Microsoft 365 Apps, Teams, and Windows updates all arrive through Delivery Optimization, and a setting that makes a download wait for peers or a cache can hold up Windows Autopilot provisioning. Microsoft calls devices being provisioned transient peers;4 in DoctorDO’s reading, they’re the devices most likely to have nothing nearby to wait for.

  • Flags the HTTP fallback delays that can hold up Autopilot provisioning, checked against the Enrollment Status Page’s 60-minute default time-out3 and Microsoft’s Autopilot guidance4
  • A provisioning profile beside the everyday one, and how to target each
  • Where Intune Win32 apps, Microsoft 365 Apps, Teams, and Store content came from, device by device
  • Download errors from Delivery Optimization’s log, decoded and tied to the app or update that failed
  • Connected Cache advice that allows for how many devices you provision each month
See it in the demoLearn: Policy assignment

Map your estate

See your network the way Delivery Optimization does.

Sites, subnets, peers, caches, and the way out to the internet, drawn from what devices report rather than from a diagram someone drew years ago.

  • A map of every site, with zoom and pan, shaded against your goal
  • From the estate to a site, a subnet, and one device, in one slide-in panel
  • Each device’s own picture: which peers and caches served it, and how much
  • Every recommendation drawn before and after the change
  • Network design that starts from today’s estate, to plan new sites and caches
See it in the demoLearn: Group IDs

Built from the field

Three problems that stop peering without an error.

Each case runs from the problem to the rule that finds it, and to the MSEndpointMgr post or Microsoft page it rests on.

  1. 01DoctorDO’s reading

    Wi-Fi client isolation

    Devices are offered peers and their own firewall lets Delivery Optimization in, yet every connection between them fails. Nothing on the device reports an error.

    The rule DO-NET-002 and 1 source

    Compares the peer connections attempted with those established, on devices whose TCP 7680 rule passes, and names the subnet or site where they fail.

    Microsoft documents the port and the failed connection, not client isolation.

    Sources

  2. 02

    TLS inspection

    A proxy that inspects TLS breaks the connection to the Delivery Optimization service, which pins its certificate. Devices get no peers, every byte comes from the CDN, and no error says why.

    The rule DO-NET-006 and 2 sources

    Checks who issued the certificate each device receives on the service’s endpoints, judging the issuing chain rather than the certificate’s own name, which an inspecting proxy can copy. A chain that is not Microsoft’s means inspection, and the finding says which endpoints to exempt.

    Sources

  3. 03

    Content that can’t be peered

    Efficiency falls away and the network team is blamed, but much of the content could never have been peered. Size is one reason: unless you change it, a file under 50 MB is not peered at all.

    The rules DO-BASE-001, DO-BASE-002 and 2 sources

    Compares DOMinFileSizeToCache, whether set or left at its 50 MB default, with Microsoft’s table for an estate of your size: 10 MB above 30 devices, 1 MB above 100.

    Sources

Every statement of Microsoft’s guidance links to the page it rests on. Where DoctorDO concludes something Microsoft does not document, it is labelled DoctorDO’s reading. The Learn page cites 24 Microsoft Learn pages.

Where the knowledge comes from

How it works

From deployment to your first findings.

There’s no DoctorDO licence fee and no appliance to put on the network, and you keep deploying policy the way you do today.

  1. Deploy to Azure

    Run one script against your Azure subscription. It deploys the portal, the ingest functions, and the database, and sets up sign-in for your tenant.

  2. Roll out the collector

    Add the two remediation scripts to Intune. The remediation installs and verifies the collector module on each device, then runs it on a schedule. Devices start reporting.

  3. Review the results

    Sign in to see every device and site: where the bytes came from, what fails, and how each site compares with your goal.

  4. Act, then measure

    Import the Intune policy a finding exports, assign it, and watch the trend show whether it helped.

What you needThe Azure and Entra roles and the tools to deploy it, devices enrolled in Intune, and a licence that includes Remediations: 6 things to check first.
Azure
A subscription in the same tenant as your devices, and Owner on it, or Contributor with User Access Administrator.
Microsoft Entra ID
Application Administrator or Cloud Application Administrator, and Privileged Role Administrator to grant the read-only Microsoft Graph permissions.
Devices
Windows devices that are Microsoft Entra joined or hybrid joined, and enrolled in Intune.
Intune
Rights to create a remediation, which installs, verifies, and runs the collector. Packaging the module as a Win32 app is optional.
Licences
The collector runs from an Intune remediation, and Remediations need the devices’ users to have a Windows Enterprise E3 or E5, Windows Education A3 or A5, or Windows VDA licence (included in Microsoft 365 F3, E3, E5, A3, and A5).
To deploy
PowerShell 7.2 or later, the Azure CLI, Node.js 22 or later, and pnpm 9 on the machine that runs the deployment scripts. The repository is private during the preview and will be public.
How DoctorDO works, on the Learn page

Get started. DoctorDO is in preview. The first public release is coming. Until then, explore the live demo.

Open the demo portal
Read the collector guide

What the collector does

What runs on a device, and where it goes.

The collector is a PowerShell module that an Intune remediation installs and runs on each Windows device. These diagrams are drawn from its code: what it reads and probes, the small signed reports that leave, and what stays behind.

1On the device

It reads what Windows already records, then checks that the device can reach what Delivery Optimization needs. It probes only Microsoft’s documented endpoints, hosts the device itself used, its Connected Cache server, and peers it already knows.

What the collector does on a device1. Intune starts the collector: An Intune remediation runs on a schedule, as SYSTEM. It installs the PowerShell module from a PowerShell repository when it is missing or out of date, and before it loads it, it checks who can write to its folder, its file list, and the SHA-256 of every file. 2. It reads what Windows already records: The Delivery Optimization policy and registry values, the state of the DoSvc service, Get-DeliveryOptimizationStatus and its performance counters and log, what the Enrollment Status Page recorded during Autopilot, and network facts: adapters, routes, proxy and PAC settings, and firewall rules. It changes none of them. 3. It probes what Delivery Optimization uses: DNS, TCP, TLS and HTTP checks to 24 Microsoft endpoints, including the CDN; one request to the Delivery Optimization geo service; TCP 80 and an HTTP request to the Connected Cache server in use; and a TCP connection to port 7680 on peers the device already knows. The probes run in two batches, one after the other: the endpoints at four seconds a probe and forty in all, then the connectivity checks at five seconds a probe and sixty in all.WINDOWS DEVICE · RUNS AS SYSTEMMICROSOFTYOUR NETWORKIntune remediationDetect, then RemediateDoctorDO.CollectorPowerShell moduleReads, read-onlyPolicy and registrySix Delivery Optimization keys, andAutopilot ESP progressDoSvc stateRunning, start type, TCP 7680DO status and performanceGet-DeliveryOptimizationStatus, perfcounters, logNetwork factsAdapters, routes, proxy and PAC,firewall rulesConnectivity probes4–5 s a probe, cappedMicrosoft endpoints24 hosts, incl. the CDNDO geo serviceOne GET: assigns a cacheConnected CacheTCP 80 and an HTTP probeLAN peersTCP 7680, known peers only123
What the collector does, in orderA probe, to a documented endpoint or a host it already usesOnly if you have one
Read this diagram as text
  1. 1Intune starts the collector. An Intune remediation runs on a schedule, as SYSTEM. It installs the PowerShell module from a PowerShell repository when it is missing or out of date, and before it loads it, it checks who can write to its folder, its file list, and the SHA-256 of every file.
  2. 2It reads what Windows already records. The Delivery Optimization policy and registry values, the state of the DoSvc service, Get-DeliveryOptimizationStatus and its performance counters and log, what the Enrollment Status Page recorded during Autopilot, and network facts: adapters, routes, proxy and PAC settings, and firewall rules. It changes none of them.
  3. 3It probes what Delivery Optimization uses. DNS, TCP, TLS and HTTP checks to 24 Microsoft endpoints, including the CDN; one request to the Delivery Optimization geo service; TCP 80 and an HTTP request to the Connected Cache server in use; and a TCP connection to port 7680 on peers the device already knows. The probes run in two batches, one after the other: the endpoints at four seconds a probe and forty in all, then the connectivity checks at five seconds a probe and sixty in all.

2Out through your network, into your Azure

Both kinds of report go to the ingest endpoint in your own Azure subscription, as signed HTTPS requests over the public internet, and are stored only there.

The path of one report, from a device to your portal1. The device sends one signed report: The collector builds a compact report, compresses it, and signs the request with the device's own Microsoft Entra device key. A routine report is 1,758 B compressed (5,270 B of JSON) and goes once a day; the fuller inventory is 5,322 B and goes when it changes, and at least every 7 days. No key, secret or token is deployed. 2. Your own egress carries it: The report is an HTTPS POST to your ingest endpoint, over the internet, and goes nowhere else. Your proxy, firewall or internet breakout treats it as any other HTTPS request; the collector refuses plain HTTP. 3. Ingest checks who sent it: The ingest function in your Azure subscription checks the signature and looks the device up in Microsoft Entra ID. The report goes on a Service Bus queue, and the device gets an empty HTTP 202 in reply. 4. The processor analyses it: The processor checks the device against the Intune device list it reads from Microsoft Graph, and drops a report from a device Intune does not manage. It analyses the rest with DoctorDO’s rules and stores the results. 5. Results are stored in your database: Devices, sites, findings and the trend are kept in PostgreSQL in your subscription. 6. You read it in the portal: The portal API reads the database, and the portal shows it to people who sign in with Microsoft Entra ID. All of it runs in your own tenant; no DoctorDO-hosted service sits in between.YOUR NETWORKYOUR MICROSOFT TENANTYOUR AZURE SUBSCRIPTIONWindows deviceDoctorDO.CollectorOne signed HTTPS requestRoutine report1,758 B gzip (5,270 B of JSON), on the dailyscheduleInventory5,322 B gzip, when it changes and at leastevery 7 daysRequest headersThe device certificate (public part),signature, time and nonceNo secret travelsThe device key signs the request and neverleaves the deviceProxy or firewallor internet breakoutIngestChecks the signature, asks Entra IDQueueService BusProcessorChecks Intune, analysesPostgreSQLResults and trendPortal APIAzure FunctionsPortalStatic Web App · Entra sign-in12HTTPS only3456
The signed report, and what reads itA lookup that carries no report
Read this diagram as text
  1. 1The device sends one signed report. The collector builds a compact report, compresses it, and signs the request with the device's own Microsoft Entra device key. A routine report is 1,758 B compressed (5,270 B of JSON) and goes once a day; the fuller inventory is 5,322 B and goes when it changes, and at least every 7 days. No key, secret or token is deployed.
  2. 2Your own egress carries it. The report is an HTTPS POST to your ingest endpoint, over the internet, and goes nowhere else. Your proxy, firewall or internet breakout treats it as any other HTTPS request; the collector refuses plain HTTP.
  3. 3Ingest checks who sent it. The ingest function in your Azure subscription checks the signature and looks the device up in Microsoft Entra ID. The report goes on a Service Bus queue, and the device gets an empty HTTP 202 in reply.
  4. 4The processor analyses it. The processor checks the device against the Intune device list it reads from Microsoft Graph, and drops a report from a device Intune does not manage. It analyses the rest with DoctorDO’s rules and stores the results.
  5. 5Results are stored in your database. Devices, sites, findings and the trend are kept in PostgreSQL in your subscription.
  6. 6You read it in the portal. The portal API reads the database, and the portal shows it to people who sign in with Microsoft Entra ID. All of it runs in your own tenant; no DoctorDO-hosted service sits in between.

3What stays behind

Some of what the collector sees never leaves the device, and the rest is reduced first. No report or device data goes to the DoctorDO project.

What stays on the device and what is sent1. These stay on the device: The device key that signs each request; the contents of files and of the Delivery Optimization cache (only the cache folder’s total size is read); user names, which nothing reads, and which are replaced where they turn up in log lines and firewall rules as a profile path such as C:\Users\<name>, DOMAIN\user or AzureAD\user (log lines are unstructured, so an unusual form can get through); and full URLs and query strings (of a download’s address only the host and up to two safe path segments leave, for Microsoft hosts only). 2. These are reduced before they are sent: The local address becomes its subnet. Peer addresses are hashed in the peer list and, in fleet mode, cut to a /24 or /48 network in the list of who served the bytes (internet peers always are). The baseboard serial is always a salted SHA-256, and the host name is dropped in fleet mode, so the portal shows the name from your own Entra directory. 3. The report has one destination: The signed report goes to your own ingest endpoint, and no report or device data goes to the DoctorDO project: there is no telemetry or analytics. Installing and updating the module is the remediation’s job: it asks a PowerShell repository (PowerShell Gallery by default) for the newest version at most once a day and, to verify a new version, downloads its file hashes from the project’s GitHub release. Those requests carry no device data.ON THE DEVICESTAYS HEREREDUCED, THEN SENTYOUR AZURE SUBSCRIPTIONKeys and tokensThe device key signs; it staysFile and cache contentsOnly the cache’s total sizeUser namesNot read; known forms scrubbedFull URLs, query stringsHost + 2 path segments leaveLocal IP addressReduced to its subnetPeer addressesHashed, or cut to a /24 or /48Serial numberSalted SHA-256, never the serialHost nameDropped in fleet modeYour ingest endpointThe report’s only destinationThe DoctorDO projectGets nothing: no telemetry1
The one thing that leaves: a signed reportNo connection at all
Read this diagram as text
  1. 1These stay on the device. The device key that signs each request; the contents of files and of the Delivery Optimization cache (only the cache folder’s total size is read); user names, which nothing reads, and which are replaced where they turn up in log lines and firewall rules as a profile path such as C:\Users\<name>, DOMAIN\user or AzureAD\user (log lines are unstructured, so an unusual form can get through); and full URLs and query strings (of a download’s address only the host and up to two safe path segments leave, for Microsoft hosts only).
  2. 2These are reduced before they are sent. The local address becomes its subnet. Peer addresses are hashed in the peer list and, in fleet mode, cut to a /24 or /48 network in the list of who served the bytes (internet peers always are). The baseboard serial is always a salted SHA-256, and the host name is dropped in fleet mode, so the portal shows the name from your own Entra directory.
  3. 3The report has one destination. The signed report goes to your own ingest endpoint, and no report or device data goes to the DoctorDO project: there is no telemetry or analytics. Installing and updating the module is the remediation’s job: it asks a PowerShell repository (PowerShell Gallery by default) for the newest version at most once a day and, to verify a new version, downloads its file hashes from the project’s GitHub release. Those requests carry no device data.
Every field it reads and sends, with the sizesRead the code behind these diagrams

Your data

It runs in your Azure subscription and changes no setting on its own.

DoctorDO is deployed into your Azure subscription and reads what your devices already record. You decide what, if anything, changes.

See exactly what is collected
  1. 01

    In your own Azure subscription

    One script deploys the portal, the ingest functions, and the database into your subscription. No shared DoctorDO service holds your data.

  2. 02

    Only your managed devices report

    Each report is checked against Microsoft Entra ID and Intune before it is stored.

  3. 03

    Sign in with Microsoft Entra ID

    Single-tenant sign-in, with an administrator role for configuration.

  4. 04

    No setting changed for you

    The collector reads what Windows records and changes no Delivery Optimization, firewall, proxy, or service setting. On each device the remediation installs the module, and the collector keeps a small state folder, two registry values, and a log. Its optional reproduction mode turns on verbose Delivery Optimization logging and restores it afterwards. A recommendation becomes a change only when you import its policy and assign it.

  5. 05

    No setting ID guessed

    Each Intune policy is a settings catalog file that you import in the Intune admin center.5 It holds only settings whose ID Microsoft publishes, and anything else waits for you to verify it.

  6. 06

    Rules backed by Microsoft sources

    Findings come from rules, each linked to the Microsoft page it rests on. The optional briefing is written from the same evidence.

Open to review

Nothing is a black box. Read it before you deploy it.

A script that runs as SYSTEM on every device needs a security review first. DoctorDO is built so that your team can do it: the device-side code is PowerShell with one C# helper in source form, the infrastructure is Bicep applied by scripts in the same repository, and the payload has a published schema. The repository is private during the preview and will be public.

  • The collector, as source

    The module is .ps1, .psm1 and .psd1 files you can read and diff, with its endpoint list and redaction rules as JSON. Two parts are not script: one C# helper, whose source is in ProbeNative.ps1 and which is compiled in memory when the module runs, and the device report page, a generated HTML file that the repository rebuilds with pnpm device-report:build.

    In the repository: collector/DoctorDO.Collector/

  • The Intune scripts

    Detect-DoctorDO.ps1 and Remediate-DoctorDO.ps1 are what Intune runs on the device: the remediation installs and checks the module, then runs it. Every step is logged in CMTrace format, so you can read what happened on a device.

    In the repository: collector/intune/

  • The infrastructure templates and scripts

    Bicep for everything deployed to your subscription: the functions, the queue, the database, the alert rules, and the portal. PowerShell and Node scripts apply it, set up the database and sign-in, and upload the portal, and can be read the same way. The ARM template the deploy button uses is compiled from the Bicep, and a build check fails if the two differ.

    In the repository: infra/

  • The portal and the services

    TypeScript: the portal, the ingest function, the processor, the API, and the analysis rules, each finding linked to the Microsoft page it rests on.

    In the repository: apps/ and packages/

  • The payload schema

    JSON Schema for the inventory and telemetry reports. Hold a captured report up against it and see exactly which fields a device can send.

    In the repository: contracts/

  • A SHA-256 manifest of the module

    Each release publishes collector-manifest.json: the module’s name, version, GUID and author, and the SHA-256 of every file.

    In the repository: collector-manifest.json

Check that what runs is what you read.

The module is not Authenticode-signed in the preview. These checks detect a change to the files after release, and the remediation applies them on every device (ADR-0041); they don’t prove who published the release. For that, pin the hashes yourself or re-sign the module.

  1. 01

    Read the release

    The collector is a folder of PowerShell files, the C# helper’s source among them. Review it, and diff each new release against the one you approved.

  2. 02

    Check it against the manifest

    Compare the files you reviewed with the SHA-256 values in collector-manifest.json.

  3. 03

    The device checks it again, every run

    Before it loads anything, the remediation checks who can write to the module folder, that the files are exactly the release’s list, and that every SHA-256 matches. If a check fails, that copy is removed and the newest earlier version that passes is used; if none passes, nothing is loaded or sent. The log says why.

  4. 04

    Pin it, or keep it in-house

    Write the hashes into the script you deploy, or point the remediation at your own PowerShell repository. The licence lets you re-sign the module with your own certificate.

The licences, as the files state them.

“Open” here means open to inspection: the collector’s licence says itself that it is not an open source licence.

The collector module
DoctorDO Collector Licence 1.0, source-available, not open source
Use it in an organisation to manage its own devices, and package it unchanged for Intune or Configuration Manager. Reading, reviewing, testing and auditing it, including for a security review, is expressly allowed. It may not be changed or sold.
The Intune scripts
MIT License
Adapt them freely: setting your ingest URL in the remediation is an example.
The portal, the services, and the templates
Not yet licensed
The collector’s terms are to cover the whole product. They await a lawyer’s review, and the licence is published with the first public release.

The first public release is coming. The link to the repository goes here when it is public.

See exactly what is collected

Costs

What it costs is what Azure bills you.

DoctorDO is free to use; you pay only for the Azure resources it runs on. The costs page works out the monthly figure from Azure list prices, resource by resource, for the demo’s size and for yours.

See the costsWork out your own estate

Questions

Common questions.

Does DoctorDO change anything on my devices?
It changes no Delivery Optimization, firewall, proxy, or service setting. It does install the collector module, keep a small state folder and two registry values, and write a log, and it makes outbound connection checks. Nothing else changes until you import a policy and assign it. Your data has the details.
Where does my data go?
Into your own Azure subscription, with no shared service in between. Your data says how each report is checked and who can sign in.
Can our security team review the code?
It is built for that. The collector is PowerShell, with one C# helper whose source is in the module; the infrastructure is Bicep, applied by PowerShell and Node scripts in the same repository; and the payload has a published schema. The repository is private during the preview and will be public. The module’s licence is source-available, not open source, and it allows a security review. Open to review says what to read, how to check it, and the licences.
What does it cost?
DoctorDO is free to use; you pay only for the Azure resources it runs on. The costs page works out what those resources cost for an estate your size. The collector runs from an Intune remediation, and Remediations need the devices’ users to have a Windows Enterprise E3 or E5, Windows Education A3 or A5, or Windows VDA licence (included in Microsoft 365 F3, E3, E5, A3, and A5).
What do I need to deploy it?
Azure and Microsoft Entra roles to deploy it, Windows devices that are Entra joined or hybrid joined and enrolled in Intune, and a licence that includes Intune Remediations. What you need lists each one.
How do I get it?
DoctorDO is in preview. The first public release is coming. Until then, explore the live demo.
Do I need Microsoft Connected Cache?
No. DoctorDO works with or without one. If you’re considering Connected Cache, it shows the sites where a cache server would pay off, and what it would save.
How is this different from Windows Update for Business reports?
Those reports show Delivery Optimization over 28 days by content type and by Group ID, city, country, and ISP, with a row per device and content type.6 They don’t say why content didn’t come from a peer, or tie a result to your sites and settings. DoctorDO does: which content, from which source, and why it didn’t come from a peer, for each device and site. If you already use the reports, DoctorDO can read that workspace too.
Can I try it on one device first?
Not yet. A report for one device, a single HTML file made with nothing deployed, arrives with the first public release. Until then, explore the live demo.
Does it use AI?
Not for the findings. They come from rules, and each one shows its evidence and its Microsoft source. If you connect Azure OpenAI in your own subscription, the Reporting page adds a briefing written from the same evidence.
Is DoctorDO a Microsoft product?
No. It’s an independent community project. The independence statement at the foot of this page says what that means.

New to Delivery Optimization?

The Learn page covers the parts that matter, each with Microsoft’s documentation.

Microsoft documentation cited on this page (6)
  1. 1What is Delivery Optimization? (opens in a new tab)learn.microsoft.com/windows/deployment/do/waas-delivery-optimization
  2. 2Delivery Optimization reference (opens in a new tab)learn.microsoft.com/windows/deployment/do/waas-delivery-optimization-reference
  3. 3Set up the Enrollment Status Page (opens in a new tab)learn.microsoft.com/intune/device-enrollment/windows/setup-status-page
  4. 4Microsoft Connected Cache for Enterprise and Education overview: plan for Windows Autopilot provisioning (opens in a new tab)learn.microsoft.com/windows/deployment/do/mcc-ent-edu-overview#plan-for-windows-autopilot-provisioning
  5. 5Use the Intune settings catalog: import and export a profile (opens in a new tab)learn.microsoft.com/intune/device-configuration/settings-catalog/#import-and-export-a-profile
  6. 6Delivery Optimization data in Windows Update for Business reports (opens in a new tab)learn.microsoft.com/windows/deployment/update/wufb-reports-do

See the whole portal before you deploy anything.

This portal runs every page on ContosoAI, a fictitious company with 46,000 devices, at 41 sites in 16 countries and working remotely. Its figures are modelled, not computed from collector reports. Every company, site, and figure in ContosoAI is invented; the problems are ones met in real estates.

Open the demo portalGet started