Latest Contributions by DavidHoy

Hi Mark, layer level stats are captured if the client requested at that level rather than at the service level. So, for requests at layer level for a feature enabled map service, the calls are captured in the server logs. The other trap is that, because Hosted Services are not serviced by an ArcSOC.exe, they do not get logged in the ArcGIS Server logs. To get stats for Hosted Services, you need to query the Web Adaptor or Load Balancer/Reverse Proxy logs ... View more

Hi Anthony, it is certainly possible to use other tools that achieve the same outcomes as SLP.  It gathers information from the Server logs either by making repeated calls to the REST endpoints or by directly reading the log files themselves. The magic is in how the raw information is turned into useful statistics. I would say it is not reasonable to ask for the source code for how this is done. You would need to gather log start transaction and end transaction records grouped by transaction-id and do the maths for the duration. Then collate a table/dictionary of all transactions and retrieve the various statistics - time of day, duration, success/error codes, etc then use this dictionary to create useful reports. or, you could write code that calls SLP.exe  to gather the stats and report with your dashboard tool - that's how ArcGIS Monitor does it Good luck in your endeavour ... View more

Yes - this is one of the possible ways to setup the administrative paths. But if setting up an internal Load Balancer is onerous, it is possible to just use the public load balancer addresses via :443 i.e .PrivatePortalURL same as webContextURL and Server Admin URL same as the Server Services URL But, this does mean: - Admin Access must be enabled in the Server Web Adaptor - The Public Load Balancer must be accessible from the Portal and Server VMs - (this isn't always the case when the Public ALB is in a DMZ) ... View more

@SaurabhUpadhyaya wrote: Thanks @DavidHoy. for explanation.  I am using web adapter(ArcGIS) for both servers, and it is linked to load balancer(https://sla.com/arcgis). Now the requirement is to add Portal in same environment to take the portal benefits. As per my understanding load balancer of ArcGIS Server can be federate with Portal. Services URL(https://sla.com/arcgis) will be load balancer url and Administration URL (https://sla.com/arcgis) and user name password will be primary site administrator url @DavidHoy can you please verify my approach if required any changed please suggest    ....reference esri url (https://enterprise.arcgis.com/en/portal/latest/administer/linux/federate-an-arcgis-server-site-with-your-portal.htm) @SaurabhUpadhyaya wrote: Thanks @DavidHoy. for explanation.  I am using web adapter(ArcGIS) for both servers, and it is linked to load balancer(https://sla.com/arcgis). Now the requirement is to add Portal in same environment to take the portal benefits. As per my understanding load balancer of ArcGIS Server can be federate with Portal. Services URL(https://sla.com/arcgis) will be load balancer url and Administration URL (https://sla.com/arcgis) and user name password will be primary site administrator url @DavidHoy can you please verify my approach if required any changed please suggest    ....reference esri url (https://enterprise.arcgis.com/en/portal/latest/administer/linux/federate-an-arcgis-server-site-with-your-portal.htm) Sorry I have been away from my desk for a few days. You diagram is not quite correct:  It is a common misunderstanding that the Server is "behind" the Portal, this is not the case. The endpoint for your Portal and your ArcGIS Server site is the Load Balancer. All calls from the clients go to the Load Balancer and are then distributed as required either to the Portal or the AGS machines. The federation between Portal and Server site also uses the Load Balancer path. You have described this correctly in your text. The Portal communicates with the Server site via the <LB>/arcgis and the Servers communicate with the Portal via the <LB>/portal. (This should happen automatically when you make the federation - this is why the Portal needs to have its webContextURL property set correctly to the LB/portal address before you federate) - you can check in the AGS site's server/admin/security/config page after federation - it should show both a "portalURL" and "privatePortalUrl" with the LB/portal address. Here is an altered diagram. I have added a fileshare because I presume you must have always had this for shared Server Config and System Directories to make your 2 machine ArcGIS Server site work in the past. I also drew in an ArcGIS Data Store - you haven't mentioned this, and it is not 100% required, but to take full advantage of ArcGIS Enterprise, you will need to establish at least a Relational Data Store and register it with your Server Site to allow it to act as a "Hosting Server" to hold system managed data created by Portal Users. ... View more

But…. Before federating - Be sure you have your Portal and Server site configured correctly to use the Load Balancer - with webContextURL set in system properties for each.  Otherwise you may find you get redirects you don’t expect  ... View more

When federating from the Portal’s “Servers” page, you are asked to supply two.URLs : service URL and administrative URL in most cases (as per the blog document) these can be the same. It is the route via the Load Balancer, including the “context”. ... View more

The documentation in this link re load  balancers should have all the info you need. i would be adding your Portal as a target group (backend pool) behind your load balancer - just with a single node in the “portal” pool. This way the load balancer is just acting as a reverse proxy for your portal.  you haven’t said whether you are using web adaptors or what type of load balancer, so hard to be specific.  the advantage of using the same LB for portal and server is that you will have one front end FQDN in the URLs for both the portal and the server site. If using WAs, it is trivial to identify which incoming requests should be directed to the portal backend (https://yourdnsname/portal/*) and which should go to the server (https://yourdnsname/arcgis if your server’s VMs are using WAs called “arcgis”. if not using WAs it is a trickier set of rules to look for in the incoming request (arcgis /home, /arcgis/sharing, /arcgis/portaladmin as a starter set) ... View more

@LaurePillet2  did you ever resolve this? ... View more

Hi Grant i believe you don't need to have the https://    and you certainly don't need the full URI including webadaptorname can you try *.domain.com ?  - that would be a typical entry see What you can do, should do and should NOT do with GPOs: Internet Explorer site to zone assignments - is it valid and why not? (evilgpo.blogspot.com)  for a few tips on what can go in the list of trusted sites. ... View more

and it is the portal web adaptor URL you have added to your list of trusted sites? It needs to be that, even if you are trying to get to the server pages, as that's what federation does - authentication is handled by the way the portal is configured. your symptom that SSO works when you go to IIS by machine name but not when you use the alias seems to be saying that alias is not in the list of "trusted sites". but your local machine name is recognised as being in "local intranet" zone. ... View more

Grant, sorry to ask, but to be clear Did you also check the box in Custom Settings for "Trusted Site"/"Local Intranet" to allow "Automatic logon with current user name and password"? As Chris P pointed out in earlier post in this discussion. This is a CLIENT SIDE setting that you may need to get pushed to all users via a Group Policy setting once you have shown it works for the machine from which you are testing.   ... View more

Hi @EsriEvan  any update on a potential workaround if ARR is used to reverse proxy the AM Server? ... View more

I don't have personal experience with stopping/starting AGW v2 or with the scaling options, so I am interested to hear the results of your testing Si. @ShanonLoughton may have experience or opinion? In another site, we dropped back to simple Load Balancer sharing to Web Adaptors - this allows simple context based routing with a single front end URL and is way cheaper and easier to deploy manually than using AGW. I like Web Adaptors - when I hear people saying they are a bottleneck, I think they are likely blaming the bad performance of underlying services on an innocent party. ... View more

ok - I just did some testing in my sandbox username does not change - just the property called IDPUsername content is still owned by the original username I confirmed by looking in the portal/sharing/rest/community/users/<username> directory where these properties are listed ... View more