Merge pull request #125013 from ArieHein/Spelling-Wave-11

Spelling Fixes - Wave 11

Author: ttorble

articles/azure-signalr/howto-enable-geo-replication.md

@@ -35,7 +35,7 @@ However, managing multiple Azure SignalR Services brings some challenges:
 2. The development team would need to manage two separate Azure SignalR Services, each with distinct domain and connection string.
 3. If a regional outage happens, the traffic needs to be switched to another region.
 
-![Diagram of using two Azure SignalR instances to handle traffic from two countries. ](./media/howto-enable-geo-replication/signalr-multiple.png "Mutiple SignalR Example")
+![Diagram of using two Azure SignalR instances to handle traffic from two countries. ](./media/howto-enable-geo-replication/signalr-multiple.png "Multiple SignalR Example")
 
 ## Harnessing geo-replication
 With the new geo-replication feature, Contoso can now establish a replica in Canada Central, effectively overcoming the above-mentioned hurdles.

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

@@ -83,7 +83,7 @@ After you add a [system-assigned identity](#add-a-system-assigned-identity) or [
    - Application ID URI of the service principal.
 
    > [!IMPORTANT]
-   > Using empty resource actully acquire a token targets to Microsoft Graph. As today, Microsoft Graph enables token encryption so it's not available for application to authenticate the token other than Microsoft Graph. In common practice, you should always create a service principal to represent your upstream target. And set the **Application ID** or **Application ID URI** of the service principal you've created.
+   > Using empty resource actually acquire a token targets to Microsoft Graph. As today, Microsoft Graph enables token encryption so it's not available for application to authenticate the token other than Microsoft Graph. In common practice, you should always create a service principal to represent your upstream target. And set the **Application ID** or **Application ID URI** of the service principal you've created.
 
 #### Authentication in a function app
 

articles/azure-signalr/scripts/signalr-cli-create-with-app-service-github-oauth.md

@@ -28,7 +28,7 @@ This sample script creates a new Azure SignalR Service resource, which is used t
 
 ### Enable GitHub authentication and Git deployment for web app
 
-1. Update the values in the following script for the desired deployment username and its passwor
+1. Update the values in the following script for the desired deployment username and its password
 
    ```azurecli
    deploymentUser=<Replace with your desired username>

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

@@ -149,7 +149,7 @@ Let's reuse the chat app created in tutorial [Create a chat room with SignalR Se
     }
     ```
 
-    Inside the code, `AddAuthentication` and `UseAuthentication` are used to add authentication support with the GitHub OAuth app, and `GetUserCompanyInfoAsync` helper method is sample code showing how to load the company info from GitHub OAuth and save into user identity. You might also notice that `UseHttpsRedirection()` is used since GitHub OAuth set `secure` cookie that only passes through to secured `https` scheme. Also don't forget to update the local `Properties/lauchSettings.json` to add https endpoint:
+    Inside the code, `AddAuthentication` and `UseAuthentication` are used to add authentication support with the GitHub OAuth app, and `GetUserCompanyInfoAsync` helper method is sample code showing how to load the company info from GitHub OAuth and save into user identity. You might also notice that `UseHttpsRedirection()` is used since GitHub OAuth set `secure` cookie that only passes through to secured `https` scheme. Also don't forget to update the local `Properties/launchSettings.json` to add https endpoint:
 
     ```json
     {

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

@@ -54,7 +54,7 @@ Once you have SignalR service and app servers/Azure Functions created in each re
 
 ### Through config
 
-You should already know how to set SignalR service connection string through environment variables/app settings/web.cofig, in a config entry named `Azure:SignalR:ConnectionString`.
+You should already know how to set SignalR service connection string through environment variables/app settings/web.config, in a config entry named `Azure:SignalR:ConnectionString`.
 If you have multiple endpoints, you can set them in multiple config entries, each in the following format:
 
 ```

articles/azure-signalr/signalr-howto-configure-application-firewall.md

@@ -134,7 +134,7 @@ services.AddSignalR().AddAzureSignalR(options =>
             // The token name is not important. You could change it as you like.
             new Claim("uniqueToken", Guid.NewGuid().ToString()),
 
-            // Cutom claim: Used in ThrottleByJwtCustomClaimRule
+            // Custom claim: Used in ThrottleByJwtCustomClaimRule
             new Claim("<Custom Claim Name>", "<Custom Claim Value>"),
             // Custom claim example
             new Claim("freeUser", context.Request.Query["username"]),

articles/azure-signalr/signalr-howto-diagnostic-logs.md

@@ -174,7 +174,7 @@ Class Chat : Hub
     public void JoinAndSendGroup(string name, string groupName)
     {
         Groups.AddToGroupAsync(Context.ConnectionId, groupName); // join group
-        Clients.Group(groupName).SendAsync("ReveiceGroupMessage", name, "I'm in group"); // send group message
+        Clients.Group(groupName).SendAsync("ReceiveGroupMessage", name, "I'm in group"); // send group message
     }
 }
 ```

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

@@ -146,7 +146,7 @@ cd samples/Management
 
 # Start the negotiation server
 # Negotiation server is responsible for generating access token for clients
-cd NegotitationServer
+cd NegotiationServer
 dotnet user-secrets set Azure:SignalR:ConnectionString "<Connection String>"
 dotnet run
 

articles/azure-signalr/signalr-howto-troubleshoot-method.md

@@ -74,7 +74,7 @@ With the client-side network trace in hand, check which request fails with what
 
 SignalR *Server* maintains the *Server Connection* between *Server* and *Service*. When the app server starts, it starts the **WebSocket** connection to Azure SignalR service. All the client traffics are routed through Azure SignalR service to these *Server Connection*s and then dispatched to the `Hub`. When a *Server Connection* drops, the clients routed to this *Server Connection* will be impacted. Our Azure SignalR SDK has a logic "Always Retry" to reconnect the *Server Connection* with at most 1-minute delay to minimize the effects.
 
-*Server Connection*s can drop because of network instability or regular maintenance of Azure SignalR Service, or your hosted app server updates/maintainance. As long as client-side has the disconnect/reconnect mechanism, the effect is minimal like any client-side caused disconnect-reconnect.
+*Server Connection*s can drop because of network instability or regular maintenance of Azure SignalR Service, or your hosted app server updates/maintenance. As long as client-side has the disconnect/reconnect mechanism, the effect is minimal like any client-side caused disconnect-reconnect.
 
 View the server-side network trace to find the status code and error detail why *Server Connection* drops or is rejected by the *Service*. Look for the root cause inside [Troubleshooting Guide](./signalr-howto-troubleshoot-guide.md).
 

articles/azure-signalr/signalr-howto-work-with-apim.md

@@ -123,7 +123,7 @@ Now, the traffic can reach SignalR Service through API Management. Let’s use [
   ```bash
   cd samples/Chatroom
   dotnet restore
-  dotnet user-secrets set Azure:SignalR:ConnectionString "<copied-onnection-string-with-client-endpoint>"
+  dotnet user-secrets set Azure:SignalR:ConnectionString "<copied-connection-string-with-client-endpoint>"
   dotnet run
   ```