Merge branch 'main' into release-scommi

Author: v-alje

.openpublishing.redirection.azure-resource-manager.json

@@ -1920,6 +1920,11 @@
           "redirect_url": "/azure/azure-resource-manager/managed-applications/overview",
           "redirect_document_id": false
         },
+        {
+          "source_path_from_root": "/articles/azure-resource-manager/managed-applications/deploy-marketplace-app-quickstart.md",
+          "redirect_url": "/azure/azure-resource-manager/managed-applications/deploy-service-catalog-quickstart",
+          "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/resource-manager-policy.md",
             "redirect_url": "/azure/governance/policy/overview",

articles/aks/howto-deploy-java-liberty-app.md

@@ -5,13 +5,13 @@ description: Deploy a Java application with Open Liberty or WebSphere Liberty on
 author: KarlErickson
 ms.author: edburns
 ms.topic: how-to
-ms.date: 04/02/2024
+ms.date: 05/29/2024
 ms.subservice: aks-developer
 keywords: java, jakartaee, javaee, microprofile, open-liberty, websphere-liberty, aks, kubernetes
 ms.custom: devx-track-java, devx-track-javaee, devx-track-javaee-liberty, devx-track-javaee-liberty-aks, devx-track-javaee-websphere, build-2023, devx-track-extended-java, devx-track-azurecli
 ---
 
-# Deploy a Java application with Open Liberty or WebSphere Liberty on an Azure Kubernetes Service cluster
+# Deploy a Java application with Open Liberty or WebSphere Liberty on an Azure Kubernetes Service (AKS) cluster
 
 This article demonstrates how to:
 
@@ -41,7 +41,7 @@ This article is intended to help you quickly get to deployment. Before you go to
 * Sign in to the Azure CLI by using the [az login](/cli/azure/reference-index#az-login) command. To finish the authentication process, follow the steps displayed in your terminal. For other sign-in options, see [Sign in with the Azure CLI](/cli/azure/authenticate-azure-cli).
 * When you're prompted, install the Azure CLI extension on first use. For more information about extensions, see [Use extensions with the Azure CLI](/cli/azure/azure-cli-extensions-overview).
 * Run [az version](/cli/azure/reference-index?#az-version) to find the version and dependent libraries that are installed. To upgrade to the latest version, run [az upgrade](/cli/azure/reference-index?#az-upgrade). This article requires at least version 2.31.0 of Azure CLI.
-* Install a Java SE implementation, version 17 or later. (for example, [Eclipse Open J9](https://www.eclipse.org/openj9/)).
+* Install a Java Standard Edition (SE) implementation, version 17 or later (for example, [Eclipse Open J9](https://www.eclipse.org/openj9/)).
 * Install [Maven](https://maven.apache.org/download.cgi) 3.5.0 or higher.
 * Install [Docker](https://docs.docker.com/get-docker/) for your OS.
 * Ensure [Git](https://git-scm.com) is installed.
@@ -145,7 +145,7 @@ If you moved away from the **Deployment is in progress** pane, the following ste
 
     ---
 
-You'll use these values later in this article. Note that the outputs list several other useful commands.
+You use these values later in this article. The outputs list several other useful commands.
 
 ## Create an Azure SQL Database instance
 
@@ -167,7 +167,7 @@ $Env:DB_RESOURCE_GROUP_NAME="<db-resource-group>"
 
 ---
 
-Now that you've created the database and AKS cluster, you can proceed to preparing AKS to host your Open Liberty application.
+Now that you created the database and AKS cluster, you can proceed to preparing AKS to host your Open Liberty application.
 
 ## Configure and deploy the sample application
 

articles/aks/workload-identity-deploy-cluster.md

@@ -44,7 +44,7 @@ az account set --subscription <subscription-id>
 
 To help simplify steps to configure the identities required, the steps below define environment variables that are referenced in the examples in this article. Remember to replace the values shown with your own values:
 
-  ```bash
+  ```azurecli-interactive
   export RESOURCE_GROUP="myResourceGroup"
   export LOCATION="eastus"
   export CLUSTER_NAME="myAKSCluster"
@@ -117,7 +117,7 @@ az aks update \
 
 To get the OIDC issuer URL and save it to an environmental variable, run the following command:
 
-```bash
+```azurecli-interactive
 export AKS_OIDC_ISSUER="$(az aks show --name "${CLUSTER_NAME}" \
     --resource-group "${RESOURCE_GROUP}" \
     --query "oidcIssuerProfile.issuerUrl" \
@@ -146,7 +146,7 @@ az identity create \
 
 Next, create a variable for the managed identity's client ID.
 
-```bash
+```azurecli-interactive
 export USER_ASSIGNED_CLIENT_ID="$(az identity show \
     --resource-group "${RESOURCE_GROUP}" \
     --name "${USER_ASSIGNED_IDENTITY_NAME}" \
@@ -164,7 +164,7 @@ az aks get-credentials --name "${CLUSTER_NAME}" --resource-group "${RESOURCE_GRO
 
 Copy and paste the following multi-line input in the Azure CLI.
 
-```bash
+```azurecli-interactive
 cat <<EOF | kubectl apply -f -
 apiVersion: v1
 kind: ServiceAccount
@@ -321,8 +321,8 @@ The following example shows how to use the Azure role-based access control (Azur
 
 To check whether all properties are injected properly by the webhook, use the [kubectl describe][kubectl-describe] command:
 
-```bash
-kubectl describe pod quick-start | grep "SECRET_NAME:"
+```azurecli-interactive
+kubectl describe pod sample-workload-identity-key-vault | grep "SECRET_NAME:"
 ```
 
 If successful, the output should be similar to the following:
@@ -333,8 +333,8 @@ If successful, the output should be similar to the following:
 
 To verify that pod is able to get a token and access the resource, use the kubectl logs command:
 
-```bash
-kubectl logs quick-start
+```azurecli-interactive
+kubectl logs sample-workload-identity-key-vault
 ```
 
 If successful, the output should be similar to the following:

articles/api-management/api-management-howto-deploy-multi-region.md

@@ -164,7 +164,7 @@ This section provides considerations for multi-region deployments when the API M
 * Configure each regional network independently. The [connectivity requirements](virtual-network-reference.md) such as required network security group rules for a virtual network in an added region are generally the same as those for a network in the primary region.
 * Virtual networks in the different regions don't need to be peered.
 > [!IMPORTANT]
-> When configured in internal VNet mode, each regional gateway must also have outbound connectivity on port 1443 to the Azure SQL database configured for your API Management instance, which is only in the *primary* region. Ensure that you allow connectivity to the FQDN or IP address of this Azure SQL database in any routes or firewall rules you configure for networks in your secondary regions; the Azure SQL service tag can't be used in this scenario. To find the Azure SQL database name in the primary region, go to the **Network** > **Network status** page of your API Management instance in the portal. 
+> When configured in internal VNet mode, each regional gateway must also have outbound connectivity on port 1433 to the Azure SQL database configured for your API Management instance, which is only in the *primary* region. Ensure that you allow connectivity to the FQDN or IP address of this Azure SQL database in any routes or firewall rules you configure for networks in your secondary regions; the Azure SQL service tag can't be used in this scenario. To find the Azure SQL database name in the primary region, go to the **Network** > **Network status** page of your API Management instance in the portal. 
 
 ### IP addresses
 

articles/api-management/azure-openai-emit-token-metric-policy.md

@@ -66,7 +66,7 @@ The `azure-openai-emit-token-metric` policy sends metrics to Application Insight
 * Product ID
 * User ID
 * Subscription ID
-* Location ID
+* Location
 * Gateway ID
 
 ## Usage

articles/api-management/emit-metric-policy.md

@@ -60,7 +60,7 @@ The `emit-metric` policy sends custom metrics in the specified format to Applica
 * Product ID
 * User ID
 * Subscription ID
-* Location ID
+* Location
 * Gateway ID
 
 ## Usage

articles/azure-app-configuration/concept-config-file.md

@@ -4,8 +4,8 @@ description: Tooling support for using configuration files with Azure App Config
 author: zhenlan
 ms.author: zhenlwa
 ms.service: azure-app-configuration
-ms.topic: conceptual
-ms.date: 10/28/2022
+ms.topic: concept
+ms.date: 05/30/2024
 ---
 
 # Azure App Configuration support for configuration files
@@ -102,9 +102,11 @@ The following example is a file based upon the KVSet file content profile, named
 
 > [!TIP]
 > If you followed the example in the previous section and have the data in your App Configuration store, you can export it to a file using the CLI command:
+
 > ```azurecli-interactive
 > az appconfig kv export --profile appconfig/kvset --label * --name <your store name> --destination file --path appconfigdata.json --format json 
 > ```
+
 > After the file is exported, update the `Beta` feature flag `enabled` property to `true` and change the `Logging:LogLevel:Default` to `Debug`.
 
 Run the following CLI command with the parameter "**--profile appconfig/kvset**" to import the file to your App Configuration store. You don't need to specify any data transformation rules such as separator, label, or content type like you did in the default file content profile section because all information is already in the file.

articles/azure-app-configuration/quickstart-bicep.md

@@ -4,7 +4,7 @@ titleSuffix: Azure App Configuration
 description: Learn how to create an Azure App Configuration store using Bicep.
 author: maud-lv
 ms.author: malev
-ms.date: 05/06/2022
+ms.date: 05/30/2024
 ms.service: azure-app-configuration
 ms.topic: quickstart
 ms.custom: subject-armqs, mode-arm, devx-track-bicep

articles/azure-cache-for-redis/cache-remove-tls-10-11.md

@@ -13,7 +13,7 @@ ms.devlang: csharp
 
 # Remove TLS 1.0 and 1.1 from use with Azure Cache for Redis
 
-To meet the industry-wide push toward the exclusive use of Transport Layer Security (TLS) version 1.2 or later, Azure Cache for Redis is moving toward requiring the use of the TLS 1.2 in November, 2024. TLS versions 1.0 and 1.1 are known to be susceptible to attacks such as BEAST and POODLE, and to have other Common Vulnerabilities and Exposures (CVE) weaknesses.
+To meet the industry-wide push toward the exclusive use of Transport Layer Security (TLS) version 1.2 or later, Azure Cache for Redis is moving toward requiring the use of the TLS 1.2 in November 2024. TLS versions 1.0 and 1.1 are known to be susceptible to attacks such as BEAST and POODLE, and to have other Common Vulnerabilities and Exposures (CVE) weaknesses.
 
 TLS versions 1.0 and 1.1 also don't support the modern encryption methods and cipher suites recommended by Payment Card Industry (PCI) compliance standards. This [TLS security blog](https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/) explains some of these vulnerabilities in more detail.
 
@@ -28,15 +28,15 @@ TLS versions 1.0 and 1.1 also don't support the modern encryption methods and ci
 
 As a part of this effort, you can expect the following changes to Azure Cache for Redis:
 
-- _Phase 1_: Azure Cache for Redis stops offering TLS 1.0/1.1 as an option for MinimumTLSVersion setting for new cache creates. Existing cache instances won't be updated at this point. You can still use the Azure portal or other management APIs to [change the minimum TLS version](cache-configure.md#access-ports) to 1.0 or 1.1 for backward compatibility.
-- _Phase 2_: Azure Cache for Redis stops supporting TLS 1.1 and TLS 1.0 starting November 1, 2024. After this change, your application must use TLS 1.2 or later to communicate with your cache. The Azure Cache for Redis service will be available while we update the MinimumTLSVerion for all caches to 1.2.
+- _Phase 1_: Azure Cache for Redis stops offering TLS 1.0/1.1 as an option for _MinimumTLSVersion_ setting for new cache creates. Existing cache instances won't be updated at this point. You can't set the _MinimiumTLSVersion_ to 1.0 or 1.1 for your existing cache.
+- _Phase 2_: Azure Cache for Redis stops supporting TLS 1.1 and TLS 1.0 starting November 1, 2024. After this change, your application must use TLS 1.2 or later to communicate with your cache. The Azure Cache for Redis service remains available while we update the _MinimumTLSVerion_ for all caches to 1.2.
 
-| Date    | Description |
-|-------- |-------------|
-| September 2023 | TLS 1.0/1.1 retirement announcement |
-| March 1, 2024 | Beginning March 1, 2024, you will not be able to create new caches with the Minimum TLS version set to 1.0 or 1.1 and you will not be able to set the Minimium TLS version to 1.0 or 1.1 for your existing cache. The Minimum TLS version won't be updated automatically for existing caches at this point.
-| October 31, 2024 | Ensure that all your applications are connecting to Azure Cache for Redis using TLS 1.2 and Minimum TLS version on your cache settings is set to 1.2
-| November 1, 2024 | Minimum TLS version for all cache instances is updated to 1.2. This means Azure Cache for Redis instances will reject connections using TLS 1.0 or 1.1.
+| Date             | Description                                                                                                                                                                                                                                                                    |
+| ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| September 2023   | TLS 1.0/1.1 retirement announcement                                                                                                                                                                                                                                            |
+| March 1, 2024    | Beginning March 1, 2024, you can't create new caches with the Minimum TLS version set to 1.0 or 1.1 and you can't set the _MinimumTLSVersion_ to 1.0 or 1.1 for your existing cache. The minimum TLS version won't be updated automatically for existing caches at this point. |
+| October 31, 2024 | Ensure that all your applications are connecting to Azure Cache for Redis using TLS 1.2 and Minimum TLS version on your cache settings is set to 1.2.                                                                                                                          |
+| November 1, 2024 | Minimum TLS version for all cache instances is updated to 1.2. This means Azure Cache for Redis instances reject connections using TLS 1.0 or 1.1 at this point.                                                                                                               |
 
   > [!IMPORTANT]
   > The content in this article does not apply to Azure Cache for Redis Enterprise/Enterprise Flash because the Enterprise tiers only support TLS 1.2.
@@ -72,7 +72,7 @@ Redis .NET clients use the earliest TLS version by default on .NET Framework 4.5
 
 Redis .NET Core clients default to the OS default TLS version, which depends on the OS itself.
 
-Depending on the OS version and any patches that have been applied, the effective default TLS version can vary. For more information, see [Transport Layer Security (TLS) best practices with the .NET Framework](/dotnet/framework/network-programming/tls).
+Depending on the OS version and any patches that were applied, the effective default TLS version can vary. For more information, see [Transport Layer Security (TLS) best practices with the .NET Framework](/dotnet/framework/network-programming/tls).
 
 However, if you're using an old OS or just want to be sure, we recommend configuring the preferred TLS version manually through the client.