Latest Contributions by ChristopherPawlyszyn

Curious to hear your results as well but here's what I've found in my testing.   I was able to reproduce this issue with the latest build by first creating a site for ArcGIS Server, exporting the site, creating a hostname.properties file (with the same FQDN defined as the original machine name) and restarting the service, then attempting to import the exported site.   I've created an issue internally for tracking this behavior and I expect preventing the hostname.properties file from being created during an upgrade using PowerShell DSC should be a viable workaround for the time-being.   When using the standard PowerShell DSC release branch, the hostname.properties file exists prior to site creation, so doesn't cause the failure condition from what I can tell. ... View more

Users with administrative roles are able to see all services for federates sites' in the REST/Services endpoint since they have permission to access all items within the organization as well. Otherwise, lesser-privileged users are verified via the privatePortalURL for permissions to services/folders prior to display of the REST services page. ... View more

Yes, that order makes perfect sense; in reality steps 1, 2, and 3 in shutdown can be combined as well as 3 and 4 in startup. Otherwise hosted services may take a bit to regain access to the relational data store. In terms of Portal for ArcGIS, you want to make sure you shutdown the standby to avoid failover (if doing things manually) or stagger the restart times between primary and standby if scheduling automatically. This will keep things from becoming split-brained as the machines start-up; primary will be recorded in the HA configuration file so start-up should be consistent when it comes back online. ... View more

I couldn't say there is zero risk associated with it, hence the preferred intro above, but the error reported by Portal is specific to the HA plugin attempting to start the machines in the correct order according to the files in the ../content/items/portal-ha directory. If anyone were publishing to the site or creating content when the file server went down there is a high risk to those items/services being corrupted, but less likely that the entire site would be affected. Since all components expect that their shared directories are always available while running, clean-up from corrupted items/services is a variable process that may require manual intervention that isn't documented. ... View more

Preferably, the dependent machines would be shutdown while restarting the file server (or at least the services stopped for those components), then brought back up after the file server becomes available on the network again. More practically speaking, and as you saw in the restart of Portal for ArcGIS on both machines, restarting following the file server should bring things back to a working state. Another point I would consider is if your shared/backup locations for the ArcGIS Data Store configuration or WebGISDR backups are located on the same file server you wouldn't want to restart it during the automatic/scheduled backup time(s). ... View more

This documentation may help you determine which approach fits best for your organization. The 'join site' method is common for this workflow when downtime can be tolerated, whereas the WebGISDR method involves replicating the deployment to a new machine with certain caveats/requirements. The WebGISDR tool would only work for this if your ArcGIS Server site is federated with the Portal for ArcGIS organization. https://enterprise.arcgis.com/en/portal/latest/administer/windows/migration-strategies.htm ... View more