Merge pull request #7641 from MicrosoftDocs/main

Angela Fleischmann · web-flow · commit 086bfdb3bc66 · 2022-05-18T16:36:32.000-06:00
Publish 05/18/2022 3:30 PM PT
diff --git a/memdocs/intune/protect/certificate-connector-overview.md b/memdocs/intune/protect/certificate-connector-overview.md
@@ -7,7 +7,7 @@ keywords:
 author: brenduns
 ms.author: brenduns
 manager: dougeby
-ms.date: 05/04/2022
+ms.date: 05/18/2022
 ms.topic: how-to
 ms.service: microsoft-intune
 ms.subservice: protect
@@ -85,11 +85,19 @@ The Certificate Connector for Microsoft Intune supports:
 
 ## Lifecycle
 
-Periodically, updates  to the certificate connector are released. Announcements for new updates appear in the [What's new for the Certificate Connector](#whats-new-for-the-certificate-connector) section in this article.
+Periodically, updates  to the certificate connector are released. Announcements for new connector updates, including the version and release date for each update, appear in the [What's new for the Certificate Connector](#whats-new-for-the-certificate-connector) section in this article.
 
-Intune supports each connector release for six months after it's released. After the six months have passed, the connector is no longer supported and might not function as expected.
+**Each new connector release**:
 
-If you don’t allow the connector to automatically update, plan to manually update it to the latest version at the first opportunity.
+- Is supported for six months after its release date. During this period, automatic updates can install a newer connector version. Updated connector versions can include but aren't limited to bug fixes and performance and feature improvements.
+
+- If an out of support connector fails, you’ll need to update to the latest supported version.
+
+- If you block the automatic update of the connector, plan to manually update the connector within six months, before support for the installed version ends. After support ends, you’ll need to update the connector to a version that remains in support to receive support for problems with the connector.
+
+- Connectors that are out of support will continue to function for up to 18 months after its release date. After 18 months, a connectors functionality might fail due to service level improvements, updates, or in addressing common security vulnerabilities that might surface in the future.
+
+For example, the connector version 6.2203.12.0 that released on May 4, 2022, will drop from support on November 4, 2022.  The same connector should continue to function (though not be supported) until November 2023. After November 2023 the connector might stop communicating with Intune.
 
 ### Automatic update
 
diff --git a/memdocs/intune/protect/compliance-policy-create-android-aosp.md b/memdocs/intune/protect/compliance-policy-create-android-aosp.md
@@ -20,7 +20,7 @@ ms.assetid: e1258fe4-0b5c-4485-8bd1-152090df6345
 #ROBOTS:
 #audience:
 
-ms.reviewer: samyada
+ms.reviewer: tycast
 ms.suite: ems
 search.appverid: MET150
 #ms.tgt_pltfrm:
diff --git a/memdocs/intune/protect/compliance-policy-create-android-for-work.md b/memdocs/intune/protect/compliance-policy-create-android-for-work.md
@@ -20,7 +20,7 @@ ms.assetid: 9da89713-6306-4468-b211-57cfb4b51cc6
 #ROBOTS:
 #audience:
 
-ms.reviewer: samyada
+ms.reviewer: tycast
 ms.suite: ems
 search.appverid: MET150
 #ms.tgt_pltfrm:
diff --git a/memdocs/intune/protect/compliance-policy-create-android.md b/memdocs/intune/protect/compliance-policy-create-android.md
@@ -18,7 +18,7 @@ ms.localizationpriority: medium
 #ROBOTS:
 #audience:
 
-ms.reviewer: samyada
+ms.reviewer: tycast
 ms.suite: ems
 search.appverid: MET150
 #ms.tgt_pltfrm:
diff --git a/memdocs/intune/protect/compliance-policy-create-ios.md b/memdocs/intune/protect/compliance-policy-create-ios.md
@@ -20,7 +20,7 @@ ms.assetid: 3cfb8222-d05b-49e3-ae6f-36ce1a16c61d
 #ROBOTS:
 #audience:
 
-ms.reviewer: samyada
+ms.reviewer: tycast
 ms.suite: ems
 search.appverid: MET150
 #ms.tgt_pltfrm:
diff --git a/memdocs/intune/protect/compliance-policy-create-mac-os.md b/memdocs/intune/protect/compliance-policy-create-mac-os.md
@@ -19,7 +19,7 @@ ms.technology:
 #ROBOTS:
 #audience:
 
-ms.reviewer: samyada
+ms.reviewer: tycast
 ms.suite: ems
 search.appverid: MET150
 #ms.tgt_pltfrm:
diff --git a/memdocs/intune/protect/compliance-policy-create-windows.md b/memdocs/intune/protect/compliance-policy-create-windows.md
@@ -18,7 +18,7 @@ ms.localizationpriority: medium
 #ROBOTS:
 #audience:
 
-ms.reviewer: samyada
+ms.reviewer: tycast
 ms.suite: ems
 search.appverid: MET150
 #ms.tgt_pltfrm:
diff --git a/memdocs/intune/protect/device-compliance-get-started.md b/memdocs/intune/protect/device-compliance-get-started.md
@@ -11,7 +11,7 @@ ms.date: 11/16/2021
 ms.topic: overview
 ms.service: microsoft-intune
 ms.subservice: protect
-ms.reviewer: samyada
+ms.reviewer: tycast
 
 # optional metadata
 
diff --git a/memdocs/intune/protect/device-compliance-partners.md b/memdocs/intune/protect/device-compliance-partners.md
@@ -13,7 +13,7 @@ ms.service: microsoft-intune
 ms.subservice: protect
 ms.localizationpriority: high
 ms.technology:
-ms.reviewer: samyada
+ms.reviewer: tycast
 
 # optional metadata
 
diff --git a/memdocs/intune/protect/microsoft-tunnel-prerequisites.md b/memdocs/intune/protect/microsoft-tunnel-prerequisites.md
@@ -5,7 +5,7 @@ keywords:
 author: brenduns
 ms.author: brenduns
 manager: dougeby
-ms.date: 03/03/2022
+ms.date: 05/18/2022
 ms.topic: how-to
 ms.service: microsoft-intune
 ms.subservice: protect
@@ -50,12 +50,11 @@ The following sections detail the prerequisites for the Microsoft Tunnel, and pr
 Set up a Linux based virtual machine or a physical server on which Microsoft Tunnel Gateway will install.
 
 > [!NOTE]
-> Only the opearating systems and container versions that are listed in the following table are supported. Versions not listed are not supported. Only after testing and supportability are verified are newer versions added to this list. 
+> Only the operating systems and container versions that are listed in the following table are supported. Versions not listed are not supported. Only after testing and supportability are verified are newer versions added to this list.
 
+- **Supported Linux distributions** - The following table details which versions of Linux are supported for the Tunnel server, and the container they require:
 
-- **Supported Linux distributions** - The following table details which versions of Linux are supported for the Tunnel server, and the container they require: 
-  
-  |Distributon version    | Container requirements   | Considerations     |
+  |Distribution version    | Container requirements   | Considerations     |
   |-----------------------|--------------------------|--------------------|
   | CentOS 7.4+           | Docker CE                | CentOS 8+ isn’t supported |
   | Red Hat (RHEL) 7.4+   | Docker CE                |                    |
@@ -64,7 +63,6 @@ Set up a Linux based virtual machine or a physical server on which Microsoft Tun
   | Ubuntu 18.04           | Docker CE               |                    |
   | Ubuntu 20.04           | Docker CE               |                    |
 
-
 - **Size the Linux server**: Use the following guidance to meet your expected use:
 
   |# Devices | # CPUs | Memory GB | # Servers | # Sites | Disk Space GB |
@@ -83,7 +81,6 @@ Set up a Linux based virtual machine or a physical server on which Microsoft Tun
 - **Install Docker CE or Podman**: Depending on the version of Linux you use for your Tunnel server, you'll need to install one of the following on the Linux server:
   - Docker version 19.03 CE or later
   - Podman version 3.0
-  
 
   Microsoft Tunnel requires Docker or Podman on the Linux server to provide support for containers. Containers provide a consistent execution environment, health monitoring and proactive remediation, and a clean upgrade experience.
 
@@ -94,7 +91,7 @@ Set up a Linux based virtual machine or a physical server on which Microsoft Tun
     > The preceding link directs you to the CentOS download and installation instructions. Use those same instructions for RHEL 7.4. The version installed on RHEL 7.4 by default is too old to support Microsoft Tunnel Gateway.
   - [Install Docker Engine on Ubuntu](https://docs.docker.com/engine/install/ubuntu/)
   - [Install Podman on Red Hat Enterprise Linux 8.4 and 8.5 (scroll down to RHEL8)](https://podman.io/getting-started/installation)  
-    These versions of RHEL don't support Docker. Instead, these versions use Podman, and *podman* is part of a module called "container-tools". In this context, a module is a set of RPM packages that represent a component and are usually installed together. A typical module contains packages with an application, packages with the application-specific dependency libraries, packages
+    These versions of RHEL don't support Docker. Instead, these versions use Podman, and *podman* is part of a module called "container-tools". In this context, a module is a set of RPM packages that represent a component and that usually install together. A typical module contains packages with an application, packages with the application-specific dependency libraries, packages
 with documentation for the application, and packages with helper utilities. For more information, see [Introduction to modules](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/installing_managing_and_removing_user-space_components/introduction-to-modules_using-appstream) in the Red Hat documentation.
 
 - **Transport Layer Security (TLS) certificate**: The Linux server requires a trusted TLS certificate to secure the connection between devices and the Tunnel Gateway server. You’ll add the TLS certificate, including the full trusted certificate chain, to the server during installation of the Tunnel Gateway.
@@ -287,14 +284,13 @@ The following details can help you configure an internal proxy when using Podmam
 
   3. Restart the Tunnel Gateway server: Run `mst-cli server restart`
 
-
-  Be aware that RHEL uses SELinux. Because a proxy that doesn't run on a SELinux port for *http_port_t* can require additional configuration, check on the use of SELinux managed ports for http. Run the following command to view the configurations: `sudo semanage port -l | grep “http_port_t” `
+  Be aware that RHEL uses SELinux. Because a proxy that doesn't run on a SELinux port for *http_port_t* can require extra configuration, check on the use of SELinux managed ports for http. Run the following command to view the configurations: `sudo semanage port -l | grep “http_port_t”`
   
   Example of the results of the port check command. In this example, the proxy uses 3128 and isn't listed:
 
   :::image type="content" source="./media/microsoft-tunnel-prerequisites/check-selinux-ports.png" alt-text="Screen shot of the port check.":::
 
-  - If your proxy runs on one of the SELinux ports for **http_port_t**, then you can continue with the Tunnel Gateway  install process.
+  - If your proxy runs on one of the SELinux ports for **http_port_t**, then you can continue with the Tunnel Gateway install process.
   - If your proxy does't run on a SELunux port for **http_port_t** as in the preceding example, you'll need to make extra configurations.
 
     **If your proxy port is not listed for** ***http_port_t***, check if the proxy port is used by another service. Use the *semnage* command to first check the port that your proxy uses and then later if needed, to change it. To check the port your proxy uses, run: `sudo semanage port -l | grep “your proxy port”`
@@ -372,7 +368,6 @@ The Microsoft Tunnel Gateway permissions group grants the following permissions:
 
 - **Read** - View Microsoft Tunnel Gateway server configurations and sites. Server configurations include settings for IP address ranges, DNS servers, ports, and split tunneling rules. Sites are logical groupings of multiple servers that support Microsoft Tunnel.
 
-
 ## Run the readiness tool
 
 Before you start a server install, we recommend you download and run the most recent version of the **mst-readiness** tool. The tool is a script that runs on your Linux server and does the following actions:
@@ -381,7 +376,7 @@ Before you start a server install, we recommend you download and run the most re
 
 - Confirms that your network configuration allows Microsoft Tunnel to access the required Microsoft endpoints.
 
-- Checks for the presence of the ip_tables module on the Linux server. This check was added to the script on February 11 2022, when support for RHEL 8.5 was added. RHEL 8.5 doesn’t load the ip_tables module by default. If they are missing after the Linux server installs, you must [manually load the ip_tables module](#manually-load-ip_tables).
+- Checks for the presence of the ip_tables module on the Linux server. This check was added to the script on February 11 2022, when support for RHEL 8.5 was added. RHEL 8.5 doesn’t load the ip_tables module by default. If they're missing after the Linux server installs, you must [manually load the ip_tables module](#manually-load-ip_tables).
 
 > [!IMPORTANT]
 > The readiness tool doesn't validate inbound ports, which is a common misconfiguration. After the readiness tool runs, review the [firewall prerequisites](#firewall) and manually validate your firewalls pass inbound traffic.
@@ -423,7 +418,7 @@ To check for the presence of this module, run the most recent version of mst-rea
 
 If the module isn’t present, the tool stops on the ip_tables module check. In this scenario, you can run the following commands to manually load the module.
 
-**Manually load the ip_tables module**:
+#### Manually load the ip_tables module
 
 In the context of sudo, run the following commands on your Linux server:
 
@@ -433,7 +428,12 @@ In the context of sudo, run the following commands on your Linux server:
 
 3. Rerun the validation to confirm the tables are now loaded: `lsmod |grep ip_tables`
 
-**Configure Linux to load ip_tables at boot**:
+> [!IMPORTANT]
+> When updating the Tunnel server, a manually loaded ip_tables module might not persist. This can require you to reload the module after the update completes. After your server update is completed, review the server for the presence of the ip_tables module.
+>
+> If the tables aren't present, use the preceding steps to reload the module, with the additional step to restart the server after the module is loaded.
+
+#### Configure Linux to load ip_tables at boot
 
 In the context of sudo, run the following command on your Linux server to create a config file that will load the ip_tables into kernel during boot time: `echo ip_tables > /etc/modules-load.d/mstunnel_iptables.conf`
 
diff --git a/windows-365/enterprise/TOC.yml b/windows-365/enterprise/TOC.yml
@@ -139,6 +139,8 @@ items:
         href: device-management-overview.md
       - name: Remotely manage Cloud PC devices 
         href: remotely-manage-cloud-pc.md
+      - name: RDP Shortpath for public networks 
+        href: rdp-shortpath-public-networks.md
       - name: Reprovision a Cloud PC
         href: reprovision-cloud-pc.md
       - name: Resize a Cloud PC
diff --git a/windows-365/enterprise/media/rdp-shortpath-public-networks/rdp-shortpath-diagram.png b/windows-365/enterprise/media/rdp-shortpath-public-networks/rdp-shortpath-diagram.png
diff --git a/windows-365/enterprise/rdp-shortpath-public-networks.md b/windows-365/enterprise/rdp-shortpath-public-networks.md
@@ -0,0 +1,92 @@
+---
+# required metadata
+title: Use RDP Shortpath for public networks with Windows 365 Cloud PCs.
+titleSuffix:
+description: Learn how to use RDP Shortpath for public networks with Windows 365 Cloud PCs.
+keywords:
+author: ErikjeMS  
+ms.author: erikje
+manager: dougeby
+ms.date: 05/18/2022
+ms.topic: how-to
+ms.service: cloudpc
+ms.subservice:
+ms.localizationpriority: high
+ms.technology:
+ms.assetid: 
+
+# optional metadata
+
+#ROBOTS:
+#audience:
+
+ms.reviewer: docoombs
+ms.suite: ems
+search.appverid: MET150
+#ms.tgt_pltfrm:
+ms.custom: intune-azure; get-started
+ms.collection: M365-identity-device-management
+---
+
+# Use RDP Shortpath for public networks (preview) with Windows 365  
+
+You can now use Remote Desktop Protocol (RDP) Shortpath for public networks with your Windows 365 Cloud PCs. RPD Shortpath for public networks can provide another connection path for improved Cloud PC connectivity, especially in suboptimal network conditions.
+
+## Requirements
+
+To use RDP Shortpath for public networks with Windows 365, you must meet these requirements:
+
+- Session Host (Cloud PC)
+  - UDP outbound to all public IP space (because, in most cases, it’s not possible to know the source IP address of the connecting PC).
+  - STUN server IP ranges on UDP port 347.
+- Client PC Network  
+  - UDP outbound:  
+    - To the public IP addresses assigned to NAT gateway or the Azure Firewall in an Azure Hosted Network Scenario.
+    - For a Microsoft Hosted network scenario, all public IP spaces.
+
+## Enable the preview of RDP Shortpath for public networks
+
+To participate in the public preview for RDP Shortpath for public networks, visit the following Azure Virtual Desktop documentation page and follow the instructions:
+
+[Enabling the preview of RDP Shortpath for public networks](/azure/virtual-desktop/shortpath-public#enabling-the-preview-of-rdp-shortpath-for-public-networks).
+
+## Verify UDP connectivity
+
+UDP connectivity can be checked within the “Connection Information” section of a Remote session. For more information, see [Verify your network connectivity]( /azure/virtual-desktop/shortpath-public#verify-your-network-connectivity).
+
+## RDP Shortpath benefits
+
+The default connectivity to a Windows 365 Cloud PC is through a TCP connection that traverses a gateway using the [reverse connect](/azure/virtual-desktop/network-connectivity) transport. The reverse transport means that there’s no need for inbound connectivity to the session host (Cloud PC) to connect RDP traffic.
+
+RDP Shortpath builds on the TCP connection and provides, when possible, another direct connection between the Remote Desktop client and the Windows 365 Cloud PC. This connection uses UDP as the underlying  transport protocol. The direct path and protocol deliver improved connection reliability, lower latency, and higher available bandwidth.
+
+![Diagram of RDP Shortpath process](./media/rdp-shortpath-public-networks/rdp-shortpath-diagram.png)
+
+For more information about RDP Shortpath benefits, see [Key benefits](/azure/virtual-desktop/shortpath-public#key-benefits).
+
+## RDP Shortpath connection process
+
+When using RPD Shortpath, the connection with the Cloud PC proceeds as follows:
+
+1. The RDP connection establishes a TCP-based connection using the reverse connect transport through the Gateway (in the same way as it does for connectivity without RDP Shortpath).
+2. If RDP Shortpath is enabled on the session host (Cloud PC), the service creates a UDP socket on all viable network interfaces.
+3. To test connectivity, the service attempts to connect to a Windows 365 STUN server on the public internet through UDP port 3478. This step also establishes the external IP address of the NAT router.
+4. The session host’s candidate table lists the public IP and listener port that it has reachable connectivity on. This information is provided to the connecting client through the established TCP session.
+5. The client sends its list of reachable public IP addresses/ports to the session host.
+6. Both parties attempt a connection at the same time. Because both are creating outbound connections, this often allows connectivity to be established through firewalls because no inbound initiated connectivity occurs.
+7. If connectivity is successful, the service evaluates if the connection is the fastest path. If it is, all dynamic virtual channels (such as graphics, input, device redirection, and more) switch to the new transport flow.
+
+## Known issues
+
+The RDP Shortpath for public networks may not work with Cloud PCs in the following scenarios:
+
+- Where double NAT is in place. For example, if the traffic is routed through a Secure Web Gateway (SWG) or proxy where the connection is Natted twice (first, on egress from Azure and, second, from the VPN/SWG endpoint.)
+- Where the connection is routed through an internet proxy or other inspection device.
+- Any network that restricts UDP access or limits access to specific ports or IP ranges.
+- Where Carrier Grade NAT (CGN) is used. Where the network shares a public IP address with other networks.
+
+For more technical details on these scenarios, see [General recommendations](/azure/virtual-desktop/shortpath-public#general-recommendations).
+
+## Next steps
+
+For complete information, see [Azure Virtual Desktop RDP Shortpath for public networks (preview)](/azure/virtual-desktop/shortpath-public).
