Review pass

Author: erikadoyle

articles/service-fabric/scripts/service-fabric-powershell-change-rdp-port-range.md

@@ -2,28 +2,21 @@
 title: Azure PowerShell Script Sample - Change the RDP port range | Microsoft Docs
 description: Azure PowerShell Script Sample - Changes the RDP port range of a deployed cluster.
 services: service-fabric
-documentationcenter: 
-author: athinanthny
-manager: chackdan
-editor: 
 tags: azure-service-management
-
-ms.assetid: 
 ms.service: service-fabric
 ms.workload: multiple
 ms.topic: sample
 ms.date: 03/19/2018
-ms.author: atsenthi
-ms.custom: mvc
+ms.custom: sfrev
 ---
 
 # Update the RDP port range values
 
-This sample script changes the RDP port range values on the cluster node VMs after the cluster has been deployed.  Azure PowerShell is used so that the underlying VMs do not cycle.  The script gets the `Microsoft.Network/loadBalancers` resource in cluster's resource group and updates the `inboundNatPools.frontendPortRangeStart` and `inboundNatPools.frontendPortRangeEnd` values. Customize the parameters as needed.
+This sample script changes the RDP port range values on the cluster node VMs after the cluster has been deployed.  Azure PowerShell is used so that the underlying VMs do not cycle.  The script gets the `Microsoft.Network/loadBalancers` resource in the cluster's resource group and updates the `inboundNatPools.frontendPortRangeStart` and `inboundNatPools.frontendPortRangeEnd` values. Customize the parameters as needed.
 
 [!INCLUDE [updated-for-az](../../../includes/updated-for-az.md)]
 
-If needed, install the Azure PowerShell using the instruction found in the [Azure PowerShell guide](/powershell/azure/overview). 
+If needed, install the Azure PowerShell using the instruction found in the [Azure PowerShell guide](/powershell/azure/overview).
 
 ## Sample script
 

articles/service-fabric/service-fabric-api-management-overview.md

@@ -1,9 +1,7 @@
 ---
 title: Azure Service Fabric with API Management overview 
 description: This article is an introduction to using Azure API Management as a gateway to your Service Fabric applications. 
-
 author: vturecek
-
 ms.topic: conceptual
 ms.date: 06/22/2017
 ms.author: vturecek
@@ -13,7 +11,7 @@ ms.author: vturecek
 
 Cloud applications typically need a front-end gateway to provide a single point of ingress for users, devices, or other applications. In Service Fabric, a gateway can be any stateless service such as an [ASP.NET Core application](service-fabric-reliable-services-communication-aspnetcore.md), or another service designed for traffic ingress, such as [Event Hubs](https://docs.microsoft.com/azure/event-hubs/), [IoT Hub](https://docs.microsoft.com/azure/iot-hub/), or [Azure API Management](https://docs.microsoft.com/azure/api-management/).
 
-This article is an introduction to using Azure API Management as a gateway to your Service Fabric applications. API Management integrates directly with Service Fabric, allowing you to publish APIs with a rich set of routing rules to your back-end Service Fabric services. 
+This article is an introduction to using Azure API Management as a gateway to your Service Fabric applications. API Management integrates directly with Service Fabric, allowing you to publish APIs with a rich set of routing rules to your back-end Service Fabric services.
 
 ## Availability
 
@@ -44,7 +42,8 @@ Azure API Management can be used with any combination of stateless services, sta
 
 In the simplest case, traffic is forwarded to a stateless service instance. To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a specific stateless service instance in the Service Fabric back-end. Requests sent to that service are sent to a random instance of the service.
 
-#### Example
+**Example**
+
 In the following scenario, a Service Fabric application contains a stateless service named `fabric:/app/fooservice`, that exposes an internal HTTP API. The service instance name is well known and can be hard-coded directly in the API Management inbound processing policy. 
 
 ![Service Fabric with Azure API Management topology overview][sf-apim-static-stateless]
@@ -53,7 +52,7 @@ In the following scenario, a Service Fabric application contains a stateless ser
 
 Similar to the stateless service scenario, traffic can be forwarded to a stateful service instance. In this case, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps a request to a specific partition of a specific *stateful* service instance. The partition to map each request to is computed via a lambda method using some input from the incoming HTTP request, such as a value in the URL path. The policy may be configured to send requests to the primary replica only, or to a random replica for read operations.
 
-#### Example
+**Example**
 
 In the following scenario, a Service Fabric application contains a partitioned stateful service named `fabric:/app/userservice` that exposes an internal HTTP API. The service instance name is well known and can be hard-coded directly in the API Management inbound processing policy.  
 
@@ -63,33 +62,33 @@ The service is partitioned using the Int64 partition scheme with two partitions
 
 ## Send traffic to multiple stateless services
 
-In more advanced scenarios, you can define an API Management operation that maps requests to more than one service instance. In this case, each operation contains a policy that maps requests to a specific service instance based on values from the incoming HTTP request, such as the URL path or query string, and in the case of stateful services, a partition within the service instance. 
+In more advanced scenarios, you can define an API Management operation that maps requests to more than one service instance. In this case, each operation contains a policy that maps requests to a specific service instance based on values from the incoming HTTP request, such as the URL path or query string, and in the case of stateful services, a partition within the service instance.
 
 To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a stateless service instance in the Service Fabric back-end based on values retrieved from the incoming HTTP request. Requests to a service are sent to a random instance of the service.
 
-#### Example
+**Example**
 
 In this example, a new stateless service instance is created for each user of an application with a dynamically generated name using the following formula:
- 
+
 - `fabric:/app/users/<username>`
 
   Each service has a unique name, but the names are not known up-front because the services are created in response to user or admin input and thus cannot be hard-coded into APIM policies or routing rules. Instead, the name of the service to which to send a request is generated in the back-end policy definition from the `name` value provided in the URL request path. For example:
 
   - A request to `/api/users/foo` is routed to service instance `fabric:/app/users/foo`
   - A request to `/api/users/bar` is routed to service instance `fabric:/app/users/bar`
 
-![Service Fabric with Azure API Management topology overview][sf-apim-dynamic-stateless]
+![Service Fabric with Azure API Management topology overview][sf-apim-dynamic-stateless.md]
 
 ## Send traffic to multiple stateful services
 
 Similar to the stateless service example, an API Management operation can map requests to more than one **stateful** service instance, in which case you also may need to perform partition resolution for each stateful service instance.
 
 To achieve this, an API Management operation contains an inbound processing policy with a Service Fabric back-end that maps to a stateful service instance in the Service Fabric back-end based on values retrieved from the incoming HTTP request. In addition to mapping a request to specific service instance, the request can also be mapped to a specific partition within the service instance, and optionally to either the primary replica or a random secondary replica within the partition.
 
-#### Example
+**Example**
 
 In this example, a new stateful service instance is created for each user of the application with a dynamically generated name using the following formula:
- 
+
 - `fabric:/app/users/<username>`
 
   Each service has a unique name, but the names are not known up-front because the services are created in response to user or admin input and thus cannot be hard-coded into APIM policies or routing rules. Instead, the name of the service to which to send a request is generated in the back-end policy definition from the `name` value provided the URL request path. For example:
@@ -113,4 +112,4 @@ Follow the [tutorial](service-fabric-tutorial-deploy-api-management.md) to set u
 [sf-apim-static-stateless]: ./media/service-fabric-api-management-overview/sf-apim-static-stateless.png
 [sf-apim-static-stateful]: ./media/service-fabric-api-management-overview/sf-apim-static-stateful.png
 [sf-apim-dynamic-stateless]: ./media/service-fabric-api-management-overview/sf-apim-dynamic-stateless.png
-[sf-apim-dynamic-stateful]: ./media/service-fabric-api-management-overview/sf-apim-dynamic-stateful.png
+[sf-apim-dynamic-stateful]: ./media/service-fabric-api-management-overview/sf-apim-dynamic-stateful.png

articles/service-fabric/service-fabric-cluster-nodetypes.md

@@ -1,29 +1,33 @@
 ---
 title: Node types and virtual machine scale sets 
-description: Learn how Azure Service Fabric node types relate to virtual machine scale sets, and how to remotely connect to a scale set instance or cluster node.
-
+description: Learn how Azure Service Fabric node types relate to virtual machine scale sets and how to remotely connect to a scale set instance or cluster node.
 ms.topic: conceptual
 ms.date: 03/23/2018
 ms.author: pepogors
+ms.custom: sfrev
 ---
 # Azure Service Fabric node types and virtual machine scale sets
-[Virtual machine scale sets](/azure/virtual-machine-scale-sets) are an Azure compute resource. You can use scale sets to deploy and manage a collection of virtual machines as a set. Each node type that you define in an Azure Service Fabric cluster sets up a separate scale.  The Service Fabric runtime installed on each virtual machine in the scale set by the Microsoft.Azure.ServiceFabric Virtual Machine extension. You can independently scale each node type up or down, change the OS SKU running on each cluster node, have different sets of ports open, and use different capacity metrics.
 
-The following figure shows a cluster that has two node types, named FrontEnd and BackEnd. Each node type has five nodes.
+[Virtual machine scale sets](/azure/virtual-machine-scale-sets) are an Azure compute resource. You can use scale sets to deploy and manage a collection of virtual machines as a set. Each node type that you define in an Azure Service Fabric cluster sets up a separate scale. The Service Fabric runtime is installed on each virtual machine in the scale set by the *Microsoft.Azure.ServiceFabric* Virtual Machine extension. You can independently scale each node type up or down, change the OS SKU running on each cluster node, have different sets of ports open, and use different capacity metrics.
+
+The following figure shows a cluster that has two node types, named *FrontEnd* and *BackEnd*. Each node type has five nodes.
 
 ![A cluster that has two node types][NodeTypes]
 
 ## Map virtual machine scale set instances to nodes
+
 As shown in the preceding figure, scale set instances start at instance 0, and then increase by 1. The numbering is reflected in the node names. For example, node BackEnd_0 is instance 0 of the BackEnd scale set. This particular scale set has five instances, named BackEnd_0, BackEnd_1, BackEnd_2, BackEnd_3, and BackEnd_4.
 
 When you scale up a scale set, a new instance is created. The new scale set instance name typically is the scale set name plus the next instance number. In our example, it is BackEnd_5.
 
 ## Map scale set load balancers to node types and scale sets
+
 If you deployed your cluster in the Azure portal or used the sample Azure Resource Manager template, all resources under a resource group are listed. You can see the load balancers for each scale set or node type. The load balancer name uses the following format: **LB-<node type name>**. An example is LB-sfcluster4doc-0, as shown in the following figure:
 
 ![Resources][Resources]
 
 ## Service Fabric Virtual Machine Extension
+
 Service Fabric Virtual Machine Extension is used to bootstrap Service Fabric to Azure Virtual Machines, and configure the Node Security.
 
 The following is a snippet of Service Fabric Virtual Machine extension:
@@ -60,23 +64,24 @@ The following is a snippet of Service Fabric Virtual Machine extension:
 
 The following are the property descriptions:
 
-| **Name** | **Allowed Values** | ** --- ** | **Guidance or Short Description** |
+| **Name** | **Allowed Values** | **Guidance or Short Description** |
 | --- | --- | --- | --- |
-| name | string | --- | unique name for extension |
-| type | "ServiceFabricLinuxNode" or "ServiceFabricWindowsNode" | --- | Identifies OS Service Fabric is bootstrapping to |
-| autoUpgradeMinorVersion | true or false | --- | Enable Auto Upgrade of SF Runtime Minor Versions |
-| publisher | Microsoft.Azure.ServiceFabric | --- | name of the Service Fabric extention publisher |
-| clusterEndpont | string | --- | URI:PORT to Management endpoint |
-| nodeTypeRef | string | --- | name of nodeType |
-| durabilityLevel | bronze, silver, gold, platinum | --- | time allowed to pause immutable Azure Infrastructure |
-| enableParallelJobs | true or false | --- | Enable Compute ParallelJobs like remove VM and reboot VM in the same scale set in parallel |
-| nicPrefixOverride | string | --- | Subnet Prefix like "10.0.0.0/24" |
-| commonNames | string[] | --- | Common Names of installed cluster certificates |
-| x509StoreName | string | --- | Name of Store where installed cluster certificate is located |
-| typeHandlerVersion | 1.1 | --- | Version of Extension. 1.0 classic version of extension are recommended to upgrade to 1.1 |
-| dataPath | string | --- | Path to the drive used to save state for Service Fabric system services and application data. 
+| name | string | Unique name for extension |
+| type | "ServiceFabricLinuxNode" or "ServiceFabricWindowsNode" | Identifies OS Service Fabric is bootstrapping to |
+| autoUpgradeMinorVersion | true or false | Enable Auto Upgrade of SF Runtime Minor Versions |
+| publisher | Microsoft.Azure.ServiceFabric | Name of the Service Fabric extention publisher |
+| clusterEndpont | string | URI:PORT to Management endpoint |
+| nodeTypeRef | string | Name of nodeType |
+| durabilityLevel | bronze, silver, gold, platinum | Time allowed to pause immutable Azure Infrastructure |
+| enableParallelJobs | true or false | Enable Compute ParallelJobs like remove VM and reboot VM in the same scale set in parallel |
+| nicPrefixOverride | string | Subnet Prefix like "10.0.0.0/24" |
+| commonNames | string[] | Common Names of installed cluster certificates |
+| x509StoreName | string | Name of Store where installed cluster certificate is located |
+| typeHandlerVersion | 1.1 | Version of Extension. 1.0 classic version of extension are recommended to upgrade to 1.1 |
+| dataPath | string | Path to the drive used to save state for Service Fabric system services and application data.
 
 ## Next steps
+
 * See the [overview of the "Deploy anywhere" feature and a comparison with Azure-managed clusters](service-fabric-deploy-anywhere.md).
 * Learn about [cluster security](service-fabric-cluster-security.md).
 * [Remote connect](service-fabric-cluster-remote-connect-to-azure-cluster-node.md) to a specific scale set instance