Complete three sections of information under the Customer Settings tab:

• Azure Identity Store
• Customer Information
• Environment Information

For information about Azure Identity Store, see Microsoft topics including the following:

• Azure Stack Hub integrated systems connection models
• Connected deployment
• Disconnected deployment

For information about the connection models, see Azure Stack Hub integrated systems connection models on the Microsoft website. This page includes the subtopic Choose a deployment connection model.

Choose an identity store. See Choose identity store on the Microsoft website. There are two types of identity stores to choose from:

• Azure Active Directory identity store
• Active Directory Federated Services identity store

For information about connected deployments, see Connected deployment on the Microsoft website.

In the Customer Information section, you provide information to integrate Azure Stack Hub with your organization’s IT infrastructure:

• Company Name—The name of your organization.
• External Domain —The external DNS zone for the Azure Stack Hub instance. This value, along with the region name, is used to construct the FQDN for all external endpoints for this Azure Stack Hub region (for example, regionname.cloudapp.externaldomainname.com). For more information, see Azure Stack Hub datacenter DNS integration.

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:

https://publicportal.chi.mast.contoso.com

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:

http://teams.chi.cloudapp.mast.contoso.com

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:

• portal.chi.mast.contoso.com
• portal.sea.mast.contoso.com

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 <Network Settings tab>) and are not exposed externally to tenants.

For more information about setting up private domains, see What is Azure Private DNS? on the Microsoft website.

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:

• Use a region name that indicates the physical location of the Azure Stack Hub scale units. In Azure, the region names correspond to the geographic location of the data centers where the compute, storage, and network resources are located (USWest, EastAsia, NorthEurope, and so on). In this way, users have a clear idea of where their resources are physically located.
• Use a naming convention that is intuitive for your users. Data center locations are a popular choice for region names. Ensure that your tenants can make a good choice as to where to deploy their resources based on the region name.
• Keep the region name short. The region is prepended to your external domain name to create the FQDN for that region.

During the deployment, computer names and corresponding IP assignments are automatically generated for both physical devices and 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.

• The Deployment Prefix is prepended to the infrastructure role machine names.
• The Physical Prefix is prepended to the physical switch and physical compute node names.

The Environment Information section collects time server and DNS server information.

Specify an IP for the time synchronization server. Although most of the components in the infrastructure can resolve a URL, some can only support IP addresses. If you are using the disconnected deployment option, you must specify a time server on your corporate network that you are sure can be reached from the infrastructure network in Azure Stack Hub. See Time synchronization on the Microsoft website.

Enter the DNS servers’ IP addresses.

Azure Stack Hub deploys its own recursive DNS servers that are part of the solutions infrastructure. If they do not have the proper authority, these recursive DNS servers forward DNS name queries to an upstream DNS server. This action ensures that the authoritative resolver for that DNS name can be found, the name resolved, and the result returned to original requester.

Azure Stack Hub DNS servers are only authoritative for the external domain name zone. For queries for DNS names outside of the Azure Stack Hub solution, provide the IP address of a DNS server in your environment that can either resolve these names or forward them as appropriate.

Provide at least two entries (separated by commas) in the DNS Servers (upstream) field. These entries must be IP addresses of valid DNS servers that are accessible from the Azure Stack Hub public infrastructure network (see <Network design and infrastructure> in Appendix A.) If you do not provide these entries, or if these entries are unavailable, queries for DNS names for endpoints outside of the Azure Stack Hub (for example, Internet endpoints such as www.bing.com) will fail.

Enter an IP address of a syslog server if desired.