ArcGIS Enterprise Admin (EAEP) cheat sheet

A base ArcGIS Enterprise deployment consists of four components: Portal for ArcGIS, ArcGIS Server, ArcGIS Web Adaptor, and ArcGIS Data Store; all four are required for the base deployment pattern.

Portal for ArcGIS hosts the portal website, content items, groups, and identity; it runs on port 7443 by default and is not itself a GIS service host.

ArcGIS Server provides the REST services (map, feature, image, geoprocessing) and the administrative REST endpoint at /arcgis/admin; the hosting server role is required to publish hosted layers.

ArcGIS Web Adaptor is a reverse proxy that forwards requests to Portal or Server on a context path such as /portal or /server, and can be configured to enforce authentication at the edge.

ArcGIS Data Store provides three store types: relational (hosted feature layers), tile cache (hosted scene layers), and spatiotemporal (feature tracking); a base deployment requires at least a relational store.

The hosting server is the ArcGIS Server site registered with the portal as a hosting server; only one hosting server site can be designated at a time in a portal.

Federating an ArcGIS Server site with the portal establishes a trust so portal tokens are accepted by the server; the server's primary site administrator is used during federation and the site is then managed through portal identities.

A highly available portal uses two portal machines behind a load balancer plus a shared content directory; the portal's configuration store is replicated across portal machines.

ArcGIS Enterprise can be deployed on Windows or Linux, and since 10.9/11.x supports containerized (Kubernetes) deployments; the component topology is the same regardless of platform.

Portal for ArcGIS requires a portal license file (.json or .prvc) applied at creation time or later through Portal Administrator Directory; ArcGIS Server requires a separate server license file.

The portal's initial administrator account is created during portal creation and cannot be renamed or deleted afterward; it can be disabled only after another administrator exists.

ArcGIS Web Adaptor must be installed on a machine with a supported web server (IIS on Windows, or a Java servlet container on Linux) and registered with the target component using an administrative account.

Before federation, configure the ArcGIS Server site with a primary site administrator account and ensure the portal and server can reach each other by fully qualified domain name over HTTPS.

Licensing model: named user licenses are assigned through the portal's organization settings, and the portal's license determines available apps and capabilities; ArcGIS Server licensing is by license file and edition (Standard/Advanced).

When configuring the portal's WebContextURL, set it to the externally reachable URL (including the Web Adaptor path) so generated links and OAuth redirects resolve correctly.

ArcGIS Data Store is configured after installation by running the configuredatastore utility against the hosting server, specifying the store type and a data directory.

Portal and Server require a supported database for their configuration stores (or default file-based stores); the configuration store should be backed up before upgrades.

Upgrades follow a defined order: upgrade Portal first, then ArcGIS Server, then ArcGIS Data Store, then Web Adaptor; consult the component-specific upgrade path for the release.

Portal supports built-in identity stores and enterprise identity stores (LDAP, Active Directory, SAML 2.0, OpenID Connect, PKI); enterprise stores are configured in the Portal Administrator Directory under security/config.

Role-based access in the portal uses roles (Viewer, User, Publisher, Administrator) plus custom roles; privileges are grouped into general, content, and analysis categories.

Sharing levels are Owner, Organization, Groups, and Everyone; an item shared with Everyone is anonymous-accessible only if the organization allows anonymous access.

The portal's security settings include anonymous access toggle, TLS enforcement, and the ability to restrict access to the portal by organization-specific rules.

Federated servers accept portal tokens; non-federated servers use their own tokens or primary site administrator credentials, so token scope must match the target service host.

ArcGIS Server security can be configured for ArcGIS tokens, Windows authentication, or PKI; the identity store configured on the server determines how credentials are validated.

SAML configuration requires an identity provider metadata file, a service provider certificate, and matching assertion consumer service URLs; clock skew between IdP and portal causes assertion failures.

HTTPS is required for federated servers and for SAML/OIDC; certificates must be trusted by all clients, and the portal's certificate should include the fully qualified domain name used in WebContextURL.

Administrative access to Portal Administrator Directory and ArcGIS Server Administrator Directory should be restricted at the network layer; these endpoints bypass normal content sharing rules.

A relational ArcGIS Data Store is required to publish hosted feature layers; the hosting server writes hosted data to the relational store, not to the server's local directories.

Hosted tile layers and hosted scene layers use the tile cache data store; feature tracking (stream) services use the spatiotemporal data store.

Registered data stores (enterprise geodatabases, folders, big data stores) are registered with the federated server so services reference data in place; the data must be reachable by every server machine in the site.

Publishing a map service from a registered enterprise geodatabase creates a service that reads directly from that database; the connecting user's permissions determine what the service can access.

Content items in the portal include maps, layers, apps, and files; each item has an owner, sharing level, and optional groups, and item IDs are GUIDs used in REST URLs.

A hosted feature layer can be overwritten by publishing from a source with the same name and schema; overwriting preserves the item ID and dependent maps.

The portal's content directory stores item data and thumbnails; it must be on shared storage in a highly available portal and included in backups.

Service publishing requires the publisher role or a custom role with the publish privilege; the hosting server must be designated before hosted layers can be created.

Layer sharing and service permissions are distinct: sharing an item controls portal visibility, while the underlying service's permissions control direct REST access.

The Portal Administrator Directory provides logs (JSON/text) and a health check endpoint; ArcGIS Server logs are available per machine and per service in the Server Administrator Directory.

Log levels range from SEVERE through FINE/VERBOSE; raising the level increases log volume and should be time-limited to avoid disk exhaustion.

ArcGIS Data Store backups are created with the backupdatastore utility and should be scheduled; the relational store backup is required to restore hosted feature layers.

Portal backup uses the export site operation in Portal Administrator Directory (or the backup utility) and includes the configuration store and content; restore requires the same version.

Monitoring options include ArcGIS Monitor (separate product) and built-in logs; server metrics such as REST request counts and response times are exposed in the Server Administrator Directory.

Performance tuning levers include instance counts and max instance settings per service, the server's SOC processes, and JVM heap sizing for Portal and Server.

A service's maximum records returned and the map/feature service's query limits affect client performance; tiling or vector tiles reduce load for large datasets.

Scheduled tasks in the portal (such as refresh of indexes or cleanup of deleted items) and regular validation of the portal's self-signed vs trusted certificates support stable operation.

After upgrades or configuration changes, verify federation status, data store registration, and that the hosting server is still designated; these are common post-maintenance failure points.