Merge remote-tracking branch 'upstream/main' into AB#7247-roubleshooting-Windows-Upgrade-Error-0xC1900101–0x20017

Author: v-tappelgate

Teams/exchange-integration/teams-exchange-interaction-issue.md

@@ -53,14 +53,15 @@ To integrate the Teams service with your installation of Exchange Server, make s
 - Validate the [version and environment compatibility](/MicrosoftTeams/exchange-teams-interact) of Microsoft Exchange Server and Microsoft Teams in your deployment.
 - Microsoft Teams must be aware whether the mailbox is hosted on Exchange Online, on-premises, or in a [hybrid Exchange server deployment](/exchange/exchange-hybrid). Teams services call the Exchange Online services through an Autodiscover V2 call, which is redirected to on-premises servers hosting the mailbox in a hybrid configuration.
 - Exchange Online integrates with the on-premises Exchange server environment, as described in [What is OAuth authentication](/exchange/using-oauth-authentication-to-support-ediscovery-in-an-exchange-hybrid-deployment-exchange-2013-help#what-is-oauth-authentication). It's preferable that you configure it by running the Exchange Hybrid Wizard, but the same result can be achieved manually as described in [Configure OAuth authentication between Exchange and Exchange Online organizations](/exchange/configure-oauth-authentication-between-exchange-and-exchange-online-organizations-exchange-2013-help). Exchange Online is represented by the application ID `00000002-0000-0ff1-ce00-000000000000`.
-- Additionally, Teams services need to authenticate on behalf of the user to access the mailbox hosted on-premises also using OAuth. In this case the application ID of Skype for Business Online `00000004-0000-0ff1-ce00-000000000000` is used by the Teams scheduling service, together with MailUser referenced at [Configure Integration and OAuth between Skype for Business Online and Exchange Server](/skypeforbusiness/deploy/integrate-with-exchange-server/oauth-with-online-and-on-premises):
-  - The account is hidden from the Exchange address book. It's a best practice to hide the account from the address book because it's a disabled account.
+- Additionally, Teams services need to use OAuth to authenticate on behalf of the user to access the mailbox hosted on-premises. The Teams scheduling service uses the 'TeamsScheduler' application that has '7557eb47-c689-4224-abcf-aef9bd7573df' as the app ID, together with TeamsIntegrationRole referenced at [Create a new Mail User account used by partner applications](/skypeforbusiness/deploy/integrate-with-exchange-server/oauth-with-online-and-on-premises#step-2-create-a-new-mail-user-account-used-by-partner-applications). 
+
+- The account is hidden from the Exchange address book. It's a best practice to hide the account from the address book because it's a disabled account.
   - The account has an Exchange management role assignment of [UserApplication](/exchange/userapplication-role-exchange-2013-help).
   - For retention and archiving, a role assignment of [ArchiveApplication](/exchange/archiveapplication-role-exchange-2013-help) is required.
   - All steps in the article are required for full Teams and Exchange server on-premises.
 
-  > [!NOTE]
-  > An example of Microsoft identity platform and OAuth 2.0 usage can be found [here](/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow).
+[!NOTE]
+
 - You should configure your internet-facing firewall or reverse proxy server to allow Microsoft Teams to access the servers that are running Exchange Server by adding the URLs and IP address ranges for Skype for Business Online and Microsoft Teams into the allowlist. For more information, see [Microsoft 365 URLs and IP address ranges - Microsoft Teams](/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#microsoft-teams&preserve-view=true).
 - Exchange Autodiscover V2 is required to allow the Teams service to perform an unauthenticated discovery against the user's mailbox that's located in Exchange Server. Autodiscover V2 is fully supported in Exchange Server 2013 Cumulative Update 19 or later. This is enough to enable Teams delegation to work correctly. However, the Teams Calendar app requires Exchange Server 2016 Cumulative Update 3 or later to be installed. Therefore, for full feature support, Exchange Server 2016 Cumulative Update 3 or later is required.
 

support/power-platform/administration/virtual-network.md

@@ -17,11 +17,11 @@ ms.custom: sap:Environment - Administration
 
 # Troubleshoot virtual network issues
 
-This article provides guidance to troubleshoot common scenarios for [virtual networks](/power-platform/admin/vnet-support-overview) in Microsoft Power Platform. This article focuses on the use of the [Microsoft.PowerPlatform.EnterprisePolicies](https://www.powershellgallery.com/packages/Microsoft.PowerPlatform.EnterprisePolicies) PowerShell module to help you identify and resolve issues that are related to virtual network configurations.
+This article provides guidance to troubleshoot common scenarios for [virtual networks](/power-platform/admin/vnet-support-overview) in Microsoft Power Platform. This article focuses on using the [Microsoft.PowerPlatform.EnterprisePolicies](https://www.powershellgallery.com/packages/Microsoft.PowerPlatform.EnterprisePolicies) PowerShell module to help you identify and resolve issues that are related to virtual network configurations.
 
 ## Use the diagnostics PowerShell module
 
-The `Microsoft.PowerPlatform.EnterprisePolicies` PowerShell module is designed to help you diagnose and troubleshoot issues that are related to virtual network configurations in Power Platform. You can use the tool to check the connectivity between your Power Platform environment and your virtual network. You can also use it to identify any misconfigurations that might be causing issues. This diagnostics PowerShell module is available from the PowerShell Gallery and its GitHub repository: [PowerPlatform-EnterprisePolicies](https://github.com/microsoft/PowerPlatform-EnterprisePolicies).
+The `Microsoft.PowerPlatform.EnterprisePolicies` PowerShell module is designed to help you diagnose and troubleshoot issues that are related to virtual network configurations in Power Platform. You can use the tool to check the connectivity between your Power Platform environment and your virtual network. You can also use it to identify any misconfigurations that might be causing issues. This diagnostics PowerShell module is available from the PowerShell Gallery and its GitHub repository, [PowerPlatform-EnterprisePolicies](https://github.com/microsoft/PowerPlatform-EnterprisePolicies).
 
 ### Install the module
 
@@ -31,15 +31,15 @@ To install the diagnostics PowerShell module, run the following PowerShell comma
 Install-Module -Name Microsoft.PowerPlatform.EnterprisePolicies
 ```
 
-### Run the diagnostic functions included in the module
+### Run the diagnostic functions
 
 After the module is installed, import it into your PowerShell session by running the following command:
 
 ```powershell
 Import-Module Microsoft.PowerPlatform.EnterprisePolicies
 ```
 
-The module includes several functions to diagnose and troubleshoot issues that are related to virtual network configurations. Some of the key functions are as follows:
+The module includes several functions to diagnose and troubleshoot issues that are related to virtual network configurations. Some of the key functions are:
 
 - [Get-EnvironmentRegion](https://github.com/microsoft/PowerPlatform-EnterprisePolicies/blob/main/docs/en-US/Microsoft.PowerPlatform.EnterprisePolicies/Get-EnvironmentRegion.md): Retrieves the region of the specified Power Platform environment
 - [Get-EnvironmentUsage](https://github.com/microsoft/PowerPlatform-EnterprisePolicies/blob/main/docs/en-US/Microsoft.PowerPlatform.EnterprisePolicies/Get-EnvironmentUsage.md): Provides information about the usage of the specified Power Platform environment
@@ -48,21 +48,21 @@ The module includes several functions to diagnose and troubleshoot issues that a
 
 ### Report issues in the diagnostics module
 
-If you encounter issues when you run the diagnostics module, report them through the GitHub repository where the module is hosted. The repository is available at: [PowerPlatform-EnterprisePolicies](https://github.com/microsoft/PowerPlatform-EnterprisePolicies).
+If you experience issues when you run the diagnostics module, report them through the GitHub repository where the module is hosted. The repository is available at: [PowerPlatform-EnterprisePolicies](https://github.com/microsoft/PowerPlatform-EnterprisePolicies).
 
-To report an issue, go to the **Issues** section of the repository, and [open a new issue](https://github.com/microsoft/PowerPlatform-EnterprisePolicies/issues/new). Provide detailed information about the issue that you experience, including any error messages or log entries that might help when investigating the issue. Don't include any sensitive information in your report.
+To report an issue, go to the **Issues** section of the repository, and [open a new issue](https://github.com/microsoft/PowerPlatform-EnterprisePolicies/issues/new). Provide detailed information about the issue that you experience, including any error messages or log entries that might help when you investigate the issue. Don't include any sensitive information in your report.
 
 ## Troubleshoot common issues
 
-### Misconfiguration of regions
+### Regions are misconfigured
 
-If everything is correctly configured but you still experience issues, use the `Get-EnvironmentRegion` function from the diagnostics PowerShell module to check whether the regions of your Power Platform environment are the same as the regions of your virtual network. Run the following command:
+If everything is correctly configured, but you still experience issues, use the `Get-EnvironmentRegion` function from the diagnostics PowerShell module to check whether the regions of your Power Platform environment are the same as the regions of your virtual network. Run the following command:
 
 ```powershell
 Get-EnvironmentRegion -EnvironmentId "<EnvironmentId>"
 ```
 
-Your environment belongs to a specific PowerPlatform region. However, a PowerPlatform region can span two Azure regions. You have to make sure that your virtual network is configured in both the Azure regions that correspond to your PowerPlatform region. Your environment can be located in either of the two Azure regions, and it can also automatically fail over between them. Therefore, to ensure high availability and connectivity, you should configure your virtual network in both Azure regions that are associated with your PowerPlatform region. To learn how PowerPlatform regions map to Azure regions that support the virtual network functionality, see [Power Platform regions](/power-platform/admin/vnet-support-overview#supported-regions).
+Your environment belongs to a specific PowerPlatform region. However, a PowerPlatform region can span two Azure regions. Your environment can be located in either region, and it can also automatically fail over between them. Therefore, to ensure high availability and connectivity, configure your virtual network in both Azure regions that are associated with your PowerPlatform region. To learn how PowerPlatform regions map to Azure regions that support the virtual network functionality, see [Power Platform regions](/power-platform/admin/vnet-support-overview#supported-regions).
 
 ### Hostname not found
 
@@ -72,11 +72,41 @@ If you experience issues that affect hostname resolution, use the `Test-DnsResol
 Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>"
 ```
 
-This command tests the DNS resolution for the specified hostname in the context of your Power Platform environment. The request initiates from your delegated subnet and tries to resolve the hostname by using the DNS server configured for your virtual network. If the hostname isn't resolved correctly, you might have to check your DNS settings to make sure that the hostname is configured correctly.
+This command tests the DNS resolution for the specified hostname in the context of your Power Platform environment. The request initiates from your delegated subnet and tries to resolve the hostname by using the DNS server that's configured for your virtual network. If the hostname isn't resolved correctly, you might have to check your DNS settings to make sure that the hostname is configured correctly.
 
 > [!IMPORTANT]
 > If you notice that your DNS setup is incorrect, and you have to update the DNS server settings for your virtual network, see [Can I update the DNS address of my virtual network after it's delegated to "Microsoft.PowerPlatform/enterprisePolicies"?](/power-platform/admin/vnet-support-overview#can-i-update-the-dns-address-of-my-virtual-network-after-its-delegated-to-microsoftpowerplatformenterprisepolicies)
 
+### Request uses a public IP address instead of the private IP address
+
+If you experience issues where requests to a resource use a public IP address instead of the private IP address, the DNS resolution for the resource's hostname might be returning a public IP address. This issue can occur with both Azure and non-Azure resources.
+
+#### Non-Azure resource without a private endpoint
+
+If a non-Azure resource doesn't have a private endpoint, but it's accessible from your virtual network, your DNS server should be configured to resolve the resource's hostname to its private IP address. Add a DNS *A* record to your DNS server that maps the resource's hostname to its private IP address:
+
+- If you're using a custom DNS server, add the A record directly to your server.
+- If you're using an Azure-provided DNS, create an [Azure Private DNS Zone](/azure/dns/private-dns-overview), and link it to your virtual network. Then, add the A record to the private DNS zone.
+
+This mapping makes sure that the resource is accessed through its private IP address.
+
+#### Azure resource with a private endpoint
+
+If an Azure resource has a private endpoint, the DNS resolution for the resource's hostname should return the private IP address that's associated with the private endpoint. If the DNS resolution returns a public IP address instead, records might be missing from your DNS configuration. Follow these steps:
+
+1. Verify that a private DNS zone exists for your resource type. For example, `privatelink.database.windows.net` for Azure SQL Database. If the private DNS zone doesn't exist, [create one](/azure/dns/private-dns-getstarted-portal#create-a-private-dns-zone).
+1. Verify that the private DNS zone is linked to your virtual network. If the private DNS zone isn't linked to your virtual network, [link it](/azure/dns/private-dns-virtual-network-links).
+
+After the private DNS zone is linked to your virtual network, the resource's hostname should resolve to the private IP address that's associated with the private endpoint.
+
+#### Test DNS configuration changes
+
+After you update the DNS configuration, use the `Test-DnsResolution` function from the diagnostics PowerShell module to verify that the hostname resolves to the correct private IP address. Run the following command:
+
+```powershell
+Test-DnsResolution -EnvironmentId "<EnvironmentId>" -HostName "<HostName>"
+```
+
 ### Can't connect to the resource
 
 If you experience issues that affect connectivity to a resource, use the `Test-NetworkConnectivity` function from the diagnostics PowerShell module to check for connectivity. Run the following command:
@@ -85,7 +115,7 @@ If you experience issues that affect connectivity to a resource, use the `Test-N
 Test-NetworkConnectivity -EnvironmentId "<EnvironmentId>" -Destination "<ResourceAddress>" -Port 1433
 ```
 
-This command tries to establish a TCP connection to the specified destination and port in the context of your Power Platform environment. The request initiates from your delegated subnet and tries to connect to the specified destination by using the network configuration from your virtual network. If the connection fails, you might have to check your network settings to make sure that the destination is reachable from your virtual network. If the connection is successful, it indicates that network connectivity exists between the Power Platform environment and the specified resource.
+This command tries to establish a TCP connection to the specified destination and port in the context of your Power Platform environment. The request initiates from your delegated subnet, and it tries to connect to the specified destination by using the network configuration from your virtual network. If the connection fails, you might have to check your network settings to make sure that the destination is reachable from your virtual network. A successful connection indicates that network connectivity exists between the Power Platform environment and the specified resource.
 
 > [!NOTE]
 > This command tests only whether a TCP connection can be established to the specified destination and port. It doesn't test whether the resource is available or whether any application-level issues might be preventing access to the resource.
@@ -95,8 +125,8 @@ This command tries to establish a TCP connection to the specified destination an
 
 If the connectivity tests are successful, but you're still experiencing issues in your application, you might have to check the application-level settings and configurations, as follows:
 
-- Verify that your firewall allows access from the delegated subnet to the resource.
-- Verify that the certificate presented by the resource is publicly trusted.
-- Make sure that no authentication or authorization issues exist that are preventing access to the resource.
+1. Verify that your firewall allows access from the delegated subnet to the resource.
+1. Verify that the certificate presented by the resource is publicly trusted.
+1. Make sure that no authentication or authorization issues exist that prevent access to the resource.
 
 You might not be able to diagnose or resolve the issue by using the diagnostics PowerShell module. In that case, create a subnet without delegation in your virtual network, and deploy a virtual machine (VM) in that subnet. You can then use the VM to perform further diagnostics and troubleshooting steps, such as checking network traffic, analyzing logs, and testing application-level connectivity.