Merge pull request #272339 from MicrosoftDocs/main

4/16 OOB Publish

Author: huypub

articles/app-service/app-service-configuration-references.md

@@ -83,7 +83,10 @@ Alternatively without any `Label`:
 @Microsoft.AppConfiguration(Endpoint=https://myAppConfigStore.azconfig.io; Key=myAppConfigKey)​
 ```
 
-Any configuration change to the app that results in a site restart causes an immediate refetch of all referenced key-values from the App Configuration store.
+Any configuration change to the app that results in a site restart causes an immediate re-fetch of all referenced key-values from the App Configuration store.
+
+> [!NOTE]
+> Automatic refresh/re-fetch of these values when the key-values have been updated in App Configuration, is not currently supported.
 
 ## Source Application Settings from App Config
 

articles/azure-resource-manager/bicep/deployment-stacks.md

@@ -3,7 +3,7 @@ title: Create & deploy deployment stacks in Bicep
 description: Describes how to create deployment stacks in Bicep.
 ms.topic: conceptual
 ms.custom: devx-track-azurecli, devx-track-azurepowershell, devx-track-bicep
-ms.date: 02/23/2024
+ms.date: 04/11/2024
 ---
 
 # Deployment stacks (Preview)
@@ -33,6 +33,7 @@ Deployment stacks provide the following benefits:
 
 - Implicitly created resources aren't managed by the stack. Therefore, no deny assignments or cleanup is possible.
 - Deny assignments don't support tags.
+- Deny assignments is not supported within the management group scope.
 - Deployment stacks cannot delete Key vault secrets. If you're removing key vault secrets from a template, make sure to also execute the deployment stack update/delete command with detach mode.
 
 ### Known issues

articles/cost-management-billing/automate/automation-ingest-usage-details-overview.md

@@ -52,7 +52,7 @@ Azure resource providers emit usage and charges to the billing system and popula
 The cost details file exposes multiple price points. They're outlined as follows.
 
 **PAYGPrice:** It's the market price, also referred to as retail or list price, for a given product or service.
-  - In all consumption usage records, `UnitPrice` reflects the market price of the meter, regardless of the benefit plan such as reservations or savings plan.
+  - In all consumption usage records, `PayGPrice` reflects the market price of the meter, regardless of the benefit plan such as reservations or savings plan.
   - Purchases and refunds have the market price for that transaction.
 
 When you deal with benefit-related records, where the `PricingModel` is `Reservations` or `SavingsPlan`, *PayGPrice* reflects the market price of the meter.

articles/cost-management-billing/manage/create-enterprise-subscription.md

@@ -7,7 +7,7 @@ ms.reviewer: amberb
 ms.service: cost-management-billing
 ms.subservice: billing
 ms.topic: conceptual
-ms.date: 04/02/2024
+ms.date: 04/16/2024
 ms.author: banders
 ---
 
@@ -58,6 +58,41 @@ A user with Enterprise Administrator or Account Owner permissions can use the fo
 
 After the new subscription is created, the account owner can see it in on the **Subscriptions** page.
 
+## View the new subscription
+
+When you created the subscription, Azure created a notification stating **Successfully created the subscription**. The notification also had a link to **Go to subscription**, which allows you to view the new subscription. If you missed the notification, you can view select the bell symbol in the upper-right corner of the portal to view the notification that has the link to **Go to subscription**. Select the link to view the new subscription.
+
+Here's an example of the notification:
+
+:::image type="content" source="./media/create-enterprise-subscription/subscription-create-notification.png" alt-text="Screenshot showing the Successfully created the subscription notification." lightbox="./media/create-enterprise-subscription/subscription-create-notification.png" :::
+
+Or, if you're already on the Subscriptions page, you can refresh your browser's view to see the new subscription.
+
+## Create subscription in other tenant and view transfer requests
+
+A user with the following permission can create subscriptions in their customer's directory if they're allowed or exempted with subscription policy. For more information, see [Setting subscription policy](manage-azure-subscription-policy.md#setting-subscription-policy).
+
+- Enterprise Administrator
+- Account Owner
+
+When you try to create a subscription for someone in a directory outside of the current directory (such as a customer's tenant), a _subscription creation request_ is created. You specify the subscription directory and subscription owner details on the Advanced tab when creating the subscription. The subscription owner must accept the subscription ownership request before the subscription is created. The subscription owner is the customer in the target tenant where the subscription is being provisioned.
+
+:::image type="content" source="./media/create-enterprise-subscription/create-subscription-other-directory.png" alt-text="Screenshot showing Create a subscription outside the current directory." lightbox="./media/create-enterprise-subscription/create-subscription-other-directory.png" :::
+
+When the request is created, the subscription owner (the customer) is sent an email letting them know that they need to accept subscription ownership. The email contains a link used to accept ownership in the Azure portal. The customer must accept the request within seven days. If not accepted within seven days, the request expires. The person that created the request can also manually send their customer the ownership URL to accept the subscription.
+
+After the request is created, it's visible in the Azure portal at **Subscriptions** > **View Requests** by the following people:
+
+- The tenant global administrator of the source tenant where the subscription provisioning request is made.
+- The user who made the subscription creation request for the subscription being provisioned in the other tenant.
+- The user who made the request to provision the subscription in a different tenant than where they make the [Subscription – Alias REST API](/rest/api/subscription/) call instead of the Azure portal.
+
+The subscription owner in the request who resides in the target tenant doesn't see this subscription creation request on the View requests page. Instead, they receive an email with the link to accept ownership of the subscription in the target tenant.
+
+:::image type="content" source="./media/create-enterprise-subscription/view-requests.png" alt-text="Screenshot showing View Requests page that lists all subscription creation requests." lightbox="./media/create-enterprise-subscription/view-requests.png" :::
+
+Anyone with access to view the request can view its details. In the request details, the **Accept ownership URL** is visible. You can copy it to manually share it with the subscription owner in the target tenant for subscription ownership acceptance.
+
 ## Can't view subscription
 
 If you created a subscription but can't find it in the Subscriptions list view, a view filter might be applied.

articles/cost-management-billing/manage/media/create-enterprise-subscription/create-subscription-other-directory.png

@@ -19,17 +19,17 @@ In Azure Deployment Environments, you can use a [catalog](concept-environments-k
 
 An environment definition is composed of least two files:
 
-- An [Azure Resource Manager template (ARM template)](../azure-resource-manager/templates/overview.md) in JSON file format. For example, *azuredeploy.json*.
+- A template from an IaC framework. For example:
+    - An Azure Resource Manager (ARM) template might use a file called *azuredeploy.json*.
+    - A Bicep template might use a file called *azuredeploy.bicep*.
+    - A Terraform template might use a file called *azuredeploy.tf*, or *azuredeploy.tf.json*.
 - A configuration file that provides metadata about the template. This file should be named *environment.yaml*.
 
->[!NOTE]
-> Azure Deployment Environments currently supports only ARM templates.
-
 Your development teams use the environment definitions that you provide in the catalog to deploy environments in Azure.
 
 Microsoft offers a [sample catalog](https://aka.ms/deployment-environments/SampleCatalog) that you can use as your repository. You can also use your own private repository, or you can fork and customize the environment definitions in the sample catalog.
 
-After you [add a catalog](how-to-configure-catalog.md) to your dev center, the service scans the specified folder path to identify folders that contain an ARM template and an associated environment file. The specified folder path should be a folder that contains subfolders that hold the environment definition files.
+After you [add a catalog](how-to-configure-catalog.md) to your dev center, the service scans the specified folder path to identify folders that contain a template and an associated environment file. The specified folder path should be a folder that contains subfolders that hold the environment definition files.
 
 In this article, you learn how to:
 
@@ -51,20 +51,13 @@ To add an environment definition:
 
 1. Add two files to the new repository subfolder:
 
-   - An ARM template as a JSON file.
-
-      To implement IaC for your Azure solutions, use ARM templates. [ARM templates](../azure-resource-manager/templates/overview.md) help you define the infrastructure and configuration of your Azure solution and repeatedly deploy it in a consistent state.
-
-      To learn how to get started with ARM templates, see the following articles:
-
-      - [Understand the structure and syntax of ARM templates](../azure-resource-manager/templates/syntax.md): Describes the structure of an ARM template and the properties that are available in the different sections of a template.
-      - [Use linked templates](../azure-resource-manager/templates/linked-templates.md?tabs=azure-powershell#use-relative-path-for-linked-templates): Describes how to use linked templates with the new ARM template `relativePath` property to easily modularize your templates and share core components between environment definitions.
+   - An IaC template file.
 
    - An environment as a YAML file.
 
-      The *environment.yaml* file contains metadata related to the ARM template.
+      The *environment.yaml* file contains metadata related to the IaC template.
 
-       The following script is an example of the contents of an *environment.yaml* file:
+       The following script is an example of the contents of an *environment.yaml* file for an ARM template:
 
        ```yaml
            name: WebApp
@@ -73,10 +66,18 @@ To add an environment definition:
            description: Deploys a web app in Azure without a datastore
            runner: ARM
            templatePath: azuredeploy.json
-        ```  
-  
-       > [!NOTE]
-       > The `version` field is optional. Later, the field will be used to support multiple versions of environment definitions.
+       ```  
+
+      Use the following table to understand the fields in the *environment.yaml* file:
+
+      | Field | Description |
+      |-------|-------------|
+      | name | The name of the environment definition. |
+      | version | The version of the environment definition. This field is optional. |
+      | summary | A brief description of the environment definition. |
+      | description | A detailed description of the environment definition. |
+      | runner | The IaC framework that the template uses. The value can be `ARM` or `Bicep`. You can also specify a path to a template stored in a container registry. |
+      | templatePath | The path to the IaC template file. |
 
       To learn more about the options and data types you can use in *environment.yaml*, see [Parameters and data types in environment.yaml](concept-environment-yaml.md#what-is-environmentyaml).
 
@@ -86,16 +87,20 @@ To add an environment definition:
 
 The service scans the repository to find new environment definitions. After you sync the repository, new environment definitions are available to all projects in the dev center.
 
-### Specify an ARM or Bicep runner for a custom image
+### Specify a Terraform image
 
-The ADE extensibility model enables you to reference your own container image and execute deployments. You can store your container image in a container repository and directly reference it by providing the URI. 
+The ADE extensibility model enables you to use your own custom container image to deploy your preferred choice of IaC framework. You can build and use your own container image to execute deployments using Terraform. Learn how to [Configure a container image to execute deployments with Terraform](https://aka.ms/deployment-environments/container-image-terraform).
 
-The following example shows how to reference a custom image in an environment definition:
+When creating environment definitions that use a custom image in their deployment, the runner property provides a link to a container registry where this container image is stored.
+
+The runner property specifies the location of the image you want to use. When you're using a Terraform image from a container registry, edit the runner property to specify the location that image, as shown in the following example:
 
 ```yaml
 runner: "{YOUR_REGISTRY}.azurecr.io/{YOUR_REPOSITORY}:{YOUR_TAG}"
 ```
 
+### Specify an ARM or Bicep image
+
 The ADE team provides sample ARM and Bicep templates accessible through the Microsoft Artifact registry (also known as the Microsoft Container Registry) to help you get started. When you perform deployments by using ARM or Bicep, you can use the standard image that is published on [Microsoft Artifact Registry](https://mcr.microsoft.com/) (previously known as the Microsoft Container Registry).
 
 To use the sample image published on the Microsoft Artifact Registry, use the respective identifiers `runner: ARM` for ARM and `runner:Bicep` for Bicep deployments.
@@ -109,7 +114,7 @@ You can specify parameters for your environment definitions to allow developers
 
 Parameters are defined in the *environment.yaml* file. 
 
-The following script is an example of an *environment.yaml* file that includes two parameters; `location` and `name`: 
+The following script is an example of an *environment.yaml* file for an ARM template that includes two parameters; `location` and `name`: 
 
 ```YAML
 name: WebApp
@@ -136,7 +141,7 @@ To learn more about the parameters and their data types that you can use in *env
 
 Developers can supply values for specific parameters for their environments through the [developer portal](https://devportal.microsoft.com).
 
-:::image type="content" source="media/configure-environment-definition/parameters.png" alt-text="Screenshot of the developer portal showing the parameters pane." lightbox="media/configure-environment-definition/parameters.png":::
+:::image type="content" source="media/configure-environment-definition/parameters.png" alt-text="Screenshot of the developer portal of the developer portal showing the parameters pane." lightbox="media/configure-environment-definition/parameters.png":::
 
 Developers can also supply values for specific parameters for their environments through the CLI.
 
@@ -159,13 +164,13 @@ To learn more about the `az devcenter dev environment create` command, see the [
 
 ## Update an environment definition
 
-To modify the configuration of Azure resources in an existing environment definition in Azure Deployment Environments, update the associated ARM template JSON file in the repository. The change is immediately reflected when you create a new environment by using the specific environment definition. The update also is applied when you redeploy an environment associated with that environment definition.
+To modify the configuration of Azure resources in an existing environment definition in Azure Deployment Environments, update the associated template  file in the repository. The change is immediately reflected when you create a new environment by using the specific environment definition. The update also is applied when you redeploy an environment associated with that environment definition.
 
-To update any metadata related to the ARM template, modify *environment.yaml*, and then [update the catalog](how-to-configure-catalog.md#update-a-catalog).
+To update any metadata related to the template, modify *environment.yaml*, and then [update the catalog](how-to-configure-catalog.md#update-a-catalog).
 
 ## Delete an environment definition
 
-To delete an existing environment definition, in the repository, delete the subfolder that contains the ARM template JSON file and the associated environment YAML file. Then, [update the catalog](how-to-configure-catalog.md#update-a-catalog).
+To delete an existing environment definition, in the repository, delete the subfolder that contains the template file and the associated environment YAML file. Then, [update the catalog](how-to-configure-catalog.md#update-a-catalog).
 
 After you delete an environment definition, development teams can no longer use the specific environment definition to deploy a new environment. Update the environment definition reference for any existing environments that use the deleted environment definition. If the reference isn't updated and the environment is redeployed, the deployment fails.