Latest Contributions by JeffSmith

I wanted to follow-up on this based on some recent findings and because of the bug that was logged related to this issue (BUG-000164666).  This issue is caused by how Windows handles network address resolution when IPv6 is disabled on a network adaptor.  Information on this is outlined in this Windows Server KB article. In short, when you disable IPv6 on a network adaptor, Windows still resolves the internal hostname of the server to the IPv6 localhost address (::1).  This is the source of the issue.  For security reasons, the publishing tool blocks requests to localhost and returns the 999999999 error in these scenarios.  There are 2 ways to address this: As mentioned and confirmed by many, you can enable IPv6. If enabling IPv6 is not an option or not desired, you can add the "DisabledComponents" registry value as outlined in the Windows Server help doc and set the value to "0x20" (technically "0xFF" works as well but is not recommended by Microsoft).  Once the server is restarted, Windows will link the internal hostname of the server to the regular IPv4 address and the publishing process will succeed. ... View more

Hi.  Just wondering if the machine name where your Enterprise is installed happens to be mapped to the localhost IP address (127.0.0.1).  There was a security enhancement added recently that limits some communication directly to localhost and I'm wondering if that may be involved here. ... View more

Hi Cody, Two thoughts here - first, I assume you've already done but just to confirm, you've defined the "WebContextURL" parameter in the Portaladmin system properties to match your external domain name and context, correct?  Second depends on the specific reverse proxy you are using, but ArcGIS Enterprise relies on the "X-Forwarded-Host" header be included when proxying requests.  Some RPs like Apache httpd include this automatically.  Others like Nginx need it to be specifically set. ... View more

Hi Stephen, You mentioned that you have the dotnet-sdk package installed, but do you have the .NET 6 Windows hosting bundle installed (part of the .NET core runtime)?  The installer should notify you if you didn't have it installed but it is worth double-checking. ... View more

For those requests where you are seeing "net::ERR_INCOMPLETE_CHUNKED_ENCODING", can you access any of those urls directly in the browser?  I'm wondering if the load balancer might be adjusting or removing the "Transfer-Encoding" response header for some reason.  That would make it freeze like you are seeing.  Can you access the sign-in page through the web adaptor url directly (bypassing the load balancer)? ... View more

@NicolasGIS I agree with you that this behavior shouldn't happen when trying to add a service that is not secured to either the new Map Viewer or to the Content page. The checkurl request should only be made if the service is secured. To @Scott_Tansley's point, yes, from a security hardening perspective, it is good that more organizations are using the "allowedProxyHosts" to limit what hostnames the portal can make proxy requests to.  As you observed, it is working as expected where the checkurl requests are blocked if the hostname is not in allowedProxyHosts. That being said, when trying to add an unsecured map/feature service (with CORS enabled) to the new Map Viewer, no proxy requests should be needed and it shouldn't get stuck in a loop like that.  If you haven't already, could you please contact Technical Support and get a bug logged? ... View more

I wanted to follow-up to my solution for this issue to clarify a few things.  The way the bug was logged makes it sound like Portal logins are blocked for anyone using the IIS web adaptor.  That is not the case.  While the underlying issue with the unencoded curly brackets exists for anyone with the IIS web adaptor in 11.1, the OAuth login issue will only be encountered for organizations that use a front-end load balancer or reverse proxy that does not accept the curly brackets in the query parameters.  Logins directly through the IIS web adaptor will work fine since IIS accepts unencoded curly brackets. Similarly, as @NicolasGIS pointed out, if the OAuth login redirects to a 3rd-party application running on a web server that blocks the curly brackets, the login issue will be observed there as well. ... View more

@DavidColey Yes, I agree.  Switching to a Java web adaptor even temporarily might be difficult for some organizations.  I'm hoping we can get this fixed and patched soon.  Keep in mind this issue will only impact organizations that use a front-end load balancer or reverse proxy that does not accept the curly braces in the query parameters.  By default IIS will allow unencoded curly braces included in the query parameters so I don't think most Windows shops will encounter this. ... View more

Ok.  That sounds fine.  I wonder if it is a permission issue of some sort.  I would double-check to make sure the account running the Server service has full control to the <ArcGIS root>\Server\framework folder.  If that still doesn't help, I would recommend contacting technical support to have someone review your system a little more closely. ... View more

Hi Felipe, When you make any changes to the Server security configuration, Server should restart automatically.  Just to be absolutely certain, you might try restarting the Server service.  Limiting it to TLSv1.2 is fine.  Was the 10.9.1 system upgraded from an earlier release?  I ask because 10.9.1 only enables TLSv1.2 and TLSv1.3 by default so I was wondering if TLSv1.1 had been enabled previously from an older release.  Also, are you using OpenSSL to validate what TLS protocols are enabled? ... View more