Address PR review issues

JKirsch1 · JKirsch1 · commit 900a8283a6bd · 2026-02-13T09:34:24.000-05:00
diff --git a/articles/automation/shared-resources/modules.md b/articles/automation/shared-resources/modules.md
@@ -61,7 +61,7 @@ The following table lists the modules that Azure Automation imports by default w
 
 The default modules are also known as global modules. In the Azure portal, the **Global module** property will be **true** when viewing a module that was imported when the account was created.
 
-![Screenshot of global module property in Azure portal](../media/modules/automation-global-modules.png)
+![Screenshot of global module property in Azure portal.](../media/modules/automation-global-modules.png)
 
 > [!NOTE]
 > We don't recommend altering modules and runbooks in Automation accounts used for deployment of the [Start/Stop VMs during off-hours](../../azure-functions/start-stop-vms/overview.md)
diff --git a/articles/azure-vmware/attach-azure-netapp-files-to-azure-vmware-solution-hosts.md b/articles/azure-vmware/attach-azure-netapp-files-to-azure-vmware-solution-hosts.md
@@ -125,7 +125,7 @@ There are some important best practices to follow for optimal performance of NFS
 - Based on your performance requirements, select the correct service level needed for the Azure NetApp Files capacity pool. See [Service levels for Azure NetApp Files](../azure-netapp-files/azure-netapp-files-service-levels.md) to understand the throughput allowed per provisioned TiB for each service level. 
 
     >[!IMPORTANT]
-    > If you've changed the Azure NetApp Files volumes performance tier or the volume size after creating the volume and datastore, see [Service level change for Azure NetApp files datastore](#service-level-change-for-azure-netapp-files-datastore) to ensure that volume/datastore metadata is in sync to avoid unexpected behavior in the portal or the API due to metadata mismatch. To do any kind of change to the volume you can use Azure portal or any other supported solution (CLI\Powershell\API).
+    > If you've changed the Azure NetApp Files volumes performance tier or the volume size after creating the volume and datastore, see [Service level change for Azure NetApp files datastore](#service-level-change-for-azure-netapp-files-datastore) to ensure that volume/datastore metadata is in sync to avoid unexpected behavior in the portal or the API due to metadata mismatch. To do any kind of change to the volume you can use Azure portal or any other supported solution (CLI\PowerShell\API).
     
 - Create one or more volumes based on the required throughput and capacity. See [Performance considerations](../azure-netapp-files/azure-netapp-files-performance-considerations.md) for Azure NetApp Files to understand how volume size, service level, and capacity pool QoS type determines volume throughput. For assistance calculating workload capacity and performance requirements, contact your Azure VMware Solution or Azure NetApp Files field expert. The default maximum number of Azure NetApp Files datastores is 64.
 
diff --git a/articles/azure-vmware/native-network-design-consideration.md b/articles/azure-vmware/native-network-design-consideration.md
@@ -20,32 +20,27 @@ This article outlines key design considerations for Azure VMware Solution Genera
 
 The following functionality is limited during this time. These limitations will be lifted in the future:
 
-1. You cannot delete your **Resource Group**, which contains your private cloud. You must delete the private cloud first before deleting the resource group.  
-2. You can only deploy **1 private cloud per Azure virtual network**.  
-1. You can only create **1 private cloud per Resource Group**. Multiple private clouds in a single Resource Group are not supported. 
-
-4. Your private cloud and virtual network for your private cloud must be in the ***same*** Resource Group.  
-5. You cannot ***move*** your private cloud from one Resource Group to another after the private cloud is created.  
-6. You cannot ***move*** your private cloud from one tenant to another after the private cloud is created.  
-1. If you require **ExpressRoute FastPath** or **Global Virtual Network Peering** for your AVS Private Cloud**,** create a Support Case through the Azure portal. 
-
-1. **Service Endpoints** direct connectivity from Azure VMware Solution workloads isn't supported.
-
-1. **Private Endpoints when globally peered** across regions connected to Azure VMware Solution isn't supported.
-
-9. **vCloud Director** using Private Endpoints is supported. However, vCloud Director using Public Endpoints isn't supported.  
-1. **vSAN Stretched Clusters** isn't supported.
-
-11. **Public IP down to the VMware NSX Microsoft Edge** for configuring internet will not be supported. You can find what internet options are supported in [Internet connectivity options](native-internet-connectivity-design-considerations.md).  
-1. During **unplanned maintenance** – like a host hardware failure – on any of the first four hosts in your SDDC, you may experience a temporary North-South network connectivity disruption for some workloads, lasting up to 30 seconds. North-South connectivity refers to traffic between your AVS VMware workloads and external endpoints beyond the NSX-T Tier-0 (T0) Edge, such as Azure services or on-premises environments. This limitation has been removed in specific Azure regions. Check with with Azure Support to see if your region is affected by this limitation.
-13. **Network Security Groups** associated with the private cloud host virtual network must be created in the ***same*** resource group as the private cloud and its virtual network.  
-14. **Cross-resource group and cross-subscription references** from customer virtual networks to the Azure VMware Solution virtual network are not supported by default. This includes resource types such as: User-defined routes (UDRs), DDoS Protection Plans, and other linked networking resources. If a customer virtual network is associated with one of these references that resides in a different resource group or subscription than the Azure VMware Solution virtual network, network programming (such as NSX segment propagation) may fail. To avoid issues, customers must ensure that the Azure VMware Solution virtual network isn't linked to resources in a different resource group or subscription and detach such resources (for example, DDoS Protection Plans) from the virtual network before proceeding.  
-    - To maintain your cross-resource group reference, create a role assignment from your cross-resource group or subscription and give the “AzS VIS Prod App” the "AVS on Fleet VIS Role". The role assignment allows you to use reference and have your reference correctly applied for your Azure VMware Solution private cloud.  
-15. Gen 2 private cloud **deployments may fail if Azure policies that enforce strict rules for Network Security Groups or route tables (for example, specific naming conventions)**. These policy constraints can block required Azure VMware Solution Network Security Group and route table creation during deployment. You must remove these policies from the Azure VMware Solution virtual network before deploying your private cloud. Once your private cloud is deployed, these policies can be added back to your Azure VMware Solution private cloud.  
-16. If you are using **Private DNS** for your Azure VMware Solution Gen 2 private cloud, using **Custom DNS** on the virtual network where an Azure VMware Solution Gen 2 private cloud is deployed is unsupported. Custom DNS breaks lifecycle operations such as scaling, upgrades, and patching.  
-17. If you are **deleting** your private cloud and some Azure VMware Solution created resources are not removed, you can retry the deletion of the Azure VMware Solution private cloud using the Azure CLI.
-18. Azure VMware Solution Gen 2 uses an HTTP Proxy to distinguish between customer and management network traffic. Certain VMware cloud service endpoints **may not follow the same network path or proxy rules as general vCenter-managed traffic**. Examples include: "scapi.vmware" and "apigw.vmware". The VAMI proxy governs the vCenter Server Appliance’s (VCSA) general outbound internet access, but not all service endpoint interactions flow through this proxy. Some interactions originate directly from the user’s browser or from integration components, which instead follow the workstation’s proxy settings or initiate connections independently. As a result, traffic to VMware cloud service endpoints may bypass the VCSA proxy entirely.
-1. HCX RAV and Bulk migrations on Gen 2 can experience significantly slower performance due to stalls during Base Sync and Online Sync phases. Customers should plan for longer migration windows and schedule waves accordingly for now. For suitable workloads, vMotion offers a faster, low‑overhead option when host and network conditions allow.
+- You cannot delete your **Resource Group**, which contains your private cloud. You must delete the private cloud first before deleting the resource group.  
+- You can only deploy **1 private cloud per Azure virtual network**.  
+- You can only create **1 private cloud per Resource Group**. Multiple private clouds in a single Resource Group are not supported. 
+- Your private cloud and virtual network for your private cloud must be in the ***same*** Resource Group.  
+- You cannot ***move*** your private cloud from one Resource Group to another after the private cloud is created.  
+- You cannot ***move*** your private cloud from one tenant to another after the private cloud is created.  
+- If you require **ExpressRoute FastPath** or **Global Virtual Network Peering** for your AVS Private Cloud, create a Support Case through the Azure portal. 
+- **Service Endpoints** direct connectivity from Azure VMware Solution workloads isn't supported.
+- **Private Endpoints when globally peered** across regions connected to Azure VMware Solution isn't supported.
+- **vCloud Director** using Private Endpoints is supported. However, vCloud Director using Public Endpoints isn't supported.  
+- **vSAN Stretched Clusters** isn't supported.
+- **Public IP down to the VMware NSX Microsoft Edge** for configuring internet will not be supported. You can find what internet options are supported in [Internet connectivity options](native-internet-connectivity-design-considerations.md).  
+- During **unplanned maintenance** – like a host hardware failure – on any of the first four hosts in your SDDC, you may experience a temporary North-South network connectivity disruption for some workloads, lasting up to 30 seconds. North-South connectivity refers to traffic between your AVS VMware workloads and external endpoints beyond the NSX-T Tier-0 (T0) Edge, such as Azure services or on-premises environments. This limitation has been removed in specific Azure regions. Check with with Azure Support to see if your region is affected by this limitation.
+- **Network Security Groups** associated with the private cloud host virtual network must be created in the ***same*** resource group as the private cloud and its virtual network.  
+- **Cross-resource group and cross-subscription references** from customer virtual networks to the Azure VMware Solution virtual network are not supported by default. This includes resource types such as: User-defined routes (UDRs), DDoS Protection Plans, and other linked networking resources. If a customer virtual network is associated with one of these references that resides in a different resource group or subscription than the Azure VMware Solution virtual network, network programming (such as NSX segment propagation) may fail. To avoid issues, customers must ensure that the Azure VMware Solution virtual network isn't linked to resources in a different resource group or subscription and detach such resources (for example, DDoS Protection Plans) from the virtual network before proceeding.  
+  - To maintain your cross-resource group reference, create a role assignment from your cross-resource group or subscription and give the “AzS VIS Prod App” the "AVS on Fleet VIS Role". The role assignment allows you to use reference and have your reference correctly applied for your Azure VMware Solution private cloud.  
+- Gen 2 private cloud **deployments may fail if Azure policies enforce strict rules for Network Security Groups or route tables (for example, specific naming conventions)**. These policy constraints can block required Azure VMware Solution Network Security Group and route table creation during deployment. You must remove these policies from the Azure VMware Solution virtual network before deploying your private cloud. Once your private cloud is deployed, these policies can be added back to your Azure VMware Solution private cloud.  
+- If you are using **Private DNS** for your Azure VMware Solution Gen 2 private cloud, using **Custom DNS** on the virtual network where an Azure VMware Solution Gen 2 private cloud is deployed is unsupported. Custom DNS breaks lifecycle operations such as scaling, upgrades, and patching.  
+- If you are **deleting** your private cloud and some Azure VMware Solution created resources are not removed, you can retry the deletion of the Azure VMware Solution private cloud using the Azure CLI.
+- Azure VMware Solution Gen 2 uses an HTTP Proxy to distinguish between customer and management network traffic. Certain VMware cloud service endpoints **may not follow the same network path or proxy rules as general vCenter-managed traffic**. Examples include: "scapi.vmware" and "apigw.vmware". The VAMI proxy governs the vCenter Server Appliance’s (VCSA) general outbound internet access, but not all service endpoint interactions flow through this proxy. Some interactions originate directly from the user’s browser or from integration components, which instead follow the workstation’s proxy settings or initiate connections independently. As a result, traffic to VMware cloud service endpoints may bypass the VCSA proxy entirely.
+- HCX RAV and Bulk migrations on Gen 2 can experience significantly slower performance due to stalls during Base Sync and Online Sync phases. Customers should plan for longer migration windows and schedule waves accordingly for now. For suitable workloads, vMotion offers a faster, low‑overhead option when host and network conditions allow.
 
 ## Unsupported integrations
 
diff --git a/articles/cyclecloud/release-notes/8-7-0.md b/articles/cyclecloud/release-notes/8-7-0.md
@@ -26,12 +26,12 @@ ms.author: bewatrou
 * Jetpack downloaded the cluster-init manifest file more times than necessary on boot 
 * For NDv5 H100, the wrong number of GPUs was reported from Azure and *gres.conf* was generated incorrectly. 
 * Jetpack and the CycleCloud CLI used an older version of AzCopy with multiple open issues.  Jetpack and the CLI now use AzCopy version 10.27.1 
-* The default firewalld rules in RHEL 9 images blocked ReturnProxy connections from cluster nodes when the ReturnProxy feature was enabled. 
+* In RHEL 9 images, the default rules for the `firewalld` firewall service blocked ReturnProxy connections from cluster nodes when the ReturnProxy feature was enabled. 
 * Jetpack incorrectly applied the AlmaLinux 8.7 GPG key patch to recent versions of AlmaLinux and RHEL leading to confusing warning messages and failures in some restricted environments. 
 * CycleCloud generated incorrect *gres.conf* for AMD GPU VM SKUs. 
 * The older Slurm step manager version contained a [Slurm security CVE](https://csirt.egi.eu/2024/10/28/vulnerability-in-slurm-stepmgr-subsystem-cve-2024-48936/) 
 * The 'CycleCloud' settings section on the Settings page could not be changed. 
-* The `cyclecloud project upload` failed when CycleCloud was configured to use Entra Id user authentication 
+* The `cyclecloud project upload` failed when CycleCloud was configured to use Microsoft Entra ID user authentication 
 * Upgrading your CycleCloud installation from 8.6.0 to the latest version broke the ‘Edit Cluster’ page due to caching issues. 
 * Links to the Azure portal were not valid 
 * When Disk deletion failed on first attempt, node deletion also failed 
@@ -42,5 +42,5 @@ ms.author: bewatrou
 
 ## Known Issues 
 
-* Older GridEngine clusters will break after upgrading to CycleCloud and Jetpack 8.7.0.   To work-around this issue, create a symlink from */bin/python3* to */bin/python* in [cloud-init](../how-to/cloud-init.md).  
+* Older GridEngine clusters will break after upgrading to CycleCloud and Jetpack 8.7.0.   To work around this issue, create a symlink from */bin/python3* to */bin/python* in [cloud-init](../how-to/cloud-init.md).  
 * When replacing Shared Access Keys with a Managed Identity for storage account access, CycleCloud’s orchestrator identity must have Storage Account Blob Data Contributor and the selected Locker identity must have Storage Account Blob Data Reader to the Locker storage account.  Existing CycleCloud installations using Managed Identity for the orchestrator identity may not have this permission.  See “[Using Managed Identities](../how-to/managed-identities.md)” in the CycleCloud documentation for more details. 
diff --git a/articles/data-manager-for-agri/quickstart-install-data-manager-for-agriculture.md b/articles/data-manager-for-agri/quickstart-install-data-manager-for-agriculture.md
@@ -11,7 +11,7 @@ ms.custom:
   - sfi-image-nochange
 ---
 
-# Quickstart install Azure Data Manager for Agriculture preview
+# Quickstart: Install Azure Data Manager for Agriculture preview
 
 Use this document to get started with the steps to install Data Manager for Agriculture. Make sure that  your Azure subscription ID is in our allowlist. Microsoft Azure Data Manager for Agriculture requires registration and is available to only approved customers and partners during the preview period. To request access to Azure Data Manager for Agriculture during the preview period, use this [**form**](https://aka.ms/agridatamanager).
 
@@ -26,7 +26,7 @@ In step 5 in the above documentation, search for `Microsoft.AgFoodPlatform` and
 ## 2: Search in marketplace
 
 > [!IMPORTANT]
-> Access the  Azure portal using <a href="https://portal.azure.com/?microsoft_azure_marketplace_ItemHideKey=Microsoft_Azure_AgFoodPlatformHidden#create/hub" target="_blank">**this link**</a> . This link enables visibility of the Azure Data Manager for Agriculture installation card in the Marketplace for our preview customers.
+> Access the  Azure portal using <a href="https://portal.azure.com/?microsoft_azure_marketplace_ItemHideKey=Microsoft_Azure_AgFoodPlatformHidden#create/hub" target="_blank">**this link**</a>. This link enables visibility of the Azure Data Manager for Agriculture installation card in the Marketplace for our preview customers.
 
 Enter Data manager for agriculture in the marketplace search bar. Then select 'create' on the listing tile as shown below.
 
@@ -65,7 +65,7 @@ Follow the steps provided in <a href="/azure/active-directory/develop/quickstart
 
 Once the App registration is done, the next step is to assign roles in the Azure portal to provide Authorization to the newly created application. Data Manager for Agriculture uses Azure RBAC to manage Authorization requests.
 
-Log in to Azure portal and navigate to the newly created resource (`<Name>-resource-name` created in step 5) under the resource group (`resource-group-name`).
+Sign in to Azure portal and navigate to the newly created resource (`<Name>-resource-name` created in step 5) under the resource group (`resource-group-name`).
 
 > [!NOTE]
 > Inside the resource group tab, if you do not find the created Data Manager for Agriculture resource, you need to enable the **show hidden types** checkbox to see the Data Manager for Agriculture resource that you created.
@@ -111,7 +111,7 @@ Replace the following parameters in the request:
 | Client ID |  The application (service principal) ID of the application you registered |
 | Client Secret |  The secret generated for the application. |
 
-The ``resource`` parameter is the identifier for the Azure Data Manager for Agriculture login application. This identifier is a constant value set to ``https://farmbeats.azure.net``.
+The ``resource`` parameter is the identifier for the Azure Data Manager for Agriculture sign-in application. This identifier is a constant value set to ``https://farmbeats.azure.net``.
 
 For Bash:
 ```bash
diff --git a/articles/event-grid/custom-disaster-recovery-client-side.md b/articles/event-grid/custom-disaster-recovery-client-side.md
@@ -68,7 +68,7 @@ namespace EventGridFailoverPublisher
         static async Task Main(string[] args)
         {
             // TODO: Enter the endpoint each topic. You can find this topic endpoint value
-            // in the "Overview" section in the "Event Grid topics" page in Azure portal..
+            // in the "Overview" section in the "Event Grid topics" page in Azure portal.
             string primaryTopic = "https://<primary-topic-name>.<primary-topic-region>.eventgrid.azure.net/api/events";
             string secondaryTopic = "https://<secondary-topic-name>.<secondary-topic-region>.eventgrid.azure.net/api/events";
 
diff --git a/articles/oracle/oracle-db/oracle-exadata-database-dedicated-infrastructure-logs.md b/articles/oracle/oracle-db/oracle-exadata-database-dedicated-infrastructure-logs.md

Original file line number	Diff line number	Diff line change
`@@ -68,7 +68,7 @@ namespace EventGridFailoverPublisher`
`68`	`68`	`static async Task Main(string[] args)`
`69`	`69`	`{`
`70`	`70`	`// TODO: Enter the endpoint each topic. You can find this topic endpoint value`
`71`		`- // in the "Overview" section in the "Event Grid topics" page in Azure portal..`
	`71`	`+ // in the "Overview" section in the "Event Grid topics" page in Azure portal.`
`72`	`72`	`string primaryTopic = "https://<primary-topic-name>.<primary-topic-region>.eventgrid.azure.net/api/events";`
`73`	`73`	`string secondaryTopic = "https://<secondary-topic-name>.<secondary-topic-region>.eventgrid.azure.net/api/events";`
`74`	`74`