Latest Contributions by ChristopherPawlyszyn

This may work: import csv from arcgis.gis import GIS gis = GIS(portalUrl,username,password) outputFile = r"<output_file_path>" users = gis.users.search('*', max_users=1500) with open(outputFile,'w',newline='') as ResultFile: wr=csv.writer(ResultFile) header = 'Username,LicenseType,Email' wr.writerow(header) for user in users: if not 'esri_' in user.username and user.userLicenseTypeId == 'viewerUT': #Filter esri_ built-in users and only includes viewer license types wr.writerow(user.username,user.userLicenseTypeId,user.email)   The user object's role doesn't include the license level of the user, rather the capabilities within the organization. Reference ... View more

You should not have a 7443 binding in IIS, since that would prevent Portal for ArcGIS from binding on that port. IIS is used to host the ArcGIS Web Adaptor and typically is bound to the standard HTTP and HTTPS ports (80 and 443, respectively). I would try removing that binding from IIS Manager, then restart the Portal for ArcGIS service, then see if you are able to load the Portal Home application. ... View more

I would caution against using ArcGIS Enterprise Builder on an EC2 instance (judging by the returned hostname) since it does not support the use of a DNS alias for the deployment and the organization and services URLs will be based-on the instance name. If this is for an internal proof of concept environment that may not matter, but the alternative would be to follow the base enterprise deployment tutorial. ArcGIS Enterprise Builder doc ... View more

The files contained in that folder can be removed with the exception of the latest file (which is likely still being written-to). There was a database setting introduced at 10.9 to prevent the build-up of the write-ahead logs when not regularly using the WebGISDR tool, as well as a 'backup' mode that will not remove the cap on the log build-up.   https://developers.arcgis.com/rest/enterprise-administration/portal/database-settings.htm ... View more

Have you tried running a backup using the backupdatastore tool included with ArcGIS Data Store? That would give us some more insight into whether the failure is unique to the WebGISDR tool or happens with both the local and remote utility. Also would be curious how large the relational data store is on your production environment and the size of the last successful backup. ... View more

Due to the nature of username uniqueness across all ArcGIS Online organizations the same tool isn't available within the SaaS platform. ... View more

Glad that shortened the restore time @NicolasGIS, although I understand the increased performance comes at an higher cost operationally.   In regards to my testing, I published a 35GB SLPK to an 11.0 stack and tested backup and restore to a separate site. The backup took a bit over an hour for the tile cache data store, while the restore took about the same (sending/staging to a network SMB share on a separate Windows machine). There's certainly room for improvement, I believe you're already attached to the existing performance defect logged in Salesforce (BUG-000139154) but I will discuss with the team on prioritization going forward. ... View more

Doing some benchmarking on my end as well and will post the results, wanted to clarify that this is during a full mode restore and not utilizing incremental mode. ... View more

We'll look into updating the property description for future releases, there were some backend logic changes that look like they didn't make it into the WebGISDR help. Thanks for the feedback! ... View more

What version are you currently testing with? The 24 hour timeout is hard-coded, so the best approach would be to try to cut down on latency between the components and the file share(s) as well as increasing the performance of the associated drives from an I/O perspective (if possible).   The first thing I'd consider is the proximity of the shared location to the ArcGIS Enterprise components, as the restore will be pulling those files for the individual component restores.   Are you able to backup only the tile cache manually, move the backup to a local drive on the standby machine, then restore using the Data Store utilities? This would give us a good comparison of the network location versus local disk. ... View more

The major problem you'll run into with on-prem clients accessing cloud RDBMS instances is the increased latency. The database connections are very chatty, so any increased network latency will be very noticeable with your desktop-based workflows. Some organizations have ExpressRoute links that reduce the latency to a reasonable threshold, but that also adds complexity to the networking side of things.   As a general rule of thumb, I would try a proof of concept where you access the cloud-hosted database from desktop clients and try some typical workflows and see if the increase in transaction times is tolerable.   Another aspect is that if the latency increases (due to ISP routing issues or changes in the network path), technical support cannot help with troubleshooting/identifying the issue since it is expressly discouraged in the documentation. The recommendation is that all components exist within the same datacenter/cloud provider region for the lowest latency and highest chance of success.   Some customers have also implemented a scheduled synchronization of on-prem and cloud enterprise geodatabases, which comes at the expense of lag time before the cloud database is up-to-date, but allows for the hybrid structure you're proposing. ... View more

The mismatch should be resolved for all versions, please let us know if you're still having any trouble. ... View more