Latest Contributions by AngusHooper1

As Moginraj Mohandas‌ said, a multi-machine site is not actually HA. When we talk about failover & HA, we need to talk about it in the context of risk. If you had two distinct AGS sites underneath a NLB, what risk are you trying to mitigate? If the network connectivity drops, failover means nothing. If the data tier drops, failover means nothing. Etc. Active-passive of AGS would only resolve an issue which is inherent to the AGS application tier. And, theoretically, both sites are identical so the issue could also occur in the passive site. I tend to find the argument for HA in the application tier is not strong enough to warrant the administrative overhead when considering how little risk it mitigates. Risk is only comprehensively mitigated when you have a passive site on a completely different domain/data centre with duplicate data holdings etc. ... View more

Just to clarify, this is a design where the hosting server would be active-passive (2 x VM's, 2 x sites)? Or, a hosting server site that is multi-machine (2 x VM's, 1 x site)? ... View more

Great post Scott. In my experience, the hiccup with these workflows is if your environment is fundamentally leveraging the federation & hosting configurations. This is particularly apparent when you have a system that has been in production for some time and you are dealing with old design niggles. As it currently stands, I cannot see how you could possibly migrate a GIS that has a hosting server from one environment to another without an outage. You would need to set the hosting GIS to be in read-only mode as you run a chance of orphaning objects/data edits during the migration proces (e.g. webgisdr). As your migration mechanism (e.g. webgisdr) creates a point-in-time backup of the GIS, no further changes can be made to the live GIS. If you only have a GIS services and registered database requirement, then you are probably fine as these can be static for a short period of time. With regards to old design niggles, something that is quite frustrating is how old server URL's can be baked into almost everything in the GIS. You could potentially get around this with DNS redirect logic, but I would suggest that this is a bandaid and you'll have to comprehensively edit items in the GIS via the python API to point to new URL's. In an ideal world, all your servers have been sitting behind a DNS or load balancer which would help you with the 'swap out' model of Join Site. This is potentially where my team will be moving to, but the first item to tick off is remediating legacy content that references FQDN's. You'll need to make sure that the federated server admin url is pointing through a DNS/load balancer for similar reasons. Any comments/advice for the above? Happy to be proven wrong. It's a topic that many in the GIS community are trying to solve it seems. ... View more

Unfortunately we are using notepad to edit the file, but that's a good line of questioning. Our local is English (Australia). As an FYI, the portal logs (debug) show no records which highlight that this error is occuring within the actual webgisdr executable logic rather than after the GIS is contacted by the tool via the REST api. ... View more

Shared_location has been \\myshare\webgisdr\backup (this fails the export due to escape character handling), \\\\myshare\\webgisdr\\backup (this fails on import with the above error) and //myshare/webgisdr/backup (fails with the above error). ... View more

I'd look at your network log (browser developer tools) to see if anything is blocked, failing or erroring out. ... View more

What version of ArcGIS? I would not apply CORS handling at the iis tier for 10.6+ in my experience. Have you added any servers to the trusted server list in Portal? Are the CORS errors happening across all clients & domains, or only a subset? In he response headers, you want to be seeing access-control-allow-credentials set to true and access-control-allow-origin the appropriate FQDN. ... View more

Yes, that example aligns exactly with our experience. It's the double edged sword of an open platform that allows users to collaborate on data. ... View more

Just as an FYI, the hosting gis server can have extremely high CPU utilisation for javaw, along with significant network sent/received associated with javaw when running expensive queries against a hosted feature layer. You can diagnose this by looking at the response times in the postgresql datastore logs. We had 20+ users querying a poorly designed dataset within seconds of each other which caused the hosting server to grind to a halt. In this case, a single user accessing this hosted feature layer had more impact on hardware than all other users combined. ... View more