Latest Contributions by CraigRussell

A few questions: Where you have blacked something out in your screenshot, is that your portal URL or server name or something else? Are you using SAML for authentication? Are you using a licensing portal (either AGOL or your ArcGIS Enterprise)? ... View more

...we are currently transitioning away from said environ however and I understand from your post that it's better to not use the fweb adaptor adress for the admin url when fedearing for security purposes It shouldn't use the same web adaptor as the one being used for end user access.  You can have a separate web adaptor for admin traffic with elevated security in some circumstances, but for what you're proposing, the 6443 direct one is probably the way to go. They are installed in the dmz server with a public certificate domain, so "public.domain.se" -> 6443/7443 -Enterprise base install machine via the web adaptors. Theres a firewall behind and in front of this DMZ machine so nothing is exposed publicly yet but it should be theoretically prepared, as I parse your reply. Can this be considered realistic for a small-scale start? Should be fine, provided that your IT security team has no qualms about using third party components like the web adaptors in your DMZ, this sort of thing comes up sometimes and ultimately you have to work within your organizations IT principles.  What's important to note is that if for some reason you end up putting a gateway/reverse proxy between the internet and your web adaptors, the public URLs/DNS entries must be the same as what you've used for the web adaptor URLs to avoid having to unfederate/refederate. ... View more

Good point - the doco suggests taking a webgisdr backup, but I'd primarily rely on a server backup/snapshot because the process to fall back using webgisdr is especially painful if the software has already been upgraded. To take it one step further, I usually suggest that people stop the ArcGIS Enterprise services before taking snapshots because Windows process IDs are written to portal/server config files.  This should make for a cleaner restoration in the event of an upgrade failure. ... View more

I've tested this on a couple of 2.7.2 installs and this appears to be a bug/regression, suggest raising it with support. I was going to check the release notes to see if there was anything relevant added/changed around this but I can't access https://pro.arcgis.com at the moment, so that's another problem... ... View more

Hi David You are correct in that you'll need to follow one of those HA patterns for external access (specifically the SAML ones given that this is your IDP), even if your deployment isn't actually HA.  Apart from the HA scenarios, I can't recall seeing any comprehensive documentation which covers public/external access. Conceptually you can look at the "load balancers" in the diagrams as being something like a gateway or reverse proxy for a non-HA scenario, it is ultimately serving the same purpose as a true load balancer (like F5 BIG IP).  The ArcGIS web adaptors themselves can also technically act as the reverse proxy, being exposed to the public via the DMZ and obscuring the backend. Some key things which may not be obvious from the diagrams/documentation are: Portal and server need to communicate with each other over ports 7443/6443, and for security/performance purposes this should all happen behind your firewall (if the admin URLs used for federation are the 6443/7443 ones then you shouldn't have an issue here) Admin access to ArcGIS Server needs to be disabled on the server web adaptor You will see that neither of the SAML scenarios has a web adaptor for Portal; this is optional, but it is generally less complicated to have a web adaptor in the mix (especially if you've already set up using one) In your OP, you mentioned this: When attempting to research how one would setup the following, if it's at the minimum case enough to expose the Portal web adaptor url, I've found the high availability setup scenarios You'll need to expose both the Portal and Server web adaptors to the public, otherwise users will be able to browse Portal content without being able to draw anything in maps or access services. Also regarding disabling anonymous access, this means that unauthenticated users won't be able to browse your portal, see featured content etc.  If this is something that you require for the public, then you could use the Sites feature to create a publicly accessible hub-type page for this sort of thing. Hope this helps! Craig ... View more

Hi Joshua Are you using HTTPS for your ArcGIS Enterprise implementation?  If so, do you get any certificate errors when you access Portal Administrator in your web browser, either via web adaptor (e.g. https://server.domain.com/portal/portaladmin) or direct access via port 7443 (e.g. https://server.domain.com:7443/arcgis/portaladmin)? ... View more

One thing to add to the documentation in that link is that while it says that you don't have to uninstall any of the components to do an upgrade, you do have to uninstall the web adaptors prior to installing the new version.  This is only covered when you go into the web adaptor installation instructions. ... View more

Yeah, I think that using your DMZ IIS to point to two internal web adaptors is the only way around this without unfederating or introducing an additional component like Azure App Gateway.  Have a go at this and let me know if it resolves the issue. ... View more

Hi Anneka Is the number and date format set to Great Britain in your organisation settings, as well as for each user? Organization > Settings > General Organization > Members > View Profile > Settings: Cheers Craig ... View more

It is possible to have a name other than /arcgis and works; we have environments where use an F5, an Apache or an IBM WAS where the paths are different (/portal & /server) and use a reverse proxy, we don't always use the /arcgis; since 10.8.1 in Azure with the cloud builder contexts can be other than /arcgis. The key is in the configuration and being able to rewrite the output / input. It might be possible, and it might work, but it doesn't mean that it is documented and/or supported.  And CloudBuilder isn't the exact same scenario as a standard reverse proxy setup because its doing all of the config for you.  This is from Configure a reverse proxy server with ArcGIS Server—ArcGIS Server | Documentation for ArcGIS Enterprise:   Its needed keep the environments separated, in other scenarios we could have the Web Adpators in the IIS and put them in the server with Portal, or in some other and make a NAT in the router to be exposed; but in this situation the internal servers can not be exposed in this way, its required use the DMZ. To clarify this option, I mean that you would still use your reverse proxy in the DMZ, and this would point to the internal web adaptors.  Installing the web adaptors on the ArcGIS Enterprise machine would allow you to use the /portal and /server context that you've already used in federation with URL Rewrite and it would then align to the requirements outlined in the ArcGIS Server documentation referenced above.  I can't say for certain that this will work, but on the surface it looks like a better fit without having to worry about unfederating and refederating.   By organization rules, they have chosen not to have third-party applications on this servers in the DMZ, they do it directly with the IIS; this is due to a security breach with a similar application that caused them inconveniences. I suspected it was something like this.  The counterargument that I would provide is that instead of using Web Adaptor which is a well supported mechanism with many real world examples of usage for public-facing deployments, you're being made to use two non-standard IIS modules (URL Rewrite and Application Request Routing) with custom logic which could potentially be less secure.  But I appreciate why these determinations are made and that you're really just trying to make the best of the situation. ... View more

Ok, so referring to the documentation for using a reverse proxy with ArcGIS Server, it states that if you aren't using web adaptor (i.e. you are directly communicating with ArcGIS Server over port 6443) then you need to use /arcgis as your web context to avoid URL redirection issues.  This is somewhat mentioned in the Portal documentation as well, but it doesn't explicitly discuss direct access over port 7443. Technically while you federated using /portal and /server web adaptors, you've uninstalled them - they are no longer part of the deployment.   I think you have three options here: Re-install the web adaptors on your DMZ IIS machine and use them instead of URL Rewrite; or Install the portal and server web adaptors on the ArcGIS Enterprise machine, which should allow you to then use the /portal and /server context in the DMZ reverse proxy rules; or Start over (unfederate Portal and Server), but: Do not install the web adaptors as part of your deployment; and Set up you reverse proxy/URL rewrite rules using the /arcgis context for both Portal and Server before federating Regarding option #1, you mentioned this in a previous post: "...in production they are now using Web Adaptors but for a special situation it is required to be done through IIS." What is the situation which requires you to use IIS without the Web Adaptors?  While I think that you should be able to set up using the second option if you really want to, it is clearly not as well documented as using the Web Adaptors, and supportability might be an issue. One other thing - ensure that your URL Rewrite reverse proxy rule isn't doing SSL offloading.  This is not supported in ArcGIS Enterprise. ... View more

When it comes to Image Server, one of the primary considerations in terms of workload separation is whether or not you're using it for raster analysis.  If you are, then a standalone site is recommended. Given that you @LanceCole have mentioned that you will only be using it for publishing mosaic datasets and won't be leveraging all the Image Server has to offer, you shouldn't have any issues combining it with the GIS Server role. ... View more

Hi Vishnu Architecting the ArcGIS System (esri.com) provides excellent coverage for this topic, including a modern ArcGIS Conceptual Reference Architecture diagram:   ... View more