Update network-details-for-ghecom.md (#54514)

Co-authored-by: Vanessa <[email protected]>

content/admin/data-residency/network-details-for-ghecom.md

@@ -78,8 +78,8 @@ If you use Azure private networking for {% data variables.product.company_short
 
 | Runner type | Supported regions |
 | ----------- | ----------------- |
-| x64 | `francecentral`, `swedencentral` |
-| arm64 | `francecentral`, `northeurope` |
+| x64 | `francecentral`, `swedencentral`, `germanywestcentral` |
+| arm64 | `francecentral`, `northeurope`, `germanywestcentral` |
 | GPU | `italynorth`, `swedencentral` |
 
 ### Supported regions in Australia

data/reusables/actions/azure-vnet-creating-network-configuration-prereqs.md

@@ -1,4 +1,10 @@
-After configuring your Azure resources, you can use an Azure Virtual Network (VNET) for private networking by creating a network configuration{% ifversion ghec %} at the enterprise or organization level{% else %} at the organization level{% endif %}. Then, you can associate that network configuration to runner groups. For more information about runner groups, see [AUTOTITLE](/actions/using-github-hosted-runners/about-larger-runners/controlling-access-to-larger-runners).
+After configuring your Azure resources, you can use an Azure Virtual Network (VNET) for private networking by creating a network configuration{% ifversion ghec %} at the enterprise or organization level{% else %} at the organization level{% endif %}. Then, you can associate that network configuration to runner groups.
+
+{% ifversion ghec %}
+
+Please note that initial setup must be at the enterprise level when creating the network settings configured with Azure. This is why, when obtaining the `databaseId`, the steps require you to configure the enterprise slug. Organizations are only allowed to create their own network configurations once the enterprise has been established and enabled through enterprise policy for hosted compute networking. For more information about runner groups, see [AUTOTITLE](/actions/using-github-hosted-runners/about-larger-runners/controlling-access-to-larger-runners).
+
+{% endif %}
 
 Once the network configuration is associated with a runner group, all runners in that group will have access to the Azure VNET that has been connected to the underlying configuration.
 

data/reusables/actions/azure-vnet-hosted-compute-troubleshooting.md

@@ -101,3 +101,7 @@ While running the command to configure Azure resources, ensure you are using the
 ```
 
 If you experience this error, you can see more information by running the command using the `---debug` flag.
+
+### Network settings configured at the wrong level
+
+If network settings were configured using an organization's `databaseId` instead of an enterprise `databaseId`, an error will occur. The error message will indicate that a private network cannot be established with the provided resource ID because it is already associated with a different enterprise or organization. To resolve this, delete the existing network settings and recreate them using the enterprise `databaseId`.

data/reusables/actions/azure-vnet-procedures-prereqs.md

@@ -12,7 +12,7 @@ You will use a script to automate configuring your Azure resources.
 
   The `.bicep` file we provide contains the minimal set of rules to use {% data variables.product.company_short %}-hosted runners with Azure VNET. You may need to add rules for your specific use case.
 
-  If you use {% data variables.enterprise.data_residency %}, in the `AllowOutBoundGitHub` section, you must also include the egress IP ranges for {% data variables.enterprise.data_residency_site %}. See [AUTOTITLE](/admin/data-residency/network-details-for-ghecom#ranges-for-egress-traffic).
+  If you use {% data variables.enterprise.data_residency %}, in the `AllowOutBoundGitHub` section, you must also include the ingress IP ranges for {% data variables.enterprise.data_residency_site %}. See [AUTOTITLE](/admin/data-residency/network-details-for-ghecom#ranges-for-ingress-traffic).
 
   > [!NOTE]
   > As an alternative to using the following file, to allow {% data variables.product.prodname_actions %} to communicate with the runners, you can allow the same firewall domains that are required for communication between self-hosted runners and {% data variables.product.github %}. For more information, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#communication-between-self-hosted-runners-and-github-enterprise-cloud). To determine the appropriate subnet IP address range, we recommend adding a 30% buffer to the maximum job concurrency you anticipate. For instance, if your network configuration's runners are set to a maximum job concurrency of 300, it's recommended to utilize a subnet IP address range that can accommodate at least 390 runners. This buffer helps ensure that your network can handle unexpected increases in VM needs to meet job concurrency without running out of IP addresses.