Latest Contributions by JonathanQuinn

This is achieved using the DR tool and geographic redundancy: https://enterprise.arcgis.com/en/portal/latest/administer/windows/overview-disaster-recovery-replication.htm The blog below covers some additional information related to hostname resolution when setting up a new, replicated environment in the context of migrating, not geographic redundancy, but the concepts still apply: https://www.esri.com/arcgis-blog/products/arcgis-enterprise/administration/migrate-to-a-new-machine-in-arcgis-enterprise-two/ ... View more

Understanding how the DR tool is communicating with the deployment is important, and we can improve our documentation to highlight that. However, in this case, while there is a chance that requests may make it from the target site to the source site, there's no chance that the restore will be able to run. Once the new environment is set up, a unique key is generated to decrypt and encrypt tokens. Site A will use key 1 and site B will use key 2. A token created in site B will have been encrypted using key 2, and if that token is used in site A, it can't be decrypted using key 1. The first restore will always fail if requests were making their way to site A. Aside from that, there's no real requirement that the target machines are in their own virtual network; typically that'll happen if you use the DR tool to support geographic redundancy, but in the case of migrating between newer hardware or operating system, that won't be the case or necessary. ... View more

This is likely an issue with the properties.json file under content\items\portal\properties.json. Can you check if that's blank? If it is and you have a WebGIS DR tool backup, you can extra the webgissite file, then the portalsite file, and copy the properties.json file from the backup into the path above. ... View more

Yikes, definitely a bug, thanks for the update. If you can, get in touch with Support Services to log a bug. ... View more

I wouldn't expect a certificate problem to impact specifically Manager access; are you able to publish hosted services? If you look at the web traffic when accessing Server Manager, do you see an error similar to "Cannot generate a token for this server"? ... View more

Does <custom subdomain>/<webadaptor> match either the services URL or the admin URL that's used in federation? When Server is federated with Portal, Portal only knows about those two URLs. When Manager is accessed, it operates as an "app", and the URL must be known to Portal, which means it can only be accessed using either the services URL or the admin URL used to federate. ... View more

The standby will be upgraded during the primary upgrade, if the upgrade was invoked on standby, or during the post-upgrade step if the upgrade was started on the primary. Either way, its handled at some point; just depends on which node you started the upgrade from. ... View more

The Web Adaptor registration page sets the "organization URL" for the portal. For example, if you access the registration page by going to https://enterprise.domain.com/portal/webadaptor, the portal will use https://enterprise.domain.com/portal as its front-end URL. Any request to the portal that isn't made to that URL will redirect to the internal machine name of the portal. Below is a link describing the various ways the organization URL can be defined: https://enterprise.arcgis.com/en/portal/latest/install/windows/determine-your-organization-s-url.htm If you set up something in front of the Web Adaptor, (load balancer or reverse proxy), you'll need to set the Web Context URL and relevant X-Forwarded-Host header to make sure that Portal knows what URL it should use.  https://enterprise.arcgis.com/en/portal/latest/administer/windows/using-a-reverse-proxy-server-with-portal-for-arcgis.htm You'd also need to make sure you re-write the Location header in the event portal redirects, which can happen in certain situations: Along with the X-Forwarded-Host header, your load balancer must be able to direct redirects (HTTP response codes 301 or 302). All Location headers should be rewritten on the load balancer to ensure that the fully qualified domain name (FQDN) and context of the response match the portal's WebContextURL value. In your case, you'd use the proxypassreverse directive with Apache: https://httpd.apache.org/docs/2.4/mod/mod_proxy.html#proxypassreverse This directive lets Apache httpd adjust the URL in the Location, Content-Location and URI headers on HTTP redirect responses. This is essential when Apache httpd is used as a reverse proxy (or gateway) to avoid bypassing the reverse proxy because of HTTP redirects on the backend servers which stay behind the reverse proxy. ... View more

The DR needs to read from the SHARED_LOCATION path, while each component needs write access to the SHARED_LOCATION path. The DR tool needs to write to the BACKUP_LOCATION path. Have you verified that the account running the DR tool can read/write to \\MAP01\Backup\backups? ... View more

No, this is a one time issue that occurred after installing the patch. The problem won't occur when the new patch is issued and failover won't be impacted. ... View more

Absolutely, that's a problem to address, not workaround. Did you recently patch the portals? There's a bug with patching an HA portal, specifically impacting the standby. The latest 11.1 patch is going to be re-issued to address the problem. ... View more

This is an issue with the Portal for ArcGIS 11.1 Enterprise Sites Security Patch in HA environments and BUG-000160830 - The 11.1 version of the Portal for ArcGIS Enterprise Sites Security Patch causes issues in highly available environments is logged to address it. We are going to re-issue the patch after correcting for the problem. For those who already installed the Portal for ArcGIS 11.1 Enterprise Sites Security Patch and encountered this problem, there will be a tech article with the manual steps to restore the correct values to the arcgis#sharing.xml in order to resolve the problem. ... View more