Blog Post

Windows IT Pro Blog
4 MIN READ

Changes coming to the Azure Update Delivery service tag

Dave_Roth's avatar
Dave_Roth
Icon for Microsoft rankMicrosoft
May 31, 2024

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.

Tip: Read an overview of Azure Firewall service tags.

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.

Published May 31, 2024
Version 1.0
servicing and updates

20 Comments

Show More
  • hspinto's avatar
    hspinto
    Icon for Microsoft rankMicrosoft
    Jun 07, 2024

    Here's an Azure Resource Graph helper query that allows you to quickly identify NSG rules that are using those service tags:

     

    resources
| where type == 'microsoft.network/networksecuritygroups'
| mv-expand nsgRule = properties.securityRules limit 400
| extend destinationAddressPrefix = tostring(nsgRule.properties.destinationAddressPrefix)
| where destinationAddressPrefix in ('AzureUpdateDelivery','AzureFrontDoor.FirstParty')
| where nsgRule.properties.access == 'Allow'
| where nsgRule.properties.direction == 'Outbound'
| extend ruleName = tostring(nsgRule.name)
| extend protocol = tostring(nsgRule.properties.protocol)
| extend destinationPortRange = iif(isnotempty(nsgRule.properties.destinationPortRange),tostring(nsgRule.properties.destinationPortRange),tostring(nsgRule.properties.destinationPortRanges))
| extend sourceAddressPrefix = iif(isnotempty(nsgRule.properties.sourceAddressPrefix),tostring(nsgRule.properties.sourceAddressPrefix),tostring(nsgRule.properties.sourceAddressPrefixes))
| extend subnets = tostring(properties.subnets)
| project destinationAddressPrefix, nsg=name, resourceGroup, subscriptionId, ruleName, protocol, destinationPortRange, sourceAddressPrefix, subnets
  • cdranschak's avatar
    cdranschak
    Copper Contributor
    Jun 07, 2024

    Dave_Roth is the AzureFrontDoor.FirstParty service itself being deprecated entirely or will it still be available for use?

     

    I see that service tag doesn't contain too many IP's.

  • cdranschak's avatar
    cdranschak
    Copper Contributor
    Jun 07, 2024

    I also just received this communication, 3 days before the "temporary outage" will occur and have the same questions. The article only mentions Azure Firewall. Does this service tag change also pertain to NSG service tags or just Azure Firewall service tags?

     

    If it does also pertain to NSG service tags, where is the migration guidance for that level?

  • Gijs_Reijn's avatar
    Gijs_Reijn
    Brass Contributor
    Jun 07, 2024

    It's quite a fast change and just as Mark mentioned, I do not see any guidance on NSG-level, nor guidance with either using Azure Automation Account (which is also on the deprecation path) or Azure Update Manager. 

     

    Is there any possibility to provide more guidance how to work with a restrictive NSG? 

  • Mark_Van_Wormer's avatar
    Mark_Van_Wormer
    Copper Contributor
    Jun 07, 2024

    Dave_Roth : I received the expected email notification for Azure changes (at the exact same time as my last post) with the subject: "Action required: Upcoming changes to AzureUpdateDelivery and AzureFrontDoor.FirstParty service tags". Inside it there is information that this blog post is missing that I hope other readers find relevant:

     

    "To prepare customers for this event, on 10 June 2024 a temporary outage will occur to force awareness of this issue. This temporary outage will end on 17 June 2024, at which time your Windows devices will be able to successfully perform Windows updates as expected, until 1 July 2024." So, in reality we have four days to take action, not until July 1st. 

    I hope I'm an outlier because a notification four days (spanning a weekend) that systems will not receive patches is very disappointing.

  • Mark_Van_Wormer's avatar
    Mark_Van_Wormer
    Copper Contributor
    Jun 06, 2024

    Dave_Roth : While I appreciate your speedy reply, I am still unclear on if there was an additional communication or not. I am unable to find a change announcement for the FrontDoor service tag either. I regularly get e-mails regarding changes in Azure and I'd like to make sure I'm getting all relevant notifications to changes that may impact my environment. Had I not stumbled upon this post I would have not had any notification until systems stopped receiving updates in July. Was there additional communication, or no? 

    Also, what guidance is there for the use case of an NSG without an Azure Firewall? After re-reading, I see that this post is specific to the Azure Firewall service, but service tags are applicable to both NSGs and Firewalls. Are the only options configuring WSUS or doing a complete redesign behind a firewall and removing the majority of the NSG rules?

  • Dave_Roth's avatar
    Dave_Roth
    Icon for Microsoft rankMicrosoft
    Jun 06, 2024

    Mark_Van_Wormer : The change in behavior with AzureFrontDoor service is what is impacting the Windows Update workflow. Specifically, the AzureUpdateDelivery service tag could continue to function but without the AzureFrontDoor.FirstParty service tag for content download the end-to-end workflow is impacted. The Windows Update workflow, itself, is not an Azure asset, rather it is a Windows service. I would expect that a change announcement for the AzureFrontDoor.FirstParty service tag would outline this.

     

  • Mark_Van_Wormer's avatar
    Mark_Van_Wormer
    Copper Contributor
    Jun 06, 2024

    We currently utilize this service tag for a handful of resources behind a highly restrictive NSG and I'm currently unable to find a notification outside of this post that this change was occurring. Did I miss something or is the little blurb on the service tag page the only other place besides this post that listed the change? I set this up about six months ago and that was not in the documentation.