Latest Contributions by JonathanQuinn

If you have a distributed environment and there's latency to the file share, then yes zipping or unzipping will take a long time. You can definitely set up the share on the local machine where the DR tool is running and set the share as the SHARED_LOCATION property and the BACKUP_LOCATION as a local drive to avoid going over the network. Then, have another process within your automated backup copy the file from the BACKUP_LOCATION to your file server where you're storing the backups. This would work for backing up the environment. For restoring, just copy from the file server to a local drive prior to the restore. We've updated the documentation to reflect this. ... View more

Can you determine the share that the error is referencing? Was the DR tool creating a backup or restoring a backup during that time? Each backup process stages the backups on the local drives. For example, the DR tool creates a backup and the SHARED_LOCATION is set to \\fileserver\staging and the BACKUP_LOCATION is set to \\fileserver\full, when the portal is backed up, it'll copy all of the items in the content directory to C:\arcgisportal\temp\<tmp backup folder>. Once it's done, it'll zip it and then copy the backup, (one large zipped file of all content), to the SHARED_LOCATION. The same happens for Server and Data Store; the backups are staged locally before copying to the SHARED_LOCATION. I imagine the copy would open a single TCP port, rather than chunking the file and opening multiple ports. ... View more

Another thing to keep in mind is that typically, ArcGIS Enterprise is accessed via standard ports, (80/443), even though the Web Adaptor supports non-standard ports starting at 10.6: Use nondefault ports for the portal's ArcGIS Web Adaptor—Portal for ArcGIS (10.6) | ArcGIS Enterprise  The assumption is that you'll set up a reverse proxy or load balancer to listen on 443 and send traffic to the web adaptor over your non-standard port, (8080): Configure the portal with your organization's reverse proxy server or load balancer, so that users access the portal through the default ports. To do this, you need to provide some information to the portal about the reverse proxy or load balancer. For full instructions, see Use a reverse proxy server with Portal for ArcGIS. ... View more

First, the two portals must be on the same version, so you won't be able to join the 10.7.x portal to the 10.6.x portal. Second, when you installed Portal on Server B, did you use the C:\arcgisportal for the default directory during the install? If not, the account used to run the service will attempt to create the C:\arcgisportal directory on Server B if it has permissions to. There's a bug to improve the error returned if either the default directory path on Server A doesn't exist on Server B or the path can't be created. Server B will want to use the same path for the index, db and temp directories as Server A. I would start by making sure the versions are the same. Is this a base deployment, all on one machine? Another approach is to use the DR tool to move the entire configuration to the new machine, so you can upgrade the new environment separately from your primary environment: Migrate to a new machine in ArcGIS Enterprise using the WebGIS DR tool  ... View more

The portal machines at 10.6 and earlier have a bigger chance of becoming out of sync, depending on how the machines are restarted, due to the architecture at those releases. There are a couple of files that determine which is primary and standby, and if both machines think they are primary, you'll run into a problem. The quickest fix is to contact Technical Support so they can go through the setup and make sure each file contains the correct information. Also, consider upgrading to at least 10.6.1, as that version has improvements to make failover faster and more reliable. ... View more

Can you describe the original purpose of setting up Portal with the etc\hosts entry set? I think you should be able to remove the etc\hosts entry, check where Portal redirects to when you go to https://localhost:7443/arcgis/sharing/rest, (when you're on the machine), and then update the privatePortalURL in the System properties for Portal to point to the URL it redirected to. This should be pushed to the Server. If it's not, you can update the server privatePortalURL property manually, (see step 9 in the doc here) ... View more

I'm assuming that the note meant "single FQDN", which is more appropriate. On each Web Adaptor machine, what happens if you reach the Portal via the Web Adaptor? Does it resolve and take you to the Portal home page? ... View more

From what I gather, it looks like you're registering the web adaptors on the new machines to the portal and server in your primary site. Instead, you want to register them to the portal and server in your secondary site. In your first screenshot, the URL you reach the web adaptor registration page with should be the URL to your primary environment. However, since you have the etc\hosts entry on that machine, those requests should resolve to the standby web adaptor: In the example above, my production/active system is accessed via enterprise.domain.com. The enterprise.domain.com machine has a web adaptor on it and the WA is registered to Portal and Server on m1.domain.com. These are all entries in DNS. I want to stand up a new environment to migrate to, so I'll: 1) Create the new machines. They end up with hostnames enterprise1.domain.com and m2.domain.com. enterprise1.domain.com has an IP address of 10.0.0.2. 2) In the etc\hosts files on each machine, i'll add a entry that resolves enterprise.domain.com to 10.0.0.2:    10.0.0.2 enterprise.domain.com.    Now on each of those machines, if I reach enterprise.domain.com, the request will resolve to the machine that has an actual FQDN of enterprise1.domain.com. 3) Install the web adaptors on enterprise1.domain.com. 4) Install Portal, Server, and Data Store on m2.esri.com and create the sites/register the data store 5) Register the web adaptor on enterprise1.domain.com to m2.domain.com via https://enterprise.domain.com/<wa context>/webadaptor/portal to portal and https://enterprise.domain.com/<wa context>/webadaptor/server to server. Again, these requests will be directed to enterprise1.domain.com 6) Federate 7) Run the DR restore The approach described above minimizes downtime for your original environment. Another approach would be to: 1) Set up your new machines for only Portal, Server, and the Data Store, (m2.domain.com) 2) Register the web adaptors on enterprise.domain.com with the machines on m2.domain.com 3) Continue to set up the environment, (registering the ArcGIS Data Store and federating) 4) Run the DR tool to restore the backup This will take down your production environment for a bit. I'll take a look at the blog and make sure that our instructions are clear. ... View more

Unfortunately, I won't be at the International Dev Summit. I can ask for a few things for troubleshooting, but only if you don't mind potentially duplicate troubleshooting efforts. In terms of being HA, the standard for being HA isn't that it's active/active at all times, it's that there are redundancies built into the software that can handle failover and can continue working effectively. Effectively is likely open to interpretation, (especially if you've run into issues with Portal HA previously) and is certainly dependent on version. Prior to 10.6.1, it took minutes for the standby portal to promote itself to primary. 10.6.1 and on, it occurs typically within 30 seconds. It seems like Oracle supports active/active where each database can accept write transactions, but SQL Server and SAP HANA seem to only support active/active as read-only systems, while being active/standby for read/write. They describe these setups under their own HA topic headings, so again, throughout the industry we will see HA covering more than just active/active. https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.03/en-US/879d9dc46bb64ccda028872c86c70afc.html ... View more

While there are different architectures (active active or active passive) for HA, the same fundamental principles apply, which you've mentioned: eliminating single points of failure and being able to fail over and recover automatically without data loss. All internal components within portal meet those requirements. The content directory for portal poses a bit of a challenge as that can be set to a simple file share, but as long as your storage is highly available, you're fine. Taking advantage of cloud native storage makes that easier as well. Bottom line, ArcGIS Enterprise, including Portal, can certainly be configured as a highly available system.   There's also no problem sending traffic to both Portal machines. Internally, the secondary/standby portal will communicate with the database on primary. Also, PG supports multiple standby machines, but there hasn't been a customer need to support it in portal. While you set up a multi-machine Server site for scalability as well as availability, you're not setting up an HA portal for scalability. Being HA means you need to have HA practices, as well. This means configuring your patching to ensure that there's always one healthy machine. If you patch the primary portal, (p1), you need to make sure that the standby, (p2) becomes primary and is healthy before patching p2. This is no different than any other relational database that operates as active/standby. Michael Robb‌ can you describe the replication corruption you experienced? ... View more

First, the script assumes the http endpoint is available. You may want to consider setting Server to https only or http and https and updating your script to use the https endpoint for security reasons. ssl - HTTPS connection Python - Stack Overflow  Secondly, I don't see any issues when running the script: Output querying for WARNING errors: Output querying for SEVERE errors: ... View more

You can query the logs via Manager to see what request it's sending the Admin API, and it turns out to be an empty dict when querying for all machines: Via the Admin API, any of the properties in the filter list are not in an array: If you want to query a machine, then it's passed in as a value within an array: Easiest approach is monitor the network traffic when making requests via the Admin API or Manager and then re-create them. ... View more

Where you're publishing from, so your desktop client with Pro or ArcMap. ... View more

Can you check the environment variables on the machine and see if you've defined the PYTHON_PATH environment variable? I can't recall the specifics but I've seen this before and the problem was the PYTHON_PATH variable was set. Once it was removed, publishing worked as expected. ... View more