Latest Contributions by JonathanQuinn

It shouldn't be present anywhere. The promote.dat file is created once the software determines that the standby should be promoted. What you may have been running into is a bug, an indefinite loop of promotion/demotion: 1) Portal 1 is primary and portal 2 is standby. Portal 1 has the promote.dat file. If this file is present in the db directory on standby, it will be promoted to primary. At some point the standby came back from being down and the file was present in the db directory on primary. 2) When standby comes back, it needs to get a db snapshot from primary. This is basically copying the db directory from portal 1 to portal 2. 3) When portal 2 gets the db directory, the promote.dat file tells it to promote itself to primary. 4) Logic in portal 1 is validating whether portal 2 is standby. When it isn't, it backs up the db directory to dbXXXX and sends over another db directory. 5) Now the deployment is back at step 3, and so on. There are two issues: 1) the promote.dat file is left on primary and 2) the promote.dat file is moved over to standby during the db snapshot. I'm not sure how 1 could have happened but 2 is easily handled by deleting the file when we create the db snapshot. We plan to do this within the software. ... View more

As you may know, the DR tool will run all backups in parallel so the Portal, Server, and Data Store backups will be running at the same time. That, on top of normal usage, can certainly result in 100% CPU usage. It's strange how the incremental backups will run for a few days and then suddenly start failing that full backups need to be taken. You're not restoring the backups, correct? Do you have a DR environment? Is the Data Store failing to create an incremental backup? It doesn't matter where the DR tool is run from, it'll always figure out which portal is primary and run the backup on that portal machine. Is the DR tool complaining that the SHARED_LOCATION path is not accessible? ... View more

Non-standard ports are supported starting at 10.6.1: Ex. Use nondefault ports for the portal's ArcGIS Web Adaptor—Portal for ArcGIS (10.6) | ArcGIS Enterprise  If you're on 10.6 or earlier, then non-standard ports are likely the problem. If you are at 10.6.1, then make sure you're following the instructions in the link above. I think the information assumes that you have a reverse proxy running on 80/443, and the software may be assuming standard ports as well. As Bill Bott‌ suggests, start with using standard ports and go from there. Reconfiguring the public URLs of the deployment does require a bit of work though. It's best to reach out to Tech Support to understand what's involved and if it's necessary to rebuild. ... View more

You may be running into this: BUG-000119454 - Publishing a line feature class to Portal from ArcGIS Pro with only the default fields in the feature class fails If you want to confirm or be attached to the bug, contact Tech Support and they can work with you on that. ... View more

Sounds like a bug. Do you have only default fields in the feature class you're publishing, (OID, Shape, etc)? If so, try to add another field and publish. You may want to reach out to Tech Support and provide your data so they can check whether they can reproduce it as well. ... View more

You can use Python to loop through the Sharing API and update the URLs for web apps to point to the new URL. A few of the examples for the Python API have code to loop through users and content so they can be used as a starting point: move_existing_user_content_to_a_new_user | ArcGIS for Developers  https://developers.arcgis.com/python/sample-notebooks/clone-portal-users-groups-and-content/ ... View more

Are there any other errors at the WARNING or SEVERE level about the inability to publish the service? ... View more

There's no way supported way to customize the 403 error that's returned from Server. This would be a good enhancement to log on the Ideas page. ... View more

Do you see anything in the Server logs? You can set the logs to DEBUG and republish if you want to get the most out of them. When publishing fails, it should log something within the Server logs. ... View more

What part of the process is taking the longest? If the BACKUP_LOCATION is set to a share, then I imagine that's what's taking the most time, (this is the "packaging" message". You can confirm from the cmd output or the logs. Zipping the backup takes a significant amount of time if you have a large amount of data and are backing up to a share. We are investigating ways to reduce this time, either by optimizing the packaging operation or providing an option to not package it at all and simply copy the backups to the BACKUP_LOCATION. ... View more

Was a site created before? Is this a new install or was everything working correctly before? The issue is that you may have files/folders within the config-store or directories path that associate those directories with an existing site, so you can't use them for a new site. If this is supposed to be a new install, you can delete the contents of the config-store and directories. If this was a functional site and things stopped working for some reason, I'd strongly suggest you contact Tech Support to sort out what happened. If you want to fix this yourself, you can backup the config-store and directories folders, (just in case), search for .dat files within each directory and delete them. These files associate the config-store and directories to a site. By deleting them, you're telling Server it can use the folders and any existing data within them. If this was an existing environment, it would be good for you to investigate what happened with Tech Support, though. ... View more

No, that's not expected behavior. The only time a dbXXXX folder will be created is when the standby comes back from a failure or when you run importSite on Portal. During normal operation, it shouldn't create those folders. It seems like it is continually thinking the standby is coming back from a failure. Can you set the logs to at least Verbose and then post the logs? Feel free to scrub the machine names out of them. Do you see a promote.dat file within the db directory on primary? ... View more

The BACKUP_STORE_PROVIDER was added at 10.5.1 to support AmazonS3 as the storage location: Create an ArcGIS Enterprise backup—Portal for ArcGIS (10.5.x) | ArcGIS Enterprise  BACKUP_STORE_PROVIDER = {FileSystem | AmazonS3} This property is new in 10.5.1. If you want to store your ArcGIS Enterprise backup in a file share location on premises, specify FileSystem, and the webgisdr utility will store your backup files in the file share you specify for BACKUP_LOCATION. You won't see it if you're on 10.5. ... View more