Merge pull request #247473 from MicrosoftDocs/main

Publish to live, Monday 4 AM PST, 8/7

Author: ttorble

articles/active-directory/saas-apps/cloudbees-ci-tutorial.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: saas-app-tutorial
 ms.workload: identity
 ms.topic: how-to
-ms.date: 07/21/2023
+ms.date: 08/04/2023
 ms.author: jeedes
 
 ---
@@ -108,11 +108,7 @@ Complete the following steps to enable Azure AD single sign-on in the Azure port
 
 ## Configure CloudBees CI SSO
 
-To configure single sign-on on **CloudBees CI** side, you need to send the downloaded **Federation Metadata XML** and appropriate copied URLs from Azure portal to [CloudBees CI support team](mailto:[email protected]). They set this setting to have the SAML SSO connection set properly on both sides.
-
-### Create CloudBees CI test user
-
-In this section, you create a user called Britta Simon at CloudBees CI SSO. Work with [CloudBees CI support team](mailto:[email protected]) to add the users in the CloudBees CI SSO platform. Users must be created and activated before you use single sign-on.
+To configure single sign-on in CloudBees CI, please follow [Configure Azure](https://github.com/jenkinsci/saml-plugin/blob/main/doc/CONFIGURE_AZURE.md) using the Federation Metadata XML and copied URLs from the Azure portal.
 
 ## Test SSO 
 

articles/aks/use-node-public-ips.md

@@ -203,24 +203,22 @@ az aks create \
 
 ### Add a new node pool with allowed ports and application security groups
 
-```azurecli-interactive
-az aks nodepool add \
+```az aks nodepool add \
   --resource-group <resourceGroup> \
   --cluster-name <clusterName> \
   --name <nodepoolName> \
-  --nodepool-allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp\
-  --nodepool-asg-ids "<asgId>,<asgId>"
+  --allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp \
+  --asg-ids "<asgId>,<asgId>"
 ```
 
 ### Update the allowed ports and application security groups for a node pool
 
-```azurecli-interactive
-az aks nodepool update \
+```az aks nodepool update \
   --resource-group <resourceGroup> \
   --cluster-name <clusterName> \
   --name <nodepoolName> \
-  --nodepool-allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp\
-  --nodepool-asg-ids "<asgId>,<asgId>"
+  --allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp \
+  --asg-ids "<asgId>,<asgId>"
 ```
 
 ## Automatically assign host ports for pod workloads (PREVIEW)

articles/application-gateway/configuration-listeners.md

@@ -5,7 +5,7 @@ services: application-gateway
 author: greg-lindsay
 ms.service: application-gateway
 ms.topic: conceptual
-ms.date: 05/19/2023
+ms.date: 07/19/2023
 ms.author: greglin 
 ---
 
@@ -89,11 +89,10 @@ WebSocket support is enabled by default. There's no user-configurable setting to
 
 ## Custom error pages
 
-You can define custom error at the global level or the listener level, however creating global-level custom error pages from the Azure portal is currently not supported. You can configure a custom error page for a 403 web application firewall error or a 502 maintenance page at the listener level. You must specify a publicly accessible blob URL for the given error status code. For more information, see [Create Application Gateway custom error pages](./custom-error.md).
+You can define customized error pages for different response codes returned by the Application Gateway. The response codes for which you can configure error pages are 400, 403, 405, 408, 500, 502, 503, and 504. You can use global-level or listener-specific error page configuration to set them granularly for each listener. For more information, see [Create Application Gateway custom error pages](./custom-error.md).
 
-![Application Gateway error codes](/azure/application-gateway/media/custom-error/ag-error-codes.png)
-
-To configure a global custom error page, see [Azure PowerShell configuration](./custom-error.md#azure-powershell-configuration).
+> [!NOTE]
+> An error originating from the backend server is passed along unmodified by the Application Gateway to the client. 
 
 ## TLS policy
 

articles/application-gateway/custom-error.md

@@ -5,58 +5,80 @@ services: application-gateway
 author: greg-lindsay
 ms.service: application-gateway
 ms.topic: how-to
-ms.date: 11/09/2022
-ms.author: greglin 
+ms.date: 07/19/2023
+ms.author: jaysoni 
 ms.custom: devx-track-azurepowershell
 ---
 
 # Create Application Gateway custom error pages
 
-Application Gateway allows you to create custom error pages instead of displaying default error pages. You can use your own branding and layout using a custom error page.
+Application Gateway allows you to create customized error pages instead of displaying default ones. You can use your branding and layout for errors related to different response codes. Some scenarios for setting custom error pages are
 
-For example, you can define your own maintenance page if your web application isn't reachable. Or, you can create an unauthorized access page if a malicious request is sent to a web application.
+- Showing a **maintenance or status page** for 502 Bad Gateway response code. This is useful when your application gateway has no backend server to route traffic to during scheduled maintenance or an unforeseen issue with backend pool servers.
+- Showing a customized **unauthorized access page** for 403 Forbidden response code that occurs when the WAF is in prevention mode and blocks malicious traffic.
+- Showing a company-branded page with contact details in case of an issue.
 
-Custom error pages are supported for the following two scenarios:
+## Supported response codes
+The custom error pages are supported for the following response codes: 
 
-- **Maintenance page** - This custom error page is sent instead of a 502 bad gateway page. It's shown when Application Gateway has no backend to route traffic to. For example, when there's scheduled maintenance or when an unforeseen issue effects backend pool access.
-- **Unauthorized access page** - This custom error page is sent instead of a 403 unauthorized access page. It's shown when the Application Gateway WAF detects malicious traffic and blocks it.
+| Response code | Description |
+| ---------- | ---------- |
+| 400 | Bad request (In preview) |
+| 403 | Forbidden |
+| 405 | Method not allowed (In preview) |
+| 408 | Request timeout (In preview) |
+| 500 | Internal Server Error (In preview) |
+| 502 | Bad gateway |
+| 503 | Service unavailable (In preview) |
+| 504 | Gateway timeout (In preview) |
 
-If an error originates from backend targets of your backend pool, the error is passed along unmodified back to the caller. Custom error pages will only be displayed when a request can't reach the backend or when WAF is in prevention mode and blocks the request.
+> [!Note]
+> - API version 2022-09-01 or later should be used to configure error pages for the new response codes (in preview).
+> - Response code 404 (Page not found) is currently unsupported.
+> - The custom error pages are displayed for response codes generated by Application Gateway. If an error originates from the backend server, it is passed along unmodified to the client.
+
+## Configuration levels
+
+The custom error pages can be defined at a Global or Listener level:
 
-Custom error pages can be defined at the global level and the listener level:
+- **Global level** - The error pages set at a global level are applied to all the listeners of that application gateway. Its configuration through the Azure portal is currently not supported.
+- **Listener level** - The error pages at a listener level gives you granular control to set error pages for application served by that listener.
 
-- **Global level** - the error page applies to traffic for all the web applications deployed on that application gateway.
-- **Listener level** - the error page is applied to traffic received on that listener.
-- **Both** - the custom error page defined at the listener level overrides the one set at global level.
+> [!Note]
+> When using a combination of Global and Listener-level error pages for a gateway, you must explicitly mention the URLs for all desired response codes for that listener. A listener-specific configuration overrides all preceding global configurations applicable to that listener.
 
-To create a custom error page, you must have:
+## Requirements
 
-- an HTTP response status code.
-- corresponding location for the error page. 
-- error page should be internet accessible and return 200 response.
-- error page should be in \*.htm or \*.html extension type.
-- error page size must be less than 1 MB.
-- error page must be hosted in Azure blob storage
+To create a custom error page, you should 
+- know the response code for which a custom error page is needed.
+- know the corresponding remote location (URL) for the HTML page. This must be a publicly accessible file.
+- ensure the error page is publicly accessible and return a 200 response.
+- ensure the error page should be in \*.htm or \*.html extension type.
+- ensure the page size is less than 1 MB.
 
-You may reference either internal or external images/CSS for this HTML file. For externally referenced resources, use absolute URLs that are publicly accessible. Be aware of the HTML file size when using base64-encoded inline images, javascript, or CSS.
+You may reference internal or external images/CSS for this HTML file. For externally referenced resources, use absolute URLs that are publicly accessible. Be aware of the HTML file size when using base64-encoded inline images, JavaScript, or CSS.
 
 > [!Note]
-> Relative links with files in the same location are not supported.
+>  - Relative links are not supported.
+
+## How it works?
+After you specify an error page in your application gateway's configuration, your gateway verifies the connectivity to the HTML page over the internet. It then downloads the file on its local cache. 
+
+When a client faces an error, your application gateway returns a response code and that HTML page. Any externally referenced resources (such as images, JavaScript, and CSS files) are fetched directly by the client. 
 
-After you specify an error page, application gateway verifies internet connectivity to the file and will save the file to the local application gateway cache. The HTML page will be served by the application gateway, whereas externally referenced resources (such as images, javascript, css files) are fetched directly by the client. To modify an existing custom error page, you must point to a different blob location in the application gateway configuration. Application gateway doesn't periodically check the blob location to fetch new versions.
+Your application gateway doesn't periodically check the source file's location to fetch a new version. You can perform any configuration update on the gateway to manually update the file's cache. For example, changing the error URL from page 1 to page 2 and then back to page 1, or upon adding a new listener.
 
 ## Portal configuration
 
-1. Navigate to Application Gateway in the portal and choose an application gateway.
+Steps to configure **listener-specific** custom error pages:
 
-2. Select **Listeners** and navigate to a particular listener where you want to specify an error page.
+1. Navigate to Application Gateway in the portal and choose the required resource.
 
-3. Configure a custom error page for a 403 WAF error or a 502 maintenance page at the listener level.
+2. Select **Listeners** and navigate to a particular listener for which you want to specify an error page.
 
-    > [!NOTE]
-    > Creating global level custom error pages from the Azure portal is currently not supported.
+3. Under **Custom error pages** section, specify publicly accessible URLs for the required status codes.
 
-4. Under **Error page url**, select **Yes**, and then configure a publicly accessible blob URL for a given error status code. Select **Save**. The Application Gateway is now configured with the custom error page.
+4. Select Save.
 
    ![Screenshot of Application Gateway custom error page.](media/custom-error/ag-error-codes.png)
 

articles/application-gateway/media/custom-error/ag-error-codes.png

@@ -119,7 +119,7 @@ Container insights Collected Data can be customized through the Azure portal, us
 | Grouping | Tables | Notes |
 | --- | --- | --- |
 | All (Default) | All standard container insights tables | Required for enabling the default container insights visualizations |
-| Performance | Perf, Insights Metrics | |
+| Performance | Perf, InsightsMetrics | |
 | Logs and events | ContainerLog or ContainerLogV2, KubeEvents, KubePodInventory | Recommended if you have enabled managed Prometheus metrics |
 | Workloads, Deployments, and HPAs | InsightsMetrics, KubePodInventory, KubeEvents, ContainerInventory, ContainerNodeInventory, KubeNodeInventory, KubeServices | |
 | Persistent Volumes | InsightsMetrics, KubePVInventory | |

articles/azure-monitor/containers/container-insights-cost-config.md

@@ -184,7 +184,7 @@ To delete a table using PowerShell:
 You can modify the schema of custom tables and add custom columns to, or delete columns from, a standard table.  
 
 > [!NOTE]
-> Column names must start with a letter and can consist of up to 45 alphanumeric characters and the characters `_` and `-`. The following are reserved column names: `Type`, `TenantId`, `resource`, `resourceid`, `resourcename`, `resourcetype`, `subscriptionid`, `tenanted`. 
+> Column names must start with a letter and can consist of up to 45 alphanumeric characters and underscores (`_`). The following are reserved column names: `Type`, `TenantId`, `resource`, `resourceid`, `resourcename`, `resourcetype`, `subscriptionid`, `tenanted`. 
 
 # [Portal](#tab/azure-portal-3)
 

articles/azure-monitor/logs/create-custom-table.md

@@ -65,7 +65,7 @@ This call is idempotent, so it has no effect if the table has already been conve
 The API call enables all DCR-based custom logs features on the table. The Data Collector API will continue to ingest data into existing columns, but won't create any new columns. Any previously defined [custom fields](../logs/custom-fields.md) won't continue to be populated. Another way to migrate an existing table to using data collection rules, but not necessarily the Log Ingestion API is applying a [workspace transformation](../logs/tutorial-workspace-transformations-portal.md) to the table.
 
 > [!IMPORTANT]
-> - Column names must start with a letter and can consist of up to 45 alphanumeric characters and the characters `_` and `-`. 
+> - Column names must start with a letter and can consist of up to 45 alphanumeric characters and underscores (`_`). 
 > - The following are reserved column names: `Type`, `TenantId`, `resource`, `resourceid`, `resourcename`, `resourcetype`, `subscriptionid`, `tenanted`. 
 > - Custom columns you add to an Azure table must have the suffix `_CF`.
 > - If you update the table schema in your Log Analytics workspace, you must also update the input stream definition in the data collection rule to ingest data into new or modified columns.

articles/azure-monitor/logs/custom-logs-migrate.md

@@ -112,7 +112,7 @@ To create a custom table into which to ingest events, in the Azure portal:
     ```
 
 > [!IMPORTANT]
-> - Column names must start with a letter and can consist of up to 45 alphanumeric characters and the characters `_` and `-`. 
+> - Column names must start with a letter and can consist of up to 45 alphanumeric characters and underscores (`_`). 
 > - The following are reserved column names: `Type`, `TenantId`, `resource`, `resourceid`, `resourcename`, `resourcetype`, `subscriptionid`, `tenanted`. 
 > - Column names are case-sensitive. Make sure to use the correct case in your data collection rule. 
 

articles/azure-monitor/logs/ingest-logs-event-hub.md

@@ -44,7 +44,7 @@ The following tables can receive data from the ingestion API.
 | Azure tables | The Logs Ingestion API can send data to the following Azure tables. Other tables may be added to this list as support for them is implemented.<br><br>- [CommonSecurityLog](/azure/azure-monitor/reference/tables/commonsecuritylog)<br>- [SecurityEvents](/azure/azure-monitor/reference/tables/securityevent)<br>- [Syslog](/azure/azure-monitor/reference/tables/syslog)<br>- [WindowsEvents](/azure/azure-monitor/reference/tables/windowsevent)
 
 > [!NOTE]
-> Column names must start with a letter and can consist of up to 45 alphanumeric characters and the characters `_` and `-`. The following are reserved column names: `Type`, `TenantId`, `resource`, `resourceid`, `resourcename`, `resourcetype`, `subscriptionid`, `tenanted`. Custom columns you add to an Azure table must have the suffix `_CF`.
+> Column names must start with a letter and can consist of up to 45 alphanumeric characters and underscores (`_`). The following are reserved column names: `Type`, `TenantId`, `resource`, `resourceid`, `resourcename`, `resourcetype`, `subscriptionid`, `tenanted`. Custom columns you add to an Azure table must have the suffix `_CF`.
 
 ## Authentication