More ISE clean up

Author: ecfan

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/introduction.md

@@ -146,7 +146,7 @@ In Standard workflows for single-tenant Azure Logic Apps, you can create nativel
 > 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](secure-single-tenant-workflow-virtual-network-private-endpoint.md).
+> review [Secure traffic between virtual networks and single-tenant Azure Logic Apps using private endpoints](../logic-apps/secure-single-tenant-workflow-virtual-network-private-endpoint.md).
 
 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.
 

articles/logic-apps/azure-arc-enabled-logic-apps-create-deploy-workflows.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-overview.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:::

articles/logic-apps/business-continuity-disaster-recovery-guidance.md

@@ -20,40 +20,37 @@ This article provides BCDR guidance and strategies that you can apply when you b
 
 * [Integration accounts](../logic-apps/logic-apps-enterprise-integration-create-integration-account.md) where you define and store the artifacts that logic apps use for [business-to-business (B2B) enterprise integration](../logic-apps/logic-apps-enterprise-integration-overview.md) scenarios. For example, you can [set up cross-region disaster recovery for integration accounts](../logic-apps/logic-apps-enterprise-integration-b2b-business-continuity.md).
 
-* [Integration service environments (ISEs)](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md) where you create logic apps that run in an isolated Logic Apps runtime instance within an Azure virtual network. These logic apps can then access resources that are protected behind a firewall in that virtual network.
-
 <a name="primary-secondary-locations"></a>
 
 ## Primary and secondary locations
 
-Each logic app needs to specify the location that you want to use for deployment. This location is either a public region in global multi-tenant Azure, such as "West US", or an integration service environment (ISE) that you previously created and deployed into an Azure virtual network. Running logic apps in an ISE is similar to running logic apps in a global Azure region, which means your disaster recovery strategy can apply to both scenarios. However, ISEs have other considerations such as configuring access to resources that are available only to ISEs.
+Each logic app needs to specify the location that you want to use for deployment, such as an Azure region, for example, "West US". This disaster recovery strategy focuses on setting up your primary logic app to [*failover*](https://en.wikipedia.org/wiki/Failover) onto a standby or backup logic app in an alternate location where Azure Logic Apps is also available. That way, if the primary suffers losses, disruptions, or failures, the secondary can take on the work. This strategy requires that your secondary logic app and dependent resources are already deployed and ready in the alternate location.
 
 > [!NOTE]
+>
 > If your logic app also works with B2B artifacts, such as trading partners, agreements, schemas, maps, and certificates, 
-> which are stored in an integration account, both your integration account and logic apps must specify the same location.
-
-This disaster recovery strategy focuses on setting up your primary logic app to [*failover*](https://en.wikipedia.org/wiki/Failover) onto a standby or backup logic app in an alternate location where Azure Logic Apps is also available. That way, if the primary suffers losses, disruptions, or failures, the secondary can take on the work. This strategy requires that your secondary logic app and dependent resources are already deployed and ready in the alternate location.
+> which are stored in an integration account, both your integration account and logic apps must use the same location.
 
 If you follow good DevOps practices, you already use [Azure Resource Manager templates](../azure-resource-manager/management/overview.md) to define and deploy your logic apps and their dependent resources. Resource Manager templates give you the capability to use a single deployment definition and then use parameter files to provide the configuration values to use for each deployment destination. This capability means that you can deploy the same logic app to different environments, for example, development, test, and production. You can also deploy the same logic app to different Azure regions or ISEs, which support disaster recovery strategies that use [paired-regions](../availability-zones/cross-region-replication-azure.md).
 
 For the failover strategy, your logic apps and locations must meet these requirements:
 
 * The secondary logic app instance has access to the same apps, services, and systems as the primary logic app instance.
 
-* Both logic app instances have the same host type. So, either both instances are deployed to regions in global multi-tenant Azure, or both instances are deployed to ISEs, which let your logic apps directly access resources in an Azure virtual network. For best practices and more information about paired regions for BCDR, see [Cross-region replication in Azure: Business continuity and disaster recovery](../availability-zones/cross-region-replication-azure.md).
+* Both logic app instances have the same host type. So, either both instances are deployed to regions in global multitenant Azure, or both instances are deployed to ISEs, which let your logic apps directly access resources in an Azure virtual network. For best practices and more information about paired regions for BCDR, see [Cross-region replication in Azure: Business continuity and disaster recovery](../availability-zones/cross-region-replication-azure.md).
 
   For example, both the primary and secondary locations must be ISEs when the primary logic app runs in an ISE and uses [ISE-versioned connectors](../connectors/managed.md#ise-connectors), HTTP actions to call resources in the Azure virtual network, or both. In this scenario, your secondary logic app must also have a similar setup in the secondary location as the primary logic app.
 
   > [!NOTE]
-  > For more advanced scenarios, you can mix both multi-tenant Azure and an 
+  > For more advanced scenarios, you can mix both multitenant Azure and an 
   > ISE as locations. However, make sure that you consider and understand the 
-  > [differences between how logic apps run in an ISE versus multi-tenant Azure](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#difference).
+  > [differences between how logic apps run in an ISE versus multitenant Azure](../logic-apps/connect-virtual-network-vnet-isolated-environment-overview.md#difference).
 
 * If you use ISEs, [make sure that they are scaled out or have enough capacity](../logic-apps/ise-manage-integration-service-environment.md#add-capacity) to handle the load.
 
-#### Example: Multi-tenant Azure
+#### Example: Multitenant Azure
 
-This example shows primary and secondary logic app instances, which are deployed to separate regions in the global multi-tenant Azure for this scenario. A single [Resource Manager template](../logic-apps/logic-apps-azure-resource-manager-templates-overview.md) defines both logic app instances and the dependent resources required by those logic apps. Separate parameter files specify the configuration values to use for each deployment location:
+This example shows primary and secondary logic app instances, which are deployed to separate regions in the global multitenant Azure for this scenario. A single [Resource Manager template](../logic-apps/logic-apps-azure-resource-manager-templates-overview.md) defines both logic app instances and the dependent resources required by those logic apps. Separate parameter files specify the configuration values to use for each deployment location:
 
 ![Primary and secondary logic app instances in separate locations](./media/business-continuity-disaster-recovery-guidance/primary-secondary-locations.png)
 
@@ -83,7 +80,7 @@ For your disaster recovery strategy, consider the locations where dependent reso
 
 ## On-premises data gateways
 
-If your logic app runs in multi-tenant Azure and needs access to on-premises resources such as SQL Server databases, you need to install the [on-premises data gateway](../logic-apps/logic-apps-gateway-install.md) on a local computer. You can then create a data gateway resource in the Azure portal so that your logic app can use the gateway when you create a connection to the resource.
+If your logic app runs in multitenant Azure and needs access to on-premises resources such as SQL Server databases, you need to install the [on-premises data gateway](../logic-apps/logic-apps-gateway-install.md) on a local computer. You can then create a data gateway resource in the Azure portal so that your logic app can use the gateway when you create a connection to the resource.
 
 The data gateway resource is associated with a location or Azure region, just like your logic app resource. In your disaster recovery strategy, make sure that the data gateway remains available for your logic app to use. You can [enable high availability for your gateway](../logic-apps/logic-apps-gateway-install.md#high-availability) when you have multiple gateway installations.
 
@@ -94,7 +91,7 @@ The data gateway resource is associated with a location or Azure region, just li
 >
 > If no ISE-versioned connector is available for the on-premises resource that you want, 
 > your logic app can still create the connection by using a non-ISE connector, 
-> which runs in the global multi-tenant Azure, not your ISE. However, this connection 
+> which runs in the global multitenant Azure, not your ISE. However, this connection 
 > requires the on-premises data gateway.
 
 <a name="roles"></a>

articles/logic-apps/create-custom-built-in-connector-standard.md

@@ -35,7 +35,7 @@ For more information, review the following documentation:
 
 * Basic knowledge about single-tenant Azure Logic Apps, Standard logic app workflows, connectors, and how to use Visual Studio Code for creating single tenant-based workflows. For more information, review the following documentation:
 
-  * [Single-tenant versus multi-tenant and integration service environment for Azure Logic Apps](single-tenant-overview-compare.md)
+  * [Single-tenant versus multitenant in Azure Logic Apps](single-tenant-overview-compare.md)
 
   * [Create an integration workflow with single-tenant Azure Logic Apps (Standard) - Azure portal](create-single-tenant-workflows-azure-portal.md)
 

articles/logic-apps/create-replication-tasks-azure-resources.md

@@ -22,7 +22,7 @@ To reduce the effect that unpredictable events can have on your Azure resources
 > You can also use replication tasks to move content between entities in the same region, but if the 
 > entire region becomes unavailable or experiences disruption, both source and target are affected.
 
-This article provides an overview about replication tasks powered by Azure Logic Apps and shows how to create an example replication task for Azure Service Bus queues. If you're new to logic apps and workflows, review [What is Azure Logic Apps](logic-apps-overview.md) and [Single-tenant versus multitenant and integration service environment for Azure Logic Apps](single-tenant-overview-compare.md).
+This article provides an overview about replication tasks powered by Azure Logic Apps and shows how to create an example replication task for Azure Service Bus queues. If you're new to logic apps and workflows, review [What is Azure Logic Apps](logic-apps-overview.md) and [Single-tenant versus multitenant in Azure Logic Apps](single-tenant-overview-compare.md).
 
 <a name="replication-task"></a>