You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Subscription, reservation, and savings plan transfers are supported for direct EA customers. A direct enterprise agreement is one that's signed between Microsoft and an enterprise agreement customer.
206
-
- Only subscription transfers are supported for indirect EA customers. Reservation and savings plan transfers aren't supported. An indirect EA agreement is one where a customer signs an agreement with a Microsoft partner.
205
+
- Subscription, reservation, and savings plan transfers are supported for EA customers. For more details, see [Azure product transfer hub](subscription-transfer.md).
Copy file name to clipboardExpand all lines: articles/iot-operations/troubleshoot/known-issues.md
+62-1Lines changed: 62 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@ author: dominicbetts
5
5
ms.author: dobett
6
6
ms.topic: troubleshooting-known-issue
7
7
ms.custom: sfi-ropc-nochange
8
-
ms.date: 11/21/2025
8
+
ms.date: 04/17/2026
9
9
---
10
10
11
11
# Known issues for Azure IoT Operations
@@ -14,6 +14,67 @@ This article lists the current known issues you might encounter when using Azure
14
14
15
15
For general troubleshooting guidance, see [Troubleshoot Azure IoT Operations](troubleshoot.md).
16
16
17
+
## Deployment and upgrade issues
18
+
19
+
This section lists current known issues with deploying and upgrading Azure IoT Operations.
20
+
21
+
### Upgrade to Azure IoT Operations 2603 can silently fail
22
+
23
+
---
24
+
25
+
Log signature: N/A
26
+
27
+
---
28
+
29
+
When you run `az iot ops upgrade` to upgrade to Azure IoT Operations 2603, the upgrade can silently fail to reach the cluster. You then observe the following symptoms:
30
+
31
+
-`provisioningState: Failed` on the Azure IoT Operations extension.
32
+
- All on-cluster workloads remain healthy (no upgrade activity occurs).
33
+
-`az iot ops upgrade` might report nothing to upgrade on subsequent attempts.
34
+
35
+
#### Root cause
36
+
37
+
During the upgrade, if a dependent system extension, such as `microsoft.extensiondiagnostics` experiences a transient Helm timeout, Azure Resource Manager marks it as **Failed**. Even if the extension eventually succeeds on-cluster, the cloud-side state remains **Failed**. This blocks the dependency chain — Azure Resource Manager never delivers the updated Azure IoT Operations or secret-store extension config to the cluster's config agent.
38
+
39
+
Symptoms include:
40
+
41
+
- Config agent PostStatus returns `400: "Configuration spec has been modified"`
42
+
-`getPendingConfigs` returns empty results
43
+
- Extension manager never receives Helm upgrade instructions
44
+
45
+
#### Workaround
46
+
47
+
The workaround is to force Azure Resource Manager to re-submit the extension specs by running a no-op update on both the Azure IoT Operations and secret-store extensions, then retrying the upgrade:
48
+
49
+
```azurecli
50
+
az k8s-extension update --name <aio-extension-name> \
To identify the Azure IoT Operations extension name, which includes a random suffix (for example, `azure-iot-operations-cym7h`), find your specific extension name by running:
> After the upgrade completes, reset `AgentOperationTimeoutInMinutes` back to a lower value like five minutes to avoid long wait times on future operations if something else fails.
77
+
17
78
## Azure Device Registry issues
18
79
19
80
This section lists current known issues for the Azure Device Registry.
Copy file name to clipboardExpand all lines: articles/static-web-apps/apis-functions.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ ms.author: jikunchen
11
11
12
12
# API support in Azure Static Web Apps with Azure Functions
13
13
14
-
Front end web applications often callback end APIs for data and services. By default, Azure Static Web Apps provides built-in serverless API endpoints via [Azure Functions](apis-functions.md).
14
+
Front end web applications often call back-end APIs for data and services. By default, Azure Static Web Apps provides built-in serverless API endpoints via [Azure Functions](apis-functions.md).
15
15
16
16
Azure Functions APIs in Static Web Apps are available in two possible configurations depending on the [hosting plan](plans.md#features):
Copy file name to clipboardExpand all lines: articles/virtual-wan/how-to-routing-policies.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -173,7 +173,7 @@ Before enabling routing intent, consider the following:
173
173
* Enabling routing intent affects the advertisement of prefixes to on-premises. See [prefix advertisements](#prefixadvertisments) for more information.
174
174
* You can open a support case to enable connectivity across ExpressRoute circuits via a Firewall appliance in the hub. Enabling this connectivity pattern modifies the prefixes advertised to ExpressRoute circuits. See [About ExpressRoute](#expressroute) for more information.
175
175
* Routing intent is the only mechanism in Virtual WAN to enable inter-hub traffic inspection via security appliances deployed in the hub. Inter-hub traffic inspection also requires routing intent to be enabled on all hubs to ensure traffic is routed symmetrically between security appliances deployed in Virtual WAN hubs.
176
-
* Routing intent sends Virtual Network and on-premises traffic to the next hop resource specified in the routing policy. Virtual WAN programs the underlying Azure platform to route your on-premises and Virtual Network traffic in accordance with the configured routing policy and doesn't process the traffic through the Virtual Hub router. Because packets routed via routing intent aren't processed by the router, you don't need to allocate additional [routing infrastructure units](hub-settings.md#capacity) for data-plane packet forwarding on hubs configured with routing intent. However, you might need to allocate additional routing infrastructure units based on the number of Virtual Machines in Virtual Networks connected to the Virtual WAN Hub.
176
+
* Routing intent sends Virtual Network and on-premises traffic to the next hop resource specified in the routing policy. Virtual WAN programs the underlying Azure platform to route your on-premises and Virtual Network traffic in accordance with the configured routing policy and doesn't process the traffic through the Virtual Hub router. This also means Virtual Hub router data processing isn't charged for traffic routed via routing intent. As a result, you don't need to allocate additional [routing infrastructure units](hub-settings.md#capacity) for data-plane packet forwarding on hubs configured with routing intent. However, you might need to allocate additional routing infrastructure units based on the number of Virtual Machines in Virtual Networks connected to the Virtual WAN Hub.
177
177
* Routing intent allows you to configure different next-hop resources for private and internet routing policies. For example, you can set the next hop for private routing policies to Azure Firewall in the hub and the next hop for internet routing policy to an NVA or SaaS solution in the hub. Because SaaS solutions and Firewall NVAs are deployed in the same subnet in the Virtual WAN hub, deploying SaaS solutions with a Firewall NVA in the same hub can impact the horizontal scalability of the SaaS solutions as there are less IP addresses available for horizontal scale-out. Additionally, you can have at most one SaaS solution deployed in each Virtual WAN hub.
![learn-build-service-prod[bot]](https://avatars.githubusercontent.com/in/237442?v=4&size=40){kind=avatar}
0 commit comments