Merging changes synced from https://github.com/MicrosoftDocs/azure-docs-pr (branch live)

Author: Learn Build Service GitHub App

articles/active-directory-domain-services/network-considerations.md

@@ -9,7 +9,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: conceptual
-ms.date: 03/14/2023
+ms.date: 07/31/2023
 ms.author: justinha
 ms.reviewer: xyuan
 
@@ -49,6 +49,16 @@ A managed domain connects to a subnet in an Azure virtual network. Design this s
 * A managed domain requires 3-5 IP addresses. Make sure that your subnet IP address range can provide this number of addresses.
     * Restricting the available IP addresses can prevent the managed domain from maintaining two domain controllers.
 
+  >[!NOTE]
+  >You shouldn't use public IP addresses for virtual networks and their subnets due to the following issues:
+  >
+  >- **Scarcity of the IP address**: IPv4 public IP addresses are limited, and their demand often exceeds the available supply. Also, there are potentially overlapping IPs with public endpoints.
+  >- **Security risks**: Using public IPs for virtual networks exposes your devices directly to the internet, increasing the risk of unauthorized access and potential attacks. Without proper security measures, your devices may become vulnerable to various threats.
+  >
+  >- **Complexity**: Managing a virtual network with public IPs can be more complex than using private IPs, as it requires dealing with external IP ranges and ensuring proper network segmentation and security.
+  >
+  >It is strongly recommended to use private IP addresses. If you use a public IP, ensure you are the owner/dedicated user of the chosen IPs in the public range you chose.
+
 The following example diagram outlines a valid design where the managed domain has its own subnet, there's a gateway subnet for external connectivity, and application workloads are in a connected subnet within the virtual network:
 
 ![Recommended subnet design](./media/active-directory-domain-services-design-guide/vnet-subnet-design.png)

articles/active-directory-domain-services/tutorial-create-instance.md

@@ -8,7 +8,7 @@ ms.service: active-directory
 ms.subservice: domain-services
 ms.workload: identity
 ms.topic: tutorial
-ms.date: 01/29/2023
+ms.date: 07/31/2023
 ms.author: justinha
 
 #Customer intent: As an identity administrator, I want to create an Azure Active Directory Domain Services managed domain so that I can synchronize identity information with my Azure Active Directory tenant and provide Domain Services connectivity to virtual machines and applications in Azure.
@@ -106,6 +106,16 @@ To quickly create a managed domain, you can select **Review + create** to accept
 * Creates a subnet named *aadds-subnet* using the IP address range of *10.0.2.0/24*.
 * Synchronizes *All* users from Azure AD into the managed domain.
 
+>[!NOTE]
+>You shouldn't use public IP addresses for virtual networks and their subnets due to the following issues:
+>
+>- **Scarcity of the IP address**: IPv4 public IP addresses are limited, and their demand often exceeds the available supply. Also, there are potentially overlapping IPs with public endpoints.
+>- **Security risks**: Using public IPs for virtual networks exposes your devices directly to the internet, increasing the risk of unauthorized access and potential attacks. Without proper security measures, your devices may become vulnerable to various threats.
+>
+>- **Complexity**: Managing a virtual network with public IPs can be more complex than using private IPs, as it requires dealing with external IP ranges and ensuring proper network segmentation and security.
+>
+>It is strongly recommended to use private IP addresses. If you use a public IP, ensure you are the owner/dedicated user of the chosen IPs in the public range you chose.
+
 Select **Review + create** to accept these default configuration options.
 
 ## Deploy the managed domain

articles/active-directory/enterprise-users/domains-admin-takeover.md

@@ -18,21 +18,21 @@ ms.collection: M365-identity-device-management
 ---
 # Take over an unmanaged directory as administrator in Azure Active Directory
 
-This article describes two ways to take over a DNS domain name in an unmanaged directory in Azure Active Directory (Azure AD), part of Microsoft Entra. When a self-service user signs up for a cloud service that uses Azure AD, they are added to an unmanaged Azure AD directory based on their email domain. For more about self-service or "viral" sign-up for a service, see [What is self-service sign-up for Azure Active Directory?](directory-self-service-signup.md)
+This article describes two ways to take over a DNS domain name in an unmanaged directory in Azure Active Directory (Azure AD), part of Microsoft Entra. When a self-service user signs up for a cloud service that uses Azure AD, they're added to an unmanaged Azure AD directory based on their email domain. For more about self-service or "viral" sign-up for a service, see [What is self-service sign-up for Azure Active Directory?](directory-self-service-signup.md)
 
 
 > [!VIDEO https://www.youtube.com/embed/GOSpjHtrRsg]
 
 ## Decide how you want to take over an unmanaged directory
 During the process of admin takeover, you can prove ownership as described in [Add a custom domain name to Azure AD](../fundamentals/add-custom-domain.md). The next sections explain the admin experience in more detail, but here's a summary:
 
-* When you perform an ["internal" admin takeover](#internal-admin-takeover) of an unmanaged Azure directory, you are added as the global administrator of the unmanaged directory. No users, domains, or service plans are migrated to any other directory you administer.
+* When you perform an ["internal" admin takeover](#internal-admin-takeover) of an unmanaged Azure directory, you're added as the global administrator of the unmanaged directory. No users, domains, or service plans are migrated to any other directory you administer.
 
 * When you perform an ["external" admin takeover](#external-admin-takeover) of an unmanaged Azure directory, you add the DNS domain name of the unmanaged directory to your managed Azure directory. When you add the domain name, a mapping of users to resources is created in your managed Azure directory so that users can continue to access services without interruption. 
 
 ## Internal admin takeover
 
-Some products that include SharePoint and OneDrive, such as Microsoft 365, do not support external takeover. If that is your scenario, or if you are an admin and want to take over an unmanaged or "shadow" Azure AD organization create by users who used self-service sign-up, you can do this with an internal admin takeover.
+Some products that include SharePoint and OneDrive, such as Microsoft 365, don't support external takeover. If that is your scenario, or if you're an admin and want to take over an unmanaged or "shadow" Azure AD organization create by users who used self-service sign-up, you can do this with an internal admin takeover.
 
 1. Create a user context in the unmanaged organization through signing up for Power BI. For convenience of example, these steps assume that path.
 
@@ -44,20 +44,20 @@ Some products that include SharePoint and OneDrive, such as Microsoft 365, do no
 
    ![first screenshot for Become the Admin](./media/domains-admin-takeover/become-admin-first.png)
 
-5. Add the TXT record to prove that you own the domain name **fourthcoffee.xyz** at your domain name registrar. In this example, it is GoDaddy.com.
+5. Add the TXT record to prove that you own the domain name **fourthcoffee.xyz** at your domain name registrar. In this example, it's GoDaddy.com.
 
    ![Add a txt record for the domain name](./media/domains-admin-takeover/become-admin-txt-record.png)
 
 When the DNS TXT records are verified at your domain name registrar, you can manage the Azure AD organization.
 
-When you complete the preceding steps, you are now the global administrator of the Fourth Coffee organization in Microsoft 365. To integrate the domain name with your other Azure services, you can remove it from Microsoft 365 and add it to a different managed organization in Azure.
+When you complete the preceding steps, you're now the global administrator of the Fourth Coffee organization in Microsoft 365. To integrate the domain name with your other Azure services, you can remove it from Microsoft 365 and add it to a different managed organization in Azure.
 
 ### Adding the domain name to a managed organization in Azure AD
 
 [!INCLUDE [portal updates](~/articles/active-directory/includes/portal-update.md)]
 
 1. Open the [Microsoft 365 admin center](https://admin.microsoft.com).
-2. Select **Users** tab, and create a new user account with a name like *user\@fourthcoffeexyz.onmicrosoft.com* that does not use the custom domain name. 
+2. Select **Users** tab, and create a new user account with a name like *user\@fourthcoffeexyz.onmicrosoft.com* that doesn't use the custom domain name. 
 3. Ensure that the new user account has Global Administrator privileges for the Azure AD organization.
 4. Open **Domains** tab in the Microsoft 365 admin center, select the domain name and select **Remove**. 
 
@@ -76,7 +76,7 @@ When you complete the preceding steps, you are now the global administrator of t
 
 ## External admin takeover
 
-If you already manage an organization with Azure services or Microsoft 365, you cannot add a custom domain name if it is already verified in another Azure AD organization. However, from your managed organization in Azure AD you can take over an unmanaged organization as an external admin takeover. The general procedure follows the article [Add a custom domain to Azure AD](../fundamentals/add-custom-domain.md).
+If you already manage an organization with Azure services or Microsoft 365, you can't add a custom domain name if it's already verified in another Azure AD organization. However, from your managed organization in Azure AD you can take over an unmanaged organization as an external admin takeover. The general procedure follows the article [Add a custom domain to Azure AD](../fundamentals/add-custom-domain.md).
 
 When you verify ownership of the domain name, Azure AD removes the domain name from the unmanaged organization and moves it to your existing organization. External admin takeover of an unmanaged directory requires the same DNS TXT validation process as internal admin takeover. The difference is that the following are also moved over with the domain name:
 
@@ -98,7 +98,7 @@ The supported service plans include:
 - Microsoft Stream
 - Dynamics 365 free trial
 
-External admin takeover is not supported for any service that has service plans that include SharePoint, OneDrive, or Skype For Business; for example, through an Office free subscription. 
+External admin takeover isn't supported for any service that has service plans that include SharePoint, OneDrive, or Skype For Business; for example, through an Office free subscription. 
 
 > [!NOTE]
 > External admin takeover is not supported cross cloud boundaries (ex. Azure Commercial to Azure Government).  In these scenarios it is recommended to perform External admin takeover into another Azure Commercial tenant, and then delete the domain from this tenant so you may verify successfully into the destination Azure Government tenant.
@@ -109,64 +109,67 @@ You can optionally use the [**ForceTakeover** option](#azure-ad-powershell-cmdle
 
 For [RMS for individuals](/azure/information-protection/rms-for-individuals), when the unmanaged organization is in the same region as the organization that you own, the automatically created [Azure Information Protection organization key](/azure/information-protection/plan-implement-tenant-key) and [default protection templates](/azure/information-protection/configure-usage-rights#rights-included-in-the-default-templates) are additionally moved over with the domain name.
 
-The key and templates are not moved over when the unmanaged organization is in a different region. For example, if the unmanaged organization is in Europe and the organization that you own is in North America.
+The key and templates aren't moved over when the unmanaged organization is in a different region. For example, if the unmanaged organization is in Europe and the organization that you own is in North America.
 
-Although RMS for individuals is designed to support Azure AD authentication to open protected content, it doesn't prevent users from also protecting content. If users did protect content with the RMS for individuals subscription, and the key and templates were not moved over, that content is not accessible after the domain takeover.
+Although RMS for individuals is designed to support Azure AD authentication to open protected content, it doesn't prevent users from also protecting content. If users did protect content with the RMS for individuals subscription, and the key and templates weren't moved over, that content isn't accessible after the domain takeover.
 
 ### Azure AD PowerShell cmdlets for the ForceTakeover option
 You can see these cmdlets used in [PowerShell example](#powershell-example).
 
 cmdlet | Usage
 ------- | -------
-`connect-msolservice` | When prompted, sign in to your managed organization.
-`get-msoldomain` | Shows your domain names associated with the current organization.
-`new-msoldomain –name <domainname>` | Adds the domain name to organization as Unverified (no DNS verification has been performed yet).
-`get-msoldomain` | The domain name is now included in the list of domain names associated with your managed organization, but is listed as **Unverified**.
-`get-msoldomainverificationdns –Domainname <domainname> –Mode DnsTxtRecord` | Provides the information to put into new DNS TXT record for the domain (MS=xxxxx). Verification might not happen immediately because it takes some time for the TXT record to propagate, so wait a few minutes before considering the **-ForceTakeover** option. 
-`confirm-msoldomain –Domainname <domainname> –ForceTakeover Force` | <li>If your domain name is still not verified, you can proceed with the **-ForceTakeover** option. It verifies that the TXT record was created and kicks off the takeover process.<li>The **-ForceTakeover** option should be added to the cmdlet only when forcing an external admin takeover, such as when the unmanaged organization has Microsoft 365 services blocking the takeover.
-`get-msoldomain` | The domain list now shows the domain name as **Verified**.
+`connect-mggraph` | When prompted, sign in to your managed organization.
+`get-mgdomain` | Shows your domain names associated with the current organization.
+`new-mgdomain -BodyParameter @{Id="<your domain name>"; IsDefault="False"}` | Adds the domain name to organization as Unverified (no DNS verification has been performed yet).
+`get-mgdomain` | The domain name is now included in the list of domain names associated with your managed organization, but is listed as **Unverified**.
+`Get-MgDomainVerificationDnsRecord` | Provides the information to put into new DNS TXT record for the domain (MS=xxxxx). Verification might not happen immediately because it takes some time for the TXT record to propagate, so wait a few minutes before considering the **-ForceTakeover** option. 
+`confirm-mgdomain –Domainname <domainname>` | - If your domain name is still not verified, you can proceed with the **-ForceTakeover** option. It verifies that the TXT record was created and kicks off the takeover process.<br>- The **-ForceTakeover** option should be added to the cmdlet only when forcing an external admin takeover, such as when the unmanaged organization has Microsoft 365 services blocking the takeover.
+`get-mgdomain` | The domain list now shows the domain name as **Verified**.
 
 > [!NOTE]
 > The unmanaged Azure AD organization is deleted 10 days after you exercise the external takeover force option.
 
 ### PowerShell example
 
-1. Connect to Azure AD using the credentials that were used to respond to the self-service offering:
+1. Connect to Microsoft Graph using the credentials that were used to respond to the self-service offering:
    ```powershell
-   Install-Module -Name MSOnline
-   $msolcred = get-credential
-    
-   connect-msolservice -credential $msolcred
+   Install-Module -Name Microsoft.Graph
+      
+   Connect-MgGraph -Scopes "User.ReadWrite.All","Domain.ReadWrite.All"
    ```
 2. Get a list of domains:
 
    ```powershell
-   Get-MsolDomain
+   Get-MgDomain
    ```
-3. Run the Get-MsolDomainVerificationDns cmdlet to create a challenge:
+3. Run the New-MgDomain cmdlet to add a new domain in Azure:
    ```powershell
-   Get-MsolDomainVerificationDns –DomainName *your_domain_name* –Mode DnsTxtRecord
+   New-MgDomain -BodyParameter @{Id="<your domain name>"; IsDefault="False"}
    ```
-    For example:
+4. Run the Get-MgDomainVerificationDnsRecord cmdlet to view the DNS challenge:
+   ```powershell
+   (Get-MgDomainVerificationDnsRecord -DomainId "<your domain name>" | ?{$_.recordtype -eq "Txt"}).AdditionalProperties.text
    ```
-   Get-MsolDomainVerificationDns –DomainName contoso.com –Mode DnsTxtRecord
+    For example:
+   ```powershell
+   (Get-MgDomainVerificationDnsRecord -DomainId "contoso.com" | ?{$_.recordtype -eq "Txt"}).AdditionalProperties.text
    ```
 
 4. Copy the value (the challenge) that is returned from this command. For example:
    ```powershell
-   MS=32DD01B82C05D27151EA9AE93C5890787F0E65D9
+   MS=ms18939161
    ```
 5. In your public DNS namespace, create a DNS txt record that contains the value that you copied in the previous step. The name for this record is the name of the parent domain, so if you create this resource record by using the DNS role from Windows Server, leave the Record name blank and just paste the value into the Text box.
-6. Run the Confirm-MsolDomain cmdlet to verify the challenge:
+6. Run the Confirm-MgDomain cmdlet to verify the challenge:
 
    ```powershell
-   Confirm-MsolDomain –DomainName *your_domain_name* –ForceTakeover Force
+   Confirm-MgDomain -DomainId "<your domain name>"
    ```
 
    For example:
 
    ```powershell
-   Confirm-MsolDomain –DomainName contoso.com –ForceTakeover Force
+   Confirm-MgDomain -DomainId "contoso.com"
    ```
 
 A successful challenge returns you to the prompt without an error.

articles/active-directory/external-identities/b2b-quickstart-invite-powershell.md

@@ -4,8 +4,8 @@ description: In this quickstart, you learn how to use PowerShell to send an invi
 services: active-directory
 ms.author: cmulligan
 author: csmulligan
-manager: celestedg
-ms.date: 03/21/2023
+manager: CelesteDG
+ms.date: 07/31/2023
 ms.topic: quickstart
 ms.service: active-directory
 ms.subservice: B2B
@@ -83,5 +83,5 @@ Remove-MgUser -UserId '3f80a75e-750b-49aa-a6b0-d9bf6df7b4c6'
 
 
 ## Next steps
-In this quickstart, you invited and added a single guest user to your directory using PowerShell. Next, learn how to [invite guest users in bulk using PowerShell](tutorial-bulk-invite.md).
+In this quickstart, you invited and added a single guest user to your directory using PowerShell. You can also invite a guest user using the [Azure portal](b2b-quickstart-add-guest-users-portal.md). Additionally you can [invite guest users in bulk using PowerShell](tutorial-bulk-invite.md).