Merge pull request #174683 from MicrosoftDocs/master

10/05 PM Publish

Author: huypub

articles/active-directory-b2c/claimstransformations.md

@@ -111,7 +111,7 @@ The **OutputClaim** element contains the following attributes:
 | ClaimTypeReferenceId | Yes | A reference to a ClaimType already defined in the ClaimsSchema section in the policy.
 | TransformationClaimType | Yes | An identifier to reference a transformation claim type. Each claim transformation has its own values. See the [claims transformation reference](#claims-transformations-reference) for a complete list of the available values. |
 
-If input claim and the output claim are the same type (string, or boolean), you can use the same input claim as the output claim. In this case, the claims transformation changes the input claim with the output value.
+Input and output claims used in claims transformation need to be distinct. The same input claim cannot be used as the output claim.
 
 ## Example
 

articles/active-directory-b2c/embedded-login.md

@@ -28,7 +28,7 @@ zone_pivot_groups: b2c-policy-type
 
 ::: zone pivot="b2c-custom-policy"
 
-For a simpler sing-up or sign-in experience, you can avoid redirecting users to a separate sing-up or sign-in page, or generating a pop-up window. By using the inline frame <iframe> HTML element, you can embed the Azure AD B2C sign-in user interface directly into your web application. 
+For a simpler sign-up or sign-in experience, you can avoid redirecting users to a separate sign-up or sign-in page, or generating a pop-up window. By using the inline frame <iframe> HTML element, you can embed the Azure AD B2C sign-in user interface directly into your web application. 
 
 > [!TIP]
 > Use the <iframe> HTML element to embed the [sign-up or sign-in](add-sign-up-and-sign-in-policy.md), [edit profile](add-profile-editing-policy.md), or [change password](add-password-change-policy.md) custom policies into your web or single page app.

articles/active-directory/authentication/howto-password-ban-bad-on-premises-agent-versions.md

@@ -6,7 +6,7 @@ services: active-directory
 ms.service: active-directory
 ms.subservice: authentication
 ms.topic: article
-ms.date: 11/21/2019
+ms.date: 06/04/2021
 
 ms.author: justinha
 author: justinha

articles/active-directory/manage-apps/manage-certificates-for-federated-single-sign-on.md

@@ -26,6 +26,8 @@ When you add a new application from the gallery and configure a SAML-based sign-
 
 ![SAML active signing certificate download options](./media/manage-certificates-for-federated-single-sign-on/active-certificate-download-options.png)
 
+SAML signing certificates generated by Azure when creating the application are app-specific, and hence each certificate is unique to each app instance. Using the same SAML certificate for all application instances is not supported. If you would like to use same SAML certificate for all app instances, you will need to generate your own SAML certificate with a private key and upload it to all app instances. SAML signing certificates generated by Azure won't have a private key (even if exporting the raw certificate). 
+
 You can also download an active or inactive certificate by selecting the **SAML Signing Certificate** heading's **Edit** icon (a pencil), which displays the **SAML Signing Certificate** page. Select the ellipsis (**...**) next to the certificate you want to download, and then choose which certificate format you want. You have the additional option to download the certificate in privacy-enhanced mail (PEM) format. This format is identical to Base64 but with a **.pem** file name extension, which isn't recognized in Windows as a certificate format.
 
 ![SAML signing certificate download options (active and inactive)](./media/manage-certificates-for-federated-single-sign-on/all-certificate-download-options.png)

articles/aks/azure-netapp-files.md

@@ -23,7 +23,7 @@ This article shows you how to use *Azure CNI* networking to create and use a vir
   * `Microsoft.Network/virtualNetworks/subnets/join/action`
   * `Microsoft.Network/virtualNetworks/subnets/read`
 * The subnet assigned to the AKS node pool cannot be a [delegated subnet](../virtual-network/subnet-delegation-overview.md).
-* If you provide your own subnet, you have to manage the Network Security Groups (NSG) associated with that subnet. AKS will not modify any of the NSGs associated with that subnet. You also must ensure the security rules in the NSGs allow traffic between the node and pod CIDR ranges.
+* AKS doesn't apply Network Security Groups (NSGs) to its subnet and will not modify any of the NSGs associated with that subnet. If you provide your own subnet and add NSGs associated with that subnet, you must ensure the security rules in the NSGs allow traffic between the node and pod CIDR ranges. For more details, see [Network security groups][aks-network-nsg].
 
 ## Plan IP addressing for your cluster
 
@@ -354,6 +354,7 @@ Learn more about networking in AKS in the following articles:
 [aks-ssh]: ssh.md
 [ManagedClusterAgentPoolProfile]: /azure/templates/microsoft.containerservice/managedclusters#managedclusteragentpoolprofile-object
 [aks-network-concepts]: concepts-network.md
+[aks-network-nsg]: concepts-network.md#network-security-groups
 [aks-ingress-basic]: ingress-basic.md
 [aks-ingress-tls]: ingress-tls.md
 [aks-ingress-static-tls]: ingress-static-ip.md
@@ -368,4 +369,4 @@ Learn more about networking in AKS in the following articles:
 [nodepool-upgrade]: use-multiple-node-pools.md#upgrade-a-node-pool
 [network-comparisons]: concepts-network.md#compare-network-models
 [system-node-pools]: use-system-pools.md
-[prerequisites]: configure-azure-cni.md#prerequisites
+[prerequisites]: configure-azure-cni.md#prerequisites

articles/aks/configure-azure-cni.md

@@ -50,7 +50,7 @@ With *Azure CNI*, each pod receives an IP address in the IP subnet, and can dire
 * Route tables and user-defined routes are required for using kubenet, which adds complexity to operations.
 * Direct pod addressing isn't supported for kubenet due to kubenet design.
 * Unlike Azure CNI clusters, multiple kubenet clusters can't share a subnet.
-* If you provide your own subnet, you have to manage the Network Security Groups (NSG) associated with that subnet. AKS will not modify any of the NSGs associated with that subnet. You also must ensure the security rules in the NSGs allow traffic between the node and pod CIDR.
+* AKS doesn't apply Network Security Groups (NSGs) to its subnet and will not modify any of the NSGs associated with that subnet. If you provide your own subnet and add NSGs associated with that subnet, you must ensure the security rules in the NSGs allow traffic between the node and pod CIDR. For more details, see [Network security groups][aks-network-nsg].
 * Features **not supported on kubenet** include:
    * [Azure network policies](use-network-policies.md#create-an-aks-cluster-and-enable-network-policy), but Calico network policies are supported on kubenet
    * [Windows node pools](./windows-faq.md)
@@ -250,6 +250,7 @@ With an AKS cluster deployed into your existing virtual network subnet, you can
 <!-- LINKS - Internal -->
 [install-azure-cli]: /cli/azure/install-azure-cli
 [aks-network-concepts]: concepts-network.md
+[aks-network-nsg]: concepts-network.md#network-security-groups
 [az-group-create]: /cli/azure/group#az_group_create
 [az-network-vnet-create]: /cli/azure/network/vnet#az_network_vnet_create
 [az-ad-sp-create-for-rbac]: /cli/azure/ad/sp#az_ad_sp_create_for_rbac

articles/aks/configure-kubenet.md

@@ -285,8 +285,7 @@ FIPS-enabled nodes are currently available in preview on Linux-based node pools.
 
 ## Can I configure NSGs with AKS?
 
-If you provide your own subnet, you have to manage the Network Security Groups (NSG) associated with that subnet. AKS will only modify the NSGs at the NIC level and will not modify any of the NSGs associated with that subnet. If you're using CNI, you also must ensure the security rules in the NSGs allow traffic between the node and pod CIDR ranges. If you're using kubenet, you also must ensure the security rules in the NSGs allow traffic between the node and pod CIDR.
-
+AKS doesn't apply Network Security Groups (NSGs) to its subnet and will not modify any of the NSGs associated with that subnet. AKS will only modify the NSGs at the NIC level. If you're using CNI, you also must ensure the security rules in the NSGs allow traffic between the node and pod CIDR ranges. If you're using kubenet, you also must ensure the security rules in the NSGs allow traffic between the node and pod CIDR. For more details, see [Network security groups](concepts-network.md#network-security-groups).
 
 <!-- LINKS - internal -->
 

articles/aks/faq.md

@@ -3,7 +3,7 @@ title: Configure Windows Update settings for Azure Automation Update Management
 description: This article tells how to configure Windows Update settings to work with Azure Automation Update Management.
 services: automation
 ms.subservice: update-management
-ms.date: 05/04/2020
+ms.date: 10/05/2021
 ms.topic: conceptual
 ---
 # Configure Windows Update settings for Azure Automation Update Management
@@ -17,17 +17,22 @@ Azure Automation Update Management relies on the [Windows Update client](/window
 
 Update Management respects many of the settings specified to control the Windows Update client. If you use settings to enable non-Windows updates, Update Management will also manage those updates. If you want to enable downloading of updates before an update deployment occurs, update deployment can be faster, more efficient, and less likely to exceed the maintenance window.
 
-For additional recommendations on setting up WSUS in your Azure subscription and securely keep your Windows virtual machines up to date, review [Plan your deployment for updating Windows virtual machines in Azure using WSUS](/azure/architecture/example-scenario/wsus/).
+For other recommendations on setting up WSUS in your Azure subscription and securely keep your Windows virtual machines up to date, review [Plan your deployment for updating Windows virtual machines in Azure using WSUS](/azure/architecture/example-scenario/wsus/).
 
 ## Pre-download updates
 
-To configure the automatic downloading of updates without automatically installing them, you can use Group Policy to [configure the Automatic Updates setting](/windows-server/administration/windows-server-update-services/deploy/4-configure-group-policy-settings-for-automatic-updates##configure-automatic-updates) to 3. This setting enables downloads of the required updates in the background, and notifies you that the updates are ready to install. In this way, Update Management remains in control of schedules, but allows downloading of updates outside the Update Management maintenance window. This behavior prevents `Maintenance window exceeded` errors in Update Management.
+To configure the automatic downloading of updates without automatically installing them, you can use Group Policy to [configure the Automatic Updates setting](/windows-server/administration/windows-server-update-services/deploy/4-configure-group-policy-settings-for-automatic-updates##configure-automatic-updates). There are two recommended values depending on the version of the operating system:
+
+* Windows Server 2016 and later, set to a value of **7**.
+* Windows Server 2012 R2 and earlier, set to a value of **3**.
+
+This setting enables downloads of the required updates in the background, and notifies you that the updates are ready to install. In this way, Update Management remains in control of schedules, but allows downloading of updates outside the Update Management maintenance window. This behavior prevents `Maintenance window exceeded` errors in Update Management.
 
 You can enable this setting in PowerShell:
 
 ```powershell
 $WUSettings = (New-Object -com "Microsoft.Update.AutoUpdate").Settings
-$WUSettings.NotificationLevel = 3
+$WUSettings.NotificationLevel = <3 or 7>
 $WUSettings.Save()
 ```