Merge pull request #265425 from Akhilesh-microsoft/AWP/Update_msdate

[AWP]: Content freshness: Updated msdate in all the articles

Author: v-dirichards

articles/azure-signalr/signalr-concept-authenticate-oauth.md

@@ -205,7 +205,7 @@ In this section, you implement a `Login` API that authenticates clients using th
 
 ### Update the Hub class
 
-By default, web client connects to SignalR Service using an internal access token. This access token isn't associated with an authenticated identity.
+By default, web client connects to SignalR Service using an internal access. This access token isn't associated with an authenticated identity.
 Basically, it's anonymous access.
 
 In this section, you turn on real authentication by adding the `Authorize` attribute to the hub class, and updating the hub methods to read the username from the authenticated user's claim.
@@ -346,7 +346,7 @@ In this section, you turn on real authentication by adding the `Authorize` attri
 
    ![OAuth Complete hosted in Azure](media/signalr-concept-authenticate-oauth/signalr-oauth-complete-azure.png)
 
-   You prompt to authorize the chat app's access to your GitHub account. Select the **Authorize** button.
+   You're prompted to authorize the chat app's access to your GitHub account. Select the **Authorize** button.
 
    ![Authorize OAuth App](media/signalr-concept-authenticate-oauth/signalr-authorize-oauth-app.png)
 

articles/azure-signalr/signalr-concept-disaster-recovery.md

@@ -11,34 +11,34 @@ ms.author: lianwei
 ---
 # Resiliency and disaster recovery in Azure SignalR Service
 
-Resiliency and disaster recovery is a common need for online systems. Azure SignalR Service already guarantees 99.9% availability, but it's still a regional service.
-Your service instance is always running in one region and doesn't fail over to another region when there's a region-wide outage.
+Resiliency and disaster recovery is a common need for online systems. Azure SignalR Service already provides 99.9% availability, however it's still a regional service.
+When there's a region-wide outage, your service instance doesn't fail over to another region because it's always running in the one region.
 
 For regional disaster recovery, we recommend the following two approaches:
 
-- **Enable Geo-Replication** (Easy way). This feature will handle regional failover for you automatically. When enabled, there remains just one Azure SignalR instance and no code changes are introduced. Check [geo-replication](howto-enable-geo-replication.md) for details.
-- **Utilize Multiple Endpoints in Service SDK**. Our service SDK provides a functionality to support multiple SignalR service instances and automatically switch to other instances when some of them aren't available. With this feature, you're able to recover when a disaster takes place, but you need to set up the right system topology by yourself. You learn how to do so **in this document**.
+- **Enable Geo-Replication** (Easy way). This feature handles regional failover for you automatically. When enabled, there's only one Azure SignalR instance and no code changes are introduced. Check [geo-replication](howto-enable-geo-replication.md) for details.
+- **Utilize Multiple Endpoints in Service SDK**. Our service SDK supports multiple SignalR service instances and automatically switches to other instances when some of them are unavailable. With this feature, you're able to recover when a disaster takes place, but you need to set up the right system topology by yourself. You learn how to do so **in this document**.
 
 
 ## High available architecture for SignalR service
 
-In order to have cross region resiliency for SignalR service, you need to set up multiple service instances in different regions. So when one region is down, the others can be used as backup.
+To ensure cross region resiliency for SignalR service, you need to set up multiple service instances in different regions. So when one region is down, the others can be used as backup.
 When app servers connect to multiple service instances, there are two roles, primary and secondary.
-Primary is an instance who is taking online traffic and secondary is a fully functional but backup instance for primary.
-In our SDK implementation, negotiate only returns primary endpoints so in normal case clients only connect to primary endpoints.
+Primary is an instance responsible for receiving online traffic, while secondary serves as a fallback instance that is fully functional.
+In our SDK implementation, negotiate only returns primary endpoints, so clients only connect to primary endpoints in normal cases.
 But when primary instance is down, negotiate returns secondary endpoints so client can still make connections.
 Primary instance and app server are connected through normal server connections but secondary instance and app server are connected through a special type of connection called weak connection.
-The main difference of a weak connection is that it doesn't accept client connection routing, because secondary instance is located in another region. Routing a client to another region isn't an optimal choice (increases latency).
+One distinguishing characteristic of a weak connection is that it's unable to accept client connection routing due to the location of secondary instance in another region. Routing a client to another region isn't an optimal choice (increases latency).
 
 One service instance can have different roles when connecting to multiple app servers.
-One typical setup for cross region scenario is to have two (or more) pairs of SignalR service instances and app servers.
+One typical setup for cross region scenario is to have two or more pairs of SignalR service instances and app servers.
 Inside each pair app server and SignalR service are located in the same region, and SignalR service is connected to the app server as a primary role.
 Between each pairs app server and SignalR service are also connected, but SignalR becomes a secondary when connecting to server in another region.
 
 With this topology, message from one server can still be delivered to all clients as all app servers and SignalR service instances are interconnected.
-But when a client is connected, it's always routed to the app server in the same region to achieve optimal network latency.
+But when a client is connected, it routes to the app server in the same region to achieve optimal network latency.
 
-Below is a diagram that illustrates such topology:
+The following diagram illustrates such topology:
 
 ![Diagram shows two regions each with an app server and a SignalR service, where each server is associated with the SignalR service in its region as primary and with the service in the other region as secondary.](media/signalr-concept-disaster-recovery/topology.png)
 
@@ -60,7 +60,7 @@ If you have multiple endpoints, you can set them in multiple config entries, eac
 Azure:SignalR:ConnectionString:<name>:<role>
 ```
 
-Here `<name>` is the name of the endpoint and `<role>` is its role (primary or secondary).
+In the ConnectionString, `<name>` is the name of the endpoint and `<role>` is its role (primary or secondary).
 Name is optional but it's useful if you want to further customize the routing behavior among multiple endpoints.
 
 #### Through code
@@ -147,7 +147,7 @@ Follow the steps to trigger the failover:
 
 ## Next steps
 
-In this article, you have learned how to configure your application to achieve resiliency for SignalR service. To understand more details about server/client connection and connection routing in SignalR service, you can read [this article](signalr-concept-internals.md) for SignalR service internals.
+In this article, you learned how to configure your application to achieve resiliency for SignalR service. To understand more details about server/client connection and connection routing in SignalR service, you can read [this article](signalr-concept-internals.md) for SignalR service internals.
 
 For scaling scenarios such as sharding that uses multiple instances together to handle large number of connections read [how to scale multiple instances](signalr-howto-scale-multi-instances.md).
 

articles/azure-signalr/signalr-concept-event-grid-integration.md

@@ -1,6 +1,6 @@
 ---
 title: React to Azure SignalR Service events
-description: Use Azure Event Grid to subscribe to Azure SignalR Service events. Other downstream services can be triggered by these events.
+description: Use Azure Event Grid to subscribe to Azure SignalR Service events. These events can also trigger other downstream services.
 services: azure-signalr,event-grid 
 author: vicancy
 ms.author: lianwei
@@ -14,25 +14,25 @@ ms.service: signalr
 
 Azure SignalR Service events allow applications to react to client connections connected or disconnected using modern serverless architectures. It does so without the need for complicated code or expensive and inefficient polling services.  Instead, events are pushed through [Azure Event Grid](https://azure.microsoft.com/services/event-grid/) to subscribers such as [Azure Functions](https://azure.microsoft.com/services/functions/), [Azure Logic Apps](https://azure.microsoft.com/services/logic-apps/), or even to your own custom http listener. With Azure SignalR, you only pay for what you consume.
 
-Azure SignalR Service events are reliably sent to the Event Grid service which provides reliable delivery services to your applications through rich retry policies and dead-letter delivery. To learn more, see [Event Grid message delivery and retry](../event-grid/delivery-and-retry.md).
+Azure SignalR Service events are reliably sent to the Event Grid service that provides reliable delivery services to your applications through rich retry policies and dead-letter delivery. To learn more, see [Event Grid message delivery and retry](../event-grid/delivery-and-retry.md).
 
 ![Event Grid Model](/azure/event-grid/media/overview/functional-model.png)
 
 ## Serverless state
-Azure SignalR Service events are only active when client connections are in a serverless state. If a client does not route to a hub server, it goes into the serverless state. Classic mode only works when the hub that client connections connect to doesn't have a hub server. Serverless mode is recommended as a best practice. To learn more details about service mode, see [How to choose Service Mode](https://github.com/Azure/azure-signalr/blob/dev/docs/faq.md#what-is-the-meaning-of-service-mode-defaultserverlessclassic-how-can-i-choose).
+Azure SignalR Service events are only active when client connections are in a serverless state. If a client doesn't route to a hub server, it goes into the serverless state. Classic mode only works when the hub that client connections connect to doesn't have a hub server. Serverless mode is recommended as a best practice. To learn more details about service mode, see [How to choose Service Mode](https://github.com/Azure/azure-signalr/blob/dev/docs/faq.md#what-is-the-meaning-of-service-mode-defaultserverlessclassic-how-can-i-choose).
 
 ## Available Azure SignalR Service events
-Event grid uses [event subscriptions](../event-grid/concepts.md#event-subscriptions) to route event messages to subscribers. Azure SignalR Service event subscriptions support two types of events:  
+Event Grid uses [event subscriptions](../event-grid/concepts.md#event-subscriptions) to route event messages to subscribers. Azure SignalR Service event subscriptions support two types of events:  
 
 |Event Name|Description|
 |----------|-----------|
 |`Microsoft.SignalRService.ClientConnectionConnected`|Raised when a client connection is connected.|
 |`Microsoft.SignalRService.ClientConnectionDisconnected`|Raised when a client connection is disconnected.|
 
 ## Event schema
-Azure SignalR Service events contain all the information you need to respond to the changes in your data. You can identify an Azure SignalR Service event with the eventType property starts with "Microsoft.SignalRService". Additional information about the usage of Event Grid event properties is documented at [Event Grid event schema](../event-grid/event-schema.md).  
+Azure SignalR Service events contain all the information you need to respond to the changes in your data. You can identify an Azure SignalR Service event with the eventType property starts with **Microsoft.SignalRService**. Additional information about the usage of Event Grid event properties is documented at [Event Grid event schema](../event-grid/event-schema.md).  
 
-Here is an example of a client connection connected event:
+Here's an example of a client connection connected event:
 ```json
 [{
   "topic": "/subscriptions/{subscription-id}/resourceGroups/signalr-rg/providers/Microsoft.SignalRService/SignalR/signalr-resource",

articles/azure-signalr/signalr-concept-scale-aspnet-core.md

@@ -13,11 +13,18 @@ ms.author: lianwei
 
 ## Developing SignalR apps
 
-Currently, there are [two versions](/aspnet/core/signalr/version-differences) of SignalR you can use with your web applications: ASP.NET SignalR, and the new ASP.NET Core SignalR. ASP.NET Core SignalR is a rewrite of the previous version. As a result, ASP.NET Core SignalR isn't backward compatible with the earlier SignalR version. The APIs and behaviors are different. The Azure SignalR Service supports both versions.
+SignalR is currently available in [two versions](/aspnet/core/signalr/version-differences) for use with web applications: 
+- ASP.NET SignalR
+- new ASP.NET Core SignalR 
 
-With Azure SignalR Service, you have the ability to run your actual web application on multiple platforms (Windows, Linux, and macOS) while hosting with [Azure App Service](../app-service/overview.md), [IIS](/aspnet/core/host-and-deploy/iis/index), [Nginx](/aspnet/core/host-and-deploy/linux-nginx), [Apache](/aspnet/core/host-and-deploy/linux-apache), [Docker](/aspnet/core/host-and-deploy/docker/index). You can also use self-hosting in your own process.
+ASP.NET Core SignalR is a rewrite of the previous version. As a result, ASP.NET Core SignalR isn't backward compatible with the earlier SignalR version. The APIs and behaviors are different. The Azure SignalR Service supports both versions.
 
-If the goals for your application include: supporting the latest functionality for updating web clients with real-time content updates, running across multiple platforms (Azure, Windows, Linux, and macOS), and hosting in different environments, then the best choice could be using the Azure SignalR Service.
+Azure SignalR Service lets you host your actual web application on multiple platforms (Windows, Linux, and macOS) [Azure App Service](../app-service/overview.md), [IIS](/aspnet/core/host-and-deploy/iis/index), [Nginx](/aspnet/core/host-and-deploy/linux-nginx), [Apache](/aspnet/core/host-and-deploy/linux-apache), [Docker](/aspnet/core/host-and-deploy/docker/index). You can also use self-hosting in your own process.
+
+Azure SignalR Service is the best choice if the goals for your application include: 
+- supporting the latest functionality for updating web clients with real-time content updates, 
+- running across multiple platforms (Azure, Windows, Linux, and macOS)
+- hosting in different environments
 
 ## Why not deploy SignalR myself?
 
@@ -27,7 +34,7 @@ One of the key reasons to use the Azure SignalR Service is simplicity. With Azur
 
 Also, WebSockets are typically the preferred technique to support real-time content updates. However, load balancing a large number of persistent WebSocket connections becomes a complicated problem to solve as you scale. Common solutions use: DNS load balancing, hardware load balancers, and software load balancing. Azure SignalR Service handles this problem for you.
 
-For ASP.NET Core SignalR, another reason might be you have no requirements to actually host a web application at all. The logic of your web application might use [Serverless computing](https://azure.microsoft.com/overview/serverless-computing/). For example, maybe your code is only hosted and executed on demand with [Azure Functions](../azure-functions/index.yml) triggers. This scenario can be tricky because your code only runs on-demand and doesn't maintain long connections with clients. Azure SignalR Service can handle this situation since the service already manages connections for you. For more information, see [overview on how to use SignalR Service with Azure Functions](signalr-concept-azure-functions.md). Since ASP.NET SignalR uses a different protocol, such Serverless mode isn't supported for ASP.NET SignalR.
+For ASP.NET Core SignalR, another reason might be you have no requirements to actually host a web application at all. The logic of your web application might use [Serverless computing](https://azure.microsoft.com/overview/serverless-computing/). For example, maybe your code is only hosted and executed on demand with [Azure Functions](../azure-functions/index.yml) triggers. This scenario can be challenging because your code only runs on-demand and doesn't maintain long connections with clients. Azure SignalR Service can handle this situation since the service already manages connections for you. For more information, see [overview on how to use SignalR Service with Azure Functions](signalr-concept-azure-functions.md). Since ASP.NET SignalR uses a different protocol, such Serverless mode isn't supported for ASP.NET SignalR.
 
 ## How does it scale?