Merge pull request #223840 from MicrosoftDocs/main

1/12 PM Publish

Author: huypub

articles/active-directory/develop/howto-configure-publisher-domain.md

@@ -116,7 +116,7 @@ You're not required to maintain the resources that are used for verification aft
 If your tenant has verified domains, in the **Select a verified domain** dropdown, select one of the domains.
 
 > [!NOTE]
-> The expected `Content-Type` header that should return is `application/json`. If you use any other header, like `application/json; charset=utf-8`, you might see this error message:
+> Content will be interpreted as UTF-8 JSON for deserialization. Supported `Content-Type` headers that should return are `application/json`, `application/json; charset=utf-8`, or ` `. If you use any other header, you might see this error message:
 >
 > `Verification of publisher domain failed. Error getting JSON file from https:///.well-known/microsoft-identity-association. The server returned an unexpected content type header value.`
 >

articles/active-directory/fundamentals/whats-new.md

@@ -83,20 +83,6 @@ In this Public Preview refresh, we have enhanced the user experience with an upd
 
 For more information, see: [Conditional Access templates (Preview)](../conditional-access/concept-conditional-access-policy-common.md).
 
-
----
-
-### Public Preview - Enabling customization capabilities for the conditional error messages in Company Branding.
-
-
-
-**Type:** New feature   
-**Service category:** Other             
-**Product capability:** End User Experiences    
-
-Updates to the Company Branding functionality on the Azure AD/Microsoft 365 login experience, to allow customizing conditional access (CA) error messages. For more information, see: [Company Branding](../fundamentals/customize-branding.md).
-
-
 ---
 
 ### Public Preview - Admins can restrict their users from creating tenants
@@ -223,31 +209,33 @@ For listing your application in the Azure AD app gallery, please read the detail
 
 ### ADAL End of Support Announcement
 
-
-
 **Type:** N/A      
 **Service category:** Other               
 **Product capability:** Developer Experience         
 
-As part of our ongoing initiative to improve the developer experience, service reliability, and security of customer applications, we will end support for the Azure Active Directory Authentication Library (ADAL). The final deadline to migrate your applications to Microsoft Authentication Library (MSAL) has been extended to **June 1, 2023**. 
+As part of our ongoing initiative to improve the developer experience, service reliability, and security of customer applications, we will end support for the Azure Active Directory Authentication Library (ADAL). The final deadline to migrate your applications to Microsoft Authentication Library (MSAL) has been extended to **June 30, 2023**. 
+
+### Why are we doing this?
 
-### Why are we doing this? 
 As we consolidate and evolve the Microsoft Identity platform, we are also investing in making significant improvements to the developer experience and service features that make it possible to build secure, robust and resilient applications. To make these features available to our customers we needed to update the architecture of our software development kits. As a result of this change, we’ve decided that the path forward requires us to sunset ADAL so that we can focus on developer experience investments with MSAL. 
 
-### What happens? 
-We recognize that changing libraries is not an easy task, and cannot be accomplished quickly. We are committed to helping customers plan their migrations to MSAL as well as execute them with minimal disruption. 
+### What happens?
+
+We recognize that changing libraries is not an easy task, and cannot be accomplished quickly. We are committed to helping customers plan their migrations to MSAL as well as execute them with minimal disruption.
+
 - In June 2020 we [announced the 2-year end of support timeline for ADAL](https://devblogs.microsoft.com/microsoft365dev/end-of-support-timelines-for-azure-ad-authentication-library-adal-and-azure-ad-graph/). 
 - In December 2022 we’ve decided to extend the ADAL end of support to June 2023. 
 - Through the next six months (January 2023 – June 2023) we will continue informing customers about the upcoming end of support along with providing guidance on migration. 
 - On June 2023 we will officially sunset ADAL, removing library documentation and archiving all GitHub repositories related to the project. 
 
-### How to find out which applications in my tenant are using ADAL? 
+### How to find out which applications in my tenant are using ADAL?
 
 Refer to our post on [Microsoft Q&A](/answers/questions/360928/information-how-to-find-apps-using-adal-in-your-te.html) for details on identifying ADAL apps with the help of [Azure Workbooks](../../azure-monitor/visualize/workbooks-overview.md). 
 ### If I’m using ADAL, what can I expect after the deadline? 
+
 - There will be no new releases (security or otherwise) to the library after June 2023. 
-- We will not be accepting any incident reports or support requests for ADAL. ADAL to MSAL Migration support would continue.   
-- The underpinning services will continue working and applications that depend on ADAL should continue working; however, applications will be at increased security and reliability risk due to not having the latest updates, service configuration, and enhancements made available through the Microsoft Identity platform. 
+- We will not be accepting any incident reports or support requests for ADAL. ADAL to MSAL migration support would continue.   
+- The underpinning services will continue working and applications that depend on ADAL should continue working; however, applications and the resources they access will be at increased security and reliability risk due to not having the latest updates, service configuration, and enhancements made available through the Microsoft Identity platform. 
 
 ### What features can I only access with MSAL?
 
@@ -558,18 +546,6 @@ Beginning September 30, 2024, Azure Multi-Factor Authentication Server deploymen
 
 ---
 
-### General Availability - Change of Default User Consent Settings
-
-
-
-**Type:** New feature  
-**Service category:** Enterprise Apps     
-**Product capability:** Developer Experience  
-
-Starting Sept 30th, 2022, Microsoft will require all new tenants to follow a new user consent configuration. While this won't impact any existing tenants that were created before September 30, 2022, all new tenants created after September 30, 2022, will have the default setting of “Enable automatic updates (Recommendation)” under User consent settings. This change reduces the risk of malicious applications attempting to trick users into granting them access to your organization's data. For more information, see: [Configure how users consent to applications](../manage-apps/configure-user-consent.md).
-
----
-
 ### Public Preview - Lifecycle Workflows is now available
 
 

articles/active-directory/hybrid/how-to-connect-group-writeback-enable.md

@@ -29,6 +29,10 @@ Group writeback requires enabling both the original and new versions of the feat
 >
 >The enhanced group writeback feature is enabled on the tenant and not per Azure AD Connect client instance. Please be sure that all Azure AD Connect client instances are updated to a minimal build version of 1.6.4.0 or later.
 
+> [!NOTE]
+> If you don't want to writeback all existing Microsoft 365 groups to Active Directory, you need to make changes to group writeback default behaviour before performing the steps in this article to enable the feature. See [Modify Azure AD Connect group writeback default behavior](how-to-connect-modify-group-writeback.md).
+> Also the new and original versions of the feature need to be enabled in the order documented. If the original feature is enabled first, all existing Microsoft 365 groups will be written back to Active Directory.
+
 ### Enable group writeback by using PowerShell 
 
 1. On your Azure AD Connect server, open a PowerShell prompt as an administrator. 

articles/active-directory/hybrid/how-to-connect-group-writeback-v2.md

@@ -118,7 +118,10 @@ You can modify the default behavior as follows:
 - Microsoft 365 groups with up to 250,000 members can be written back to on-premises. 
 
 If you plan to make changes to the default behavior, we recommend that you do so before you enable group writeback. However, you can still modify the default behavior if group writeback is already enabled. For more information, see [Modify Azure AD Connect group writeback default behavior](how-to-connect-modify-group-writeback.md). 
- 
+
+> [!NOTE]
+> You need to make these changes before enabling group writeback; otherwise, all existing Microsoft 365 groups will be automatically written back to Active Directory. Also, the new and original versions of the feature need to be enabled in the order documented. If the original feature is enabled first, all existing Microsoft 365 groups will be written back to Active Directory.
+
 ## Understand limitations of public preview  
 
 Although this release has undergone extensive testing, you might still encounter issues. One of the goals of this public preview release is to find and fix any issues before the feature moves to general availability. Please also note that any public preview functionality can still receive breaking changes which may require you to make changes to you configuration to continue using this feature. We may also decide to change or remove certain functionality without prior notice.
@@ -143,4 +146,4 @@ These limitations and known issues are specific to group writeback:
 
 - [Modify Azure AD Connect group writeback default behavior](how-to-connect-modify-group-writeback.md) 
 - [Enable Azure AD Connect group writeback](how-to-connect-group-writeback-enable.md)
-- [Disable Azure AD Connect group writeback](how-to-connect-group-writeback-disable.md)
+- [Disable Azure AD Connect group writeback](how-to-connect-group-writeback-disable.md)

articles/active-directory/manage-apps/protect-against-consent-phishing.md

@@ -62,7 +62,7 @@ Administrators should be in control of application use by providing the right in
   - Block [consent phishing emails with Microsoft Defender for Office 365](/microsoft-365/security/office-365-security/set-up-anti-phishing-policies#impersonation-settings-in-anti-phishing-policies-in-microsoft-defender-for-office-365) by protecting against phishing campaigns where an attacker is impersonating a known user in the organization.
   - Configure Microsoft Defender for Cloud Apps policies to help manage abnormal application activity in the organization. For example, [activity policies](/cloud-app-security/user-activity-policies), [anomaly detection](/cloud-app-security/anomaly-detection-policy), and [OAuth app policies](/cloud-app-security/app-permission-policy).
   - Investigate and hunt for consent phishing attacks by following the guidance on [advanced hunting with Microsoft 365 Defender](/microsoft-365/security/defender/advanced-hunting-overview).
-- Allow access to trusted applications that meet certain criteria and that protect against those applications that don't:
+- Allow access to trusted applications that meet certain criteria and protect against those applications that don't:
   - [Configure user consent settings](./configure-user-consent.md?tabs=azure-portal) to allow users to only consent to applications that meet certain criteria, such as applications developed by your organization or from verified publishers and only for low risk permissions you select.
   - Use applications that have been publisher verified. [Publisher verification](../develop/publisher-verification-overview.md) helps administrators and users understand the authenticity of application developers through a Microsoft supported vetting process. Even if an application does have a verified publisher, it is still important to review the consent prompt to understand and evaluate the request. For example, reviewing the permissions being requested to ensure they align with the scenario the app is requesting them to enable, additional app and publisher details on the consent prompt, etc.
   - Create proactive [application governance](/microsoft-365/compliance/app-governance-manage-app-governance) policies to monitor third-party application behavior on the Microsoft 365 platform to address common suspicious application behaviors.
@@ -72,3 +72,4 @@ Administrators should be in control of application use by providing the right in
 - [Application consent grant investigation](/security/compass/incident-response-playbook-app-consent)
 - [Managing access to applications](./what-is-access-management.md)
 - [Restrict user consent operations in Azure AD](../../security/fundamentals/steps-secure-identity.md#restrict-user-consent-operations)
+- [Compromised and malicious applications investigation](/security/compass/incident-response-playbook-compromised-malicious-app)

articles/aks/azure-cni-overlay.md

@@ -86,7 +86,6 @@ Use the traditional VNet option when:
 
 The overlay solution has the following limitations today
 
-* Only available for Linux and not for Windows.
 * You can't deploy multiple overlay clusters on the same subnet.
 * Overlay can be enabled only for new clusters. Existing (already deployed) clusters can't be configured to use overlay.
 * You can't use Application Gateway as an Ingress Controller (AGIC) for an overlay cluster.

articles/aks/node-updates-kured.md

@@ -67,7 +67,7 @@ helm repo update
 kubectl create namespace kured
 
 # Install kured in that namespace with Helm 3 (only on Linux nodes, kured is not working on Windows nodes)
-helm install my-release kubereboot/kured --namespace kured --set nodeSelector."kubernetes.io/os"=linux
+helm install my-release kubereboot/kured --namespace kured --set nodeSelector."kubernetes\.io/os"=linux
 ```
 
 You can also configure additional parameters for `kured`, such as integration with Prometheus or Slack. For more information about additional configuration parameters, see the [kured Helm chart][kured-install].

articles/aks/support-policies.md

@@ -127,17 +127,17 @@ Although you can sign in to and change agent nodes, doing this operation is disc
 
 You may only customize the NSGs on custom subnets. You may not customize NSGs on managed subnets or at the NIC level of the agent nodes. AKS has egress requirements to specific endpoints, to control egress and ensure the necessary connectivity, see [limit egress traffic](limit-egress-traffic.md). For ingress, the requirements are based on the applications you have deployed to cluster.
 
-## Stopped or de-allocated clusters
+## Stopped, de-allocated, and "Not Ready" nodes
 
-As stated earlier, manually de-allocating all cluster nodes via the IaaS APIs/CLI/portal renders the cluster out of support. The only supported way to stop/de-allocate all nodes is to [stop the AKS cluster](start-stop-cluster.md#stop-an-aks-cluster), which preserves the cluster state for up to 12 months.
+If you do not need your AKS workloads to run continuously, you can [stop the AKS cluster](start-stop-cluster.md#stop-an-aks-cluster) which stops all nodepools and the control plane, and start it again when needed. When you stop a cluster using the `az aks stop` command, the cluster state will be preserved for up to 12 months. After 12 months the cluster state and all of its resources will be deleted.
 
-Clusters that are stopped for more than 12 months will no longer preserve state. 
+Manually de-allocating all cluster nodes via the IaaS APIs/CLI/portal is not a supported way to stop an AKS cluster or nodepool. The cluster will be considered out of support and will be stopped by AKS after 30 days. The clusters will then be subject to the same 12 month preservation policy as a correctly stopped cluster.
 
-Clusters that are de-allocated outside of the AKS APIs have no state preservation guarantees. The control planes for clusters in this state will be archived after 30 days, and deleted after 12 months.
+Clusters with 0 "Ready" nodes (or all "Not Ready") and 0 Running VMs will be stopped after 30 days. 
 
 AKS reserves the right to archive control planes that have been configured out of support guidelines for extended periods equal to and beyond 30 days. AKS maintains backups of cluster etcd metadata and can readily reallocate the cluster. This reallocation can be initiated by any PUT operation bringing the cluster back into support, such as an upgrade or scale to active agent nodes.
 
-If your subscription is suspended or deleted, your cluster's control plane and state will be deleted after 90 days.
+All clusters in a suspended or deleted subscription will be stopped immediately and deleted after 30 days
 
 ## Unsupported alpha and beta Kubernetes features
 

articles/azure-monitor/app/java-standalone-config.md

@@ -711,6 +711,8 @@ If your application is behind a firewall and can't connect directly to Applicati
 }
 ```
 
+You can also set the http proxy using the environment variable `APPLICATIONINSIGHTS_PROXY`, which takes the format `https://<host>:<port>`. It then takes precedence over the proxy specified in the JSON configuration.
+
 Application Insights Java 3.x also respects the global `https.proxyHost` and `https.proxyPort` system properties if they're set, and `http.nonProxyHosts`, if needed.
 
 ## Recovery from ingestion failures