|
POST
|
So to confirm, Engine is required if you are deploying Notebook Server onto a windows 2016/2019 machine?
... View more
09-11-2019
04:01 PM
|
0
|
4
|
3592
|
|
POST
|
Just to expand on this point, if Docker for Desktop is documented (by Docker) as only being available/supported for Windows 10, how can we deploy ArcGIS Notebook Server on a Windows 2016/2019 server? The Esri documentation references Docker runtime 17.0+ as the supported version which does not align with "Docker for Desktop". ArcGIS Notebook Server system requirements—ArcGIS Enterprise system requirements | ArcGIS Enterprise Then, the Esri documentation references Docker for Desktop as the avenue for getting Docker Engine which is required. Install Docker for ArcGIS Notebook Server—ArcGIS Notebook Server Installation Guide (10.7) | ArcGIS Enterprise Docker for Desktop states that it is only supported for windows 10. https://hub.docker.com/editions/community/docker-ce-desktop-windows Docker Engine Enterprise states that it supports 2016+. Install Docker Engine - Enterprise on Windows Servers | Docker Documentation So, do we use docker for desktop or docker engine enterprise when deploying Notebook Server onto a 2016/2019 server?
... View more
09-09-2019
06:05 PM
|
0
|
6
|
3592
|
|
POST
|
If you turn on automatic account creation, are accounts automatically created per a ldap user when they hit the portal home page?
... View more
09-02-2019
05:42 PM
|
0
|
1
|
1897
|
|
POST
|
If this was not happening previously then it is likely that the certificate has expired.
... View more
08-29-2019
09:28 PM
|
0
|
1
|
2297
|
|
POST
|
Exactly. When dealing with the various stakeholders you need to make sure everyone understands the differences between multi-machine site, multiple sites with distinct functions, multiple sites in HA under a NLB etc. Some of these design options may give the desired 'HA' benefit that you are wanting without being a 'true HA' design. For example, a multi-machine site provides some clever workflows for upgrading the site, upgrading underlying OS' and dropping or adding VM's without a perceived outage. This, depending on some audiences, may be the primary reason for a HA design and yet I wouldn't call it actual HA. It's all semantics, but I find the tricky part is unpacking that requirement of 'HA' or 'fault-tolerant' or 'no outages' and then pointing that in the direction of an appropriate design.
... View more
08-29-2019
04:30 PM
|
1
|
2
|
2320
|
|
POST
|
You are correct, you can have both web adaptors on the same server but they need to have unique names. The most common web adaptor name tends to be 'arcgis' as per the online help. When two web adaptors are on the same web server then it tends to be 'portal' and 'server' to easily differentiate. You could also use the webadaptor name to highlight the solution name or capability component if that suits your goals, e.g. 'govmap' for public facing local govt maps. That way, when users connect to it, they type a URL which makes sense, e.g. the web adaptor for the image server is called imagery. I would suggest webgis could be improved as webgis tends to be a catch-all term for a web enabled GIS and not just an ArcGIS Server.
... View more
08-27-2019
09:28 PM
|
3
|
0
|
2614
|
|
POST
|
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
08-27-2019
07:21 PM
|
1
|
4
|
2320
|
|
POST
|
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
08-22-2019
06:53 PM
|
0
|
7
|
2320
|
|
POST
|
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
08-15-2019
06:44 PM
|
3
|
1
|
8835
|
|
POST
|
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
08-11-2019
04:49 PM
|
0
|
1
|
2343
|
|
POST
|
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
08-07-2019
04:31 PM
|
0
|
3
|
2343
|
|
POST
|
Most organisations would handle this with an appropriate software management system, e.g. SCCM. It is then a decision as to whether you push out updates, have a beta/early adopters group for the latest release, keep 2 versions live in SCCM etc. This is a question that should be handled & answered by your IT team and not necessarily the GIS team (assuming they are separate).
... View more
08-06-2019
05:56 PM
|
2
|
0
|
1671
|
|
POST
|
G'day everyone, We are attempting to design & confirm a configuration of ArcGIS Enterprise (single machine deployment) that can be used to provide core services (basemaps, geometry service, geocoding etc) in an active-passive configuration. The current design is two single-machine deployments of ArcGIS Enterprise behind a third party network load balancer. Installed components: PFA 10.7.0 AGS 10.7.0 Web adaptor (portal, server) Data Store 10.7.0 (relational) Citrix netscaler load balancer which presents a virtual IP with the active-passive VM's sitting in that pool Relevant configurations: Datastore is registered to AGS via fully qualified domain name (e.g. vm1.domain.com:6443). ArcGIS Server is federated to Portal via the NLB services url (e.g. NLB.domain.com) and the FQDN admin url (e.g. VM1.domain.com:6443). Portal has IWA web tier authentication. Portal webcontexturl set to https://nlb.domain.com/portal. Both virtual machines in the active-passive configuration are identical and from a user/client perspective, the above configuration provides a seemless SSO experience through the NLB to both VM's. Using the webgisdr workflow to migrate changes from active to passive, we encountered an issue on importing the webgisdr site. Failed to get SHARED_LOCATION property in "webgisdr file". Malformed \uxxxx encoding. Any ideas? The only discrepancy I can see from the documented workflow here is that we have not altered the hosts file. Our justification for using this workflow is to migrate ad-hoc changes to our core services offering, upgrade underlying operating systems and reduce 'in place' ArcGIS Enterprise upgrades. Perhaps there is an alternative? Cheers, Angus
... View more
08-05-2019
05:12 PM
|
1
|
6
|
2642
|
|
POST
|
I'd look at your network log (browser developer tools) to see if anything is blocked, failing or erroring out.
... View more
06-05-2019
09:04 PM
|
1
|
0
|
1023
|
|
POST
|
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
05-28-2019
07:46 PM
|
0
|
0
|
4989
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 09-07-2023 09:45 PM | |
| 1 | 02-18-2025 07:21 PM | |
| 1 | 03-17-2025 05:07 PM | |
| 4 | 12-04-2024 05:46 PM | |
| 1 | 09-19-2024 04:41 PM |
| Online Status |
Offline
|
| Date Last Visited |
10-09-2025
03:01 PM
|