When managing authentication with your chosen identity store in Portal for ArcGIS, authentication can be configured at the Portal tier, the Web tier, or the External tier. The primary differences from a user experience perspective being Portal tier requires credentials to be provided to sign in and it does not support a Single Sign On (SSO) experience. Web tier can be configured to utilise the ArcGIS Web Adaptor, Microsoft Internet Information Services (IIS), and Integrated Windows Authentication (IWA) for a SSO user experience.
If using an enterprise identity store with Portal tier authentication, by its nature it requires a closer integration with your Microsoft Active Directory (AD) or Lightweight Directory Access Protocol (LDAP) compatible identity store.
In any enterprise environment, it is crucial that services are able to restart/recover automatically in the event of disruption or failure. In the example of this blog post, this would be if there is a power outage or the server reboots unexpectedly.
When your services are not able to automatically recover, this can cause long outages for your users, especially if you are not actively monitoring your underlying infrastructure.
ArcGIS Enterprise Cloud Builder for Microsoft Azure is an application you install on your local Microsoft Windows machine to deploy ArcGIS Enterprise and stand-alone ArcGIS Server sites on Microsoft Azure. Depending on what role you want the site to fill, Azure Cloud builder provides several deployment options.
This blog will discuss the workflow of deploying multi-machine ArcGIS Enterprise (non-HA) with each component of base Enterprise deployment – Portal for ArcGIS, ArcGIS GIS Server, Data Store and App Gateway – installed on its own dedicated servers. One thing to note, starting from Azure Cloud Builder 10.8 for Microsoft Azure, the base ArcGIS Enterprise deployment is no longer accessed through a load balancer and reverse proxy. The 10.8 version of ArcGIS Enterprise Cloud Builder for Microsoft Azure creates ArcGIS Enterprise deployments that use a single Azure Application Gateway to access the portal and all federated servers – this is referred to as a version 2 (V2) deployment type.