Latest Contributions by RandallWilliams

This patch should be applied to all instances of ArcGIS Server, regardless of role. ... View more

The patch addresses a critical vulnerability in ArcGIS Server causing improper access control validation when specially crafted requests are sent to the server. This results in secured services and their data to be exposed to users when they should not otherwise have access. ... View more

This issue is addressed in ArGIS Enterprise 10.6.  See 'Disable External Content' Configure a disconnected deployment—Portal for ArcGIS (10.6) | ArcGIS Enterprise  ... View more

I'll take a different tack. When working with Desktop against an enterprise geodatabase, the communication is quite chatty. In addition to the suggestions above, I'd also look a this from a bandwidth perspective.  Here's a quick test: Do users in your remote office have trouble performing this same workflow when connected to this database? If not, then the issue is likely related to the network.  In this case, can you create a child replica from the parent, work locally from the replica, then when you're done reconcile and post to the parent? ... View more

Personally, instead of upping the heap space I'd try to optimize the query. 64 megs is a huge response. ... View more

They should be in the setups directory specified in the config files. node['arcgis']['repository']['setups']  = Path to folder with ArcGIS software setups. Default path is  %USERPROFILE%\Documents  on Windows and  ~/arcgis  on Linux. node['arcgis']['repository']['archives']  = Path to folder with ArcGIS software setup archives. Default path is  %USERPROFILE%\Software\Esri  on Windows and  ~/software/esri  on Linux. node['arcgis']['repository']['patches']  = Path to folder with hot fixes and patches for ArcGIS Enterprise software. The default path on Windows is  %USERPROFILE%\Software\Esri\Patches , on Linux is  ~/software/esri/patches . ... View more

Are the other setup files in the same directory as setup.exe? Like, there should be a folder with resources called used by the setup.exe, I think called 'setupFiles'. ... View more

Since I'm thinking about it, and while it's a little informal (I wrote this as a blog for an internal audience), here's some detail on CORS headers specifically that I like to send to folks to help provide context:   CORS and ArcGIS Enterprise   I frequently have the opportunity to review and comment on automated security scans organizations perform against their ArcGIS Enterprise instances. A point of confusion I see is regarding 'Insecure CORS Configuration', which some tools flag as a 'HIGH' priority finding.   In general, context is key when examining security related findings, and a 'finding' is relative to the intent of the application.    Background:   CORS (Cross Origin Resource Sharing) is used in *JavaScript* applications when making POST requests to Feature of GP Services on a different server.  CORS is not the only way to make cross domain requests. If a web application is just used for viewing a map service, CORS isn't used.   In context, CORS requests are used when editing feature services or submitting a job to a GP Service. CORS is enforced either at the client tier or via the web browser.   By Cross-Origin, what is meant is that if a web service and a web application are hosted on the same machine, no Origin Crossing happens.   If a web service is hosted on machine A and a JavaScript web application that consumes a service is on machine B (Crossing Origins), and clients interact with a Feature Service/GP Service via Post requests, machine B's FQDN must be configured in machine A's 'Allowed Origins'.   Restricting Cross-Domain requests does not restrict overall access to web services (that's what securing the service does) - restricting CORS headers is a layer of protection in a defense-in-depth strategy.   By default ArcGIS Server and Portal for ArcGIS sets the Access-Control-Allow-Origin header to '*' (allowing all origins), because by default ArcGIS has no way of knowing from which domain web services will be consumed prior to installation.   This default configuration is what the automated tool flags.   Detail:   In many use cases (let's use Facebook as an example), there will be only one application consuming web services - Facebook.com. In this case, it makes sense to limit allowed origins to one domain - Facebook.com. However, if an Esri customer wants to configure Allowed Origins, the admin must know from where a given web app will be hosted. In many cases, this will be easy. Other times, it may not be possible to know from which domain an app that consumes services may be hosted. This all depends on the intent of the web service.   With ArcGIS Server, domains must be explicitly specified in a comma separated list. Wildcards are not supported. Best form is to use the FQDN format, like https://host.domain.com.   Starting at 10.6, we introduced the ability to set CORS origins in Portal for ArcGIS via the Portal Home Application. At previous versions, allowed origins can be set in the Portal Sharing API.   Allowed CORS origins can also be defined at the web tier. See: https://enable-cors.org – be careful though, if the same allowed origin is defined twice, the app may decline to consume the web service.   In Portal's case, CORS allowed origins applies to Portal items or resources instead of GIS Services. Wildcards are supported Portal-side.   TL;DR:   Restricting Cross-Domain requests does not restrict overall access to web services (that's what securing the service does) - restricting CORS headers is a layer of protection in a defense in depth strategy that restricts how JS apps interact with web services depending on the origin of the request.   Proper context and framing is required to verify the severity of a given finding discovered by an automated scanner. ... View more

Sometimes it doesn't make sense to set these headers. For instance, you won't see CORS headers on ArcGIS Online basemap servers because there's no way to proactively know from where an application that consumes our services may be hosted - plus, those are just images, typically retrieved via a GET instead of a POST, and users won't be editing those. ArcGIS Online Org admins do have the ability to define allowed origins for their hosted services. By default Esri doesn't set these - again, we don't know who you'll allow to consume services you publish ahead of time. Configure security settings—ArcGIS Online Help | ArcGIS  Context is key. A heavy handed approach by IT staff that lacks context won't work well.  ... View more

Where are your apps hosted? These are all set at the web server tier. Implementing these depends on the web server. HTTP Public Key Pinning (HPKP) Header  I've personally never had anyone ask about HPKP. This feature helps if a Certificate Authority were somehow compromised, an attacker could potentially present those certs to users via an intercepting proxy, and a user wouldn't get a warning in the browser.  HTTP Strict Transport Security (HSTS) Header I implement this header on my servers. It'll be supported OOTB in a near future version of ArcGIS Server. If a site has HSTS enabled, after the first visit to the site, all subsequent visits will be forced over HTTPS. There's also an option for HSTS preloading that will force even the first visit to a site to be over HTTPS, but the browser has to know ahead of time that the site is HSTS enabled and advertises preload. X-Frame-Options Header This header specifies whether a website can be rendered in a frame. Frames can be used to steal input into a site. Setting this header value to SAMEORIGIN means that the page rendered in a frame or other object comes from the same origin/server as the site in a frame. Other options are 'ALLOW' and 'DENY'. This header should always be set when there's a login form. Depending on the data you're collecting through a form, you may want to set this on other locations. We purposefully don't set this on the ArcGIS Online map viewer, since it's meant to be framed.  X Permitted Cross Domain Policies Header  There's a couple ways to implement this. These days, this is typically 'Access-Control-Allow-Origin', or CORS. This specifies from which hosts JS apps can submit POST requests. This has value for feature access edits or apps that consume GP services.  Content-Security-Policy (CSP) Header  Specifies from where executable content can be loaded from. Helps prevent Cross Site Scripting (XSS). X-Content-Type-Options Header (AKA NOSNIFF) This prevents MIME type spoofing. We're working on supporting it - this requires significant changes on our end. If you set this at the web tier you'll likely break your apps because they're all expecting a specific mime type.  Referrer-Policy HTTP header This one's pretty new. It prevents referrer spoofing. Auth headers often depend on the referrer field. Some providers only allow content to be loaded on specific websites. This header prevents that. Referer spoofing - Wikipedia  ... View more

I think I know what happened. There's 2 installers in play: 1. The screen you're seeing looks like the self-extracting executable (like a zip file that contains the setup files) is trying to lay the install files down in your documents folder. 2. Once that happens, there's a setup.exe that can be called. My guess is that the script doesn't know what to do with the self extracting installer, which is why it's waiting for input (?) ... View more

Hi Paul, I'm unsure I understand your question. Are you connecting to Portal via ArcGIS Desktop? Is this a new issue - did it happen before? Are you using a CA issued certificate? Has the certificate expired, or was it issued against a hostname that differs from the FQDN you're requesting? Do you see similar errors in your browser when you browse to the Portal? While it's only speculation, the only thing I can think of client side that may have changed would be if you'd previously trusted the certificate you're using, then removed that cert from your local store. You'd know if you did that though. ... View more

You can enable the WMS capability with ArcGIS Server. The challenge you'll find is that there's little support among OGC clients for Esri's Token Security model - they typically expect basic or digest auth.  WMS services—Documentation | ArcGIS Enterprise  How will your clients be consuming the WMS you're intending to publish? Will they be writing their own apps? While I am an Esri employee and promote Esri software, there are other options like GeoServer or Open Layers from which OGC layers can be served. I've used GeoServer a good bit, and it accepts shape files as source data. You won't be able to host OGC layers in a desktop app like ArcGIS Desktop or Pro. ... View more

Yeah, I'd run the post installs. It sounds to me like the ArcSOC account password may have changed due to group policy or something. I don't remember the message, but this may be related to licensing on the SOC also. That used to be step 1 when troubleshooting ArcGIS 10.0, but it's been a long time since I've troubleshot 10.0 and below. ... View more

Check the keycodes file for expired licenses.  ... View more