Update msdate

Author: Michael Bender

articles/virtual-network-manager/concept-cross-tenant.md

@@ -12,17 +12,17 @@ ms.custom: template-concept
 
 # Cross-tenant support in Azure Virtual Network Manager
 
-In this article, you’ll learn about cross-tenant support in Azure Virtual Network Manager. Cross-tenant supports allows organizations to use a central Network Manager instance for managing virtual networks across different tenants and subscriptions.
+In this article, you learn about cross-tenant support in Azure Virtual Network Manager. Cross-tenant supports allows organizations to use a central Network Manager instance for managing virtual networks across different tenants and subscriptions.
 
 [!INCLUDE [virtual-network-manager-preview](../../includes/virtual-network-manager-preview.md)]
 
  ## Overview of Cross-tenant 
 
-Cross-tenant support in Azure Virtual Network Manager allows you to add subscriptions or management groups from other tenants to your network manager. This is done by establishing a two-way connection between the network manager and target tenants. Once connected, the central manager can deploy connectivity and/or security admin rules to virtual networks across those connected subscriptions or management groups. This support will assist organizations that fit the following scenarios: 
+Cross-tenant support in Azure Virtual Network Manager allows you to add subscriptions or management groups from other tenants to your network manager. This is done by establishing a two-way connection between the network manager and target tenants. Once connected, the central manager can deploy connectivity and/or security admin rules to virtual networks across those connected subscriptions or management groups. This support assists organizations that fit the following scenarios: 
 
 - Acquisitions – In instances where organizations merge through acquisition and have multiple tenants, cross tenant support allows a central network manager to manage virtual networks across the tenants. 
 
-- Managed service provider – In managed service provider scenarios, an organization may manage the resources of other organizations. Cross-tenant support will allow central management of virtual networks by a central service provider for multiple clients. 
+- Managed service provider – In managed service provider scenarios, an organization can manage the resources of other organizations. Cross-tenant support allows central management of virtual networks by a central service provider for multiple clients. 
 
 ## Cross-tenant connection 
 
@@ -31,12 +31,12 @@ Establishing cross-tenant support begins with creating a cross tenant connection
 - Network manager connection - You create a cross-tenant connection from your network manager. The connection includes the exact scope of the tenant’s subscriptions or management groups to manage in your network manager.
 - Virtual network manager hub connection - the tenant creates a cross-tenant connection from their virtual network manager hub. This connection includes the scope of subscriptions or management groups to be managed by the central network manager.
 
-Once both cross-tenant connections exist and the scopes are exactly the same, a true connection is established. Administrators can use their network manager to add cross-tenant resources to their [network groups](concept-network-groups.md) and to manage virtual networks included in the connection scope. Existing connectivity and/or security admin rules will be applied to the resources based on existing configurations.
+Once both cross-tenant connections exist and the scopes are exactly the same, a true connection is established. Administrators can use their network manager to add cross-tenant resources to their [network groups](concept-network-groups.md) and to manage virtual networks included in the connection scope. Existing connectivity and/or security admin rules are applied to the resources based on existing configurations.
 
-A cross-tenant connection can only be established and maintained when both objects from each party exist. When one of the connections is removed, the cross-tenant connection is broken. If you need to delete a cross-tenant connection, you'll perform the following:
+A cross-tenant connection can only be established and maintained when both objects from each party exist. When one of the connections is removed, the cross-tenant connection is broken. If you need to delete a cross-tenant connection, you perform the following:
 
-- Remove cross-tenant connection from the network manager side via Cross-tenant connections blade.
-- Remove cross-tenant connection from the tenant side via Virtual network manager hub's Cross-tenant connections blade.
+- Remove cross-tenant connection from the network manager side via Cross-tenant connections settings in the Azure portal.
+- Remove cross-tenant connection from the tenant side via Virtual network manager hub's Cross-tenant connections settings in the Azure portal.
 
 > [!NOTE] 
 > Once a connection is removed from either side, the network manager will no longer be able to view or manage the tenant's resources under that former connection's scope.
@@ -45,8 +45,8 @@ A cross-tenant connection can only be established and maintained when both objec
 The resources required to create the cross-tenant connection contain a state, which represents whether the associated scope has been added to the Network Manager scope. Possible state values include:
 
 * Connected: Both the Scope Connection and Network Manager Connection resources exist. The scope has been added to the Network Manager's scope.
-* Pending: One of the two approval resources has not been created. The scope has not yet been added to the Network Manager's scope.
-* Conflict: There is already a network manager with this subscription or management group defined within its scope. Two network managers with the same scope access cannot directly manage the same scope, therefore this subscription/management group cannot be added to the Network Manager scope. To resolve the conflict, remove the scope from the conflicting network manager's scope and recreate the connection resource.
+* Pending: One of the two approval resources hasn't been created. The scope hasn't yet been added to the Network Manager's scope.
+* Conflict: There's already a network manager with this subscription or management group defined within its scope. Two network managers with the same scope access can't directly manage the same scope, therefore this subscription/management group can't be added to the Network Manager scope. To resolve the conflict, remove the scope from the conflicting network manager's scope and recreate the connection resource.
 * Revoked: The scope was at one time added to the Network Manager scope, but the removal of an approval resource has caused it to be revoked.
 
 The only state that represents the scope has been added to the Network Manager scope is 'Connected'.

articles/virtual-network-manager/concept-enforcement.md

@@ -15,7 +15,7 @@ In this article, you'll learn how [security admins rules](concept-security-admin
 
 ## Virtual network enforcement 
 
-With [network security groups (NSGs)](../virtual-network/network-security-group-how-it-works.md) alone, widespread enforcement on VNets across several applications, teams, or even entire organizations can be tricky. Often there’s a balancing act between attempts at centralized enforcement across an organization and handing over granular, flexible control to teams. 
+With [network security groups (NSGs)](../virtual-network/network-security-group-how-it-works.md) alone, widespread enforcement on virtual networks across several applications, teams, or even entire organizations can be tricky. Often there’s a balancing act between attempts at centralized enforcement across an organization and handing over granular, flexible control to teams. 
 
 [Security admin rules](concept-security-admins.md) aim to eliminate this sliding scale between enforcement and flexibility altogether by consolidating the pros of each of these models while reducing the cons of each. Central governance teams establish guard rails through security admin rules, while still leaving room for individual teams to flexibly pinpoint security as needed through NSG rules. Security admin rules aren't meant to override NSG rules. Instead, they work with NSG rules to provide enforcement and flexibility across your organization.
 
@@ -58,9 +58,9 @@ In this case, the administrator wants to make an exception to the application vi
 
 The company administrator can create a network manager with the root management group of the firm as the scope of this network manager instance.
 
-#### Step 2: Create network groups for VNets
+#### Step 2: Create network groups for virtual networks
 
-The administrator creates two network groups – *ALL network group* consisting of all the VNets in the organization, and App network group consisting of VNets for the application needing an exception. ALL network group in the above diagram consists of *VNet 1* to *VNet 5*, and App network group has *VNet 4* and *VNet 5*. Users can easily define both network groups using dynamic membership.
+The administrator creates two network groups – *ALL network group* consisting of all the virtual networks in the organization, and App network group consisting of virtual networks for the application needing an exception. ALL network group in the above diagram consists of *VNet 1* to *VNet 5*, and App network group has *VNet 4* and *VNet 5*. Users can easily define both network groups using dynamic membership.
 
 #### Step 3: Create a security admin configuration
 
@@ -70,7 +70,7 @@ In this step, two security admin rules are defined with the following security a
 
 #### Step 4: Deploy the security admin configuration
 
-After the deployment of the security admin configuration, all VNets in the company have the deny inbound SSH traffic rule enforced by the security admin rule. No individual team can modify this rule, only the defined company administrator. The App VNets have both an allow inbound SSH traffic rule and a deny inbound SSH traffic rule (inherited from All network group rule). The priority number of the allow inbound SSH traffic rule for App network group should be smaller so that it's evaluated first. When inbound SSH traffic comes to an App VNet, it is allowed by this higher priority security admin rule. Assuming there are NSGs on the subnets of the App VNets, this inbound SSH traffic is further evaluated by NSGs set by the application team. The security admin rule methodology described here allows the company administrator to effectively enforce company policies and create flexible security guard rails across an organization that work with NSGs.
+After the deployment of the security admin configuration, all virtual networks in the company have the deny inbound SSH traffic rule enforced by the security admin rule. No individual team can modify this rule, only the defined company administrator. The App virtual networks have both an allow inbound SSH traffic rule and a deny inbound SSH traffic rule (inherited from All network group rule). The priority number of the allow inbound SSH traffic rule for App network group should be smaller so that it's evaluated first. When inbound SSH traffic comes to an App VNet, it's allowed by this higher priority security admin rule. Assuming there are NSGs on the subnets of the App virtual networks, this inbound SSH traffic is further evaluated by NSGs set by the application team. The security admin rule methodology described here allows the company administrator to effectively enforce company policies and create flexible security guard rails across an organization that work with NSGs.
 
 
 ## Next steps