NetworkWatcherRG Deployment Causing DINE Policy (Deploy-VNET-HubSpoke) To Fail In Multi-Region Deployment/Assignment

[pagyP]

Describe the bug
the 'Deploys virtual network peering to hub' policy will fail if NetworkWatcherRG already exists in a different location. This RG may already exist because a virtual network has already been deployed in the subscription and/or policy is in place to create a network watcher.
So the policy 'Deploys virtual network peering to hub' cannot be used to deploy an additional vnet to a subscription or even a subscription that may have once had a vnet, but no longer has, but the NetworkWatcherRG is still present.

Steps to reproduce

1.Assign 'Deploys virtual network peering to hub' policy to a subscription
2. Policy deployment if not exists fails because NetworkWatcherRG already exists
3. "{"error":{"code":"InvalidResourceGroupLocation","message":"Invalid resource group location 'northeurope'. The Resource group already exists in location 'uksouth'."}}",

Screenshots

[jtracey93]

Thanks @pagyP for raising this.

I actually think this is due to the policy trying to create the NetworkWatcherRG in multiple regions which isn't supported by the platform for any resource group; as you can see from my quick test here:

Therefore I believe the policy should either:

1. Have additional logic and input parameter for the NetworkWatcherRG location
2. Remove the deployment of the NetworkWatcherRG as part of the DINE policy as it is enabled automatically on VNET creation if it doesn't exist by the platform already today (unless opted out) as per: https://docs.microsoft.com/en-us/azure/network-watcher/network-watcher-create

Have you tried amending the policy definition to try either of these options above? Or could you and report back?

Once I'm back from holiday I'll check in with @daltondhcp who created this policy for some further context before creating a PR to resolve, if required.

Thanks

Jack

[pagyP]

i think removing the network watcher Rg creation from the def is the simplest thing to do here. I'll test doing just that and update this issue.

[pagyP]

@jtracey93 Removing the RG creation sorts this out. Further context as to why it's in there would be good though in case I'm missing something.

There are a couple of other problems with this policy that I've noticed as well so will raise additional issues for those. Can then probably wrap up all changes to this policy def in one PR.

[jtracey93]

Thanks for letting us know @pagyP!

When we are all back from some holiday I'm sure @daltondhcp will let us know why it is part of the definition. However, from memory I'm sure it was to ensure the Landing Zone was enabled completely from the start with all the features it needs for the networking side of things.

But I think we are safe to remove it going forward as the platform does it automatically as described in a previous comment.

[daltondhcp]

Thank you for reporting @pagyP - will investigate if we still need to pre-create it or if we can now leave it to the platform.