Merge pull request #284901 from ecfan/ise

ISE retirement prep: Remove references to ISE

Author: Jill Grant

articles/azure-monitor/autoscale/autoscale-custom-metric.md

@@ -27,7 +27,7 @@ Azure Monitor autoscale applies to:
 + [Azure Cloud Services](https://azure.microsoft.com/services/cloud-services/)
 + [Azure App Service - Web Apps](https://azure.microsoft.com/services/app-service/web/)
 + [Azure Data Explorer cluster](https://azure.microsoft.com/services/data-explorer/) 
-+ Integration service environment and [Azure API Management](../../api-management/api-management-key-concepts.md)
++ [Azure API Management](../../api-management/api-management-key-concepts.md)
 
 ## Prerequisite
 

articles/connectors/built-in.md

@@ -17,7 +17,7 @@ For a smaller number of services, systems, and protocols, Azure Logic Apps provi
 
 For example, a Standard workflow can use both managed connectors and built-in connectors for Azure Blob Storage, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, FTP, IBM DB2, IBM MQ, SFTP, and SQL Server. A Consumption workflow doesn't have the built-in versions. A Consumption workflow can use built-in connectors for Azure API Management, and Azure App Service, while a Standard workflow doesn't have these built-in connectors.
 
-Also, in Standard workflows, some [built-in connectors with specific attributes are informally known as *service providers*](../logic-apps/custom-connector-overview.md#service-provider-interface-implementation). Some built-in connectors support only a single way to authenticate a connection to the underlying service. Other built-in connectors can offer a choice, such as using a connection string, Microsoft Entra ID, or a managed identity. All built-in connectors run in the same process as the Azure Logic Apps runtime. For more information, review [Single-tenant versus multitenant and integration service environment (ISE)](../logic-apps/single-tenant-overview-compare.md).
+Also, in Standard workflows, some [built-in connectors with specific attributes are informally known as *service providers*](../logic-apps/custom-connector-overview.md#service-provider-interface-implementation). Some built-in connectors support only a single way to authenticate a connection to the underlying service. Other built-in connectors can offer a choice, such as using a connection string, Microsoft Entra ID, or a managed identity. All built-in connectors run in the same process as the Azure Logic Apps runtime. For more information, review [Single-tenant versus multitenant in Azure Logic Apps](../logic-apps/single-tenant-overview-compare.md).
 
 This article provides a general overview about built-in connectors in Consumption workflows versus Standard workflows.
 

articles/connectors/introduction.md

@@ -29,7 +29,7 @@ This overview provides a high-level introduction to connectors and how they gene
 
 ## Built-in connectors versus managed connectors
 
-In Azure Logic Apps, connectors are either *built in* or *managed*. Some connectors have both versions. The available versions depend on whether you create a *Consumption* logic app workflow that runs in multi-tenant Azure Logic Apps or a *Standard* logic app workflow that runs in single-tenant Azure Logic Apps. For more information about logic app resource types, see [Resource types and host environment differences](../logic-apps/logic-apps-overview.md#resource-environment-differences).
+In Azure Logic Apps, connectors are either *built in* or *managed*. Some connectors have both versions. The available versions depend on whether you create a *Consumption* logic app workflow that runs in multitenant Azure Logic Apps or a *Standard* logic app workflow that runs in single-tenant Azure Logic Apps. For more information about logic app resource types, see [Resource types and host environment differences](../logic-apps/logic-apps-overview.md#resource-environment-differences).
 
 * [Built-in connectors](built-in.md) are designed to run directly and natively inside Azure Logic Apps.
 
@@ -120,7 +120,7 @@ If your workflows also use managed connectors, such as the Office 365 Outlook co
 
 ## Custom connectors and APIs
 
-In Consumption workflows for multi-tenant Azure Logic Apps, you can call Swagger-based or SOAP-based APIs that aren't available as out-of-the-box connectors. You can also run custom code by creating custom API Apps. For more information, see the following documentation:
+In Consumption workflows for multitenant Azure Logic Apps, you can call Swagger-based or SOAP-based APIs that aren't available as out-of-the-box connectors. You can also run custom code by creating custom API Apps. For more information, see the following documentation:
 
 * [Swagger-based or SOAP-based custom connectors for Consumption workflows](../logic-apps/custom-connector-overview.md#custom-connector-consumption)
 
@@ -138,7 +138,17 @@ In Standard workflows for single-tenant Azure Logic Apps, you can create nativel
 
 ## ISE and connectors
 
-For workflows that need direct access to resources in an Azure virtual network, you can use a dedicated [integration service environment (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md) where you can build, deploy, and run your workflows on dedicated resources.
+> [!IMPORTANT]
+>
+> On August 31, 2024, the ISE resource retires, due to its dependency on Azure Cloud Services (classic), 
+> which retires at the same time. Before the retirement date, export any logic apps from your ISE to Standard 
+> logic apps to avoid service disruption. Standard logic app workflows run in single-tenant Azure Logic Apps 
+> and provide the same capabilities plus more. For example, Standard workflows support using private endpoints 
+> for inbound traffic so that your workflows can communicate privately and securely with virtual networks. 
+> Standard workflows also support virtual network integration for outbound traffic. For more information, 
+> review [Secure traffic between virtual networks and single-tenant Azure Logic Apps using private endpoints](/azure/logic-apps/secure-single-tenant-workflow-virtual-network-private-endpoint).
+
+If you use a dedicated [integration service environment (ISE)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md) where workflows can directly access to resources in an Azure virtual network, you can build, deploy, and run your workflows on dedicated resources.
 
 Custom connectors created within an ISE don't work with the on-premises data gateway. However, these connectors can directly access on-premises data sources that are connected to an Azure virtual network hosting the ISE. So, logic app workflows in an ISE most likely don't need the data gateway when communicating with those resources. If you have custom connectors that you created outside an ISE that require the on-premises data gateway, workflows in an ISE can use those connectors.
 
@@ -147,36 +157,20 @@ In the workflow designer, when you browse the built-in connectors or managed con
 :::row:::
     :::column:::
         ![Example CORE connector](./media/apis-list/example-core-connector.png)
-        \
-        \
-        **CORE**
-        \
-        \
-        Built-in connectors with this label run in the same ISE as your workflows.
+        <br><br>**CORE**
+        <br><br>Built-in connectors with this label run in the same ISE as your workflows.
     :::column-end:::
     :::column:::
         ![Example ISE connector](./media/apis-list/example-ise-connector.png)
-        \
-        \
-        **ISE**
-        \
-        \
-        Managed connectors with this label run in the same ISE as your workflows.
-        \
-        \
-        If you have an on-premises system that's connected to an Azure virtual network, an ISE lets your workflows directly access that system without using the [on-premises data gateway](../logic-apps/logic-apps-gateway-connection.md). Instead, you can either use that system's **ISE** connector if available, an HTTP action, or a [custom connector](#custom-connectors-and-apis).
-        \
-        \
-        For on-premises systems that don't have **ISE** connectors, use the on-premises data gateway. To find available ISE connectors, review [ISE connectors](#ise-and-connectors).
+        <br><br>**ISE**
+        <br><br>Managed connectors with this label run in the same ISE as your workflows.
+        <br><br>If you have an on-premises system that's connected to an Azure virtual network, an ISE lets your workflows directly access that system without using the [on-premises data gateway](../logic-apps/logic-apps-gateway-connection.md). Instead, you can either use that system's **ISE** connector if available, an HTTP action, or a [custom connector](#custom-connectors-and-apis).
+        <br><br>For on-premises systems that don't have **ISE** connectors, use the on-premises data gateway. To find available ISE connectors, review [ISE connectors](#ise-and-connectors).
     :::column-end:::
     :::column:::
-        ![Example non-ISE connector](./media/apis-list/example-multi-tenant-connector.png)
-        \
-        \
-        No label
-        \
-        \
-        All other connectors without a label, which you can continue to use, run in the global, multi-tenant Logic Apps service.
+        ![Example non-ISE connector](./media/apis-list/example-multitenant-connector.png)
+        <br><br>No label
+        <br><br>All other connectors without a label, which you can continue to use, run in the global, multitenant Logic Apps service.
     :::column-end:::
     :::column:::
     :::column-end:::

articles/connectors/managed.md

@@ -15,7 +15,7 @@ Managed connectors provide ways for you to access other services and systems whe
 
 For a smaller number of services, systems and protocols, Azure Logic Apps provides a built-in version alongside the managed version. The number and range of built-in connectors vary based on whether you create a Consumption logic app workflow that runs in multitenant Azure Logic Apps or a Standard logic app workflow that runs in single-tenant Azure Logic Apps. In most cases, the built-in version provides better performance, capabilities, pricing, and so on. In a few cases, some built-in connectors are available only in one logic app workflow type, and not the other.
 
-For example, a Standard workflow can use both managed connectors and built-in connectors for Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, and SQL Server, while a Consumption workflow doesn't have the built-in versions. A Consumption workflow can use built-in connectors for Azure API Management, Azure App Services, and Batch, while a Standard workflow doesn't have these built-in connectors. For more information, review [Built-in connectors in Azure Logic Apps](built-in.md) and [Single-tenant versus multitenant and integration service environment (ISE)](../logic-apps/single-tenant-overview-compare.md).
+For example, a Standard workflow can use both managed connectors and built-in connectors for Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, and SQL Server, while a Consumption workflow doesn't have the built-in versions. A Consumption workflow can use built-in connectors for Azure API Management, Azure App Services, and Batch, while a Standard workflow doesn't have these built-in connectors. For more information, review [Built-in connectors in Azure Logic Apps](built-in.md) and [Single-tenant versus multitenant in Azure Logic Apps](../logic-apps/single-tenant-overview-compare.md).
 
 This article provides a general overview about managed connectors and the way they're organized in the Consumption workflow designer versus the Standard workflow designer with examples. For technical reference information about each managed connector in Azure Logic Apps, review [Connectors reference for Azure Logic Apps](/connectors/connector-reference/connector-reference-logicapps-connectors).
 
@@ -37,8 +37,6 @@ Some managed connectors also fall into the following informal groups:
 
 * [Integration account connectors](#integration-account-connectors) help you transform and validate XML, encode and decode flat files, and process business-to-business (B2B) messages using AS2, EDIFACT, and X12 protocols.
 
-* [Integration service environment connectors](#ise-connectors) and are designed to run specifically in an ISE and provide benefits over their non-ISE versions.
-
 <a name="standard-connectors"></a>
 
 ## Standard connectors

articles/connectors/media/apis-list/example-multi-tenant-connector.png renamed to articles/connectors/media/apis-list/example-multitenant-connector.png

@@ -85,7 +85,7 @@ In this tutorial, you learn how to:
    > make sure that you create a *stateful* workflow, not a stateless workflow. This tutorial applies only 
    > to Consumption logic apps, which follow a different user experience. To add Azure Event Grid operations 
    > to your workflow in the designer, on the operations picker pane, make sure that you select the **Azure** tab. 
-   > For more information about multitenant versus single-tenant Azure Logic Apps, review [Single-tenant versus multitenant and integration service environment](../logic-apps/single-tenant-overview-compare.md).
+   > For more information about multitenant versus single-tenant Azure Logic Apps, review [Single-tenant versus multitenant](../logic-apps/single-tenant-overview-compare.md).
 
 1. When you're done, select **Review + create**. On the next pane, confirm the provided information, and select **Create**.
 

articles/event-grid/monitor-virtual-machine-changes-logic-app.md

@@ -23,7 +23,7 @@ For example, this cluster can be Azure Kubernetes Service, bare-metal Kubernetes
 For more information, review the following documentation:
 
 - [What is Azure Arc-enabled Logic Apps?](azure-arc-enabled-logic-apps-overview.md)
-- [Single-tenant versus multitenant and integration service environment](../logic-apps/single-tenant-overview-compare.md)
+- [Single-tenant versus multitenant in Azure Logic Apps](../logic-apps/single-tenant-overview-compare.md)
 - [Azure Arc overview](../azure-arc/overview.md)
 - [Azure Kubernetes Service overview](/azure/aks/intro-kubernetes)
 - [What is Azure Arc-enabled Kubernetes?](../azure-arc/kubernetes/overview.md)

articles/logic-apps/azure-arc-enabled-logic-apps-create-deploy-workflows.md

@@ -27,7 +27,7 @@ With Azure Arc-enabled Logic Apps, you can develop and run single-tenant based l
 For more information, review the following documentation:
 
 - [What is Azure Logic Apps?](../logic-apps/logic-apps-overview.md)
-- [Single-tenant versus other Logic Apps environments](../logic-apps/single-tenant-overview-compare.md)
+- [Single-tenant versus multitenant in Azure Logic Apps](../logic-apps/single-tenant-overview-compare.md)
 - [Azure Arc overview](../azure-arc/overview.md)
 - [Azure Kubernetes Service overview](/azure/aks/intro-kubernetes)
 - [What is Azure Arc-enabled Kubernetes?](../azure-arc/kubernetes/overview.md)
@@ -39,13 +39,13 @@ For more information, review the following documentation:
 
 With Azure Arc-enabled Logic Apps, you can create and deploy logic app workflows in the same way as in the single-tenant experience for Azure Logic Apps. You also gain more control and flexibility when you have logic apps running on a Kubernetes infrastructure that you operate and manage.
 
-Minor differences exist between the Azure Arc and single-tenant Logic Apps experiences for creating, designing, and deploying logic apps. When you use Azure Arc-enabled Logic Apps, the major difference is that your logic apps run in a *custom location*. This location is mapped to an Azure Arc-enabled Kubernetes cluster where you have installed and enabled the Azure App Service platform extensions bundle.
+Minor differences exist between the Azure Arc and single-tenant Azure Logic Apps experiences for creating, designing, and deploying logic apps. When you use Azure Arc-enabled Logic Apps, the major difference is that your logic apps run in a *custom location*. This location is mapped to an Azure Arc-enabled Kubernetes cluster where you have installed and enabled the Azure App Service platform extensions bundle.
 
 For example, this cluster can be Azure Kubernetes Service, bare-metal Kubernetes, or another setup. The extensions bundle enables you to run platform services such as Azure Logic Apps, Azure Functions, and Azure App Service on your Kubernetes cluster.
 
 For more information, review the following documentation:
 
-- [Single-tenant versus other Azure Logic Apps environments](../logic-apps/single-tenant-overview-compare.md)
+- [Single-tenant versus multitenant in Azure Logic Apps](../logic-apps/single-tenant-overview-compare.md)
 - [Azure Kubernetes Service overview](/azure/aks/intro-kubernetes)
 - [What is Azure Arc-enabled Kubernetes?](../azure-arc/kubernetes/overview.md)
 - [Custom locations on Azure Arc-enabled Kubernetes](../azure-arc/kubernetes/conceptual-custom-locations.md)
@@ -56,15 +56,15 @@ For more information, review the following documentation:
 
 ## When to use Azure Arc-enabled Logic Apps
 
-Although Kubernetes provides more control and flexibility, you also have operational overhead. If you're satisfied that the Logic Apps service meets your needs, you're encouraged to continue using this service. However, consider using Azure Arc-enabled Logic Apps when you have the following scenarios:
+Although Kubernetes provides more control and flexibility, you also have operational overhead. If you're satisfied that Azure Logic Apps meets your needs, you're encouraged to continue using this service. However, consider using Azure Arc-enabled Logic Apps when you have the following scenarios:
 
 - You already run all your apps and services on Kubernetes. You want to extend these processes and controls to all your other PaaS services.
 
-- You want to use Logic Apps as your integration platform. However, you need fine grained networking with compute control and flexibility. You don't want to use an integration service environment (ISE) or App Service Environment (ASE).
+- You want to use Azure Logic Apps as your integration platform. However, you need fine grained networking with compute control and flexibility. You don't want to use an App Service Environment (ASE).
 
 - For security reasons, you need control over where your logic apps run, for example, in your own region or in your own datacenter. 
 
-- You want to run your logic apps in multi-cloud scenarios and use the Logic Apps service as your sole integration platform for all your applications wherever they run.
+- You want to run your logic apps in multi-cloud scenarios and use Azure Logic Apps as your sole integration platform for all your applications wherever they run.
 
 <a name="compare"></a>
 
@@ -77,10 +77,10 @@ This table provides a high-level comparison between the capabilities in the curr
       **Capability**
    :::column-end:::
    :::column:::
-      **Multi-tenant Logic Apps (Consumption)**
+      **Multitenant Azure Logic Apps (Consumption)**
    :::column-end:::
    :::column:::
-      **Single-tenant Logic Apps (Standard)**
+      **Single-tenant Azure Logic Apps (Standard)**
    :::column-end:::
    :::column:::
       **Standalone containers** <br><br>**Note**: Unsupported for workflows in production environments. For fully supported containers, [create Azure Arc-enabled Logic Apps workflows](azure-arc-enabled-logic-apps-create-deploy-workflows.md) instead.
@@ -128,16 +128,16 @@ This table provides a high-level comparison between the capabilities in the curr
       Management
    :::column-end:::
    :::column:::
-      Fully managed Logic Apps experience
+      Fully managed Azure Logic Apps experience
    :::column-end:::
    :::column:::
-      Fully managed Logic Apps experience
+      Fully managed Azure Logic Apps experience
    :::column-end:::
    :::column:::
       Not managed
    :::column-end:::
    :::column:::
-      Managed Logic Apps experience with operational control at the Kubernetes level
+      Managed Azure Logic Apps experience with operational control at the Kubernetes level
    :::column-end:::
 :::row-end:::
 :::row:::