Merge pull request #292391 from MicrosoftDocs/main

12/24 PM Publish

Author: Saisang

articles/active-directory-b2c/add-api-connector-token-enrichment.md

@@ -169,7 +169,7 @@ A claim provides temporary storage of data during an Azure AD B2C policy executi
 </ClaimType>
 ```
 ## Add the RESTful API technical profile 
-A [Restful technical profile](restful-technical-profile.md) provides support for interfacing with your own RESTful service. Azure AD B2C sends data to the RESTful service in an `InputClaims` collection and receives data back in an `OutputClaims` collection. Find the **ClaimsProviders** element in your <em>**`TrustFrameworkExtensions.xml`**</em> file and add a new claims provider as follows:
+A [RESTful technical profile](restful-technical-profile.md) provides support for interfacing with your own RESTful service. Azure AD B2C sends data to the RESTful service in an `InputClaims` collection and receives data back in an `OutputClaims` collection. Find the **ClaimsProviders** element in your <em>**`TrustFrameworkExtensions.xml`**</em> file and add a new claims provider as follows:
 ```xml
 <ClaimsProvider>
   <DisplayName>REST APIs</DisplayName>

articles/active-directory-b2c/add-api-connector.md

@@ -442,7 +442,7 @@ A claim provides temporary storage of data during an Azure AD B2C policy executi
 
 ## Add the RESTful API technical profile 
 
-A [Restful technical profile](restful-technical-profile.md) provides support for interfacing to your own RESTful service. Azure AD B2C sends data to the RESTful service in an `InputClaims` collection and receives data back in an `OutputClaims` collection. Find the **ClaimsProviders** element and add a new claims provider as follows:
+A [RESTful technical profile](restful-technical-profile.md) provides support for interfacing to your own RESTful service. Azure AD B2C sends data to the RESTful service in an `InputClaims` collection and receives data back in an `OutputClaims` collection. Find the **ClaimsProviders** element and add a new claims provider as follows:
 
 ```xml
 <ClaimsProvider>

articles/active-directory-b2c/custom-policy-reference-sso.md

@@ -291,7 +291,7 @@ To use the `SM-Saml-issuer` session management technical profile, add a referenc
 The `NoopSSOSessionProvider` session provider is used to suppress single sign on behavior. Technical profiles that use this type of session provider will always be processed, even when the user has an active session. This type of session provider can be useful to force particular technical profiles to always run, for example:
 
 - [Claims transformation](claims-transformation-technical-profile.md) - To create, or transform claims that are later used to determine which orchestration steps to process or skip.
-- [Restful](restful-technical-profile.md) - Fetch updated data from a Restful service each time the policy runs. You can also call a Restful for extended logging, and auditing.
+- [RESTful](restful-technical-profile.md) - Fetch updated data from a RESTful service each time the policy runs. You can also call a RESTful for extended logging, and auditing.
 - [Self-asserted](self-asserted-technical-profile.md) - Force the user to provide data each time the policy runs. For example, verify emails with one-time pass-code, or ask the user's consent.
 - [Phonefactor](phone-factor-technical-profile.md) - Force the user to perform multifactor authentication as part of a "step up authentication" even during subsequent logons (single sign-on).
 

articles/active-directory-b2c/identity-provider-google.md

@@ -51,7 +51,7 @@ To enable sign-in for users with a Google account in Azure Active Directory B2C
     1. In the **Authorized domains** section, enter *b2clogin.com*.
     1. In the **Developer contact information** section, enter comma separated emails for Google to notify you about any changes to your project. 
     1. Select **Save**.
-1. Select **Credentials** in the left menu, and then select **Create credentials** > **Oauth client ID**.
+1. Select **Credentials** in the left menu, and then select **Create credentials** > **OAuth client ID**.
 1. Under **Application type**, select **Web application**.
     1. Enter a **Name** for your application.
     1. For the **Authorized JavaScript origins**, enter `https://your-tenant-name.b2clogin.com`. If you use a [custom domain](custom-domain.md), enter `https://your-domain-name`.

articles/api-management/api-management-howto-integrate-internal-vnet-appgateway.md

@@ -61,7 +61,7 @@ In the first setup example, all your APIs are managed only from within your virt
 * **Back-end server pool**: This server pool is the internal virtual IP address of API Management.
 * **Back-end server pool settings**: Every pool has settings like port, protocol, and cookie-based affinity. These settings are applied to all servers within the pool.
 * **Front-end port**: This public port is opened on the application gateway. Traffic that hits it gets redirected to one of the back-end servers.
-* **Listener**: The listener has a front-end port, a protocol (Http or Https, these values are case sensitive), and the Transport Layer Security (TLS) certificate name (if configuring TLS offload).
+* **Listener**: The listener has a front-end port, a protocol (HTTP or HTTPS, these values are case sensitive), and the Transport Layer Security (TLS) certificate name (if configuring TLS offload).
 * **Rule**: The rule binds a listener to a back-end server pool.
 * **Custom health probe**: Application Gateway, by default, uses IP address-based probes to figure out which servers in `BackendAddressPool` are active. API Management only responds to requests with the correct host header, so the default probes fail. You define a custom health probe to help the application gateway determine that the service is alive and should forward requests.
 * **Custom domain certificates**: To access API Management from the internet, create Domain Name System (DNS) records to map its host names to the Application Gateway front-end IP address. This mapping ensures that the Host header and certificate sent to API Management are valid. In this example, we use three certificates. They're for API Management's gateway (the back end), the developer portal, and the management endpoint.

articles/app-service/app-service-web-nodejs-best-practices-and-troubleshoot-guide.md

@@ -249,7 +249,7 @@ The `cnodeconstants` [source file](https://github.com/Azure/iisnode/blob/master/
 
 Enable FREB for your application to see the win32 error code (be sure you enable FREB only on non-production sites for performance reasons).
 
-| Http Status | Http Substatus | Possible Reason? |
+| HTTP Status | HTTP Substatus | Possible Reason? |
 | --- | --- | --- |
 | 500 |1000 |There was some issue dispatching the request to IISNODE – Check if node.exe was started. Node.exe could have crashed when starting. Check your web.config configuration for errors. |
 | 500 |1001 |- Win32Error 0x2 - App is not responding to the URL. Check the URL rewrite rules or check if your express app has the correct routes defined. - Win32Error 0x6d – named pipe is busy – Node.exe is not accepting requests because the pipe is busy. Check high cpu usage. - Other errors – check if node.exe crashed. |

articles/app-service/web-sites-monitor.md

@@ -60,7 +60,7 @@ You can increase or remove quotas from your app by upgrading your App Service pl
 > [!NOTE]
 > Metrics for an app include the requests to the app's SCM site(Kudu).  This includes requests to view the site's logstream using Kudu.  Logstream requests may span several minutes, which will affect the Request Time metrics.  Users should be aware of this relationship when using these metrics with autoscale logic.
 > 
-> **Http Server Errors** only records requests that reach the backend service (the worker(s) hosting the app). If the requests are failing at the FrontEnd, they are not recorded as Http Server Errors. The [Health Check feature](./monitor-instances-health-check.md) / Application Insights availability tests can be used for outside in monitoring.
+> **HTTP Server Errors** only records requests that reach the backend service (the worker(s) hosting the app). If the requests are failing at the FrontEnd, they are not recorded as HTTP Server Errors. The [Health Check feature](./monitor-instances-health-check.md) / Application Insights availability tests can be used for outside in monitoring.
 
 Metrics provide information about the app or the App Service plan's behavior.
 

articles/application-gateway/application-gateway-ilb-arm.md

@@ -29,7 +29,7 @@ This article walks you through the steps to configure a Standard v1 Application
 * **Backend server pool:** The list of IP addresses of the backend servers. The IP addresses listed should either belong to the virtual network but in a different subnet for the application gateway or should be a public IP/VIP.
 * **Backend server pool settings:** Every pool has settings like port, protocol, and cookie-based affinity. These settings are tied to a pool and are applied to all servers within the pool.
 * **Frontend port:** This port is the public port that is opened on the application gateway. Traffic hits this port, and then gets redirected to one of the backend servers.
-* **Listener:** The listener has a frontend port, a protocol (Http or Https, these are case-sensitive), and the SSL certificate name (if configuring SSL offload).
+* **Listener:** The listener has a frontend port, a protocol (HTTP or HTTPS, these are case-sensitive), and the SSL certificate name (if configuring SSL offload).
 * **Rule:** The rule binds the listener and the backend server pool and defines which backend server pool the traffic should be directed to when it hits a particular listener. Currently, only the *basic* rule is supported. The *basic* rule is round-robin load distribution.
 
 ## Create an application gateway

articles/automation/troubleshoot/update-agent-issues.md

@@ -140,7 +140,7 @@ $endpoint = $jrdsEndpointLocationMoniker + “-jobruntimedata-prod-su1.azure-aut
 (Test-NetConnection -ComputerName $endpoint -Port 443 -WarningAction SilentlyContinue).TcpTestSucceeded  
 ```
 
-### Https connection
+### HTTPS connection
 Simplifies the ongoing management of your network security rules. Allow the [prerequisite URLs](../automation-network-configuration.md#update-management-and-change-tracking-and-inventory).
 
 After the network changes, you can either rerun the Troubleshooter or run the below commands to validate:
@@ -413,7 +413,7 @@ CheckResultMessageArguments :
 
 RuleId                      : HttpsConnection 
 RuleGroupId                 : connectivity 
-RuleName                    : Https connection 
+RuleName                    : HTTPS connection 
 RuleGroupName               : connectivity 
 RuleDescription             : Check if VM is able to make https requests. 
 CheckResult                 : Passed 

articles/databox-online/azure-stack-edge-troubleshoot-iot-edge.md

@@ -6,13 +6,11 @@ author: alkohli
 
 ms.service: azure-stack-edge
 ms.topic: troubleshooting
-ms.date: 02/27/2024
+ms.date: 12/24/2024
 ms.author: alkohli
 ---
 # Troubleshoot IoT Edge issues on your Azure Stack Edge FPGA device 
 
-[!INCLUDE [applies-to-GPU-and-pro-r-and-mini-r-skus](../../includes/azure-stack-edge-applies-to-gpu-pro-r-mini-r-sku.md)]
-
 [!INCLUDE [Azure Stack Edge Pro FPGA end-of-life](../../includes/azure-stack-edge-fpga-eol.md)]
 
 This article describes how to troubleshoot compute-related errors on an Azure Stack Edge FPGA device by reviewing IoT Edge agent runtime responses.  
@@ -25,4 +23,4 @@ This article describes how to troubleshoot compute-related errors on an Azure St
 ## Next steps
 
 - [Debug Kubernetes issues related to IoT Edge](azure-stack-edge-gpu-connect-powershell-interface.md#debug-kubernetes-issues-related-to-iot-edge).<!--Update list for FPGA.-->
-- [Troubleshoot device issues](azure-stack-edge-gpu-troubleshoot.md).
+- [Troubleshoot device issues](azure-stack-edge-gpu-troubleshoot.md).