Merge pull request #299411 from mbender-ms/freshness-may-2025-01

virtual network manager | Maintenanace | May 2025 - Updates to SEO and Freshness

Author: JillGrant615

articles/virtual-network-manager/TOC.yml

@@ -116,6 +116,8 @@
       href: how-to-manage-ip-addresses-network-manager.md
 - name: Troubleshoot
   items:
+    - name: Common issues 
+      href: common-issues.md
     - name: Event Log Options for Azure Virtual Network Manager
       href: concept-event-logs.md
     - name: Configure Event Logs for Azure Virtual Network Manager

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

@@ -1,40 +1,57 @@
 ---
 title: 'Common issues seen with Azure Virtual Network Manager'
-description: Learn about common issues seen when using Azure Virtual Network Manager.
+description: Learn about common issues with Azure Virtual Network Manager and how to resolve them quickly. Find solutions and troubleshoot effectively.
 author: mbender-ms
 ms.author: mbender
 ms.service: azure-virtual-network-manager
 ms.topic: how-to
-ms.date: 06/10/2024
+ms.date: 05/06/2025
 ms.custom: template-concept
 ---
 
 # Common issues seen with Azure Virtual Network Manager
 
-In this article, we cover common issues you may face when using Azure Virtual Network Manager and provide some possible solutions.
+This article describes common issues with Azure Virtual Network Manager and provides solutions to help you quickly troubleshoot and resolve them.
 
-## Why isn't my configuration getting applied? 
+## Configuration changes aren't applied 
 
-**Common reasons for configurations not being applied:** 
+These are some common reasons why your configuration changes aren't applied:
 
-* The configuration isn't deployed to the regions where virtual networks are located. 
 
-* You haven't deployed the configuration yet. You need to deploy the configuration to have it take effect. 
+### The configuration isn't applied to the regions where virtual networks are located.
 
-* The configuration didn't have enough time to effect. The time it takes for the configuration 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. 
+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.
 
-## I updated my configuration, but the changes aren't reflected in my environment. 
+To resolve this issue, you need to add the region where the virtual network is located to the configuration. 
+
+### Configuration isn't deployed
+
+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.
+
+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 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. 
 
-## Why is my connectivity configuration not working? 
+## Connectivity configuration isn't working as expected 
+
+Here are common reasons why your connectivity configuration isn't working as expected:
 
-**You'll need to consider the following items:** 
+### 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. 
+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. 
 
-* If you want to have members in the network group to communicate with each other across regions in a hub and spoke topology configuration, you need to enable the global mesh option. 
+### Members in the network group can't communicate with each other
+
+If you want to have members in the network group to communicate with each other across regions in a hub and spoke topology configuration, you need to enable the global mesh option. 
 
 ## Next steps
 
-See [Azure Virtual Network Manager FAQ](faq.md), for answers to frequently asked questions.
+- [Azure Virtual Network Manager overview](overview.md)
+- [Azure Virtual Network Manager FAQ](faq.md)
+

articles/virtual-network-manager/concept-cross-tenant.md

@@ -1,52 +1,58 @@
 ---
 title: 'Cross-tenant support in Azure Virtual Network Manager'
-description: Learn about how cross-tenant connections are supported in Azure Virtual Network Manager.
+description: Learn how cross-tenant support in Azure Virtual Network Manager helps manage virtual networks across multiple tenants. Explore scenarios and benefits.
 author: mbender-ms    
 ms.author: mbender
 ms.service: azure-virtual-network-manager
 ms.topic: concept-article
-ms.date: 03/22/2024
+ms.date: 05/06/2025
 ---
 
 
-# Cross-tenant support in Azure Virtual Network Manager
+# Cross-Tenant Support in Azure Virtual Network Manager
 
-In this article, you learn about cross-tenant support in Azure Virtual Network Manager. Cross-tenant supports allows organizations to use a central Network Manager instance for managing virtual networks across different tenants and subscriptions.
+Cross-tenant support in Azure Virtual Network Manager enables organizations to centrally manage virtual networks across multiple tenants and subscriptions. This article describes scenarios, benefits, and how to establish cross-tenant connections.
 
- ## Overview of Cross-tenant 
+## Overview of cross-tenant support
 
-Cross-tenant support in Azure Virtual Network Manager allows you to add subscriptions or management groups from other tenants to your network manager. This is done by establishing a two-way connection between the network manager and target tenants. Once connected, the central manager can deploy connectivity and/or security admin rules to virtual networks across those connected subscriptions or management groups. This support assists organizations that fit the following scenarios: 
+Cross-tenant support in Azure Virtual Network Manager allows you to add subscriptions or management groups from other tenants to your network manager. This is done by establishing a two-way connection between the network manager and target tenants. Once connected, the central manager can deploy connectivity and/or security admin rules to virtual networks across those connected subscriptions or management groups. 
+
+This support assists organizations that fit the following scenarios: 
 
 - Acquisitions – In instances where organizations merge through acquisition and have multiple tenants, cross tenant support allows a central network manager to manage virtual networks across the tenants. 
 
 - Managed service provider – In managed service provider scenarios, an organization can manage the resources of other organizations. Cross-tenant support allows central management of virtual networks by a central service provider for multiple clients. 
 
-## Cross-tenant connection 
+## Establish cross-tenant connection 
 
 Establishing cross-tenant support begins with creating a cross tenant connection between two tenants. Cross-tenant support requires two-way consent--one from the network manager, the other from the target tenant's virtual network manager hub. The connections are as follows:
 
-- Network manager connection - You create a cross-tenant connection from your network manager. The connection includes the exact scope of the tenant’s subscriptions or management groups to manage in your network manager.
-- Virtual network manager hub connection - the tenant creates a cross-tenant connection from their virtual network manager hub. This connection includes the scope of subscriptions or management groups to be managed by the central network manager.
+| Connection Type | Description |
+|----------------|-------------|
+| Network manager connection | You create a cross-tenant connection from your network manager. The connection includes the exact scope of the tenant's subscriptions or management groups to manage in your network manager. |
+| Virtual network manager hub connection | The tenant creates a cross-tenant connection from their virtual network manager hub. This connection includes the scope of subscriptions or management groups managed the central network manager. |
 
 Once both cross-tenant connections exist and the scopes are exactly the same, a true connection is established. Administrators can use their network manager to add cross-tenant resources to their [network groups](concept-network-groups.md) and to manage virtual networks included in the connection scope. Existing connectivity and/or security admin rules are applied to the resources based on existing configurations.
 
-A cross-tenant connection can only be established and maintained when both objects from each party exist. When one of the connections is removed, the cross-tenant connection is broken. If you need to delete a cross-tenant connection, you perform the following:
+A cross-tenant connection can only be established and maintained when both objects from each party exist. When one of the connections is removed, the cross-tenant connection is broken. If you need to delete a cross-tenant connection, you perform the following steps:
 
 - Remove cross-tenant connection from the network manager side via Cross-tenant connections settings in the Azure portal.
 - Remove cross-tenant connection from the tenant side via Virtual network manager hub's Cross-tenant connections settings in the Azure portal.
 
 > [!NOTE] 
-> Once a connection is removed from either side, the network manager will no longer be able to view or manage the tenant's resources under that former connection's scope.
+> Once a connection is removed from either side, the network manager can't view or manage the tenant's resources under that former connection's scope.
 
 ## Connection states
-The resources required to create the cross-tenant connection contain a state, which represents whether the associated scope has been added to the Network Manager scope. Possible state values include:
+The resources required to create the cross-tenant connection contain a state, which represents whether the associated scope is added to the Network Manager scope. Possible state values include:
 
-* Connected: Both the Scope Connection and Network Manager Connection resources exist. The scope has been added to the Network Manager's scope.
-* Pending: One of the two approval resources hasn't been created. The scope hasn't yet been added to the Network Manager's scope.
-* Conflict: There's already a network manager with this subscription or management group defined within its scope. Two network managers with the same scope access can't directly manage the same scope, therefore this subscription/management group can't be added to the Network Manager scope. To resolve the conflict, remove the scope from the conflicting network manager's scope and recreate the connection resource.
-* Revoked: The scope was at one time added to the Network Manager scope, but the removal of an approval resource has caused it to be revoked.
+| State | Description |
+|-------|-------------|
+| Connected | Both the Scope Connection and Network Manager Connection resources exist. The scope is added to the Network Manager's scope. |
+| Pending | One of the two approval resources isn't created. The scope isn't added to the Network Manager's scope yet. |
+| Conflict | There's already a network manager with this subscription or management group defined within its scope. Two network managers with the same scope access can't directly manage the same scope, therefore this subscription/management group can't be added to the Network Manager scope. To resolve the conflict, remove the scope from the conflicting network manager's scope and recreate the connection resource. |
+| Revoked | The scope was at one time added to the Network Manager scope, but the removal of an approval resource caused revocation. |
 
-The only state that represents the scope has been added to the Network Manager scope is 'Connected'.
+The only state that represents the scope is added to the Network Manager scope is 'Connected'.
 
 ## Required permissions 
 

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

@@ -1,47 +1,47 @@
 ---
-title: 'Configuration deployments in Azure Virtual Network Manager'
-description: Learn about how configuration deployments work in Azure Virtual Network Manager.
+title: 'Manage Configuration Deployments in Azure Virtual Network Manager'
+description: Learn how configuration deployments work in Azure Virtual Network Manager, and discover best practices to manage your network configurations effectively.
 author: mbender-ms    
 ms.author: mbender
 ms.service: azure-virtual-network-manager
 ms.topic: concept-article
-ms.date: 03/22/2024
+ms.date: 05/06/2024
 ---
 
-# Configuration deployments in Azure Virtual Network Manager
+# Manage Configuration Deployments in Azure Virtual Network Manager
 
-In this article, you learn about how configurations are applied to your network resources. Also, you explore how updating a configuration deployment is different for each membership type. Then we go into 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 membership type, and understand details about *Deployment status* and *Goal state model*.
 
-## Deployment
+## 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.
 
-When committing a deployment, you select the region(s) to which 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 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.
 
 > [!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.
 
-## Deployment latency
+## 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: 
 
 - The base time of applying a configuration is a few minutes. 
 
 - The time to receive a notification of network group membership can vary. 
 
-For manually added members, notification is immediate. For dynamic members where the scope is less than 1000 subscriptions, notification takes a few minutes. In environments with more than 1000 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, 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.  
 
-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 1000 subscriptions. When the virtual network manager is notified of group membership, the configuration is applied in a few minutes. 
+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. 
 
-## Deployment status
+## 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 request 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 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.
 
 :::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 configuration(s), 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 region(s) you no longer wish to have any configurations applied.
+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.
 
 ## Configuration availability