Merge pull request #200701 from dknappettmsft/avd-data-locations-refresh

AVD data locations refresh

Author: 19BMG00

articles/virtual-desktop/data-locations.md

@@ -4,51 +4,50 @@ description: A brief overview of which locations Azure Virtual Desktop's data an
 author: Heidilohr
 ms.topic: conceptual
 ms.custom: references_regions
-ms.date: 06/30/2021
+ms.date: 06/07/2022
 ms.author: helohr
 manager: femila
 ---
 # Data locations for Azure Virtual Desktop
 
-Azure Virtual Desktop is currently available for all geographical locations. Administrators can choose the location to store user data when they create the host pool virtual machines and associated services, such as file servers. Learn more about Azure geographies at [Data residency in Azure](https://azure.microsoft.com/global-infrastructure/data-residency/#overview).
+Azure Virtual Desktop is available in many Azure regions, which are grouped by geography. When Azure Virtual Desktop resources are deployed, you have to specify the Azure region they'll be created in. The location of the resource determines where its information will be stored and the geography where related information will be stored. Azure Virtual Desktop itself is a non-regional service where there's no dependency on a specific Azure region. Learn more about [Data residency in Azure](https://azure.microsoft.com/global-infrastructure/data-residency/#overview) and [Azure geographies](https://azure.microsoft.com/global-infrastructure/geographies/).
 
->[!NOTE]
->Microsoft doesn't control or limit the regions where you or your users can access your user and app-specific data.
+Azure Virtual Desktop stores various information for service objects, such as host pool names, application group names, workspace names, and user principal names. Data is categorized into different types, such as customer input, customer data, diagnostic data, and service-generated data. For more information about data category definitions, see [How Microsoft categorizes data for online services](https://www.microsoft.com/trust-center/privacy/customer-data-definitions).
 
->[!IMPORTANT]
->Azure Virtual Desktop stores various types of information like host pool names, app group names, workspace names, and user principal names in a datacenter. While creating any of the service objects, the customer has to enter the location where the object needs to be created. The location of this object determines where the information for the object will be stored. The customer will choose an Azure region and the related information will be stored in the associated geography. Customers also choose a region for the Session host Virtual Machines in an additional step in the deployment process. This region can be any Azure region, hence it can be the same region as the service objects or a separate region. For a list of all Azure regions and related geographies, visit [https://azure.microsoft.com/global-infrastructure/geographies/](https://azure.microsoft.com/global-infrastructure/geographies/).
-
-This article describes which information the Azure Virtual Desktop service stores. To learn more about the customer data definitions, see [How Microsoft categorizes data for online services](https://www.microsoft.com/trust-center/privacy/customer-data-definitions).
+> [!NOTE]
+> Microsoft doesn't control or limit the regions where you or your users can access your user and app-specific data.
 
 ## Customer input
 
-To set up the Azure Virtual Desktop service, the customer must create host pools and other service objects. During configuration, the customer must give information like the host pool name, application group name, and so on. This information is considered customer input. Customer input is stored in the geography associated with the region the object is created in. Azure Resource Manager paths to the objects are considered organizational information, so data residency doesn't apply to them. Data about Azure Resource Manager paths will be stored outside of the chosen geography.
+To set up Azure Virtual Desktop, you must create host pools and other service objects. During configuration, you must enter information such as the host pool name, application group name, and so on. This information is considered *customer input*. Customer input is stored in the geography associated with the Azure region the resource is created in. Azure Resource Manager paths to the objects are considered organizational information, so data residency doesn't apply to them. Data about Azure Resource Manager paths will be stored outside of the chosen geography.
 
 ## Customer data
 
-The service doesn't directly store any user created or app-related information, but it does store customer data like application names and user principal names because they're part of the object setup process. This information is stored in the geography associated with the region the customer created the object in.
+The Azure Virtual Desktop service doesn't directly store any user-created or app-related information, but it does store customer data, such as application names and user principal names, because they're part of the resource deployment process. This information is stored in the geography associated with the region you created the resource in. 
 
 ## Diagnostic data
 
-Azure Virtual Desktop gathers service-generated diagnostic data whenever the customer or user interacts with the service. This data is only used for troubleshooting, support, and checking the health of the service in aggregate form. For example, from the session host side, when a VM registers to the service, we generate information that includes the virtual machine (VM) name, which host pool the VM belongs to, and so on. This information is stored in the geography associated with the region the host pool is created in. Also, when a user connects to the service and launches a remote desktop, we generate diagnostic information that includes the user principal name, client location, client IP address, which host pool the user is connecting to, and so on. This information is sent to two different locations:
+Diagnostic data is generated by the Azure Virtual Desktop service and is gathered whenever administrators or users interact with the service. This data is only used for troubleshooting, support, and checking the health of the service in aggregate form. For example, when a session host VM is registered to a host pool, information is generated that includes the virtual machine (VM) name, which host pool the VM belongs to, and so on. This information is stored in the geography associated with the Azure region the host pool is created in. Also, when a user connects to the service and launches a session, diagnostic information is generated that includes the user principal name, client location, client IP address, which host pool the user is connecting to, and so on. This information is sent to two different locations:
 
-- The location closest to the user where the service infrastructure (client traces, user traces, diagnostic data) is present.
+- The location closest to the user where the service infrastructure (client traces, user traces, and diagnostic data) is present.
 - The location where the host pool is located.
 
 ## Service-generated data
 
-To keep Azure Virtual Desktop reliable and scalable, we aggregate traffic patterns and usage to check the health and performance of the infrastructure control plane. For example, to understand how to ramp up regional infrastructure capacity as service usage increases, we process service usage log data. We then review the logs for peak times and decide which data centers to add to meet this capacity. 
+To keep Azure Virtual Desktop reliable and scalable, traffic patterns and usage are aggregated to check the health and performance of the infrastructure control plane. For example, to help us understand how to ramp up regional infrastructure capacity as service usage increases, we process service usage log data. We then review the logs for peak times and decide where to increase capacity. 
 
-We currently support storing the aforementioned data in the following locations:
+Storing service-generated data is currently supported in the following geographies:
 
 - United States (US)
 - Europe (EU)
 - United Kingdom (UK)
 - Canada (CA)
-- Japan (JP) (Public Preview)
+- Japan (JP) \**in Public Preview*
+
+In addition, service-generated data is aggregated from all locations where the service infrastructure is, and sent to the US geography. The data sent to the US includes scrubbed data, but not customer data.
 
-In addition we aggregate service-generated from all locations where the service infrastructure is, then send it to the US geography. The data sent to the US region includes scrubbed data, but not customer data.
+## Data storage
 
-More geographies will be added as the service grows. The stored information is encrypted at rest, and geo-redundant mirrors are maintained within the geography. Customer data, such as app settings and user data, resides in the location the customer chooses and isn't managed by the service.
+Stored information is encrypted at rest, and geo-redundant mirrors are maintained within the geography. Data generated by the Azure Virtual Desktop service is replicated within the Azure geography for disaster recovery purposes. 
 
-The outlined data is replicated within the Azure geography for disaster recovery purposes.
+User-created or app-related information, such as app settings and user data, resides in the Azure region you choose and isn't managed by the Azure Virtual Desktop service.