[AzureADDS] Freshness updates and edits

Author: iainfoulds

articles/active-directory-domain-services/manage-dns.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 08/07/2019
+ms.date: 10/31/2019
 ms.author: iainfou
 
 ---

articles/active-directory-domain-services/manage-group-policy.md

@@ -9,14 +9,16 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 08/05/2019
+ms.date: 10/31/2019
 ms.author: iainfou
 
 ---
 # Administer Group Policy in an Azure AD Domain Services managed domain
 
 Settings for user and computer objects in Azure Active Directory Domain Services (Azure AD DS) are often managed using Group Policy Objects (GPOs). Azure AD DS includes built-in GPOs for the *AADDC Users* and *AADDC Computers* containers. You can customize these built-in GPOs to configure Group Policy as needed for your environment. Members of the *Azure AD DC administrators* group have Group Policy administration privileges in the Azure AD DS domain, and can also create custom GPOs and organizational units (OUs). More more information on what Group Policy is and how it works, see [Group Policy overview][group-policy-overview].
 
+In a hybrid environment, group policies configured in an on-premises AD DS environment aren't synchronized to Azure AD DS. To define configuration settings for users or computers in Azure AD DS, edit one of the default GPOs or create a custom GPO.
+
 This article shows you how to install the Group Policy Management tools, then edit the built-in GPOs and create custom GPOs.
 
 [!INCLUDE [active-directory-ds-prerequisites.md](../../includes/active-directory-ds-prerequisites.md)]
@@ -76,7 +78,7 @@ There are two built-in Group Policy Objects (GPOs) in an Azure AD DS managed dom
 
     ![Built-in GPOs applied to the default 'AADDC Computers' and 'AADDC Users' containers](./media/active-directory-domain-services-admin-guide/builtin-gpos.png)
 
-1. These built-in GPOs can be customized to configure specific group policies on your Azure AD DS managed domain. Right-select one of the GPOs, such as *AADDC Computers GPO*, then select **Edit...**.
+1. These built-in GPOs can be customized to configure specific group policies on your Azure AD DS managed domain. Right-select one of the GPOs, such as *AADDC Computers GPO*, then choose **Edit...**.
 
     ![Choose the option to 'Edit' one of the built-in GPOs](./media/active-directory-domain-services-admin-guide/edit-builtin-gpo.png)
 

articles/active-directory-domain-services/scenarios.md

@@ -10,25 +10,25 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 08/22/2019
+ms.date: 10/31/2019
 ms.author: iainfou
 
 ---
 # Common use-cases and scenarios for Azure Active Directory Domain Services
 
-Azure Active Directory Domain Services (Azure AD DS) provides managed domain services such as domain join, group policy, LDAP, and Kerberos / NTLM authentication. Azure AD DS integrates with your existing Azure AD tenant, which makes it possible for users to sign in using their existing credentials. You use these domain services without the need to deploy, manage, and patch domain controllers in the cloud, which provides a smoother lift-and-shift of on-premises resources to Azure.
+Azure Active Directory Domain Services (Azure AD DS) provides managed domain services such as domain join, group policy, lightweight directory access protocol (LDAP), and Kerberos / NTLM authentication. Azure AD DS integrates with your existing Azure AD tenant, which makes it possible for users to sign in using their existing credentials. You use these domain services without the need to deploy, manage, and patch domain controllers in the cloud, which provides a smoother lift-and-shift of on-premises resources to Azure.
 
 This article outlines some common business scenarios where Azure AD DS provides value and meets those needs.
 
 ## Secure administration of Azure virtual machines
 
 To let you use a single set of AD credentials, Azure virtual machines (VMs) can be joined to an Azure AD DS managed domain. This approach reduces credential management issues such as maintaining local administrator accounts on each VM or separate accounts and passwords between environments.
 
-VMs that are joined to an Azure AD DS managed domain can also be managed and secured using Group Policy. Required security baselines can be applied to VMs to lock them down in accordance with corporate security guidelines. For example, you can use group policy management capabilities to restrict the types of applications that can be launched on the VM.
+VMs that are joined to an Azure AD DS managed domain can also be managed and secured using group policy. Required security baselines can be applied to VMs to lock them down in accordance with corporate security guidelines. For example, you can use group policy management capabilities to restrict the types of applications that can be launched on the VM.
 
 ![Streamlined administration of Azure virtual machines](./media/active-directory-domain-services-scenarios/streamlined-vm-administration.png)
 
-Let's look at a common example scenario. As servers and other infrastructure reaches end-of-life, Contoso wants to move applications currently hosted on premises to the cloud. Their current IT standard mandates that servers hosting corporate applications must be domain-joined and managed using group policy. Contoso's IT administrator would prefer to domain join VMs deployed in Azure to make administration easier as users can then sign in using their corporate credentials. When domain-joined, VMs can also be configured to comply with required security baselines using Group Policy. Contoso would prefer not to deploy, monitor, and manage their own domain controllers in Azure.
+Let's look at a common example scenario. As servers and other infrastructure reaches end-of-life, Contoso wants to move applications currently hosted on premises to the cloud. Their current IT standard mandates that servers hosting corporate applications must be domain-joined and managed using group policy. Contoso's IT administrator would prefer to domain join VMs deployed in Azure to make administration easier as users can then sign in using their corporate credentials. When domain-joined, VMs can also be configured to comply with required security baselines using group policy objects (GPOs). Contoso would prefer not to deploy, monitor, and manage their own domain controllers in Azure.
 
 Azure AD DS is a great fit for this use-case. An Azure AD DS managed domain lets you domain-join VMs, use a single set of credentials, and apply group policy. As a managed domain, you don't have to configure and maintain the domain controllers yourself.
 
@@ -59,7 +59,7 @@ The following deployment considerations apply to this example use case:
 
 ## Lift-and-shift on-premises applications that use LDAP read to access the directory
 
-Like the previous example scenario, let's assume Contoso has an on-premises line-of-business (LOB) application that was developed almost a decade ago. This application is directory aware and was designed to use Lightweight Directory Access Protocol (LDAP) to read information/attributes about users from AD DS. The application doesn't modify attributes or otherwise write to the directory.
+Like the previous example scenario, let's assume Contoso has an on-premises line-of-business (LOB) application that was developed almost a decade ago. This application is directory aware and was designed to use LDAP to read information/attributes about users from AD DS. The application doesn't modify attributes or otherwise write to the directory.
 
 Contoso wants to migrate this application to Azure and retire the aging on-premises hardware currently hosting this application. The application can't be rewritten to use modern directory APIs such as the REST-based Azure AD Graph API. A lift-and-shift option is desired where the application can be migrated to run in the cloud, without modifying code or rewriting the application.
 
@@ -95,7 +95,7 @@ You can use Azure AD DS to provide managed domain services to remote desktop ser
 
 ## Domain-joined HDInsight clusters (preview)
 
-You can set up an Azure HDInsight cluster that is joined to an Azure AD DS managed domain with Apache Ranger enabled. This feature is currently in preview. You can create and apply Hive policies through Apache Ranger, and allow users, such as data scientists, to connect to Hive using ODBC-based tools like Excel or Tableau. We continue to work to add other workloads, such as HBase, Spark, and Storm to domain-joined HDInsight.
+You can set up an Azure HDInsight cluster that is joined to an Azure AD DS managed domain with Apache Ranger enabled. You can create and apply Hive policies through Apache Ranger, and allow users, such as data scientists, to connect to Hive using ODBC-based tools like Excel or Tableau. We continue to work to add other workloads, such as HBase, Spark, and Storm to domain-joined HDInsight.
 
 For more information about this deployment scenario, see [how to configure domain-joined HDInsight clusters][hdinsight]
 

articles/active-directory-domain-services/synchronization.md

@@ -10,13 +10,13 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 08/20/2019
+ms.date: 10/31/2019
 ms.author: iainfou
 
 ---
 # How objects and credentials are synchronized in an Azure AD Domain Services managed domain
 
-Objects and credentials in an Azure Active Directory Domain Services (AD DS) managed domain can either be created locally within the domain, or synchronized from an Azure Active Directory (AD) tenant. When you first deploy Azure AD DS, an automatic one-way synchronization is configured and started to replicate the objects from Azure AD. This one-way synchronization continues to run in the background to keep the Azure AD DS managed domain up-to-date with any changes from Azure AD.
+Objects and credentials in an Azure Active Directory Domain Services (AD DS) managed domain can either be created locally within the domain, or synchronized from an Azure Active Directory (Azure AD) tenant. When you first deploy Azure AD DS, an automatic one-way synchronization is configured and started to replicate the objects from Azure AD. This one-way synchronization continues to run in the background to keep the Azure AD DS managed domain up-to-date with any changes from Azure AD. No synchronization occurs from Azure AD DS back to Azure AD.
 
 In a hybrid environment, objects and credentials from an on-premises AD DS domain can be synchronized to Azure AD using Azure AD Connect. Once those objects are successfully synchronized to Azure AD, the automatic background sync then makes those objects and credentials available to applications using the Azure AD DS managed domain.
 
@@ -43,7 +43,9 @@ The following table lists some common attributes and how they're synchronized to
 | SID history for users and groups | On-premises primary user and group SID | The *SidHistory* attribute for users and groups in Azure AD DS is set to match the corresponding primary user or group SID in an on-premises AD DS environment. This feature helps make lift-and-shift of on-premises applications to Azure AD DS easier as you don't need to re-ACL resources. |
 
 > [!TIP]
-> **Sign in to the managed domain using the UPN format** The *SAMAccountName* attribute, such as `CONTOSO\driley`, may be auto-generated for some user accounts in an Azure AD DS managed domain. Users' auto-generated *SAMAccountName* may differ from their UPN prefix, so isn't always a reliable way to sign in. For example, if multiple users have the same *mailNickname* attribute or users have overly long UPN prefixes, the *SAMAccountName* for these users may be auto-generated. Use the UPN format, such as `[email protected]`, to reliably sign in to an Azure AD DS managed domain.
+> **Sign in to the managed domain using the UPN format** The *SAMAccountName* attribute, such as `CONTOSO\driley`, may be auto-generated for some user accounts in an Azure AD DS managed domain. Users' auto-generated *SAMAccountName* may differ from their UPN prefix, so isn't always a reliable way to sign in.
+>
+> For example, if multiple users have the same *mailNickname* attribute or users have overly long UPN prefixes, the *SAMAccountName* for these users may be auto-generated. Use the UPN format, such as `[email protected]`, to reliably sign in to an Azure AD DS managed domain.
 
 ### Attribute mapping for user accounts
 
@@ -108,7 +110,7 @@ As previously detailed, there's no synchronization from Azure AD DS back to Azur
 
 ## What isn't synchronized to Azure AD DS
 
-The following objects or attributes aren't synchronized to Azure AD or to Azure AD DS:
+The following objects or attributes aren't synchronized from an on-premises AD DS environment to Azure AD or Azure AD DS:
 
 * **Excluded attributes:** You can choose to exclude certain attributes from synchronizing to Azure AD from an on-premises AD DS environment using Azure AD Connect. These excluded attributes aren't then available in Azure AD DS.
 * **Group Policies:** Group Policies configured in an on-premises AD DS environment aren't synchronized to Azure AD DS.