Merge pull request #302659 from andreamichaelmsft/andrea-branch-3

[Azure Doc-a-thon] Heavily updated all AVNM general docs

Author: AnnaMHuff

articles/virtual-network-manager/common-issues.md

@@ -5,7 +5,7 @@ author: mbender-ms
 ms.author: mbender
 ms.service: azure-virtual-network-manager
 ms.topic: how-to
-ms.date: 07/11/2025
+ms.date: 05/06/2025
 ms.custom: template-concept
 ---
 
@@ -15,42 +15,40 @@ This article describes common issues with Azure Virtual Network Manager and prov
 
 ## Configuration changes aren't applied 
 
-The following are some common reasons why your configuration changes aren't applied:
+These are some common reasons why your configuration changes aren't applied:
 
-### The configuration isn't deployed
 
-You must deploy the configuration to your desired regions that contain your intended virtual networks after you create or modify the configuration. The configuration is only applied to the virtual networks after the configuration is deployed to the regions of those virtual networks.
+### The configuration isn't applied to the regions where virtual networks are located
 
-To resolve this issue, you need to [deploy the configuration](./concept-deployments.md) after you create or modify the configuration.
+You need to check the regions where the virtual networks are located. The configuration is only applied to the regions where the virtual networks are located. If you have a virtual network in a region that isn't included in the configuration, the configuration isn't applied to that virtual network.
 
-### Updated configuration changes aren't reflected in my virtual network
+To resolve this issue, you need to add the region where the virtual network is located to the configuration. 
 
-Upon modifying your configuration, you must deploy the configuration again in the desired regions for those changes to take effect. 
+### Configuration isn't deployed
 
-### The configuration isn't deployed to the region where the virtual network is located
+You need to deploy the configuration after the configuration is created or modified. The configuration is only applied to the virtual networks after the configuration is deployed.
 
-Verify the region where the virtual network is located is a part of the region set where you deployed your configuration. To take effect, the configuration must be deployed to the region where the virtual network is located. If you have a virtual network in a region that isn't targeted by the configuration's deployment, the configuration isn't applied to that virtual network.
-
-To resolve this issue, you need to [deploy the configuration](./concept-deployments.md) to the region where the virtual network is located.
+To resolve this issue, you need to deploy the configuration after the configuration is created or modified.
 
 ### Configuration changes didn't have enough time to apply
 
-You need to wait for the configuration changes to finish deploying. Upon deployment, it can take up to 15-20 minutes for configuration changes to apply across the virtual networks in your targeted regions. When there's an update to your network group membership, it can take about 10 minutes for the appropriate configuration changes to reflect.
+You need to wait for the configuration changes to apply. The time it takes for the configuration changes to apply after you commit the configuration is around 15-20 minutes. When there's an update to your network group membership, it would take about 10 minutes for the changes to reflect.
+
+### Updated configuration changes aren't reflected in Azure Virtual Network Manager
 
+You need to deploy the new configuration after the configuration is modified. 
 
 ## Connectivity configuration isn't working as expected 
 
-The following are some common reasons why your connectivity configuration isn't working as expected:
+Here are common reasons why your connectivity configuration isn't working as expected:
 
 ### The virtual network peering creation fails
 
 In a hub-and-spoke topology, if you enable the option to *use the hub as a gateway*, you need to have a gateway in the hub virtual network. Otherwise, the creation of the virtual network peering between the hub and the spoke virtual networks fails. 
 
 ### Members in the network group can't communicate with each other
 
-If you want to have members in the network group communicate with each other across regions, you need to enable the global mesh option.
-
-In a hub-and-spoke topology, if you want the members of your spoke network group to communicate with each other, you need to enable the direct connectivity option. This option connects the members of a spoke network group among each other without going through the hub virtual network. If your topology contains multiple spoke network groups, it's important to note that this direct connectivity option only enables connectivity *within* each network group, meaning cross-network group communication is *not* established.
+If you want to have members in the network group communicate with each other across regions in a hub and spoke topology configuration, you need to enable the global mesh option. 
 
 ## Next steps
 

articles/virtual-network-manager/concept-deployments.md

@@ -5,49 +5,49 @@ author: mbender-ms
 ms.author: mbender
 ms.service: azure-virtual-network-manager
 ms.topic: concept-article
-ms.date: 05/06/2024
+ms.date: 07/11/2025
 ---
 
-# Manage Configuration Deployments in Azure Virtual Network Manager
+# Manage configuration deployments in Azure Virtual Network Manager
 
-Learn how configuration deployments in Azure Virtual Network Manager are applied to your network resources. Explore how updating a configuration deployment differs by membership type, and understand details about *Deployment status* and *Goal state model*.
+Learn how configuration deployments in Azure Virtual Network Manager are applied to your network resources. Explore how updating a configuration deployment differs by network group membership type, and understand details about [deployment status](#deployment-status-and-monitoring) and the [goal state model](#goalstate).
 
 ## How deployment works
 
-*Deployment* is the method Azure Virtual Network Manager uses to apply configurations to your virtual networks in network groups. Configurations don't take effect until they're deployed. When a deployment request is sent to Azure Virtual Network Manager, it calculates the [goal state](#goalstate) of all resources under your network manager in that region. Goal state is a combination of deployed configurations and network group membership. Network manager applies the necessary changes to your infrastructure.
+*Deployment* is the method Azure Virtual Network Manager uses to apply configurations to your network groups' virtual networks. Configurations don't take effect until they're deployed. When a deployment request is sent to Azure Virtual Network Manager, it calculates the [goal state](#goalstate) of all targeted resources under your network manager in the targeted regions. The goal state is a combination of deployed configurations and network group membership. Azure Virtual Network Manager applies the necessary changes to your resources' settings to achieve the desired goal state.
 
-When committing a deployment, you select the regions where the configuration applies. The length of time for a deployment depends on how large the configuration is. Once the virtual networks are members of a network group, deploying a configuration onto that network group takes a few minutes. This includes adding or removing group members directly, or configuring an Azure Policy resource. Safe deployment practices recommend gradually rolling out changes on a per-region basis.
+When committing a deployment, you select the regions where you want the selected configurations to apply. The time it takes for a deployment to complete depends on how large the configuration is. Once the virtual networks are members of a network group targeted by a configuration, deploying that configuration onto that network group can take a few minutes. This scenario includes adding or removing virtual networks to or from the targeted network group manually or conditionally with Azure Policy. Safe deployment practices recommend gradually rolling out changes on a per-region basis.
 
 > [!IMPORTANT]
-> Only one security configuration can be deployed to a region. However, multiple connectivity configurations can exist in a region. To deploy multiple security admin configurations to a region, you can create multiple rule collections in a security configuration, instead of creating multiple security admin configurations.
+> Only one security admin configuration can be deployed from a single network manager to a region at a time. However, multiple connectivity and routing configurations can exist in a region. To deploy multiple sets of security admin rules to a region, you can create multiple rule collections within a security admin configuration.
 
 ## Deployment latency and timing
 
-Deployment latency is the time it takes for a deployment configuration to be applied and take effect. There are two factors in how quickly the configurations are applied: 
+There are two factors in how quickly a deployment's configurations are applied and take effect: 
 
-- The base time of applying a configuration is a few minutes. 
+- The base time of applying a configuration is a few minutes.
 
-- The time to receive a notification of network group membership can vary. 
+- The time to update network group membership (and thus the members onto which active configurations are newly applied to or removed from) can vary.
 
-For manually added members, notification is immediate. For dynamic members where the scope is less than 1,000 subscriptions, notification takes a few minutes. In environments with more than 1,000 subscriptions, the notification mechanism works in a 24-hour window. Changes to network groups take effect without the need for configuration redeployment.  
+For manually added members, the network group membership immediately updates. For conditionally added members where the scope is less than 1,000 subscriptions, the network group membership can take a few minutes to update. For conditionally added members in environments with more than 1,000 subscriptions, the network group gets notified by Azure Policy in a 24-hour window; after that notification, active configurations are applied to the updated network group members in a few minutes. Changes to network group membership take effect without the need for configuration redeployment.
 
-Virtual network manager applies the configuration to the virtual networks in the network group even if your network group consists of dynamic members from more than 1,000 subscriptions. When the virtual network manager is notified of group membership, the configuration is applied in a few minutes. 
+For example, if a virtual network is newly added to a network group with an active configuration already deployed onto it in the same region as that new virtual network member, that virtual network automatically receives the configuration without manually deploying the configuration again.
 
 ## Deployment status and monitoring
 
-When you commit a configuration deployment, the API does a POST operation. Once the deployment request is made, Azure Virtual Network Manager calculates the goal state of your networks in the deployed regions and requests the underlying infrastructure to make the changes. You can see the deployment status on the *Deployment* page of the Virtual Network Manager.
+When you commit a configuration deployment, the API forms a POST operation. Once the deployment request is made, Azure Virtual Network Manager calculates the goal state of your networks in the deployed regions and requests the underlying infrastructure to make the changes. You can see the deployment status on the *Deployment* page of your Azure Virtual Network Manager instance, or network manager.
 
 :::image type="content" source="./media/tutorial-create-secured-hub-and-spoke/deployment-in-progress.png" alt-text="Screenshot of deployment in progress in deployment list.":::
 
 ## <a name = "goalstate"></a> Goal state model
 
-When you commit a deployment of configurations, you're describing the goal state of your network manager in that region. This goal state is enforced during the next deployment. For example, when you commit configurations named *Config1* and *Config2* into a region, these two configurations get applied and become the region's goal state. If you decided to commit configuration named *Config1* and *Config3* into the same region, *Config2* would then be removed, and *Config3* would be added. To remove all configurations, you would deploy a **None** configuration against the regions you no longer wish to have any configurations applied.
+When you commit a deployment of configurations, you describe the goal state of your network manager in the targeted regions. This goal state is enforced during the next deployment. For example, when you commit configurations *Config1* and *Config2* into a region, these two configurations get applied and become the region's goal state. If you decided to commit configurations *Config1* and *Config3* into the same region, *Config2* would then be removed, and *Config3* would be added. To remove all configurations, you would deploy **None** to the regions where you no longer wish to have any configurations applied.
 
 ## Configuration availability
 
-A virtual network manager instance is available in a region as long as the region is up and running. Should a region with a virtual network manager go down, the virtual network manager instance is no longer available for deploying new configurations or editing current configurations. However, the configurations that were deployed to the virtual networks in the network group are still in effect unless those virtual networks are in the region that went down.
+A network manager is available in a region as long as the region is up and running. Should a region with a network manager go down, the network manager is no longer available to submit new configuration deployments or modify existing configurations. However, the configurations that were deployed to the targeted network groups' virtual networks in the targeted regions are still in effect unless those virtual networks are in the region that went down.
 
-For example, if an Azure Virtual Network Manager instance is created in region A and programs the VNets in region B, the configurations are still in effect even if region A goes down. However, if region B goes down, the configurations are no longer in effect. Also, you can't create new configurations or edit current configurations for virtual networks in region B.
+For example, if a network manager exists in *regionA* and has deployed configurations onto virtual networks in *regionB*, those configurations are still in effect even if *regionA* goes down. However, you won't be able to create new, modify existing, or deploy configurations from the network manager in *regionA*. As another example, if *regionB* goes down, those configurations are no longer in effect. In this case, further deployments to virtual networks in *regionB* won't be successful.
 
 ## Next steps