In the Customer Information section, you provide information to integrate Azure Stack Hub with your organization’s IT infrastructure:
For more information, see Azure Stack Hub DNS namespace.
As with the region name, choose the external domain name carefully because it is used to form all the URLs for external endpoints that your tenants will access. It cannot be changed after you have deployed Azure Stack Hub.
The following case study is an example deployment scenario of a fictitious company to help illustrate how values such as Region Name and External Domain Name are used.
Contoso wants to deploy Azure Stack Hub and already owns the DNS name Contoso.com. They want to leverage this existing DNS name because their customers are already familiar with their name and brand. Consequently, they want to use an external domain name for Azure Stack Hub that is a subdomain of Contoso.com. They are going to start with a single region in their Chicago data center, and they plan to add more regions in the future. They have chosen to call this Azure cloud “MAST” because it is simple and they like the way that it sounds.
Contoso chooses the following values for their deployment:
Company name: Contoso
Region name: CHI
External domain name: mast.contoso.com
Using this combination of values, the Azure Stack Hub Tenant Portal URL for this deployment would be:
What if a tenant wants to create a load balancer with a public IP address for their web application and give it a DNS name label? It is for a teamwork application, so the tenant uses the DNS name label “Teams.” The resulting URL for the web application would be:
Contoso chooses an external domain name that was a subdomain of an existing DNS domain name. Contoso can set up a DNS delegation for that zone down to the Azure Stack Hub DNS so that tenants can resolve these names from outside of the Azure Stack Hub instance. Contoso could also, for example, set up a CNAME or alias for Azure Stack Hub to point to portal.mast.contoso.com that in turn points to portal.chi.mast.contoso.com.
In the future, depending on proximity, availability, or other business rules, when Contoso wants to add another region in Seattle, they can set load-balancing rules to route the portal.mast.contoso.com name to either:
Organizations can set this up differently, according to their business needs. This example illustrates the factors to consider during your namespace planning.
The private domain information is used to create the internal, Active Directory integrated DNS domain that will be used for Azure Stack Hub infrastructure services. This domain is used for internal endpoints, service-to-service communications, infrastructure role machine accounts, group-managed service accounts, and so on. This domain and the endpoints in it are accessible only from the infrastructure subnet (see Overview of Network Setting tab) and are not exposed externally to tenants.
For more information about setting up private domains, see What is Azure Private DNS?.
This value is prepended to your External Domain Name suffix, as described in the following section. It is used to create the FQDN of your external endpoints (for example, regionname.cloudapp.externaldomainname.com). Even if there is only one region, you must provide a region name consisting of only letters and numbers between 0 through 9.
When choosing a region name, use the following rules:
During the deployment, computer names and corresponding IP assignments are automatically generated for both physical devices as well as deployment-related items such as management virtual machines (VMs) and Active Directory object names. In the xxx fields, you provide two alphanumeric prefix strings up to eight characters long, which are prepended to the automatically generated names and assignments for easy identification. These prefixes are used with well-known suffixes to make names consistent across all Azure Stack Hub installations and to facilitate troubleshooting and diagnostics. It is easier to diagnose issues if you recognize the naming pattern in the trace logs.
Two options (deployment and physical prefixes) are provided because different teams with different naming conventions often manage network devices, physical computer devices, and service-specific VMs. They can be the same string.