Firewall rule to allow Windows update

Question

Hello everyone,

I’m seeking advice regarding firewall configurations for Windows updates. Despite having three active rules, the update process occasionally fails with the following error: 'We couldn't connect to the update service. We'll try again later.'

My current configuration includes:

M365 URL EDL: Source servers to Palo Alto M365 URL EDL (ports 80/443).

M365 IP EDL: Source servers to Palo Alto M365 IP EDL (ports 80/443).

Custom URL List: Source servers to a collection of Microsoft update URLs (ports 80/443).

Despite these rules, connectivity remains inconsistent. I suspect I may be missing specific required URLs. Could someone provide guidance or a comprehensive list of the necessary endpoints?

Thank you,

Answer 1

For reliable Windows Update connectivity behind a firewall/proxy, allow the documented Windows Update and related Microsoft service endpoints instead of relying only on generic M365 URL/IP feeds.

Key points:

1. Allow core Windows Update endpoints For Windows 10/11 clients, make sure outbound access is allowed (and not SSL-inspected where noted in the linked docs) to at least the following, with the specified protocols/ports: From Windows Update troubleshooting guidance:
   • *.prod.do.dsp.mp.microsoft.com (TLS 1.2)
   • emdl.ws.microsoft.com (HTTP)
   • *.dl.delivery.mp.microsoft.com (HTTP)
   • *.windowsupdate.com (HTTP)
   • *.delivery.mp.microsoft.com (HTTPS)
   • *.update.microsoft.com (TLS 1.2)
   • tsfe.trafficshaping.dsp.mp.microsoft.com (TLS 1.2)
   Note: Do not change HTTP ↔ HTTPS; the documentation explicitly states that using HTTPS where HTTP is required (and vice versa) will cause failures.
2. Allow Microsoft Update / WSUS-related endpoints If using WSUS/ConfigMgr or Microsoft Update as a source, ensure the software update point (or clients going direct) can reach:
   • http://windowsupdate.microsoft.com
   • http://*.windowsupdate.microsoft.com
   • https://*.windowsupdate.microsoft.com
   • http://*.update.microsoft.com
   • https://*.update.microsoft.com
   • http://*.windowsupdate.com
   • http://download.windowsupdate.com
   • http://download.microsoft.com
   • http://*.download.windowsupdate.com
   • http://ntservicepack.microsoft.com
3. Allow Defender/AV and content-delivery endpoints (often required during update) Defender and content delivery can also be blocked by strict firewalls and cause update issues. Ensure outbound 443 (and 80 where specified) to: Defender Antivirus cloud and update services:
   • *.wdcp.microsoft.com
   • *.wdcpalt.microsoft.com
   • *.wd.microsoft.com
   • *.update.microsoft.com
   • *.delivery.mp.microsoft.com
   • *.windowsupdate.com
   • ctldl.windowsupdate.com
   Delivery Optimization / Connected Cache (if used):
   • *.dl.delivery.mp.microsoft.com (HTTP/80)
   • *.windowsupdate.com (HTTP/80)
4. Use version-specific endpoint lists Endpoint sets vary by Windows version. For a comprehensive, authoritative list per OS version, use the “Manage connection endpoints” articles referenced for Windows 10/11 Enterprise and the Windows Update client policies firewall/proxy requirements. These provide the full set of URLs that must be reachable for Windows Update and related services.
5. Avoid SSL inspection on critical update URLs For some update and Defender endpoints, SSL inspection can break connectivity. The troubleshooting guidance for Defender updates explicitly calls out that SSL inspection on required URLs can cause errors like 0x80072ee7 (name not resolved). Ensure those URLs are exempted from SSL inspection where recommended in the linked docs.
6. Validate with Microsoft guidance rather than only M365 EDLs M365 URL/IP EDLs typically focus on Microsoft 365 SaaS (Exchange Online, SharePoint, Teams, etc.), not the full Windows Update/Defender/Delivery Optimization set. Use:
   • Windows Update client policies firewall/proxy requirements
   • “Manage connection endpoints for Windows 10/11 Enterprise”
   • Microsoft 365 URL and IP address ranges (for M365 workloads only)
   to build/verify a dedicated Windows Update rule set in addition to M365 EDL-based rules.
7. Basic troubleshooting steps Once the above endpoints are allowed:
   • Confirm devices can resolve and reach a sample of these URLs (e.g., nslookup and curl/Invoke-WebRequest).
   • Ensure Windows Update and BITS services are running.
   • If using a fallback order for Defender updates, verify Microsoft Update (MicrosoftUpdateServer) is first when appropriate.

Implementing the documented Windows Update, Microsoft Update, Defender, and Delivery Optimization endpoints—using the exact protocol/port combinations—and excluding critical URLs from SSL inspection typically resolves intermittent “couldn’t connect to the update service” errors in locked-down environments.

---

References:

• Windows Update issues troubleshooting
• Internet access requirements
• Configure and validate Microsoft Defender Antivirus network connections
• Troubleshooting Security Intelligence Updates from Microsoft Update source
• Microsoft Connected Cache content and services endpoints
• Configure your network

Answer 2

Hi Leo,

How is your issue going? Has it been resolved yet? If it has, please consider accepting the answer as it helps others sharing the same problem benefit too. Thank you :)

VP

Answer 3

Hi Leo,

The core issue stems from relying on Microsoft 365 External Dynamic Lists for operating system updates, as Microsoft maintains a strict separation between its productivity application endpoints and its Windows Update infrastructure. While your current lists successfully handle regular Office traffic, the Windows Update agent is being blocked from reaching its dedicated content delivery networks. To stabilize the update process, you must expand your custom URL list on the Palo Alto appliance to include the native Microsoft wildcards for https://www.google.com/search?q=update.microsoft.com, https://www.google.com/search?q=windowsupdate.com, https://www.google.com/search?q=delivery.mp.microsoft.com, and https://www.google.com/search?q=download.windowsupdate.com over both port 80 and 443. Permitting HTTP alongside HTTPS is essential because the update client frequently initiates unencrypted requests for payload manifests before securing the connection to download the binaries.

Beyond simply allowing the traffic through your security policies, you must configure your firewall to bypass SSL Decryption and Deep Packet Inspection for these specific domains. The Windows Update client utilizes strict certificate pinning, meaning it explicitly expects a security certificate issued directly by Microsoft. If the firewall intercepts this traffic and presents its own internal inspection certificate, the update agent will drop the connection for security reasons, resulting in the generic connection error you are experiencing. You can verify if decryption is breaking the chain by running the Get-WindowsUpdateLog cmdlet in PowerShell and reviewing the generated log file on your desktop for TLS or certificate validation failures.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP