Merge branch 'release-migration-plan' of https://github.com/MicrosoftDocs/azure-docs-pr into smh-include

Author: shellyhaverkamp

.openpublishing.redirection.api-management.json

@@ -1,5 +1,50 @@
 {
   "redirections": [
+    {
+        "source_path_from_root": "/articles/api-management/powershell-samples.md",
+        "redirect_url": "https://github.com/Azure/azure-docs-powershell-samples",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/api-management/scripts/powershell-add-user-and-get-subscription-key.md",
+        "redirect_url": "https://github.com/Azure/azure-docs-powershell-samples",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/api-management/scripts/powershell-create-apim-service.md",
+        "redirect_url": "https://github.com/Azure/azure-docs-powershell-samples",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/api-management/scripts/powershell-backup-restore-apim-service.md",
+        "redirect_url": "https://github.com/Azure/azure-docs-powershell-samples",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/api-management/scripts/powershell-scale-and-addregion-apim-service.md",
+        "redirect_url": "https://github.com/Azure/azure-docs-powershell-samples",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/api-management/scripts/powershell-setup-custom-domain.md",
+        "redirect_url": "https://github.com/Azure/azure-docs-powershell-samples",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/api-management/scripts/powershell-import-api-and-add-to-product.md",
+        "redirect_url": "https://github.com/Azure/azure-docs-powershell-samples",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/api-management/scripts/powershell-secure-backend-with-mutual-certificate-authentication.md",
+        "redirect_url": "https://github.com/Azure/azure-docs-powershell-samples",
+        "redirect_document_id": false
+    },
+    {
+        "source_path_from_root": "/articles/api-management/scripts/powershell-setup-rate-limit-policy.md",
+        "redirect_url": "https://github.com/Azure/azure-docs-powershell-samples",
+        "redirect_document_id": false
+    },
     {
         "source_path_from_root": "/articles/api-management/policies/authorize-request-using-external-authorizer.md",
         "redirect_url": "https://github.com/Azure/api-management-policy-snippets",

articles/active-directory-domain-services/TOC.yml

@@ -49,7 +49,7 @@
       href: concepts-replica-sets.md
     - name: Forests trusts
       href: concepts-forest-trust.md
-    - name: How Microsoft Entra DS synchronization works
+    - name: How Domain Services synchronization works
       href: synchronization.md
     - name: How password hash synchronization works
       href: ../active-directory/hybrid/connect/how-to-connect-password-hash-synchronization.md?context=/azure/active-directory-domain-services/context/azure-ad-ds-context
@@ -71,7 +71,7 @@
           href: create-ou.md
         - name: Create a group managed service account (gMSA)
           href: create-gmsa.md
-    - name: Manage Microsoft Entra DS
+    - name: Manage Domain Services
       items:
         - name: Administer Group Policy
           href: manage-group-policy.md
@@ -89,7 +89,7 @@
           href: change-sku.md
         - name: Retrieve data
           href: how-to-data-retrieval.md
-    - name: Secure Microsoft Entra DS
+    - name: Secure Domain Services
       items:
         - name: Secure your managed domain
           href: secure-your-domain.md

articles/active-directory-domain-services/administration-concepts.md

@@ -16,7 +16,7 @@ ms.author: justinha
 
 # Management concepts for user accounts, passwords, and administration in Microsoft Entra Domain Services
 
-When you create and run a Microsoft Entra Domain Services (AD DS) managed domain, there are some differences in behavior compared to a traditional on-premises AD DS environment. You use the same administrative tools in Microsoft Entra DS as a self-managed domain, but you can't directly access the domain controllers (DC). There's also some differences in behavior for password policies and password hashes depending on the source of the user account creation.
+When you create and run a Microsoft Entra Domain Services managed domain, there are some differences in behavior compared to a traditional on-premises AD DS environment. You use the same administrative tools in Domain Services as a self-managed domain, but you can't directly access the domain controllers (DC). There's also some differences in behavior for password policies and password hashes depending on the source of the user account creation.
 
 This conceptual article details how to administer a managed domain and the different behavior of user accounts depending on the way they're created.
 
@@ -35,26 +35,26 @@ User accounts can be created in a managed domain in multiple ways. Most user acc
 
 ## Password policy
 
-Microsoft Entra DS includes a default password policy that defines settings for things like account lockout, maximum password age, and password complexity. Settings like account lockout policy apply to all users in a managed domain, regardless of how the user was created as outlined in the previous section. A few settings, like minimum password length and password complexity, only apply to users created directly in a managed domain.
+Domain Services includes a default password policy that defines settings for things like account lockout, maximum password age, and password complexity. Settings like account lockout policy apply to all users in a managed domain, regardless of how the user was created as outlined in the previous section. A few settings, like minimum password length and password complexity, only apply to users created directly in a managed domain.
 
 You can create your own custom password policies to override the default policy in a managed domain. These custom policies can then be applied to specific groups of users as needed.
 
 For more information on the differences in how password policies are applied depending on the source of user creation, see [Password and account lockout policies on managed domains][password-policy].
 
 ## Password hashes
 
-To authenticate users on the managed domain, Microsoft Entra DS needs password hashes in a format that's suitable for NT LAN Manager (NTLM) and Kerberos authentication. Microsoft Entra ID doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Microsoft Entra DS for your tenant. For security reasons, Microsoft Entra ID also doesn't store any password credentials in clear-text form. Therefore, Microsoft Entra ID can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials.
+To authenticate users on the managed domain, Domain Services needs password hashes in a format that's suitable for NT LAN Manager (NTLM) and Kerberos authentication. Microsoft Entra ID doesn't generate or store password hashes in the format that's required for NTLM or Kerberos authentication until you enable Domain Services for your tenant. For security reasons, Microsoft Entra ID also doesn't store any password credentials in clear-text form. Therefore, Microsoft Entra ID can't automatically generate these NTLM or Kerberos password hashes based on users' existing credentials.
 
-For cloud-only user accounts, users must change their passwords before they can use the managed domain. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Microsoft Entra ID. The account isn't synchronized from Microsoft Entra ID to Microsoft Entra DS until the password is changed.
+For cloud-only user accounts, users must change their passwords before they can use the managed domain. This password change process causes the password hashes for Kerberos and NTLM authentication to be generated and stored in Microsoft Entra ID. The account isn't synchronized from Microsoft Entra ID to Domain Services until the password is changed.
 
 For users synchronized from an on-premises AD DS environment using Microsoft Entra Connect, [enable synchronization of password hashes][hybrid-phs].
 
 > [!IMPORTANT]
-> Microsoft Entra Connect only synchronizes legacy password hashes when you enable Microsoft Entra DS for your Microsoft Entra tenant. Legacy password hashes aren't used if you only use Microsoft Entra Connect to synchronize an on-premises AD DS environment with Microsoft Entra ID.
+> Microsoft Entra Connect only synchronizes legacy password hashes when you enable Domain Services for your Microsoft Entra tenant. Legacy password hashes aren't used if you only use Microsoft Entra Connect to synchronize an on-premises AD DS environment with Microsoft Entra ID.
 >
-> If your legacy applications don't use NTLM authentication or LDAP simple binds, we recommend that you disable NTLM password hash synchronization for Microsoft Entra DS. For more information, see [Disable weak cipher suites and NTLM credential hash synchronization][secure-domain].
+> If your legacy applications don't use NTLM authentication or LDAP simple binds, we recommend that you disable NTLM password hash synchronization for Domain Services. For more information, see [Disable weak cipher suites and NTLM credential hash synchronization][secure-domain].
 
-Once appropriately configured, the usable password hashes are stored in the managed domain. If you delete the managed domain, any password hashes stored at that point are also deleted. Synchronized credential information in Microsoft Entra ID can't be reused if you later create another managed domain - you must reconfigure the password hash synchronization to store the password hashes again. Previously domain-joined VMs or users won't be able to immediately authenticate - Microsoft Entra ID needs to generate and store the password hashes in the new managed domain. For more information, see [Password hash sync process for Microsoft Entra DS and Microsoft Entra Connect][azure-ad-password-sync].
+Once appropriately configured, the usable password hashes are stored in the managed domain. If you delete the managed domain, any password hashes stored at that point are also deleted. Synchronized credential information in Microsoft Entra ID can't be reused if you later create another managed domain - you must reconfigure the password hash synchronization to store the password hashes again. Previously domain-joined VMs or users won't be able to immediately authenticate - Microsoft Entra ID needs to generate and store the password hashes in the new managed domain. For more information, see [Password hash sync process for Domain Services and Microsoft Entra Connect][azure-ad-password-sync].
 
 > [!IMPORTANT]
 > Microsoft Entra Connect should only be installed and configured for synchronization with on-premises AD DS environments. It's not supported to install Microsoft Entra Connect in a managed domain to synchronize objects back to Microsoft Entra ID.
@@ -63,27 +63,27 @@ Once appropriately configured, the usable password hashes are stored in the mana
 
 A *forest* is a logical construct used by Active Directory Domain Services (AD DS) to group one or more *domains*. The domains then store objects for user or groups, and provide authentication services.
 
-In Microsoft Entra DS, the forest only contains one domain. On-premises AD DS forests often contain many domains. In large organizations, especially after mergers and acquisitions, you may end up with multiple on-premises forests that each then contain multiple domains.
+In Domain Services, the forest only contains one domain. On-premises AD DS forests often contain many domains. In large organizations, especially after mergers and acquisitions, you may end up with multiple on-premises forests that each then contain multiple domains.
 
-By default, a managed domain is created as a *user* forest. This type of forest synchronizes all objects from Microsoft Entra ID, including any user accounts created in an on-premises AD DS environment. User accounts can directly authenticate against the managed domain, such as to sign in to a domain-joined VM. A user forest works when the password hashes can be synchronized and users aren't using exclusive sign-in methods like smart card authentication.
+By default, a managed domain synchronizes all objects from Microsoft Entra ID, including any user accounts created in an on-premises AD DS environment. User accounts can directly authenticate against the managed domain, such as to sign in to a domain-joined VM. This approach works when the password hashes can be synchronized and users aren't using exclusive sign-in methods like smart card authentication.
 
-In a Microsoft Entra DS *resource* forest, users authenticate over a one-way forest *trust* from their on-premises AD DS. With this approach, the user objects and password hashes aren't synchronized to Microsoft Entra DS. The user objects and credentials only exist in the on-premises AD DS. This approach lets enterprises host resources and application platforms in Azure that depend on classic authentication such LDAPS, Kerberos, or NTLM, but any authentication issues or concerns are removed.
+In a Domain Services, you can also create a one-way forest *trust* to let users sign in from their on-premises AD DS. With this approach, the user objects and password hashes aren't synchronized to Domain Services. The user objects and credentials only exist in the on-premises AD DS. This approach lets enterprises host resources and application platforms in Azure that depend on classic authentication such LDAPS, Kerberos, or NTLM, but any authentication issues or concerns are removed.
 
 <a name='azure-ad-ds-skus'></a>
 
-## Microsoft Entra DS SKUs
+## Domain Services SKUs
 
-In Microsoft Entra DS, the available performance and features are based on the SKU. You select a SKU when you create the managed domain, and you can switch SKUs as your business requirements change after the managed domain has been deployed. The following table outlines the available SKUs and the differences between them:
+In Domain Services, the available performance and features are based on the SKU. You select a SKU when you create the managed domain, and you can switch SKUs as your business requirements change after the managed domain has been deployed. The following table outlines the available SKUs and the differences between them:
 
 | SKU name   | Maximum object count | Backup frequency | 
 |------------|----------------------|------------------|
 | Standard   | Unlimited            | Every 5 days     |
 | Enterprise | Unlimited            | Every 3 days     | 
 | Premium    | Unlimited            | Daily            | 
 
-Before these Microsoft Entra DS SKUs, a billing model based on the number of objects (user and computer accounts) in the managed domain was used. There is no longer variable pricing based on the number of objects in the managed domain.
+Before these Domain Services SKUs, a billing model based on the number of objects (user and computer accounts) in the managed domain was used. There is no longer variable pricing based on the number of objects in the managed domain.
 
-For more information, see the [Microsoft Entra DS pricing page][pricing].
+For more information, see the [Domain Services pricing page][pricing].
 
 ### Managed domain performance
 
@@ -99,7 +99,7 @@ As the SKU level increases, the frequency of those backup snapshots increases. R
 
 ## Next steps
 
-To get started, [create a Microsoft Entra DS managed domain][create-instance].
+To get started, [create a Domain Services managed domain][create-instance].
 
 <!-- INTERNAL LINKS -->
 [password-policy]: password-policy.md

articles/active-directory-domain-services/alert-ldaps.md

@@ -16,9 +16,9 @@ ms.author: justinha
 ---
 # Known issues: Secure LDAP alerts in Microsoft Entra Domain Services
 
-Applications and services that use lightweight directory access protocol (LDAP) to communicate with Microsoft Entra Domain Services (Microsoft Entra DS) can be [configured to use secure LDAP](tutorial-configure-ldaps.md). An appropriate certificate and required network ports must be open for secure LDAP to work correctly.
+Applications and services that use lightweight directory access protocol (LDAP) to communicate with Microsoft Entra Domain Services can be [configured to use secure LDAP](tutorial-configure-ldaps.md). An appropriate certificate and required network ports must be open for secure LDAP to work correctly.
 
-This article helps you understand and resolve common alerts with secure LDAP access in Microsoft Entra DS.
+This article helps you understand and resolve common alerts with secure LDAP access in Domain Services.
 
 ## AADDS101: Secure LDAP network configuration
 
@@ -28,7 +28,7 @@ This article helps you understand and resolve common alerts with secure LDAP acc
 
 ### Resolution
 
-When you enable secure LDAP, it's recommended to create additional rules that restrict inbound LDAPS access to specific IP addresses. These rules protect the managed domain from brute force attacks. To update the network security group to restrict TCP port 636 access for secure LDAP, complete the following steps:
+When you enable secure LDAP, it's recommended to create extra rules that restrict inbound LDAPS access to specific IP addresses. These rules protect the managed domain from brute force attacks. To update the network security group to restrict TCP port 636 access for secure LDAP, complete the following steps:
 
 1. In the [Microsoft Entra admin center](https://entra.microsoft.com), search for and select **Network security groups**.
 1. Choose the network security group associated with your managed domain, such as *AADDS-contoso.com-NSG*, then select **Inbound security rules**
@@ -42,7 +42,7 @@ When you enable secure LDAP, it's recommended to create additional rules that re
 The managed domain's health automatically updates itself within two hours and removes the alert.
 
 > [!TIP]
-> TCP port 636 isn't the only rule needed for Microsoft Entra DS to run smoothly. To learn more, see the [Microsoft Entra DS Network security groups and required ports](network-considerations.md#network-security-groups-and-required-ports).
+> TCP port 636 isn't the only rule needed for Domain Services to run smoothly. To learn more, see the [Domain Services Network security groups and required ports](network-considerations.md#network-security-groups-and-required-ports).
 
 ## AADDS502: Secure LDAP certificate expiring
 
@@ -52,11 +52,11 @@ The managed domain's health automatically updates itself within two hours and re
 
 ### Resolution
 
-Create a replacement secure LDAP certificate by following the steps to [create a certificate for secure LDAP](tutorial-configure-ldaps.md#create-a-certificate-for-secure-ldap). Apply the replacement certificate to Microsoft Entra DS, and distribute the certificate to any clients that connect using secure LDAP.
+Create a replacement secure LDAP certificate by following the steps to [create a certificate for secure LDAP](tutorial-configure-ldaps.md#create-a-certificate-for-secure-ldap). Apply the replacement certificate to Domain Services, and distribute the certificate to any clients that connect using secure LDAP.
 
 ## Next steps
 
-If you still have issues, [open an Azure support request][azure-support] for additional troubleshooting assistance.
+If you still have issues, [open an Azure support request][azure-support] for more troubleshooting help.
 
 <!-- INTERNAL LINKS -->
 [azure-support]: ../active-directory/fundamentals/how-to-get-support.md