acrolinx

Author: LiSeda

articles/azure-cache-for-redis/cache-how-to-scale.md

@@ -13,10 +13,10 @@ In addition to calling activity functions, orchestrator functions can call other
 
 An orchestrator function can call another orchestrator function using the *"call-sub-orchestrator"* API. The [Error Handling & Compensation](durable-functions-error-handling.md#automatic-retry-on-failure) article has more information on automatic retry.
 
-Sub-orchestrator functions behave just like activity functions from the caller's perspective. They can return a value, throw an exception, and can be awaited by the parent orchestrator function.
+Sub-orchestrator functions behave just like activity functions from the caller's perspective. They can return a value and throw an exception as the parent orchestrator function anticipates them.
 
 > [!NOTE]
-> Sub-orchestrations are not yet supported in PowerShell.
+> Sub-orchestrations aren't yet supported in PowerShell.
 
 [!INCLUDE [functions-nodejs-durable-model-description](../../../includes/functions-nodejs-durable-model-description.md)]
 
@@ -151,7 +151,7 @@ public void deviceProvisioningOrchestration(
 
 This orchestrator function can be used as-is for one-off device provisioning or it can be part of a larger orchestration. In the latter case, the parent orchestrator function can schedule instances of `DeviceProvisioningOrchestration` using the *"call-sub-orchestrator"* API.
 
-Here is an example that shows how to run multiple orchestrator functions in parallel.
+The following example shows how to run multiple orchestrator functions at the same time:
 
 # [C# (InProc)](#tab/csharp-inproc)
 

articles/azure-functions/durable/durable-functions-dotnet-entities.md

@@ -8,13 +8,13 @@ ms.author: adjohnso
 
 # Terminate a Cluster
 
-You can terminate a cluster when it has completed all the submitted jobs and the cluster is no longer needed. Terminating the cluster will stop and remove the virtual machines and delete any non­-persistent volumes in the cluster. Nodes that originate from a nodearray are removed, while other nodes remain in the cluster in the `Off` state.
+You can terminate a cluster when it completes all jobs submitted and the cluster isn't needed. Terminating the cluster stops and removes virtual machines and delete any non­persistent volumes in the cluster. Nodes that originate from a nodearray are removed, while other nodes remain in the cluster in the `Off` state.
 
-Terminating is an orchestration process. Cluster nodes will move into the `Terminating` state and then to `Off` if the termination was successful. If there is an error during the process, that node will be marked as `Failed` and can be retried.
+Terminating is an orchestration process where cluster nodes move into the `Terminating` state and then to `Off` if the termination succeeds. If there's an error during the process, that node is marked as `Failed` and can be retried.
 
 ## Terminate via CycleCloud GUI
 
-Click **Terminate** in the CycleCloud GUI to shut down all of the cluster's infrastructure. All underlying Azure resources will be cleaned up as part of the cluster termination, which may take several minutes.
+Select **Terminate** in the CycleCloud GUI to shut down the cluster's infrastructure. All underlying Azure resources are cleaned up as part of the cluster termination, which can take several minutes.
 
 ::: moniker range="=cyclecloud-7"
 ![terminate cluster dialog](../images/version-7/terminate-cluster.png)
@@ -34,21 +34,22 @@ cyclecloud terminate_cluster my_cluster_name
 
 ## Delete a Resource Group
 
-To remove the resources no longer needed, you can simply delete the resource group. Everything within that group will be cleaned up as part of the process:
+To remove the resources that aren't needed, you can delete the resource group and everything within it:
 
 ```azurecli-interactive
 az group delete --name "{RESOURCE GROUP}"
 ```
 
 ::: moniker range=">=cyclecloud-8"
-## Force-Delete VMs
 
-CycleCloud 8.2.1 supports the **Force Delete** option for VMs, which can provide faster delete times at the risk of possible data loss on the disks. This can be enabled separately for standalone VMs (such as scheduler head nodes) or scaleset VMs (execute nodes). To enable it, go to the **Settings** page in the upper right corner, and **Configure CycleCloud**.
+## Force-Delete Virtual Machines
+
+CycleCloud 8.2.1 supports the **Force Delete** option for VMs, which can provide faster delete times at the risk of possible data loss on the disks. This feature can be enabled separately for standalone VMs (such as scheduler head nodes) or scaleset VMs (execute nodes). To enable it, go to the **Settings** page in the upper right corner, and **Configure CycleCloud**.
 
 ![Force Delete settings](~/articles/cyclecloud/images/force-delete-settings.png)
 
-This setting affects all VMs managed by CycleCloud, but can be changed at any time.
+This setting affects all VMs managed by CycleCloud but can be changed at any time.
 
 > [!WARNING]
-> This feature is not recommended for VMs whose data disks contain critical data!
+> This feature isn't recommended for VMs whose data disks contain critical data!
 ::: moniker-end

articles/azure-functions/durable/durable-functions-sub-orchestrations.md

@@ -7,6 +7,7 @@ ms.topic: conceptual
 ms.date: 10/03/2024
 ms.subservice: integration-services
 ---
+
 # Use Azure SQL Managed Instance with SQL Server Integration Services (SSIS) in Azure Data Factory or Azure Synapse Analytics
 
 [!INCLUDE[appliesto-adf-asa-md](includes/appliesto-adf-asa-md.md)]
@@ -53,7 +54,7 @@ You can now move your SQL Server Integration Services (SSIS) projects, packages,
 
         - when Azure-SSIS IR inside a virtual network
 
-            There is a special scenario when SQL Managed Instance is in a region that Azure-SSIS IR does not support, Azure-SSIS IR is inside a virtual network without VNet peering due to Global VNet peering limitation. In this scenario, **Azure-SSIS IR inside a virtual network** connects SQL Managed Instance **over public endpoint**. Use below Network Security Group(NSG) rules to allow traffic between SQL Managed Instance and Azure-SSIS IR:
+            There is a special scenario when SQL Managed Instance is in a region that Azure-SSIS IR doesn't support, Azure-SSIS IR is inside a virtual network without VNet peering due to Global VNet peering limitation. In this scenario, **Azure-SSIS IR inside a virtual network** connects SQL Managed Instance **over public endpoint**. Use the following Network Security Group(NSG) rules to allow traffic between SQL Managed Instance and Azure-SSIS IR:
 
             1. **Inbound requirement of SQL Managed Instance**, to allow inbound traffic from Azure-SSIS IR.
 
@@ -83,15 +84,15 @@ You can now move your SQL Server Integration Services (SSIS) projects, packages,
         - A network security group, with the name *\<Guid>-azurebatch-cloudservicenetworksecuritygroup
         - An Azure public IP address, with the name -azurebatch-cloudservicepublicip
 
-        Those resources will be created when your Azure-SSIS IR starts. They'll be deleted when your Azure-SSIS IR stops. To avoid blocking your Azure-SSIS IR from stopping, don't reuse these network resources in your other resources.
+        Those resources are created when your Azure-SSIS IR starts. They're deleted when your Azure-SSIS IR stops. To avoid blocking your Azure-SSIS IR from stopping, don't reuse these network resources in your other resources.
 
-    1. Make sure that you have no [resource lock](../azure-resource-manager/management/lock-resources.md) on the resource group/subscription to which the virtual network belongs. If you configure a read-only/delete lock, starting and stopping your Azure-SSIS IR will fail, or it will stop responding.
+    1. Make sure that you have no [resource lock](../azure-resource-manager/management/lock-resources.md) on the resource group/subscription to which the virtual network belongs. If you configure a read-only/delete lock, starting and stopping your Azure-SSIS IR will fail or it'll stop responding.
 
     1. Make sure that you don't have an Azure Policy definition that prevents the following resources from being created under the resource group/subscription to which the virtual network belongs:
         - Microsoft.Network/LoadBalancers
         - Microsoft.Network/NetworkSecurityGroups
 
-    1. Allow traffic on Network Security Group (NSG) rule, to allow traffic between SQL Managed Instance and Azure-SSIS IR, and traffic needed by Azure-SSIS IR.
+    1. Allow traffic on Network Security Group (NSG) rule to allow traffic between SQL Managed Instance and Azure-SSIS IR, and traffic needed by Azure-SSIS IR.
         1. **Inbound requirement of SQL Managed Instance**, to allow inbound traffic from Azure-SSIS IR.
 
             | Transport protocol | Source | Source port range | Destination | Destination port range | Comments |
@@ -113,7 +114,7 @@ You can now move your SQL Server Integration Services (SSIS) projects, packages,
            | Transport protocol | Source | Source port range | Destination | Destination port range | Comments |
            |---|---|---|---|---|---|
            | TCP | BatchNodeManagement | * | VirtualNetwork | 29876, 29877 (if you join the IR to a Resource Manager virtual network) <br/><br/>10100, 20100, 30100 (if you join the IR to a classic virtual network)| The Data Factory service uses these ports to communicate with the nodes of your Azure-SSIS IR in the virtual network. <br/><br/> Whether or not you create a subnet-level NSG, Data Factory always configures an NSG at the level of the network interface cards (NICs) attached to the virtual machines that host the Azure-SSIS IR. Only inbound traffic from Data Factory IP addresses on the specified ports is allowed by that NIC-level NSG. Even if you open these ports to internet traffic at the subnet level, traffic from IP addresses that aren't Data Factory IP addresses is blocked at the NIC level. |
-           | TCP | CorpNetSaw | * | VirtualNetwork | 3389 | (Optional) This rule is only required when Microsoft supporter asks customer to open for advanced troubleshooting and can be closed right after troubleshooting. **CorpNetSaw** service tag permits only secure access workstations on the Microsoft corporate network to use remote desktop. And this service tag can't be selected from portal and is only available via Azure PowerShell or Azure CLI. <br/><br/> At NIC level NSG, port 3389 is open by default and we allow you to control port 3389 at subnet level NSG, meanwhile Azure-SSIS IR has disallowed port 3389 outbound by default at windows firewall rule on each IR node for protection. |
+           | TCP | CorpNetSaw | * | VirtualNetwork | 3389 | (Optional) This rule is only required when Microsoft supporter asks customer to open for advanced troubleshooting and can be closed right after troubleshooting. **CorpNetSaw** service tag permits only secure access workstations on the Microsoft corporate network to use remote desktop. And this service tag can't be selected from portal and is only available via Azure PowerShell or Azure CLI. <br/><br/> At NIC level NSG, port 3389 is open by default, and we allow you to control port 3389 at subnet level NSG. Meanwhile, Azure-SSIS IR has prevented port 3389 outbound by default at Windows Firewall rule on each IR node for protection. |
            |||||||
 
     1. See [virtual network configuration](azure-ssis-integration-runtime-virtual-network-configuration.md) for more info: