Merge pull request #10546 from MicrosoftDocs/main

Out-of-band push to live for critical updates to CU articles for SQL Server 2022 CU23 and 2025 CU1

Author: aartig13

support/azure/azure-container-instances/configuration-setup/container-group-deployment-waiting-state.md

@@ -2,8 +2,8 @@
 title: Container group deployment remains in Waiting state
 description: Learn how to resolve an issue in which a container group deployment never progresses from the Waiting state in Azure Container Instances.
 ms.date: 04/17/2025
-author: tysonfms
-ms.author: tysonfreeman
+author: kennethgp
+ms.author: kegonzal
 editor: v-jsitser
 ms.reviewer: edneto, v-leedennis
 ms.service: azure-container-instances
@@ -22,33 +22,30 @@ When you try to deploy a container group, the deployment times out after 30 minu
 
 The Waiting state indicates there's a condition preventing deployment setup or container start. The most likely root causes include:
 
-- The container main process won't start or crashes.
+- The container main process doesn't start or crashes.
 - The container is using reserved ports.
 - The container group has an Azure file share volume and it's failing to mount.
-- There's subnet IP exhaustion (like bring your own virtual network (BYOVNET)).
+- There's subnet IP exhaustion (bring your own virtual network (BYOVNET) deployment).
 - There are capacity issues.
 
 ## Solution
 
 Possible solutions include:
 
-- Check that the container runs fine locally. A local machine with Docker can be used to do this.
+- Check that the container runs fine locally. A local machine with Docker can be used to validate the container runs correctly.
 - Inspect possible errors on the **Container Events** tab starting with the main container process.
 - Make sure no reserved ports are being used in the container definition. For more information, see [Does the ACI service reserve ports for service functionality?](/azure/container-instances/container-instances-faq#does-the-aci-service-reserve-ports-for-service-functionality-).
-- Check that there's connectivity to the Azure file share and that the key is correct or valid. If deployment is on BYOVNET, check that DNS resolution is working for the Azure file share fully qualified domain name (FQDN).
-- Check Azure file share volume [limitations](/azure/container-instances/container-instances-volume-azure-files#limitations) for Azure Container Instances (ACI). Using a private endpoint to connect to an Azure file share hasn't been tested and might not be reliable. Instead, use a subnet service endpoint for private connectivity as recommended in documentation.
-- Change the subnet network mask. ACI keeps its own IP mapping internally and at ARM level all IPs always show as available. Depending on the frequency of deployments or restarts, subnet IP exhaustion errors can happen because internal mapping isn't updated in time. To avoid this issue, we recommend using a subnet network mask of `/24` or greater.
-- Attempt the deployment with less resource requests or in another region to confirm possible capacity issues.
+- Check that there's connectivity to the Azure file share and that the key is correct or valid. If deployment is on BYOVNET, check that domain name system (DNS) resolution is working for the Azure file share fully qualified domain name (FQDN).
+- Check Azure file share volume [limitations](/azure/container-instances/container-instances-volume-azure-files#limitations) for Azure Container Instances (ACI). Using a private endpoint to connect to an Azure file share isn't tested and might not be reliable. Instead, use a subnet service endpoint for private connectivity as recommended in documentation.
+- Change the subnet network mask. ACI keeps its own IP mapping internally and at Azure Resource Manager level all IPs always show as available. Depending on the frequency of deployments or restarts, subnet IP exhaustion errors can happen because internal mapping isn't updated in time. To avoid IP exhaustion, we recommend using a subnet network mask of `/24` or greater.
+- To confirm possible capacity issues, attempt the deployment with fewer resource requests or in another region.
 
 > [!NOTE]
-> We don't recommend using subnets smaller than `/24` to work around unsupported scenarios (like simulating a fixed IP address by restricting the Dynamic Host Configuration Protocol (DHCP) to only a few IPs) as this can cause failed deployments or failed start operations due to subnet full errors.
+> We don't recommend using subnets smaller than `/24` to work around unsupported scenarios (like simulating a fixed IP address by restricting the Dynamic Host Configuration Protocol (DHCP) to only a few IPs) as this configuration can cause failed deployments or failed start operations due to subnet full errors.
 
 ## Resources
 
 - [Tutorial: Deploy a multi-container group using a Resource Manager template](/azure/container-instances/container-instances-multi-container-group)
-
 - [Azure Container Instances states](/azure/container-instances/container-state)
 
- 
-
 [!INCLUDE [Third-party contact disclaimer](~/includes/third-party-contact-disclaimer.md)]

support/azure/azure-container-instances/configuration-setup/container-group-transitioning-state.md

@@ -1,63 +1,53 @@
 ---
 title: Container group remains in transitioning state
 description: Learn how to resolve a problem that causes a container group to get stuck in the transitioning state (status code 409, ContainerGroupTransitioning).
-ms.date: 06/25/2024
-author: tysonfms
-ms.author: tysonfreeman
+ms.date: 01/15/2025
+author: kennethgp
+ms.author: kegonzal
 editor: v-jsitser
-ms.reviewer: v-leedennis
 ms.service: azure-container-instances
 ms.topic: troubleshooting-problem-resolution
 ms.custom: sap:Configuration and Setup
 #Customer intent: As an Azure administrator, I want to learn how to resume a container group that's stuck in a transitioning state so that I can successfully perform a container group operation (such as create, start, restart, stop, or delete).
 ---
 # Container group remains in transitioning state
 
-This article discusses how to resolve an operational failure that occurs when a container group remains in a transitioning state indefinitely in Microsoft Azure Container Instances. The article also discusses failures that occur during container group operations to [create, start, restart](/azure/container-instances/container-state#create-start-and-restart-operations), [stop, or delete](/azure/container-instances/container-state#stop-and-delete-operations) a container group.
+This article discusses how to resolve an operational failure that occurs when a container group remains in a transitioning state indefinitely in Microsoft Azure Container Instances. The article also discusses failures that occur during container group operations to [start, restart](/azure/container-instances/container-state#create-start-and-restart-operations), [stop, or delete](/azure/container-instances/container-state#stop-and-delete-operations) a container group.
 
 ## Symptoms
 
-When you do something that directly or indirectly triggers a container group operation, such as deleting an Azure Kubernetes Service (AKS) cluster, you receive the following error message:
+When you issue a start/stop operation on a container group, you receive the following error message:
 
-> **InternalErrorCode**: "ContainerGroupTransitioning"  
-> **StatusCode**: "409"  
-> **Message**: "The container group '\<container-group-name>' is still transitioning, please retry later."
+**InternalErrorCode**: "ContainerGroupTransitioning"  
+**StatusCode**: "409"  
+**Message**: "The container group '\<container-group-name>' is still transitioning, please retry later."
 
 ## Cause
 
-During a continuous start operation of the container group, sidecar containers in Container Instances aren't terminated as expected. In this situation, the container group is stuck in the **Succeeded** state.
+### Cause 1: After stop operation
 
-## Solution 1: Stop and restart the container group
+During a continuous stop operation of the container group, system sidecar containers in the container group aren't terminated in time.
 
-1. In the [Azure portal](https://portal.azure.com), search for and select **Container instances**.
+### Cause 2: After start operation
 
-1. In the list of container instances, select the name of your container group (container instance).
+The stopped state for previous operation wasn't propagated yet or didn't propagate correctly (known platform issue).
 
-1. On the **Overview** page of your container group, select **Stop** to stop the container group. In the **Stop container instances** dialog box, select **Yes** to confirm this action.
+## Solution 1
 
-1. Wait until the container group is completely stopped. (This can take up to three minutes.)
-
-1. Select **Start** to start the container group again.
-
-## Solution 2: Stop the container group for a non-running container (deployed by Logic Apps)
-
-If the [container is deployed by using an Azure Logic App](/azure/connectors/connectors-create-api-container-instances?toc=%2Fazure%2Fcontainer-instances%2Ftoc.json&bc=%2Fazure%2Fcontainer-instances%2Fbreadcrumb%2Ftoc.json), check the state of the container. If the container isn't in the **Running** state, stop the container group. For more information, see [Run sentiment analysis based on triggers with Azure Container Instances (ACI) and the ACI Logic Apps connector](https://github.com/Azure-Samples/aci-logicapps-integration).
+- Wait until the container group is fully stopped to allow the system sidecars to fully terminate (allow at least 10 seconds between operations).
+- If the [container is deployed by using an Azure Logic App](/azure/connectors/connectors-create-api-container-instances?toc=%2Fazure%2Fcontainer-instances%2Ftoc.json&bc=%2Fazure%2Fcontainer-instances%2Fbreadcrumb%2Ftoc.json), check the state of the container and then make sure the status is **Stopped** before issuing a start operation.
+- For job container groups (process runs once and exits, restart policy is **Never**) in **Terminated** state, issue a stop operation before a start operation to make sure the correct status is propagated first. You can also issue a restart operation. A restart operation avoids a new container group deployment and instead restarts the application process inside the container.
 
 > [!NOTE]
-> As a best practice, we recommend that you check the state of the container before you stop or start a container group. If you start a container group that already has a running container, you might cause the transitioning state problem.
+> As a best practice, we recommend that you always issue a stop operation before a start operation to ensure the correct status is propagated. If you start a container group that already has a running container, you might cause the transitioning state problem.
 
-## Solution 3: Open a support ticket
+## Solution 2: Open a support ticket
 
-If the previous solutions don't fix the problem, and you still encounter the error message, open a support ticket.
+If the previous solutions don't fix the problem and you still encounter the error message, open a support ticket.
 
-## More information
+## Resources
 
 - [Tutorial: Deploy a multi-container group using a Resource Manager template](/azure/container-instances/container-instances-multi-container-group)
-
 - [Azure Container Instances states](/azure/container-instances/container-state)
-
 - [Manually stop or start containers in Azure Container Instances](/azure/container-instances/container-instances-stop-start)
-
 - [Update containers in Azure Container Instances](/azure/container-instances/container-instances-update)
-
- 

support/azure/azure-container-instances/configuration-setup/docker-hub-rate-limit-registryerrorresponse.md

@@ -1,19 +1,19 @@
 ---
-title: ACI can't pull images anonymously from Docker Hub
+title: Anonymous image pulls from Docker Hub to Azure Container Instances fail due to rate limits
 description: Provides a solution to errors when you try to create or update an Azure container instance and pull images anonymously from Docker Hub.
 ms.date: 09/24/2024
-ms.reviewer: chiragpa, albarqaw, v-weizhu
+ms.reviewer: kegonzal
 ms.service: azure-container-instances
 ms.custom: sap:Configuration and Setup
 ---
 
 # Anonymous image pulls from Docker Hub to Azure Container Instances fail due to rate limits
 
-This article provides a solution to errors that occur during anonymous image pulls from Docker Hub when you try to create or update an Azure container instance.
+This article provides a solution to errors that occur during anonymous image pulls from Docker Hub when you try to create or update an Azure Container Instance.
 
 ## Symptoms
 
-When you try to create or update a container instance and pull images anonymously from Docker Hub using the Azure portal or Azure CLI, an error message that resembles the following text is displayed:
+When you try to create or update a container instance, an error message that resembles the following text is displayed:
 
 > Error code: RegistryErrorResponse  
 > An error response is received from the docker registry 'index.docker.io'. Please retry later.
@@ -32,21 +32,19 @@ You might also see the following error messages:
 
 ## Cause
 
-This issue might occur due to the rate limits on image pulls from Docker Hub. An agreement between Microsoft and Docker to allow Azure IP addresses to make unlimited anonymous image pulls from Docker Hub ended on June 30, 2024.
+This issue might occur due to the rate limits on image pulls from Docker Hub. An agreement between Microsoft and Docker to allow Azure IP addresses to make unlimited anonymous image pulls from Docker Hub ended on June 30, 2024. If you're deploying to a Virtual Network (BYOVNET), the image pull occurs through a random platform public IP.
 
 ## Solution
 
-To resolve this issue, create a Docker account and use the Docker account credentials to authenticate the image pulls. This can immediately increase the rate limit. However, we strongly recommend using the Artifact Cache feature within Azure Container Registry (ACR) with your Docker subscription. This allows you to configure an authenticated cache rule for caching images from Docker Hub to your ACR. You can then modify your build and deployment scripts to pull the same images directly from ACR.
+Create a Docker account and use the Docker account credentials to authenticate the image pulls and immediately increase the rate limit. However, we strongly recommend using the Artifact Cache feature within Azure Container Registry (ACR) with your Docker subscription. This setup allows you to configure an authenticated cache rule for caching images from Docker Hub to your ACR. You can then modify your build and deployment scripts to pull the same images directly from ACR.
 
 > [!NOTE]
 > Docker offers a free subscription that allows customers to get 200 pulls every six hours. If 200 pulls aren't enough for you, we recommend purchasing a paid Docker subscription. A paid Docker subscription gives you 5,000 pulls every 24 hours, which can be increased by contacting Docker directly.
 
-## References
+## Resources
 
 - [Docker Hub usage and rate limits](https://docs.docker.com/docker-hub/download-rate-limit/)
 - [Configure Artifact Cache to consume public content](/azure/container-registry/buffer-gate-public-content#configure-artifact-cache-to-consume-public-content)
 - [Artifact cache in Azure Container Registry](/azure/container-registry/container-registry-artifact-cache)
 
 [!INCLUDE [Third-party disclaimer](../../../includes/third-party-disclaimer.md)]
-
- 

support/azure/azure-container-instances/configuration-setup/error-codes-spot-container-creation.md

@@ -5,7 +5,7 @@ ms.date: 04/14/2025
 author: tysonfms
 ms.author: tysonfreeman
 editor: v-jsitser
-ms.reviewer: edneto, v-weizhu, v-leedennis
+ms.reviewer: edneto, v-weizhu, v-leedennis, kegonzal
 ms.service: azure-container-instances
 ms.custom: sap:Configuration and Setup
 #customer intent: As a user of Azure Container Instances, I want find details and solutions to common user errors that involve Spot containers so that I can create Spot containers successfully.
@@ -21,10 +21,7 @@ This article provides solutions to common errors that occur when you try to crea
 | `SpotPriorityContainerGroupWithGPUResourcesNotSupported` | `Spot Priority Container Groups that include containers requesting GPU resources are not supported.` | GPUs aren't supported for Spot containers. Remove the GPU from the request, and try again. |
 | `PriorityNotSpecified` | `The 'Priority' must be one of 'Regular,Spot' for container group '{xyz}'.` | If the priority is mentioned in the request body, specify a value of `Regular` or `Spot`. |
 
-## More information
+## Resources
 
 - [Azure Container Instances Spot containers (preview)](/azure/container-instances/container-instances-spot-containers-overview)
-
 - [FAQ - Spot containers on Azure Container Instances (Preview)](/azure/container-instances/container-instances-faq#spot-containers-on-azure-container-instances--preview)
-
- 

support/azure/azure-container-instances/configuration-setup/inaccessible-image.md

@@ -5,7 +5,7 @@ ms.date: 01/18/2024
 author: tysonfms
 ms.author: tysonfreeman
 editor: v-jsitser
-ms.reviewer: v-leedennis, v-weizhu
+ms.reviewer: v-leedennis, v-weizhu, kegonzal
 ms.service: azure-container-instances
 ms.custom: sap:Configuration and Setup
 #Customer intent: As an Azure administrator, I want to learn how to resolve the "InaccessibleImage" error so that I can successfully deploy an image onto a container instance.
@@ -37,22 +37,19 @@ When you try to deploy a container instance, the deployment fails, and you recei
 
 ## Cause
 
-You're trying to use a service principal to access the Azure container registry. This scenario can occur because of one of the following reasons:
-
+- You're trying to use a service principal to access the Azure Container Registry.
 - You specified incorrect credentials when you tried to create the container instance.
-
-- You specified the correct credentials, but the service calls on Container Instances are blocked by firewall rules in the Azure container registry.
+- You specified the correct credentials, but the Azure Container Registry firewall blocks the calls.
 
 ## Solution
 
 You must use a managed identity to allow the Container Instances trusted service to access the container registry. For more information, see [Allow trusted services to securely access a network-restricted container registry](/azure/container-registry/allow-access-trusted-services#about-trusted-services). You can also learn more at [Deploy to Azure Container Instances from Azure Container Registry using a managed identity](/azure/container-instances/using-azure-container-registry-mi).
 
-## References
+> [!NOTE]
+> Image pull phase happens before container is created. If you're deploying to a Virtual Network (BYOVNET), image pull occurs through a random platform public IP. Because of this, private registries other than Azure Container Registry aren't supported even if there's private connectivity from the target subnet.
 
-- [Managed identities in Azure Container Apps](/azure/container-apps/managed-identity)
+## Resources
 
+- [Managed identities in Azure Container Apps](/azure/container-apps/managed-identity)
 - [Azure Container Apps image pull with managed identity](/azure/container-apps/managed-identity-image-pull)
-
 - [Tutorial: Deploy a multi-container group using a Resource Manager template](/azure/container-instances/container-instances-multi-container-group)
-
-