This round-up covers what Microsoft changed between 22 and 29 October 2026 in the areas the series covers. This week brings retirement dates for a batch of Foundry models, four features that are now generally available, one preview and two other changes worth knowing. One of them changes what the AZ-700 guide says about Front Door WAF policies. For each item we show where the books, the glossary and the study notes cover it.
New in the series
Our published books are free to read with Kindle Unlimited.
Retirements
Retirement dates for Llama, FLUX, Grok and other models in Microsoft Foundry
This week Microsoft added retirement dates for a group of models to the Microsoft Foundry model retirement schedule. The nearest is Llama-4-Maverick-17B-128E-Instruct-FP8, which retires on 19 November 2026. FLUX-1.1-pro and FLUX.1-Kontext-pro follow on 5 January 2027; FLUX.2-flex, FLUX.2-pro and the gpt-realtime-2 preview (replacement: gpt-realtime-2.1) on 20 January 2027; Llama-3.3-70B-Instruct, Llama-4-Scout-17B-16E-Instruct, grok-4 and grok-code-fast-1 on 31 January 2027; and Codestral-2501 on 15 February 2027. Most of these have no named replacement yet. Microsoft Learn says it picks the official replacement about 90 to 120 days before retirement, and that you don’t need to wait for one before you evaluate and move to another model. A retired model returns 410 Gone to every request, so check your deployments against the schedule now.
Where we cover it: chapter 1, “Microsoft Foundry: models, resources and deployments”, of the AI-103 guide, which explains retired and replaced models and the model version upgrade policy; glossary: Microsoft Foundry, Foundry Models sold by Azure, Model catalog, Model version upgrade policy.
Source: Microsoft Learn: Model retirement schedule · Microsoft Learn: Microsoft Foundry Models lifecycle and support policy
Now generally available
Profile and route level WAF policies on Azure Front Door
On 27 October 2026, Microsoft made profile and route level policies for Web Application Firewall on Azure Front Door Premium generally available. Until now a Front Door WAF policy was attached to domains. You can now attach a policy at profile, domain or route scope: for example, one profile-level policy as a baseline for every domain, and a stricter route-level policy for sign-in, checkout or API paths. When more than one scope applies to a request, the most specific wins: route beats domain, and domain beats profile. Existing domain-level associations keep working unchanged. Microsoft Learn suggests starting with a profile-level baseline and adding narrower policies only where you need different controls. We’ll reflect this in the next update of the AZ-700 guide, which says a Front Door WAF policy is attached to domains.
Where we cover it: chapter 15, “Web Application Firewall”, and chapter 11, “Azure Front Door”, of the AZ-700 guide; chapter 12, “Securing App Service, Functions, Logic Apps, WAF and API Management”, of the SC-500 guide; study note: Choosing an Azure load-balancing service; glossary: Global WAF policy, WAF policy, Security policy (Front Door), Route (Front Door), Front Door Premium. See also NSG vs Azure Firewall vs WAF, and service tags in Front Door WAF custom rules in our round-up for 22 October.
Source: Azure Updates · Microsoft Learn: Policy settings for Web Application Firewall in Azure Front Door
Filtering for virtual network flow logs
Filtering for virtual network flow logs in Network Watcher became generally available on 26 October 2026, and you can now set it up in the Azure portal as well as with PowerShell. A filter decides which flows are logged, by direction, source and destination IP or CIDR range, port, protocol, encryption state and flow state (begin, continuing, end or deny). Logging only the flows you need cuts log volume and storage costs and makes analysis easier, for example by recording only denied traffic. You can change the filter on an existing flow log without recreating it. At the time of writing, the Microsoft Learn filtering page still carries a preview notice; the announcement gives the general availability.
Where we cover it: chapter 14, “Monitoring with Azure Monitor and Network Watcher”, of the AZ-104 guide; chapter 16, “Monitoring, DDoS protection and network security posture”, of the AZ-700 guide; chapter 4, “Monitoring and observability”, of the AZ-305 guide; glossary: Virtual network flow logs, NSG flow logs, Network Watcher, Traffic Analytics.
Source: Azure Updates · Microsoft Learn: Filter virtual network flow logs
Up to 1,000 storage accounts per region per subscription
On 27 October 2026, higher storage account quotas became generally available. The default stays at 250 storage accounts with standard endpoints per region per subscription, but you can now raise it to as many as 1,000 yourself, through Quotas in the Azure portal, Azure CLI or Azure PowerShell, without opening a support ticket. You need the Contributor role (or a role that includes it) to request the increase. The change applies to managing accounts through the Storage resource provider, not to data operations inside an account. The AZ-802 guide’s statement that the default limit is 250 accounts per subscription per region remains correct.
Where we cover it: chapter 4, “Storage accounts: types, redundancy, encryption and data transfer”, of the AZ-104 guide; chapter 9, “Azure Files and Azure File Sync”, of the AZ-802 guide; glossary: Storage account, Quotas and limits, Usage + quotas. See also Azure storage redundancy: LRS vs ZRS vs GRS vs GZRS.
Source: Azure Updates · Microsoft Learn: Increase Azure Storage account quotas
File recovery from Premium SSD v2 and Ultra disks in Azure Backup
Since 23 October 2026, Azure Backup item-level recovery (file recovery) has been generally available for Azure VMs that use Premium SSD v2 and Ultra Disk, with 512-byte or 4-KB logical sectors. Until now file recovery wasn’t available for these disk types. As with other disk types, you generate a file-recovery executable or script from the portal, CLI or PowerShell, run it on a compatible machine to mount the recovery point, and copy the files and folders you need. It works for Windows VMs and for Linux VMs running Ubuntu, RHEL, Debian, Oracle Linux, SLES or openSUSE, including VMs that mix disk types, so file recovery now covers every managed disk type.
Where we cover it: chapter 15, “Backup and disaster recovery”, of the AZ-104 guide; chapter 13, “Backup and disaster recovery”, of the AZ-305 guide; glossary: File recovery, Recovery point, Recovery Services vault, Premium SSD v2, Ultra Disk, iSCSI.
Source: Azure Updates · Microsoft Learn: Recover files from Azure virtual machine backup
In preview
Cross-tenant restore in Azure Backup
On 28 October 2026, Microsoft announced a public preview of cross-tenant restore for Azure Backup. It restores vaulted backups from one Microsoft Entra tenant into another, using the existing backup copy rather than a second set of backup data. That gives you an independent recovery path for tenant lockout, a ransomware attack on the source tenant, tenant consolidation or cross-tenant disaster recovery. You map a source vault to a target vault in the same region, and the mapping is protected by multi-user authorisation: the target vault must be associated with a Resource Guard in the target tenant. For Recovery Services vaults it covers Azure VMs, Azure Files, and SQL Server, SAP HANA and SAP ASE in Azure VMs in all public regions; some Backup vault workloads are supported in selected regions. Only vaulted recovery points and alternate-location restore are supported, and Confidential VMs, VMs encrypted with Azure Disk Encryption and archive-tier recovery points are excluded.
Where we cover it: chapter 15, “Backup and disaster recovery”, of the AZ-104 guide and chapter 13, “Backup and disaster recovery”, of the AZ-305 guide, which cover multi-user authorisation with Resource Guard; chapter 4, “Governance: Azure Policy, roles, locks and backup protection”, of the SC-500 guide; glossary: Resource Guard, Multi-user authorization, Recovery Services vault, Backup vault, Microsoft Entra tenant.
Source: Azure Updates · Microsoft Learn: What is cross-tenant restore for Azure Backup? (Preview)
Other changes
Azure Container Apps: the Log Analytics logging destination is now legacy
On 28 October 2026, Microsoft announced that the Log Analytics logging destination for Azure Container Apps is now a legacy option, and recommends moving environments to the Azure Monitor destination. Existing environments keep working, but the Log Analytics destination depends on the HTTP Data Collector API, whose support ended on 14 September 2026; it now gets only critical security fixes. If your queries, alerts, workbooks or dashboards use the ContainerAppConsoleLogs_CL or ContainerAppSystemLogs_CL tables, you’re on the legacy destination. After the switch, new records go to ContainerAppConsoleLogs and ContainerAppSystemLogs, with column names that have no type suffix; historical records stay in the old tables, and Microsoft Learn shows workspace functions that query both. Express environments can’t use the Azure Monitor destination yet. The AI-200 guide already recommends the Azure Monitor destination.
Where we cover it: chapter 3, “Azure Container Apps: environments, revisions and secrets”, and chapter 6, “Monitoring and troubleshooting AKS and Container Apps”, of the AI-200 guide; chapter 9, “Containers: registries, instances, Container Apps and AKS”, of the AZ-104 guide; glossary: Azure Container Apps, Container Apps environment, Log Analytics workspace, Diagnostic setting, Resource-specific tables.
Source: Azure Updates · Microsoft Learn: Change Azure Container Apps logging from Log Analytics to Azure Monitor
Intune: activate eSIMs on up to 100 Android devices at once
In the week of 26 October 2026, Microsoft Intune added bulk eSIM actions for corporate-owned Android Enterprise devices (fully managed, dedicated and corporate-owned with a work profile). From Devices > All devices > Bulk device actions you can activate eSIMs on up to 100 devices running Android 15 or later, using your carrier’s activation server URL. It’s available only in the updated bulk device actions experience. A bulk wipe of these devices keeps their eSIM data plans by default, unless you choose to remove them. Personally owned devices with a work profile aren’t supported.
Where we cover it: chapter 10, “Remote actions and device diagnostics”, of the MD-102 guide; study note: Intune retire vs wipe vs delete vs Fresh Start; glossary: Bulk device actions, Wipe, Android Enterprise, COPE, COSU.
Source: Microsoft Learn: What’s new in Microsoft Intune · Microsoft Learn: Activate eSIMs on multiple Android Enterprise devices
Every term above is explained in the series glossary. To get next week’s round-up, follow the RSS feed.
Tony Rough
