finish review.

Author: cebundy

articles/azure-signalr/TOC.yml

@@ -123,7 +123,7 @@
       href: howto-shared-private-endpoints-key-vault.md
     - name: Use managed identity
       href: howto-use-managed-identity.md
-    - name: Authorize from Azure Application
+    - name: Authorize from Azure Applications
       href: signalr-howto-authorize-application.md
     - name: Authorize from Managed Identity
       href: signalr-howto-authorize-managed-identity.md

articles/azure-signalr/concept-connection-string.md

@@ -6,44 +6,41 @@ services: signalr
 author: vicancy
 ms.service: signalr
 ms.topic: conceptual
-ms.date: 05/06/2020
+ms.date: 35/29/2023
 ms.author: lianwei
 ---
 
 # Configure network access control
 
-Azure SignalR Service enables you to secure and control the level of access to your service endpoint, based on the request type and subset of networks used. When network rules are configured, only applications requesting data over the specified set of networks can access your Azure SignalR Service.
+Azure SignalR Service enables you to secure and control the level of access to your service endpoint based on the request type and subset of networks. When network rules are configured, only applications requesting data over the specified set of networks can access your SignalR Service.
 
-Azure SignalR Service has a public endpoint that is accessible through the internet. You can also create [Private Endpoints for your Azure SignalR Service](howto-private-endpoints.md). Private Endpoint assigns a private IP address from your VNet to the Azure SignalR Service, and secures all traffic between your VNet and the Azure SignalR Service over a private link. The Azure SignalR Service network access control provides access control for both public endpoint and private endpoints.
+SignalR Service has a public endpoint that is accessible through the internet. You can also create [private endpoints for your Azure SignalR Service](howto-private-endpoints.md). A private endpoint assigns a private IP address from your VNet to the SignalR Service, and secures all traffic between your VNet and the SignalR Service over a private link. The SignalR Service network access control provides access control for both public and private endpoints.
 
-Optionally, you can choose to allow or deny certain types of requests for public endpoint and each private endpoint. For example, you can block all [Server Connections](signalr-concept-internals.md#application-server-connections) from public endpoint and make sure they only originate from a specific VNet.
+Optionally, you can choose to allow or deny certain types of requests for the public endpoint and each private endpoint. For example, you can block all [Server Connections](signalr-concept-internals.md#application-server-connections) from public endpoint and make sure they only originate from a specific VNet.
 
-An application that accesses an Azure SignalR Service when network access control rules are in effect still requires proper authorization for the request.
+An application that accesses a SignalR Service when network access control rules are in effect still requires proper authorization for the request.
 
 ## Scenario A - No public traffic
 
-To completely deny all public traffic, you should first configure the public network rule to allow no request type. Then, you should configure rules that grant access to traffic from specific VNets. This configuration enables you to build a secure network boundary for your applications.
+To completely deny all public traffic, first configure the public network rule to allow no request type. Then, you can configure rules that grant access to traffic from specific VNets. This configuration enables you to build a secure network boundary for your applications.
 
 ## Scenario B - Only client connections from public network
 
-In this scenario, you can configure the public network rule to only allow [Client Connections](signalr-concept-internals.md#client-connections) from public network. You can then configure private network rules to allow other types of requests originating from a specific VNet. This configuration hides your app servers from public network and establishes secure connections between your app servers and Azure SignalR Service.
+In this scenario, you can configure the public network rule to only allow [Client Connections](signalr-concept-internals.md#client-connections) from the public network. You can then configure private network rules to allow other types of requests originating from a specific VNet. This configuration hides your app servers from the public network and establishes secure connections between your app servers and SignalR Service.
 
 ## Managing network access control
 
-You can manage network access control for Azure SignalR Service through the Azure portal.
+You can manage network access control for SignalR Service through the Azure portal.
 
-### Azure portal
-
-1. Go to the Azure SignalR Service you want to secure.
-
-1. Select on the settings menu called **Network access control**.
+1. Go to the SignalR Service instance you want to secure.
+1. Select **Network access control** from the left side menu.
 
     ![Network ACL on portal](media/howto-network-access-control/portal.png)
 
 1. To edit default action, toggle the **Allow/Deny** button.
 
     > [!TIP]
-    > The default action is the action the service takes when there is no ACL rule matches. For example, if the default action is **Deny**, then the request types that are not explicitly approved will be denied.
+    > The default action is the action the service takes when no access control rule matches a request. For example, if the default action is **Deny**, then the request types that are not explicitly approved will be denied.
 
 1. To edit public network rule, select allowed types of requests under **Public network**.
 

articles/azure-signalr/howto-network-access-control.md

@@ -6,14 +6,14 @@ ms.service: signalr
 ms.topic: conceptual
 ms.devlang: csharp
 ms.custom: devx-track-csharp
-ms.date: 01/05/2023
-ms.author: lianwei
+ms.date: 03/29/2023
+ms.author: lanwei
 ---
 # Azure SignalR Service internals
 
 Azure SignalR Service is built on top of ASP.NET Core SignalR framework. It also supports ASP.NET SignalR by reimplementing ASP.NET SignalR's data protocol on top of the ASP.NET Core framework.
 
-You can easily migrate a local ASP.NET Core SignalR or an ASP.NET SignalR application to work with SignalR Service, with a few lines of code change.
+You can easily migrate a local ASP.NET Core SignalR or an ASP.NET SignalR application to work with SignalR Service, with by changing few lines of code.
 
 The diagram describes the typical architecture when you use the SignalR Service with your application server.
 
@@ -28,7 +28,7 @@ A self-hosted ASP.NET Core SignalR application server listens to and connects cl
 With SignalR Service, the application server no longer accepts persistent client connections, instead:
 
 1. A `negotiate` endpoint is exposed by Azure SignalR Service SDK for each hub.
-1. The endpoint responds to client's negotiation requests and redirect clients to SignalR Service.
+1. The endpoint responds to client negotiation requests and redirect clients to SignalR Service.
 1. The clients connect to SignalR Service.
 
 For more information, see [Client connections](#client-connections).
@@ -41,15 +41,11 @@ Once the application server is started:
 
 The initial number of connections defaults to 5 and is configurable using the `InitialHubServerConnectionCount` option in the SignalR Service SDK.  For more information, see  [configuration](https://github.com/Azure/azure-signalr/blob/dev/docs/run-asp-net-core.md#maxhubserverconnectioncount). 
 
-While the application server is connected to the SignalR service, the Azure SignalR service may send load-balancing messages to the server.  Then, the SDK starts new server connections to the service for better performance. 
-
-<!-- Question: What does this mean?  Are the connections client <-> service? -->
-Messages to and from clients are multiplexed into these connections.
-
+While the application server is connected to the SignalR service, the Azure SignalR service may send load-balancing messages to the server.  Then, the SDK starts new server connections to the service for better performance. Messages to and from clients are multiplexed into these connections.
 
 Server connections are persistently connected to the SignalR Service. If a server connection is disconnected due to a network issue:
 
-- All clients served by this server connection disconnect (for more information, see [Data transmission between client and server](#data-transmission-between-client-and-server)).
+- All clients served by this server connection disconnect. For more information, see [Data transmission between client and server](#data-transmission-between-client-and-server).
 - The server automatically reconnects the clients.
 
 ## Client connections
@@ -91,7 +87,7 @@ At this point, the application server receives an event with information from th
 
 SignalR Service transmits data from the client to the pairing application server. Data from the application server is sent to the mapped clients.
 
-SignalR Service doesn't save or store customer data, all customer data received is transmitted to target server or clients in real-time.
+SignalR Service doesn't save or store customer data, all customer data received is transmitted to the target server or clients in real-time.
 
 The Azure SignalR Service acts as a logical transport layer between  application server and clients. All persistent connections are offloaded to SignalR Service.  As a result, the application server only needs to handle the business logic in the hub class, without worrying about client connections.
 

articles/azure-signalr/signalr-concept-internals.md

@@ -3,7 +3,7 @@ title: Authorize managed identity requests to a SignalR resource
 description: This article provides information about authorizing request to SignalR resources with Azure AD from managed identities
 author: vicancy
 ms.author: lianwei
-ms.date: 07/18/2022
+ms.date: 03/28/2023
 ms.service: signalr
 ms.topic: how-to
 ms.devlang: csharp
@@ -12,7 +12,7 @@ ms.custom: subject-rbac-steps
 
 # Authorize managed identity requests to a SignalR resource
 
-Azure SignalR Service supports Azure Active Directory (Azure AD) authorizing requests from Azure resources using [Managed identities for Azure resources
+Azure SignalR Service supports Azure Active Directory (Azure AD) authorizing requests from Azure resources using [managed identities for Azure resources
 ](../active-directory/managed-identities-azure-resources/overview.md).
 
 This article shows how to configure your SignalR resource and code to authorize a managed identity request to a SignalR resource.
@@ -30,8 +30,7 @@ This example shows you how to configure `System-assigned managed identity` on a
 1. Select the **Save** button to confirm the change.
 
 
-To learn how to create user-assigned managed identities, see this article:
-- [Create a user-assigned managed identity](../active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md#create-a-user-assigned-managed-identity)
+To learn how to create user-assigned managed identities, see [Create a user-assigned managed identity](../active-directory/managed-identities-azure-resources/how-manage-user-assigned-managed-identities.md#create-a-user-assigned-managed-identity)
 
 To learn more about configuring managed identities, see one of these articles:
 
@@ -66,7 +65,7 @@ The following steps describe how to assign a `SignalR App Server` role to a syst
 
 1. Select your Azure subscription.
 
-1. Select **System-assigned managed identity**, search for a virtual machine to which would you'd like to assign the role, and then select it.
+1. Select **System-assigned managed identity**, search for a virtual machine to which you'd like to assign the role, and then select it.
 
 1. On the **Review + assign** tab, select **Review + assign** to assign the role.
 
@@ -86,11 +85,9 @@ To learn more about how to assign and manage Azure role assignments, see these a
 
 #### Using system-assigned identity
 
-You can use either [DefaultAzureCredential](/dotnet/api/overview/azure/identity-readme#defaultazurecredential) or [ManagedIdentityCredential](/dotnet/api/azure.identity.managedidentitycredential) to configure your SignalR endpoints.
+You can use either [DefaultAzureCredential](/dotnet/api/overview/azure/identity-readme#defaultazurecredential) or [ManagedIdentityCredential](/dotnet/api/azure.identity.managedidentitycredential) to configure your SignalR endpoints. However, the best practice is to use `ManagedIdentityCredential` directly.
 
-However, the best practice is to use `ManagedIdentityCredential` directly.
-
-The system-assigned managed identity will be used by default, but **make sure that you don't configure any environment variables** that the [EnvironmentCredential](/dotnet/api/azure.identity.environmentcredential) preserved if you were using `DefaultAzureCredential`. Otherwise it will fall back to use `EnvironmentCredential` to make the request and it will result to a `Unauthorized` response in most cases.
+The system-assigned managed identity is used by default, but **make sure that you don't configure any environment variables** that the [EnvironmentCredential](/dotnet/api/azure.identity.environmentcredential) preserved if you were using `DefaultAzureCredential`. Otherwise it falls back to use `EnvironmentCredential` to make the request and it results to a `Unauthorized` response in most cases.
 
 ```C#
 services.AddSignalR().AddAzureSignalR(option =>
@@ -127,14 +124,14 @@ You might need a group of key-value pairs to configure an identity. The keys of
 
 #### Using system-assigned identity
 
-If you only configure the service URI, then the `DefaultAzureCredential` is used. This class is useful when you want to share the same configuration on Azure and local dev environment. To learn how `DefaultAzureCredential` works, see [DefaultAzureCredential](/dotnet/api/overview/azure/identity-readme#defaultazurecredential).
+If you only configure the service URI, then the `DefaultAzureCredential` is used. This class is useful when you want to share the same configuration on Azure and local development environments. To learn how `DefaultAzureCredential` works, see [DefaultAzureCredential](/dotnet/api/overview/azure/identity-readme#defaultazurecredential).
 
-On Azure portal, use the following example to configure a `DefaultAzureCredential`. If don't configure any [environment variables listed here](/dotnet/api/overview/azure/identity-readme#environment-variables), then the system-assigned identity will be used to authenticate.
+In the Azure portal, use the following example to configure a `DefaultAzureCredential`. If you don't configure any [environment variables listed here](/dotnet/api/overview/azure/identity-readme#environment-variables), then the system-assigned identity is used to authenticate.
 ```
 <CONNECTION_NAME_PREFIX>__serviceUri=https://<SIGNALR_RESOURCE_NAME>.service.signalr.net
 ```
 
-Here's a config sample of `DefaultAzureCredential` in the `local.settings.json` file. At the local scope there's no managed identity, and the authentication via Visual Studio, Azure CLI, and Azure PowerShell accounts will be attempted in order.
+Here's a config sample of `DefaultAzureCredential` in the `local.settings.json` file. At the local scope there's no managed identity, and the authentication via Visual Studio, Azure CLI, and Azure PowerShell accounts are attempted in order.
 ```json
 {
   "Values": {
@@ -143,7 +140,7 @@ Here's a config sample of `DefaultAzureCredential` in the `local.settings.json`
 }
 ```
 
-If you want to use system-assigned identity independently and without the influence of [other environment variables](/dotnet/api/overview/azure/identity-readme#environment-variables), you should set the `credential` key with connection name prefix to `managedidentity`. Here's an application settings sample:
+If you want to use system-assigned identity independently and without the influence of [other environment variables](/dotnet/api/overview/azure/identity-readme#environment-variables), you should set the `credential` key with the connection name prefix to `managedidentity`. Here's an application settings sample:
 
 ```
 <CONNECTION_NAME_PREFIX>__serviceUri = https://<SIGNALR_RESOURCE_NAME>.service.signalr.net
@@ -152,12 +149,14 @@ If you want to use system-assigned identity independently and without the influe
 
 #### Using user-assigned identity
 
-If you want to use user-assigned identity, you need to assign one more `clientId` key with connection name prefix compared to system-assigned identity. Here's the application settings sample:
+If you want to use user-assigned identity, you need to assign `clientId`in addition to the `serviceUri` and `credential` keys with the connection name prefix. Here's the application settings sample:
+
 ```
 <CONNECTION_NAME_PREFIX>__serviceUri = https://<SIGNALR_RESOURCE_NAME>.service.signalr.net
 <CONNECTION_NAME_PREFIX>__credential = managedidentity
 <CONNECTION_NAME_PREFIX>__clientId = <CLIENT_ID>
 ```
+
 ## Next steps
 
 See the following related articles:

articles/azure-signalr/signalr-howto-authorize-managed-identity.md

@@ -4,38 +4,32 @@ description: An overview on why the customer needs to routinely rotate the acces
 author: vicancy
 ms.service: signalr
 ms.topic: how-to
-ms.date: 07/18/2022
+ms.date: 03/29/2023
 ms.author: lianwei
 ---
 # Rotate access keys for Azure SignalR Service
 
-For security reasons and compliance requirements, it is important to routinely rotate your access keys. This article describes how to rotate access keys for Azure SignalR Service.
+For security reasons and compliance requirements, it's important to routinely rotate your access keys. This article describes how to rotate access keys for Azure SignalR Service.
 
 Each Azure SignalR Service instance has a primary and a secondary key. They're used to authenticate SignalR clients when requests are made to the service. The keys are associated with the instance endpoint URL. Keep your keys secure, and rotate them regularly. You're provided with two access keys so that you can maintain connections by using one key while regenerating the other.
 
 
 ## Regenerate access keys
 
-1. Go to the [Azure portal](https://portal.azure.com/), and sign in with your credentials.
-
-1. Find the **Keys** section in the Azure SignalR Service instance with the keys that you want to regenerate.
-
-1. Select **Keys** on the navigation menu.
-
+1. Go to your SignalR instance in the [Azure portal](https://portal.azure.com/).
+1. Select **Keys** on the left side menu.
 1. Select **Regenerate Primary Key** or **Regenerate Secondary Key**.
 
-   A new key and corresponding connection string are created and displayed.
+A new key and corresponding connection string are created and displayed.
 
-   ![Regenerate Keys](media/signalr-howto-key-rotation/regenerate-keys.png)
+:::image type="content" source="media/signalr-howto-key-rotation/regenerate-keys.png" alt-text="Screenshot of SignalR key rotation.":::
 
 You also can regenerate keys by using the [Azure CLI](/cli/azure/signalr/key#az-signalr-key-renew).
 
 ## Update configurations with new connection strings
 
 1. Copy the newly generated connection string.
-
 1. Update all configurations to use the new connection string.
-
 1. Restart the application as needed.
 
 ## Forced access key regeneration