Azure Update Delivery service tag is being deprecated starting July 1, 2024. If your Azure Firewall is configured to receive Windows updates using this service tag, you'll need to migrate away from the service tag and use Azure Firewall application rules instead.
In this article, let's talk about the Azure Update Delivery service tag, what's changing, and specific actions to take today.
What is the Azure Update Delivery service tag?
Azure Firewall service tags are collections of IP addresses and ranges associated with a named resource. They simplify the process of configuring your firewall. The tags are automatically updated to reflect changes to IP addresses. This means that you don't need to monitor or manually adjust your firewall rules with such address changes.
The AzureUpdateDelivery service tag has been used to enable Windows devices to scan for Windows updates. The process of scanning connects a Windows device to Microsoft Windows Update services, checking for any necessary operating system updates, drivers, firmware, and applications.
The AzureUpdateDelivery service tag allows the Azure Firewall to recognize the specific IP addresses used by Microsoft Windows Update scanning. This helps ensure that your Windows devices are securely connecting to the correct Microsoft services with confidence.
After your Windows device completes a Windows Update scan, it identifies the needed content updates. Then, the device downloads and verifies the content using the URLs that it learned during the scan. Installation follows.
To enable Azure Firewall to authorize these downloads, you may have used the “AzureFrontDoor.FirstParty” service tag. This service tag represents a list of trusted IP addresses from which you can download update content. After download, the content is validated for security and integrity before it's installed on your device.
What is changing?
Due to changes in the workflow, content downloads may now come from trusted third-party Content Delivery Networks (CDN) outside of the Azure network. However, these aren't addressable through a service tag. Therefore, while scanning for updates, the secondary stage of content download might fail.
We recommend switching from using service tags (like AzureUpdateDelivery and AzureFrontDoor.FirstParty) to application firewall rules. Keep in mind that third-party CDNs can't create Azure Firewall service tags that contain their IP addresses. When you shift to using Azure Firewall application rules with Fully Qualified Domain Name (FQDN) filtering tags, you'll perform the same task using DNS hosts.
Continue reading to learn more about this recommended process.
How do I know if I'm using the Azure Update Delivery service tag?
The AzureUpdateDelivery and AzureFrontDoor.FirstParty service tags are not automatically applied. A network administrator, possibly you, or someone before you, must have explicitly applied them as Azure Firewall rules.
If you're not sure whether these tags are in use, check your Azure Firewall policy network rules for these specific destination service tags. For more information on firewall rules, refer to the Azure Firewall Basic features documentation.
What should I do if I use the Azure Update Delivery service tag?
Please move away from using the AzureUpdateDelivery and AzureFrontDoor.FirstParty service tags. Instead, follow these recommendations for enterprise scenarios:
- Azure Firewall application rule with the Windows Update fully qualified domain name (FQDN) tag. Set your Azure Firewall policy with an application rule configured for the Windows Update FQDN tag. This tells the firewall exactly which Windows Update-related hosts to trust when scanning and downloading content. Use this strategy for both Windows desktop and server devices.
- Use published Microsoft guidance for your firewall or proxy. Microsoft publishes guidance on how you can configure your enterprise firewall and proxy services to enable proper access to Windows Update services.
- Use Windows Service Update Services (WSUS). This enterprise solution provides a service inside your network permitter. That's where your Windows devices can scan and download update content.
Creating Windows Update application firewall rules
We recommend that you use the Windows Update FQDN tag to configure your Azure Firewall to permit Windows updates for your Windows devices. Azure manages the FQDNs associated with Windows Update for both scanning and content download.
You can do this by adding an application rule to your Azure Firewall policy resource. Note that you can create these application FQDN filtering rules in any Azure Firewall (from basic to premium). See an example in Application FQDN filtering rules.
When you create the application rule, configure it with the following:
- From the Destination Types options, choose FQDN Tag.
- In the FQDN Tags option, select the pre-defined FQDN tag called WindowsUpdate.
- For the Protocol option, enter “HTTP:80,HTTPS:443.”
- Leave any TLS inspection option unselected if your firewall offers it.
After saving this application rule and allowing it to be deployed, your Windows devices will properly scan, download, and install updates.
Using Microsoft guidance for enterprise firewalls and proxies
If you use your own firewall or proxy services, then configure them per the official Microsoft guidelines:
This documentation applies to both Windows client and server devices.
Using Windows Server Update Services
Another option is to keep all Windows updates limited inside your network. That way, your devices never connect to the internet for scanning or downloading. You can achieve this using WSUS.
In this case, a Windows Server is configured with the WSUS feature, and Windows devices are configured to use this server for both scanning and content download.
Follow guidance on deploying and using WSUS here:
Azure Update Delivery service tags have been marked for deprecation for some time now (find it in Azure service tags overview). Deprecation isn't just a part of a product's lifecycle but an essential part of your larger security strategy as you keep your environment up to date. Thankfully, you have two possible solutions to choose from. Let's get you ready for July 1st!
Continue the conversation. Find best practices. Bookmark the Windows Tech Community, then follow us @MSWindowsITPro on X/Twitter. Looking for support? Visit Windows on Microsoft Q&A.