Using Alternate ANCs in Windows 365

[Guest Matt Shadbolt]

Organizations using Windows 365 have two networking options for their Cloud PCs: Microsoft Hosted Network (MHN) or Azure Network Connection (ANC).

 

Microsoft Hosted Network is a Microsoft managed networking option, where no Azure vNet or subscription is required for Cloud PC network connectivity. If you need granular control of your corporate network traffic – firewall rules, custom routes or on-prem network access – the Azure Network Connection feature allows you to bring your own Azure vNet/subscription to Windows 365.

 

When you decide to use an ANC network connection, you are required to create an Azure vNet in the region of your choice. When Cloud PCs are provisioned using this ANC, the compute objects are created in the region of the vNet.

 

But ANC is more than just a bring-your-own vNet. Each ANC performs a set of health checks periodically to ensure the network prerequisites are in place, healthy, and ready to be used for Cloud PC provisioning. Checks include domain join tests, IP address space availability, public and private DNS checks, and many others.

 

When an ANC becomes unhealthy, we purposely block Cloud PC provisioning for provisioning policies that rely upon that ANC. Your organization then needs to remediate the environmental problem that’s causing the ANC health check failures before you can continue provisioning. This makes sense, as if your ANC checks have not passed, we cannot guarantee provisioning success and that a user’s Cloud PC will be ready for use once provisioning completes.

 

Some organizations gave feedback that if one ANC is unhealthy, they’d love to continue provisioning successfully using additional ANCs. For instance, if a primary ANC runs out of IP address allocation, perhaps you’d like to create a second ANC to be used when that primary allocation is exhausted.

 

This led to our recently released feature: Alternate ANC.

 

Alternate ANC

 

 

The Alternate ANC feature allows you to define more than one ANC within a provisioning policy. This allows the provisioning process to ‘failover’ to an alternate ANC if your primary ANC is unhealthy. This ‘failover’ will be automatic and immediate for the next provisioning request received for that provisioning policy.

 

Screenshot showing the selection of join type details during Cloud PC provisioning

 

We also allow admins to add more than one alternate ANC. In fact, you can add as many ANCs as you have configured in your tenant, and use the Priority feature to prioritize the order in which ANCs are used.

 

In my example above, I have two vNets defined in ANCs: one based in West US 2 and another in West US 3. Since my users are spread across the west coast of the USA, I don’t really care which one is used.

 

By default, the highest priority ANC will be used to provision new Cloud PCs – in my example, the ANC in West US 2.

 

However, if the West US 2 region has issues, or my ANC is failing due to on-premises networking issues, with my Alternate ANC added, my provisioning will seamlessly begin to use the West US 3 ANC instead.

 

When my primary ANC becomes healthy again, it will automatically be used for new Cloud PCs being provisioned.

 

Screenshot showing a list of All Cloud PCs list provisioned and the ANC used

 

In the All Cloud PCs list, for each Cloud PC provisioned, you can determine which ANC was used during provisioning.

 

Alternate ANC use considerations

 

 

We think many organizations will see value in adding additional ANCs to improve the success rate of their provisioning, but we wanted to call out some considerations before adding additional ANCs.

 

Alternate ANC use is optional: By default, only one ANC is required in a provisioning policy, and we will not force you to add alternate ANCs. So, if you’re happy using your single ANC, there’s no need for you to change your existing configuration.

 

Alternate ANC selection is automatic: We use the priority order to decide which ANC to use, in addition to the health state of the ANCs. For example, if I add two ANCs and they’re both unhealthy, provisioning will still fail. If I add a third ANC and it’s healthy, the third ANC will be used and provisioning will be successful. If you do not wish to provision into an alternate region, do not add an alternate ANC.

 

Alternate ANCs should use the same domain: If you are using a Hybrid Azure AD Join ANC, ensure the alternate ANCs added to your provisioning policy match the domain used as your primary ANC. If the domain does not match, your result may be some Cloud PCs joined to the primary ANC domain, and other Cloud PCs joined to the alternate ANC domain.

 

Alternate ANCs should be geographically appropriate: As the alternate ANC will be used when primary ANCs are healthy, you’ll want to be mindful of the Azure regions in which these ANCs are created. If the regions are geographically far apart, you may end up with Cloud PCs in remote regions that are not appropriate for the users you’re provisioning for.

 

Monitor your ANC health: If your primary ANC is often unhealthy, an alternate ANC may be used more than you expected. We recommend that you keep your primary ANC healthy, and use your alternate ANC as an exception to your primary ANC health. Ensure that you are monitoring your ANC health closely, and only add an alternate ANC if you fully understand the implications of provisioning Cloud PCs in a different ANC.

 

You can have Alternate ANCs in the same region: Your Alternate ANCs do not need to be in a different region. You may have scenarios in which Alternate ANCs in the same region provide value – for example, a vNet with a different route back to on-prem, or a different subnet if your primary ANC subnet is reaching its limit.

 

Thank you, and we hope you enjoy the Alternate ANC feature!

 

 

Continue the conversation. Find best practices. Bookmark the Windows Tech Community and follow us @MSWindowsITPro on Twitter. Looking for support? Visit Windows on Microsoft Q&A.

 

Continue reading...