Latest Contributions by PF1

Hi Rebecca, We cache our services in a separate ArcGIS Server Site (built only for caching), then move the cache to our test environment where the data people can review and approve the cache.  Once its approved we 'release' it to production. The original cache server was a measly 1 vCPU with 4GB RAM.  Cache build took over 8 hours.  We acquired some new beefy hardware with GPU's attached that are intended for a XenDesktop deployment for ArcGIS Desktop, Imagery software, and ArcGIS Pro.  That project has been moving slower than we like, so we started using a small portion of that hardware for our cache builds... we presented 28 vCPU and 100GB ram on a VM to windows 2008 and the cache build is now around 2.5 hours with 27 instances. ... View more

Hi Yi, We have the same scenario.  We've been building cached services to level 14 (~1:36K) which takes about 32GB of disk storage (processing was 8 hours, but we beefed up the server significantly and got that process down to 2 hours).  Dynamic service at full extent is terrible performance (30-90 seconds).  Since the bounding box is so small at level 15 and below (much less data is returned that needs to be fetched, processed, and rendered) the performance is sub-second on the dynamic requests. An example cached service: https://gis.blm.gov/arcgis/rest/services/lands/BLM_Natl_SMA_Cached_with_PriUnk/MapServer And Dynamic Service: https://gis.blm.gov/arcgis/rest/services/lands/BLM_Natl_SMA_LimitedScale/MapServer Consumed in example application: https://eplanning.blm.gov/epl-front-office/eplanning/lup/lup_register.do You can see in the network traffic that the requests switch from the cached service (level 14) to the dynamic service: Although this has been working pretty well for us, some of our business programs want to be able to enable and disable layers in the cached service.  Unfortunately the have not been able to do that so we have had to build multiple cached services for their use (each service has layers enabled/disabled based on their requirements): Unfortunately this approach requires us to store the cache 3 times (at ~30GB each) and have to re-process the data 3 times each quarter also (~2 hours each now). Cost of doing business... I would be in favor of a service having the ability to cache to a certain scale (level 14) then automatically switch to a dynamic request when it is not cached below that level!  maybe a post to ideas.arcgis.com is in order... Thanks to Dan Huber​ who helps us with this process!  ... View more

OK... re-opening this thread.  The ArcGIS Server v10.3.1 release extended the limit from 11 installations to 21.  Although we hit our 22nd yesterday and tested out the manual install.  Manual install work around is still good, but it would be great to have native support for more than 21!  I submitted an ideas thread about it today for anyone that wants to vote up): http://ideas.arcgis.com/ideaView?id=087E0000000kBh8IAE 🙂 ... View more

Hi Ghali, I had opened a ticket with Esri, but if I recall right... we were using the pre-release version of the software.  The ticket was closed until I could confirm if we had the same issue with the final release, but I had given up and worked out an alternate solution for our issue at hand.  Unfortunately I ended up building my own object to implement some of the same functionality that I needed from the FeatureSet.  I had always intended to get back to this, but ran out of time and the object I built meet the needs for the project I was on at the time.  ... View more

Hi Geoffrey, I think you are trying to use your ArcGIS Online (AGOL) token to authorize your access to your ArcGIS Server (AGS).  I think you need to have your AGS federated with AGOL in order for this to work.  If AGS is not federated with AGOL, then you need to acquire an AGS token and use that for access to web-services hosted with AGS.  This also assumes your AGS 'site' is setup to use ArcGIS Tokens for its authentication tier which is the default settings when deployed.  If you have switched to a 'web-tier' authentication scheme, then you do not require tokens any more but rather use the authentication mechanisms that your web-adaptor deployment supports such as: HTTP Basic HTTP Digest Integrated Windows Authentication (IWA) Using Kerberos or NTLM Take a look at this thread and see if it helps shed some light: Re: Federating an ArcGIS Server site with your portal ... View more

How is your arcgis servers security configured?  Are you federated with your arcgis.com solution?  What is your user and role store?  ... View more

Hello Shafi, I think I understand your questions.  You are running a highly-available ArcGIS Server (AGS) and Portal without the use of a web-adaptor.  This implies you are NOT using web-tier authentication with either product but rather the Esri proprietary token based authentication.  My understanding is that when you federate an AGS solution with a portal solution that the AGS inherits the identity store and authentication/authorization methods of the portal.  This means that you can use 1 identity in portal to authenticate and subsequently be authorized access (via portal groups) to the underlying services available in the ArcGIS Server.  I highly recommend you read the article Accessing REST resources from a federated server article. Bottom Line... since the AGS relies on the portal identities, the client application (enterprise web-app, smart phone app, etc) will need to authenticate against the portal to access the ArcGIS Server services.  The developer will need to acquire a portal token and use the portal token to access AGS services.  Since AGS uses a portal token, I believe that AGS checks the validity of the portal token with the portal to make sure the token is valid.  Because of this, its best that the AGS and Portal live 'close together' (LAN based connection rather than WAN based) for performance reasons.  --- Here is an example with our on-premise deployment.  Our portal is configured with Integrated Windows Authentication (IWA) using the web-adaptor.  We are leveraging our existing Active Directory (AD) identities within our portal.  Assume this to be: https://myportal.domain/portal/home We have a federated ArcGIS Server with this portal.  This ArcGIS Server does not use the web-adaptor and was federated with the portal.  Assume this to be: https://myags.domain:6443/arcgis When I access my ArcGIS Server outside of the portal with the direct url: https://myags.domain:6443/arcgis/rest/services I can see services that are shared with 'Everyone' (public anonymous).  If I want access to a secured resource (a service shared with only a specific group), then I need to authenticate with my portal and pass my portal token.  This assumes I'm in a group that is authorized access to the secured web-service.  Looking at my AGS 'Info' Page: https://myags.domain:6443/arcgis/rest/info?f=json I see the following: {   currentVersion: 10.22,   fullVersion: "10.2.2",   soapUrl: "https://myags.domain:6443/arcgis/services",   secureSoapUrl: null,   owningSystemUrl: "https://myportal.domain/portal",   authInfo:   {   isTokenBasedSecurity: true,   tokenServicesUrl: "https://myportal.domain/portal/sharing/generateToken"   } } That just told me that I need to acquire a token from the tokenServicesUrl (which is the portal) to access secured resources.  Per the documentation (see the 'accessing REST resources...' link above), I need to acquire a token with a 'Webapp URL' being the URL of the ArcGIS Server: https://myags.domain:6443/arcgis/rest I can acquire a token with the methods above, and use the token to access protected resources in my arcgis server. --- I would think a best practice of accessing services outside of the portal would be to do something like: Query the ArcGIS Server 'info' page to identify the authInfo (authentication information).  Use the tokenServicesUrl to acquire a token for the end user.  You will most likely need to prompt for a username/password.  Make sure to set the 'WebApp URL' appropriately.  Use the token generated in step 2 for requests to the ArcGIS server, passing the parameter token with the value being the generated token.  Make sure to protect this token as it represents an identity and if compromised could be used with malicious intent.  Monitor requests with the token.  If the token expires (or is somehow invalidated at some point) either prompt for credentials again and acquire a new token, or securely retain the original credentials and generate a new token.  --- Bonus points (extra credit): If the HTTP Request to the AGS 'info' page fails with an HTTP status code 401 (unauthorized) and there is a www-authenticate header present, then use the www-authenticate header value to determine what sort of 'web-tier' authentication method is supported.  I often times do this as we are striving to go web-tier anywhere available.  Per the doc, this may not be necessary in your scenario: If the server you want to federate uses web-tier authentication, you'll need to disable web-tier authentication (basic or digest) and enable anonymous access on the ArcGIS Web Adaptor configured with your site before federating it with the portal. Although it may sound counterintuitive, this is necessary so your site is free to federate with the portal and read the portal's users and roles. If your ArcGIS Server site is not already using web-tier authentication, no action is required on your part. You can continue with the steps below. But would provide a code-base that would work for services federated with a portal, and services not federated with a portal.  I ended up with the following pseudo-code in for a few 'tools' that I built: Execute HTTP Request to AGS 'info' Page if HTTP Response Status == 401 (unauthorized)     if 'www-authenticate' in HTTP response headers                 #inspection options in order of preference         if 'Negotiate' in www-authenticate header             try                 set kerberos authentication method                 retry request.  If success retain kerberos setting and continue processing             except                 set NTLM authentication method                 retry request.  If success retain NTLM setting and continue processing                 if 'NTLM' in www-authenticate header             set NTLM authentication method (Single-Sign on supported OR prompt credentials?)             retry request.  If success retain NTLM setting and continue processing                 if 'digest' in www-authenticate header             set HTTP Digest authentication method (prompt credentials?)             retry request.  If success retain digest settings and continue                 if 'basic' in www-authenticate header             set http basic authentication method  (prompt credentials?)             try request again                 #how to handle SAML?                 #how to handle PKI?                 #others?  OATH?  OATH2?  Forms based? if authInfo.isTokenBasedSecurity key of the HTTP Response DATA == True         #this could be a portal, or it could be an ArcGIS Server token.  Handle both if different     Execute HTTP Request to the authInfo.tokenServicesUrl  (prompt credentials first)?     Grab token from HTTP Response and use for future requests     continue processing But have yet to work out SAML, PKI, OAUTH, OAUTH2 and other authentication methods since we have not yet implemented those.  Best of luck! ... View more

Hi Roberto, I think it depends on how you setup the ARR configuration.  It appears you are experiencing a URL Re-Direct rather than a URL Re-Write.  We have set it up ARR to do a URL Re-write 2 different ways (depending on requirements): Option 1: Setup a server farm and then establish an inbound rule with a 'URL Re-write' Rule at the root of the server.  Make sure under 'Actions' that Route to Server Farm is selected: Option 2: Do not setup the server farm but instead, create a Reverse Proxy Inbound Rule‌ with an action of 'Re-Write': Good luck!  If you do a URL Re-direct it will look like this and that might be the reason you are getting an HTTP Status Code 302: Kuddos to Dan Huber‌ who helped us establish rules in a few environments (they get a little tricky). ... View more

Thanks Mike Minami‌ for the update.  I've started an ArcGIS Ideas post to see if we can get some headway on this limitation: ArcGIS Idea - ArcGIS Server Web-Tier authentication: Enable editing in ArcGIS Online web maps, Portal web maps, and offl… ... View more

Hi Roberto, For this thread, we do not actually have a reverse proxy in front of our portal.  We instead applied a DNS alias but that broke our server federation.  Following the configuration steps in the 'Configuring a reverse proxy server with your portal' solved our system issues.  We have, however, on other systems deployed a reverse proxy in front of various solutions.  We have used network appliances (such as NetContinuum and Barracuda Networks Web-Application Firewall) but have also used the Microsoft IIS Application Request Routing (ARR) successfully on a few other projects.  ... View more