Merge pull request #294127 from mbender-ms/patch-609799

virtual network manager | Maintenance | February 2025

Author: v-shils

articles/virtual-network-manager/concept-ip-address-management.md

@@ -5,7 +5,7 @@ author: mbender-ms
 ms.author: mbender
 ms.service: azure-virtual-network-manager
 ms.topic: how-to
-ms.date: 01/16/2024
+ms.date: 02/05/2025
 ms.custom:  references_regions
 #customer intent: As a network administrator, I want to learn about IP address management in Azure Virtual Network Manager so that I can manage IP addresses in my virtual networks.
 ---
@@ -22,9 +22,9 @@ In Azure Virtual Network Manager, IP address management (IPAM) helps you central
 
 - Create pools for IP address planning.
 
-- Automatically assign nonoverlapped CIDRs to Azure resources.
+- Autoassign nonoverlapped CIDRs to Azure resources.
 
-- Reserve IPs for specific needs.
+- Create reserved IPs for specific needs.
 
 - Prevent Azure address space from overlapping on-premises and cloud environments. 
 
@@ -42,37 +42,38 @@ The IPAM feature in Azure Virtual Network Manager works through the following ke
 
 ### Manage IP address pools
 
-IPAM allows network administrators to plan and organize IP address usage by creating pools with address spaces and respective sizes. These pools act as containers for groups of CIDRs, enabling logical grouping for specific networking purposes. You can create a structured hierarchy of pools, dividing a larger pool into smaller, more manageable pools, aiding in more granular control and organization of your network's IP address space. 
+IPAM allows network administrators to plan and organize IP address usage by creating pools with address spaces and respective sizes. These pools act as containers for groups of CIDRs, enabling logical grouping for specific networking purposes. You can create a structured hierarchy of pools by dividing a larger pool into smaller, more manageable pools. This hierarchy provides more granular control and organization of your network's IP address space.
 
 There are two types of pools in IPAM:
-- Root pool: The first pool created in your instance is the root pool. This represents your entire IP address range.
-- Child pool: A child pool is a subset of the root pool or another child pool. You can create multiple child pools within a root pool or another child pool. You can have up to seven layers of pools
+- **Root pool**: The first pool created in your instance is the root pool. This represents your entire IP address range.
+- **Child pool**: A child pool is a subset of the root pool or another child pool. You can create multiple child pools within a root pool or another child pool. You can have up to seven layers of pools
 
 ### Allocating IP addresses to Azure resources
 
-When it comes to allocation, you can assign Azure resources with CIDRs, such as virtual networks, to a specific pool. This helps in identifying which CIDRs are currently in use. There's also the option to allocate static CIDRs to a pool, useful for occupying CIDRs that are either not currently in use within Azure or are part of Azure resources not yet supported by the IPAM service. Allocated CIDRs are released back to the pool if the associated resource is removed or deleted, ensuring efficient utilization and management of the IP space.
+You can allocate Azure resources, such as virtual networks, to a specific pool with CIDRs. This helps in identifying which CIDRs are currently in use. There's also the option to allocate static CIDRs to a pool, useful for occupying CIDRs that are either not currently in use within Azure or are part of Azure resources not yet supported by the IPAM service. Allocated CIDRs are released back to the pool if the associated resource is removed or deleted, ensuring efficient utilization and management of the IP space.
 
 ### Delegating permissions for IPAM
 
 With IPAM, you can delegate permission to other users to utilize the IP address pools, ensuring controlled access and management while democratizing pool allocation. These permissions allow users to see the pools they have access to, aiding in choosing the right pool for their needs.
 
 Delegating permissions also allows others to view usage statistics and lists of resources associated with the pool. Within your network manager, complete usage statistics are available including:
-    - The total number of IPs in pool.
-    - The percentage of allocated pool space.
+
+- The total number of IPs in pool.
+- The percentage of allocated pool space.
 
 Additionally, it shows details for pools and resources associated with pools, giving a complete overview of the IP usages and aiding in better resource management and planning.
 
 ### Simplifying resource creation
 
-When creating CIDR-supporting resources like virtual networks, CIDRs are automatically allocated from the selected pool, simplifying the resource creation process. The system ensures that the automatically allocated CIDRs don't overlap within the pool, maintaining network integrity and preventing conflicts.
+When you create CIDR-supporting resources like virtual networks, CIDRs are automatically allocated from the selected pool, simplifying the resource creation process. The system ensures that the automatically allocated CIDRs don't overlap within the pool, maintaining network integrity and preventing conflicts.
 
 ## Permission requirements for IPAM in Azure Virtual Network Manager
 
-When using IPAM, the **IPAM Pool User** role alone is sufficient for delegation. During the public preview, you also need to grant **Network Manager Read** access to ensure full discoverability of IP address pools and virtual networks across the Network Manager's scope. Without this role, users with only the **IPAM Pool User** role won't see available pools and virtual networks.
+The **IPAM Pool User** role alone is sufficient for delegation when using IPAM. If permission issues arise, you also need to grant **Network Manager Read** access to ensure full discoverability of IP address pools and virtual networks across the Network Manager's scope. Without this role, users with only the **IPAM Pool User** role don't see available pools and virtual networks.
 
 Learn more about [Azure role-based access control (Azure RBAC)](../role-based-access-control/overview.md).
 
 ## Next steps
 
 > [!div class="nextstepaction"]
-> [Learn how to manage IP addresses in Azure Virtual Network Manager](./how-to-manage-ip-addresses-network-manager.md)
+> [Learn how to manage IP addresses in Azure Virtual Network Manager](./how-to-manage-ip-addresses-network-manager.md)

articles/virtual-network-manager/concept-security-admins.md

@@ -1,11 +1,11 @@
 ---
 title: 'Security admin rules in Azure Virtual Network Manager'
-description: Learn about what security admin rules are in Azure Virtual Network Manager, how they work, and how traffic rules are evaluated including nonapplication of security admin rules and exceptions.
+description: Learn about what security admin rules in Azure Virtual Network Manager, how they work, and how traffic rules are evaluated. This includes nonapplication of security admin rules and exceptions.
 author: mbender-ms
 ms.author: mbender
 ms.service: azure-virtual-network-manager
 ms.topic: concept-article
-ms.date: 12/07/2023
+ms.date: 02/04/2025
 ---
 
 # Security admin rules in Azure Virtual Network Manager
@@ -14,7 +14,7 @@ In this article, you learn about security admin rules in Azure Virtual Network M
 
 ## What is a security admin rule?
 
-Security admin rules are global network security rules that enforce security policies defined in the rule collection on virtual networks. These rules can be used to Allow, Always Allow, or Deny traffic across virtual networks within your targeted network groups. These network groups can only consist of virtual networks within the scope of your virtual network manager instance. Security admin rules can't apply to virtual networks not managed by a virtual network manager.
+Security admin rules are global network security rules that enforce security policies defined in the rule collection on virtual networks. These rules can be used to *Allow*, *Always Allow*, or *Deny* traffic across virtual networks within your targeted network groups. These network groups can only consist of virtual networks within the scope of your virtual network manager instance. Security admin rules can't apply to virtual networks not managed by a virtual network manager.
 
 Here are some scenarios where security admin rules can be used:
 
@@ -29,7 +29,7 @@ Here are some scenarios where security admin rules can be used:
 With Azure Virtual Network Manager, you have a centralized location to manage security admin rules. Centralization allows you to define security policies at scale and apply them to multiple virtual networks at once.
 
 > [!NOTE]
-> Currently, security admin rules do not apply to private endpoints that fall under the scope of a managed virtual network.
+> Currently, security admin rules don't apply to private endpoints that fall under the scope of a managed virtual network.
 
 ## How do security admin rules work?
 
@@ -49,7 +49,7 @@ To enforce security policies across multiple virtual networks, you [create and d
 
 Security admin rules and network security groups (NSGs) can be used to enforce network security policies in Azure. However, they have different scopes and priorities.#
 
-Security admin rules are intended to be used by network admins of a central governance team, thereby delegating NSG rules to individual application or service teams to further specify security as needed. Security admin rules have a higher priority than NSGs and are evaluated before NSG rules.
+Security admin rules are intended to be used by network admins of a central governance team. This allows individual application or service teams to further specify security as needed with NSGs. Security admin rules have a higher priority than NSGs and are evaluated before NSG rules.
 
 NSGs, on the other hand, are used to filter network traffic to and from individual subnets or network interfaces. They're intended to be used by individual application or service teams to further specify security as needed. NSGs have a lower priority than security admin rules and are evaluated after security admin rules.
 
@@ -69,7 +69,7 @@ If you create an *Always Allow* or *Deny* rule, traffic evaluation is terminated
 By using security admin rules and NSGs together, you can enforce network security policies at both the global and individual levels, ensuring that your virtual networks are secure and compliant with your organization's security policies.
 
 > [!IMPORTANT]
-> When security admin rules are deployed, the eventual consistency model is used. This means that security admin rules will be eventually applied to the resources contained in a virtual network after a short delay.   Resources that are added to a virtual network that already has security admin rules applied on it will eventually receive those same security admin rules with a delay as well.
+> When security admin rules are deployed, the eventual consistency model is used. This means that security admin rules will be eventually applied to the resources contained in a virtual network after a short delay.   Resources that are added to a virtual network that have security admin rules applied on it will eventually receive those same security admin rules with a delay as well.
 
 ## Benefits of security admin rules
 
@@ -128,8 +128,8 @@ When a virtual network contains these services, the security admin rules skip th
 You can create a security configuration with *Allow* rules only and deploy it to your virtual networks with [Azure PowerShell](/powershell/module/az.network/new-aznetworkmanagersecurityadminconfiguration#example-1) and [Azure CLI](/cli/azure/network/manager/security-admin-config#az-network-manager-security-admin-config-create-examples).
 
 > [!NOTE]
-> When multiple Azure Virtual Network Manager instances apply different settings in the `securityConfiguration.properties.applyOnNetworkIntentPolicyBasedServices` class to the same virtual network, the setting of the network manager instance with the highest scope will be used.
-> Let's say you have two virtual network managers. The first network manager is scoped to the root management group and has a security configuration with set to *AllowRulesOnly* in the `securityConfiguration.properties.applyOnNetworkIntentPolicyBasedServices` class. The second virtual network manager is scoped to a subscription under the root management group and uses the default field of *None* in its security configuration. When both configurations apply security admin rules to the same virtual network, the *AllowRulesOnly* setting will be applied to the virtual network.
+> When multiple Azure Virtual Network Manager instances apply different settings in the `securityConfiguration.properties.applyOnNetworkIntentPolicyBasedServices` class to the same virtual network, the setting of the network manager instance with the highest scope is used.
+> Let's say you have two virtual network managers. The first network manager is scoped to the root management group and has a security configuration with set to *AllowRulesOnly* in the `securityConfiguration.properties.applyOnNetworkIntentPolicyBasedServices` class. The second virtual network manager is scoped to a subscription under the root management group and uses the default field of *None* in its security configuration. When both configurations apply security admin rules to the same virtual network, the *AllowRulesOnly* setting is applied to the virtual network.
 
 ### Nonapplication of security admin rules at subnet level
 
@@ -146,7 +146,7 @@ Similarly, some services don't apply security admin rules at the subnet level wh
 In this case, security admin rules don't affect the resources in the subnet with these services. However, other subnets within the same virtual network have security admin rules applied to them.
 
 > [!NOTE]
-> If you want to apply security admin rules on subnets containing an Azure Application Gateway, ensure each subnet only contains gateways that have been provisioned with [network isolation](../application-gateway/application-gateway-private-deployment.md) enabled. If a subnet contains an Azure Application Gateway without network isolation, security admin rules won't be applied to this subnet.
+> If you want to apply security admin rules on subnets containing an Azure Application Gateway, ensure each subnet only contains gateways that are provisioned with [network isolation](../application-gateway/application-gateway-private-deployment.md) enabled. If a subnet contains an Azure Application Gateway without network isolation, security admin rules aren't applied to this subnet.
 
 ## Security admin fields
 
@@ -188,7 +188,7 @@ Protocols currently supported with security admin rules are:
 #### Source and destination types
 
 * **IP addresses**: You can provide IPv4 or IPv6 addresses or blocks of address in CIDR notation. To list multiple IP address, separate each IP address with a comma.
-* **Service Tag**: You can define specific service tags based on regions or a whole service. See the public documentation on [available service tags](../virtual-network/service-tags-overview.md#available-service-tags) for the list of supported tags. Out of this list, security admin rules currently do not support the AzurePlatformDNS, AzurePlatformIMDS, and AzurePlatformLKM service tags.
+* **Service Tag**: You can define specific service tags based on regions or a whole service. See the public documentation on [available service tags](../virtual-network/service-tags-overview.md#available-service-tags) for the list of supported tags. Out of this list, security admin rules currently don't support the AzurePlatformDNS, AzurePlatformIMDS, and AzurePlatformLKM service tags.
 
 #### Source and destination ports
 
@@ -208,4 +208,4 @@ You can define specific common ports to block from the source or to the destinat
 
 ## Next steps 
 > [!div class="nextstepaction"]
-> Learn how to block network traffic with a [Security admin configuration](how-to-block-network-traffic-portal.md).
+> Learn how to block network traffic with a [Security admin configuration](how-to-block-network-traffic-portal.md).

articles/virtual-network-manager/create-virtual-network-manager-terraform.md

@@ -6,7 +6,7 @@ ms.topic: quickstart
 ms.custom: devx-track-terraform
 author: mbender-ms
 ms.author: mbender
-ms.date: 06/07/2023
+ms.date: 02/05/2025
 content_well_notification: 
   - AI-contribution
 zone_pivot_groups: azure-virtual-network-manager-quickstart-options
@@ -38,13 +38,13 @@ In this article, you learn how to:
 ## Prerequisites
 
 - [Install and configure Terraform](/azure/developer/terraform/quickstart-configure)
-- To modify dynamic network groups, you must be [granted access via Azure RBAC role](concept-network-groups.md#network-groups-and-azure-policy) assignment only. Classic Admin/legacy authorization is not supported
+- To modify dynamic network groups, you must be [granted access via Azure RBAC role](concept-network-groups.md#network-groups-and-azure-policy) assignment only. Classic Admin/legacy authorization isn't supported
 
 :::zone pivot="sub"
 
 ## Implement the Terraform code
 
-This code sample will implement Azure Virtual Network Manager at the subscription scope.
+This code sample implements Azure Virtual Network Manager at the subscription scope.
 
 > [!NOTE]
 > The sample code for this article is located in the [Azure Terraform GitHub repo](https://github.com/Azure/terraform/tree/master/quickstart/101-virtual-network-manager-create-mesh). You can view the log file containing the [test results from current and previous versions of Terraform](https://github.com/Azure/terraform/tree/master/quickstart/101-virtual-network-manager-create-mesh/TestRecord.md).
@@ -131,7 +131,7 @@ This code sample will implement Azure Virtual Network Manager at the management
     terraform output virtual_network_names
     ``` 
   
-1. For each virtual network name printed in the previous step, run [az network manager list-effective-connectivity-config](/cli/azure/network/manager#az-network-manager-list-effective-connectivity-config) to print the effective (applied) configurations. Replace the `<virtual_network_name>` placeholder with the vnet name.
+1. For each virtual network name printed in the previous step, run [az network manager list-effective-connectivity-config](/cli/azure/network/manager#az-network-manager-list-effective-connectivity-config) to print the effective (applied) configurations. Replace the `<virtual_network_name>` placeholder with the virtual network name.
 
     ```azurecli
     az network manager list-effective-connectivity-config \
@@ -153,7 +153,7 @@ This code sample will implement Azure Virtual Network Manager at the management
     Get-AzResourceGroup -Name $resource_group_name
     ```
 
-1. For each virtual network name printed in the previous step, run [Get-AzNetworkManagerEffectiveConnectivityConfiguration](/powershell/module/az.network/get-aznetworkmanagereffectiveconnectivityconfiguration) to print the effective (applied) configurations. Replace the `<virtual_network_name>` placeholder with the vnet name.
+1. For each virtual network name printed in the previous step, run [Get-AzNetworkManagerEffectiveConnectivityConfiguration](/powershell/module/az.network/get-aznetworkmanagereffectiveconnectivityconfiguration) to print the effective (applied) configurations. Replace the `<virtual_network_name>` placeholder with the virtual network name.
 
 ```azurepowershell
     Get-AzNetworkManagerEffectiveConnectivityConfiguration 
@@ -173,4 +173,4 @@ This code sample will implement Azure Virtual Network Manager at the management
 ## Next steps
 
 > [!div class="nextstepaction"]
-> [Block network traffic with Azure Virtual Network Manager](how-to-block-network-traffic-portal.md)
+> [Block network traffic with Azure Virtual Network Manager](how-to-block-network-traffic-portal.md)