Windows 365 has a range of connectivity requirements in terms of FQDNs which need to be accessible directly from the VNet for the service to be able to operate and users connect to their Cloud PC. As the service has grown and expanded, over time this list has grown at in parallel. Significant effort has been going on in the background by our fantastic engineering team to simplify and reduce these requirements and also abstract customers from future change where possible as the service expands and improves over time.
I’m pleased to announce Windows 365 customers will start to see the first of the improvements cumulating from this work start rolling out over the coming months. This has been relayed to customers via message center post ID MC675811 already but you’ll find more detail on this change below.
What is changing?
The first of these improvements revolves around the reduction of the required FQDNs for the service. Over the coming months we’ll be removing the use of a considerable number of the required FQDNs from the requirements, once this is fully complete, we’ll remove them from our docs page and at that point they can then be safely removed from any firewall rules etc. We will send out official communications to customers when this removal can be done. Following this initial phase, even more removals are planned in future as engineering work to facilitate this completes. In addition there are also other significant improvements being worked on which we’ll announce nearer the time they are ready to be released.
What are the endpoints being replaced with?
We’re moving a large number of the FQDNs to resolve under an existing wildcard FQDN *.infra.windows365.microsoft.com (*.infra.windows365.microsoft.us if within Windows 365 US Government environments) which has been part of the published endpoint requirements for a considerable amount of time. For example, an existing endpoint such as cpcsaamssa1prodprap01.blob.core.windows.net will now become accessible via something.infra.windows365.microsoft.com instead. As the wildcard means ‘anything’, this means we can create future endpoints inside this wildcard domain without the need for changes to your rulesets and configuration.
Where in my Windows 365 deployment does this impact?
These changes are only for the Cloud PC side only. No access is required for these endpoints on the side of the physical device connecting to Windows 365.
- For customers using recommended Microsoft Hosted Network (MHN) model, the underlying network for the VNet automatically has access to the required endpoints so for example for traffic initiated during the provision phase has access with no configuration required. However, please ensure any proxy or Secure Web Gateway (SWG) path allows access to this endpoint should connectivity be required from the Cloud PC itself post provisioning.
- For customers using Azure Network Connection (ANC) please ensure that the underlying network path the VNet has, allows for direct access to this domain, for example through a virtual firewall in Azure providing the required connectivity for the service. Please also ensure any proxy/ SWG path the Cloud PC uses once provisioned, also allows access. Customers using Azure Firewall and FQDN tags should have to make no change as the endpoint is already included in the tag.
For more information on these two network deployment models, see here.
What are the benefits of this change?
There are numerous benefits accrued through this first phase of improvements:
- Reduced endpoint requirements for initial configuration – Configuring firewalls and rulesets will become significantly simpler.
- Vastly reduced change rate – As with any growing and expanding cloud service, new endpoint requirements happen regularly. With this approach the goal is to ensure wherever possible, any new service endpoint will come from the existing wildcard FQDN meaning customers are abstracted from this change and do not have to make regular rule updates.
- Reduced risk of misconfiguration – The simpler requirements and reduced change rate, reduces the risk of missing endpoints in any configuration.
- Enables future improvements in required endpoint provisioning/management to be announced at a future date.
What do I need to do to prepare?
As the endpoint we’re migrating to (*.infra.windows365.microsoft.com) has been in the published requirements for a considerable amount of time, it’s very likely that no change to configuration is necessary in most customer environments. However, you may want to ratify that this endpoint is accessible from your environments by doing the following.
- For Customers using Azure Network Connection, please ensure *.infra.windows365.microsoft.com is accessible directly from the VNet, for example in an Azure Firewall or other NVA. Customers using FQDN tags in Azure firewall need to make no change as the endpoint is already in the tag.
- For any customers using a proxy or Secure Web Gateway (SWG) for traffic initiated from the Cloud PC once provisioned & configured, please ensure the rulesets for these services allow *.infra.windows365.microsoft.com
How do I check access is possible?
Although this endpoint isn’t designed to be human accessible, If you wish to ratify that access is possible to *.infra.windows365.microsoft.com you can use the following methods:
- The recommended way to check is by using an ANC Healthcheck. The check for this wildcard FQDN will be live in the ANC checks late October 23 and will flag a warning if not accessible. I’ll update this blog when this method is live and ready for use.
- If you wish to manually check access, from a browser running within the VNet you want to test, go to saprod.infra.windows365.microsoft.com – If accessible you’ll get an XML error returned as per the example below. Ensure the traffic is sent direct from the VNet however and not via a proxy or similar as the key connectivity is required during provisioning when proxies will not be in use.
- From a windows device within the VNet you can use PSPING to make a test TCP connection to the endpoint using the following command
Psping -n 5 saprod.infra.windows365.microsoft.com:443
You will again need to ensure this connection is routed directly out of the VNet and not via any SWG/Proxy infrastructure so as to ensure the direct path required for provisioning/operation is available. If successful you should see a response similar to that below:
