Merge pull request #215363 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)

Author: huypub

articles/active-directory-b2c/force-password-reset.md

@@ -9,9 +9,10 @@ manager: CelesteDG
 ms.service: active-directory
 ms.workload: identity
 ms.topic: how-to
-ms.date: 08/04/2022
+ms.date: 10/06/2022
 ms.author: kengaderdus
 ms.subservice: B2C
+ms.custom: b2c-support
 zone_pivot_groups: b2c-policy-type
 ---
 
@@ -132,6 +133,9 @@ Content-type: application/json
 
 If you disabled the strong [password complexity](password-complexity.md), update the password policy to [DisableStrongPassword](user-profile-attributes.md#password-policy-attribute):
 
+> [!NOTE]
+> After the user resets their password, the passwordPolicies will be changed back to DisablePasswordExpiration
+
 ```http
 PATCH https://graph.microsoft.com/v1.0/users/<user-object-ID>
 Content-type: application/json

articles/aks/configure-azure-cni.md

@@ -145,7 +145,7 @@ The following screenshot from the Azure portal shows an example of configuring t
 
 ## Dynamic allocation of IPs and enhanced subnet support
 
-A drawback with the traditional CNI is the exhaustion of pod IP addresses as the AKS cluster grows, resulting in the need to rebuild the entire cluster in a bigger subnet. The new dynamic IP allocation capability in Azure CNI solves this problem by allotting pod IPs from a subnet separate from the subnet hosting the AKS cluster. It offers the following benefits:
+A drawback with the traditional CNI is the exhaustion of pod IP addresses as the AKS cluster grows, resulting in the need to rebuild the entire cluster in a bigger subnet. The new dynamic IP allocation capability in Azure CNI solves this problem by allocating pod IPs from a subnet separate from the subnet hosting the AKS cluster. It offers the following benefits:
 
 * **Better IP utilization**: IPs are dynamically allocated to cluster Pods from the Pod subnet. This leads to better utilization of IPs in the cluster compared to the traditional CNI solution, which does static allocation of IPs for every node.  
 

articles/azure-monitor/essentials/metrics-supported.md

@@ -2712,7 +2712,7 @@ This latest update adds a new column and reorders the metrics to be alphabetical
 
 |Metric|Exportable via Diagnostic Settings?|Metric Display Name|Unit|Aggregation Type|Description|Dimensions|
 |---|---|---|---|---|---|---|
-|PEBytesIn|Yes|Bytes In|Count|Total|Total number of Bytes Out|No Dimensions|
+|PEBytesIn|Yes|Bytes In|Count|Total|Total number of Bytes In |No Dimensions|
 |PEBytesOut|Yes|Bytes Out|Count|Total|Total number of Bytes Out|No Dimensions|
 
 

articles/container-registry/container-registry-tutorial-sign-build-push.md

@@ -33,18 +33,18 @@ In this tutorial:
 > [!NOTE]
 > The tutorial uses early released versions of notation and notation plugins.  
 
-1. Install notation with plugin support from the [release version](https://github.com/notaryproject/notation/releases/)
+1. Install notation 0.11.0-alpha.4 with plugin support on a Linux environment. You can also download the package for other environments from the [release page](https://github.com/notaryproject/notation/releases/tag/v0.11.0-alpha.4).
 
     ```bash
     # Download, extract and install
-    curl -Lo notation.tar.gz https://github.com/notaryproject/notation/releases/download/v0.9.0-alpha.1/notation_0.9.0-alpha.1_linux_amd64.tar.gz
+    curl -Lo notation.tar.gz https://github.com/notaryproject/notation/releases/download/v0.11.0-alpha.4/notation_0.11.0-alpha.4_linux_amd64.tar.gz
     tar xvzf notation.tar.gz
 
     # Copy the notation cli to the desired bin directory in your PATH
     cp ./notation /usr/local/bin
     ```
 
-2. Install the notation Azure Key Vault plugin for remote signing and verification
+2. Install the notation Azure Key Vault plugin for remote signing and verification.
 
     > [!NOTE]
     > The plugin directory varies depending upon the operating system being used.  The directory path below assumes Ubuntu.
@@ -56,13 +56,13 @@ In this tutorial:
     
     # Download the plugin
     curl -Lo notation-azure-kv.tar.gz \
-        https://github.com/Azure/notation-azure-kv/releases/download/v0.3.1-alpha.1/notation-azure-kv_0.3.1-alpha.1_Linux_amd64.tar.gz
+        https://github.com/Azure/notation-azure-kv/releases/download/v0.4.0-alpha.4/notation-azure-kv_0.4.0-alpha.4_Linux_amd64.tar.gz
     
     # Extract to the plugin directory
     tar xvzf notation-azure-kv.tar.gz -C ~/.config/notation/plugins/azure-kv notation-azure-kv
     ```
 
-3. List the available plugins and verify that the plugin is available
+3. List the available plugins and verify that the plugin is available.
 
     ```bash
     notation plugin ls
@@ -73,7 +73,7 @@ In this tutorial:
 > [!NOTE]
 > For easy execution of commands in the tutorial, provide values for the Azure resources to match the existing ACR and AKV resources.
 
-1. Configure AKV resource names
+1. Configure AKV resource names.
 
     ```bash
     # Name of the existing Azure Key Vault used to store the signing keys
@@ -84,7 +84,7 @@ In this tutorial:
     CERT_PATH=./${KEY_NAME}.pem
     ```
 
-2. Configure ACR and image resource names
+2. Configure ACR and image resource names.
 
     ```bash
     # Name of the existing registry example: myregistry.azurecr.io
@@ -106,7 +106,7 @@ Otherwise create an x509 self-signed certificate storing it in AKV for remote si
 
 ### Create a self-signed certificate (Azure CLI)
 
-1. Create a certificate policy file
+1. Create a certificate policy file.
 
     Once the certificate policy file is executed as below, it creates a valid signing certificate compatible with **notation** in AKV. The EKU listed is for code-signing, but isn't required for notation to sign artifacts.
 
@@ -128,32 +128,32 @@ Otherwise create an x509 self-signed certificate storing it in AKV for remote si
     EOF
     ```
 
-1. Create the certificate
+1. Create the certificate.
 
     ```azure-cli
     az keyvault certificate create -n $KEY_NAME --vault-name $AKV_NAME -p @my_policy.json
     ```
 
-1. Get the Key ID for the certificate
+1. Get the Key ID for the certificate.
 
     ```bash
     KEY_ID=$(az keyvault certificate show -n $KEY_NAME --vault-name $AKV_NAME --query 'kid' -o tsv)
     ```
-4. Download public certificate
+4. Download public certificate.
 
     ```bash
     CERT_ID=$(az keyvault certificate show -n $KEY_NAME --vault-name $AKV_NAME --query 'id' -o tsv)
     az keyvault certificate download --file $CERT_PATH --id $CERT_ID --encoding PEM
     ```
 
-5. Add the Key ID to the keys and certs
+5. Add the Key ID to the keys and certs.
 
     ```bash
     notation key add --name $KEY_NAME --plugin azure-kv --id $KEY_ID
     notation cert add --name $KEY_NAME $CERT_PATH
     ```
 
-6. List the keys and certs to confirm
+6. List the keys and certs to confirm.
 
     ```bash
     notation key ls
@@ -162,31 +162,39 @@ Otherwise create an x509 self-signed certificate storing it in AKV for remote si
 
 ## Build and sign a container image
 
-1. Build and push a new image with ACR Tasks
+1. Build and push a new image with ACR Tasks.
 
     ```azure-cli
     az acr build -r $ACR_NAME -t $IMAGE $IMAGE_SOURCE
     ```
 
-2. Authenticate with your individual Azure AD identity to use an ACR token
+2. Authenticate with your individual Azure AD identity to use an ACR token.
 
     ```azure-cli
     export USER_NAME="00000000-0000-0000-0000-000000000000"
     export PASSWORD=$(az acr login --name $ACR_NAME --expose-token --output tsv --query accessToken)
     export NOTATION_PASSWORD=$PASSWORD
     ```
 
-3. Sign the container image
+3. Choose [COSE](https://datatracker.ietf.org/doc/html/rfc8152) or JWS signature envelope to sign the container image.
 
+   - Sign the container image with the COSE signature envelope:
+ 
+    ```bash
+    notation sign --envelope-type cose --key $KEY_NAME $IMAGE
+    ```
+    
+   - Sign the container image with the default JWS signature envelope:
+   
     ```bash
     notation sign --key $KEY_NAME $IMAGE
     ```
-
+    
 ## View the graph of artifacts with the ORAS CLI
 
-ACR support for ORAS artifacts enables a linked graph of supply chain artifacts that can be viewed through the ORAS CLI or the Azure CLI
+ACR support for ORAS artifacts enables a linked graph of supply chain artifacts that can be viewed through the ORAS CLI or the Azure CLI.
 
-1. Signed images can be view with the ORAS CLI
+1. Signed images can be view with the ORAS CLI.
 
     ```bash
     oras login -u $USER_NAME -p $PASSWORD $REGISTRY
@@ -195,7 +203,7 @@ ACR support for ORAS artifacts enables a linked graph of supply chain artifacts
 
 ## View the graph of artifacts with the Azure CLI
 
-1. List the manifest details for the container image
+1. List the manifest details for the container image.
 
     ```azure-cli
     az acr manifest show-metadata $IMAGE -o jsonc
@@ -248,4 +256,4 @@ notation verify $IMAGE
 
 ## Next steps
 
-[Enforce policy to only deploy signed container images to Azure Kubernetes Service (AKS) utilizing **ratify** and **gatekeeper**.](https://github.com/Azure/notation-azure-kv/blob/main/docs/nv2-sign-verify-aks.md)
+See [Enforce policy to only deploy signed container images to Azure Kubernetes Service (AKS) utilizing **ratify** and **gatekeeper**.](https://github.com/Azure/notation-azure-kv/blob/main/docs/nv2-sign-verify-aks.md)

articles/virtual-wan/how-to-routing-policies.md

@@ -36,7 +36,7 @@ While Private Traffic  includes both branch and Virtual Network address prefixes
 
 * **Internet Traffic Routing Policy**:  When an Internet Traffic Routing Policy is configured on a Virtual WAN hub, all branch (User VPN (Point-to-site VPN), Site-to-site VPN, and ExpressRoute) and Virtual Network connections to that Virtual WAN Hub will forward Internet-bound traffic to the Azure Firewall resource, Third-Party Security provider or **Network Virtual Appliance** specified as part of the Routing Policy.
 
-    In other words, when Traffic Routing Policy is configured on a Virtual WAN hub, the Virtual WAN will advertise a **default** route to all spokes, Gateways and Network Virtual Appliances (deployed in the hub or spoke). This includes the **Network Virtual Appliance** that is the next hop for the Itnernet Traffic routing policy.
+    In other words, when Traffic Routing Policy is configured on a Virtual WAN hub, the Virtual WAN will advertise a **default** route to all spokes, Gateways and Network Virtual Appliances (deployed in the hub or spoke). This includes the **Network Virtual Appliance** that is the next hop for the Internet Traffic routing policy.
 
 * **Private Traffic Routing Policy**: When a Private Traffic Routing Policy is configured on a Virtual WAN hub, **all** branch and Virtual Network traffic in and out of the Virtual WAN Hub including inter-hub traffic will be forwarded to the Next Hop Azure Firewall resource or Network Virtual Appliance resource that was specified in the Private Traffic Routing Policy.