POST
|
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
14 hours ago
|
0
|
0
|
11
|
POST
|
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
14 hours ago
|
1
|
0
|
32
|
POST
|
This will be addressed in the next 10.9.1 Security patch. I'm not sure when it will be released though.
... View more
14 hours ago
|
1
|
0
|
39
|
POST
|
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
4 weeks ago
|
0
|
0
|
132
|
POST
|
Yikes, definitely a bug, thanks for the update. If you can, get in touch with Support Services to log a bug.
... View more
02-16-2024
01:40 PM
|
0
|
0
|
152
|
POST
|
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
02-16-2024
07:12 AM
|
0
|
2
|
166
|
POST
|
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
02-15-2024
11:05 AM
|
1
|
4
|
257
|
POST
|
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
12-22-2023
08:19 AM
|
1
|
0
|
473
|
POST
|
Depending on when you ran the setups and when the services on each machine were stopped as part of the upgrade process, there's a chance that the standby determined that the primary was unhealthy and promoted itself to primary. It's more deterministic to run the setups sequentially rather than in parallel, or at least run it on standby first, wait for the standby to shut down, then run it on primary. I'll take a look at whether we can improve our documentation. Aside from that, the failure to unzip content may not be relevant to the roles of the machines. I'd suggest reaching out to Support with debug logs of the failure so they can troubleshoot. If you want, reply with the case number so I can take a look.
... View more
12-20-2023
09:01 AM
|
2
|
0
|
603
|
POST
|
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
11-27-2023
10:26 AM
|
0
|
4
|
396
|
POST
|
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
11-21-2023
08:17 AM
|
0
|
0
|
316
|
POST
|
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
09-26-2023
12:08 PM
|
0
|
1
|
688
|
POST
|
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
09-21-2023
06:43 AM
|
0
|
1
|
627
|
POST
|
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
09-20-2023
02:02 PM
|
0
|
3
|
748
|
POST
|
I suspected that the arcgis#sharing.xml file was the culprit, since any requests to create content will use that connection string. The /gwdb?targetServerType=master syntax should be at the end of the JDBC URL; the cleanest approach is to unregister standby and re-register it. However, if you don't want to go that route, you can update the arcgis#sharing.xml file and add /gwdb?targetServerType=master to Portal2's JDBC URL and restart the standby.
... View more
09-19-2023
10:37 AM
|
0
|
5
|
810
|
Title | Kudos | Posted |
---|---|---|
1 | 14 hours ago | |
1 | 14 hours ago | |
1 | 02-15-2024 11:05 AM | |
1 | 06-22-2020 03:51 PM | |
1 | 12-22-2023 08:19 AM |
Online Status |
Offline
|
Date Last Visited |
5 hours ago
|