Latest Contributions by ArchitSrivastava

Thank you, @DanPatterson Yes, I have started keeping a manual copy of the messages for new runs now, especially for the deep learning tools. I also enabled the Write geoprocessing operations to XML log file option for safety, based on this documentation: https://doc.esri.com/en/arcgis-pro/latest/help/analysis/geoprocessing/basics/geoprocessing-history.html#537  Hopefully this helps preserve more information going forward, or at least gives me another place to check if the Messages tab loses details after restarting ArcGIS Pro. ... View more

Hi @GlenterpriseUK, Thank you for the suggestion. I first tried running the Buffer tool, but since it does not generate much detailed messaging, it was not the best comparison for this issue. I then tested another non-deep-learning geoprocessing tool, Spatial Autocorrelation (Global Moran’s I), because it produces a more detailed Messages output. After restarting ArcGIS Pro, the Messages tab for that tool still retained the results, including the Moran’s I summary, z-score, p-value, and output HTML report path. Screenshot Before Restart Screenshot After Restart From this quick test, it looks like the issue may not be happening with every geoprocessing tool. So far, I have only noticed it with the deep learning tools I mentioned earlier, but I have not tested every tool category yet. ... View more

@JoshuaBixby  Completely reasonable point. I’m not saying the geodatabase type by itself is the cause. I’ve just noticed in a few environments that services backed by a centralized SDE tended to look more consistent across nodes, while file-based data deployments sometimes showed more variation. Either way, agreed it’s worth validating with a couple targeted tests. On your question about the full REST call: yes, the REST call I meant is the basic layer resource endpoint: https://<cname>/arcgis/rest/services/General/Data/MapServer/86?f=json&token=<token>  For troubleshooting, it also helps to hit each node directly and compare headers: https://<machine1>:6443/arcgis/rest/services/General/Data/MapServer/86?f=json&token=<token>  https://<machine2>:6443/arcgis/rest/services/General/Data/MapServer/86?f=json&token=<token>  Also, just to be clear: keeping the token stable during testing is simply to avoid changing the URL between requests (general HTTP caching behavior). I couldn’t find specific Esri documentation describing how ArcGIS Server generates ETags or whether the token is included as an input. ... View more

@NicolasGIS  Thanks for the added screenshots, they help a lot. What you’re seeing is expected in a multi-machine ArcGIS Server site, especially when you access it through ArcGIS Web Adaptor, since Web Adaptor distributes requests round-robin across the machines. So the same URL can hit different nodes on refresh. https://enterprise.arcgis.com/en/web-adaptor/latest/install/iis/multiple-machine-deployment-with-arcgis-web-adaptor.htm  ETag + Cache-Control + client-side caching all work together: the browser decides whether it can reuse a cached response based on Cache-Control: max-age, and once that expires it revalidates using ETag (If-None-Match). If ETags differ across machines, you can see mixed 200 and 304 results even for identical responses. https://enterprise.arcgis.com/en/server/latest/publish-services/windows/improve-map-service-display-performance.htm  On cacheControlMaxAge: Esri documents that this value is returned as max-age by the Export operation and the Tile resource. That matches your screenshots where tile/export-style requests honor max-age, while the layer metadata endpoint (.../MapServer/86?f=json) can still return "max-age=0". https://developers.arcgis.com/rest/enterprise-administration/server/editservice/  https://enterprise.arcgis.com/en/server/latest/publish-services/linux/setup-caches-for-client-consumption.htm  Your point about SDE vs file geodatabase is valid. In real deployments, services backed by SDE often behave more consistently across nodes (centralized backend), while file geodatabases can show more node-to-node differences depending on how the data is deployed (replicated per machine vs shared storage), which can show up as different ETags. Additionally, I agree it’s worth logging an Idea. Multi-machine behavior being more transparent client-side is a reasonable expectation, and even if it’s “by design,” it’s still a good enhancement request. https://community.esri.com/t5/arcgis-ideas/ct-p/arcgis-ideas  ... View more

Hello @JoshuaBixby , This understanding comes primarily from hands-on experience managing multiple ArcGIS Enterprise environments over time. I’ve seen this behavior across several multi-machine ArcGIS Server sites, configured with Web Adaptors and load balancers, using different browsers and client applications. It’s not based on a single observation, but repeated testing while troubleshooting client-side caching and REST performance. That said, this behavior is not driven by ArcGIS Server alone. It’s the interaction between ArcGIS Server headers, the Web Adaptor’s request routing, and browser caching behavior that produces what you see. The cacheControlMaxAge property works in combination with how the browser honors caching and validation headers. If someone wants to reproduce and validate this, two simple test scenarios help isolate the behavior (assuming a Web Adaptor–based site): Test scenario 1: Browser-side caching behavior (isolate browser caching and ETag handling.) Disable browser caching completely (for example, using Chrome DevTools). Reference (Follow the one with 2120 upvotes): https://stackoverflow.com/questions/5690269/disabling-chrome-cache-for-website-development  Open a REST endpoint such as a layer or export request. Send the same request multiple times. Observe that responses consistently return 200, regardless of machine routing. This confirms the browser cache is a contributing factor. Test scenario 2: ArcGIS Server caching behavior (observe the effect of ArcGIS Server cache headers.) Disable client-side caching for the service by setting cacheControlMaxAge to 0. Reference (official Esri documentation or you can control this from Service confirguration in ArcGIS Server Manager): https://pro.arcgis.com/en/pro-app/3.5/help/sharing/overview/configure-web-tile-layer.htm#:~:text=Optionally%2C%20check%20the,10.5%20or%20earlier.  Make sure browser caching is enabled. Send repeated REST requests through the Web Adaptor. Observe that caching behavior changes and ETag validation is no longer leveraged in the same way. In a Web Adaptor setup, requests are distributed in a round-robin manner by design. When caching is enabled, hitting the same machine with a valid ETag may return 304, while hitting another machine may return 200. This is expected given machine-specific ETag generation and client-side cache validation. Different environments, browsers, and request patterns can show slightly different results, which may explain why behavior appears inconsistent across sites. Keep in mind that changing these caching properties can have a direct impact on service performance. Disabling or reducing client-side caching may cause the service to fetch data or tiles on every request instead of reusing cached responses, which can increase load on ArcGIS Server and lead to slower response times. ... View more

Hello @NicolasGIS, Yes, as per my understanding, this is expected behavior in a multi-machine ArcGIS Server site. How ArcGIS Server uses ETags ArcGIS Server generates ETag headers per machine. Even when the REST response payload is identical, different machines return different ETags. In a load-balanced setup, this leads to alternating 200 and 304 responses. When accessing services through the Web Adaptor, this is also seems to be by design. The Web Adaptor distributes requests in a round-robin manner across ArcGIS Server machines. If a request is routed to the same machine where the cached response is still valid and the ETag has not expired, the server returns 304 Not Modified. If it is routed to a different machine, the ETag does not match and a fresh 200 response is returned. When a request is repeated and the maximum age of the cache has not expired, the browser uses the cached response without sending the request to the server. If the maximum age has expired, the browser must send the request to the server and set an IF-NONE-MATCH header with an associated ETag value corresponding to the response in its cache. ArcGIS Server evaluates the request and uses the ETag value to determine if the response has changed. If the response from the server is different than the copy on the browser, the server sends a new response to the browser. If the response is identical to the copy on the browser, the server alerts the browser to continue to use the response in its cache. (Quoted from Document)  How to influence caching behavior Rather than relying on ETags, Esri recommends controlling client-side caching using the cacheControlMaxAge property. This defines how long (in seconds) a response can be cached before revalidation, providing predictable behavior in load-balanced environments. It’s best to test different cacheControlMaxAge values to determine what works best for your usage patterns. For more details, see the official ArcGIS Enterprise documentation on setting up caches for client consumption:  https://enterprise.arcgis.com/en/server/latest/publish-services/linux/setup-caches-for-client-consumption.htm#ESRI_SECTION1_C8C2AA1672F34194817DD3BC793F52F5:~:text=a%20map%20service.-,Enable%20clients%20to%20cache%20locally,-When%20displaying%20cached  cacheControlMaxAge property details : https://enterprise.arcgis.com/en/server/latest/publish-services/linux/setup-caches-for-client-consumption.htm#ESRI_SECTION1_C8C2AA1672F34194817DD3BC793F52F5:~:text=Define%20the-,cacheControlMaxAge%20property,-When%20clients%20send  Hope it helps! ... View more

Hello @CodyPatterson, As you mentioned, the environment uses "standard "arcgis" service account", there should not be a lot of impact after the admin’s personal domain account is disabled. Portal, Server, and Data Store rely on the service account, not on the user account. However, it would be great to run a  couple of checks though (as I have encountered such scenario before): Check the Authentication Method If Portal uses IWA/Active DirectoryIf admin's domain account exists as a Portal login identity, Verify: The admin's user is not the only Portal Administrator Make sure another AD user or AD group already has admin privileges.                  If his account gets disabled and and that is the only admin, the environment would be locked b. If Portal uses built-in accounts Then all good, nothing to worry 2. Verify all core Windows Service : On every machine (Portal, Server, Data Store etc.) confirm that services run under "arcgis", not under personal domain account (you mentioned it's arcgis but worth checking once) 3. Check Portal item Ownership : If the domain account ever logged Portal with his domain account and created: Hosted Service, maps or apps, Groups, Database Connections (These would get harder to manage after the domain account is disabled) 4. Check permission on Shared Directories : Check that the "arcgis" service account, not his domain account, has permissions to: ArcGIS Server config-store, Server directories, Portal content directory, Any shared certificate folders, Shared file-based data sources. If his domain account has any unique permissions, replace them with the "arcgis" account or and AD group and test things once. 5. Scheduled Tasks, Scripts, and Automation (these are tricky ones to find as well) : If the AD user created, "Windows task Scheduler jobs, Python Scripts, batch jobs and Backups running under his user. Change the run-as to "arcgis" or any other AD account. 6. Check Database Connections: Check registered database connections, make sure none are registered with his AD account. Additionally, as @DEWright_CA , you can always reach out to ESRI support in case of any issues post the admin's AD account is disabled, they are great and guiding you through those kinds of events if you need. Hope it helps! ... View more

Hello @NarayanHamde , To better understand what’s happening, could you clarify a couple of things: What version of ArcGIS Enterprise are you using? How large are the multipatch layers or the SLPKs you’re working with (in GB)? When you say some layers fail with waittimeout, does this show up in the ArcGIS Server logs at the SEVERE or WARNING level? It would be great, if can share the below details as well: Server Logs – Set logs to DEBUG temporarily and review what happens at the moment publishing fails. This can confirm if it’s a timeout, memory, or cache issue.(Be sure to switch back to SEVERE or WARNING afterward, since keeping logs at DEBUG can quickly consume storage.) Machine Resources – Large 3D publishing jobs can require a lot of CPU/RAM. Do you know how many cores and memory your ArcGIS Server site has available? Sharing these details will really help in narrowing down the root cause of the issue. ... View more

Hello @vaishalikulkarni00 , I wanted to provide a quick update. I have not been able to identify any viable workarounds for this issue so far. However, I’m continuing to explore possible solutions. I’ll keep you informed of any progress. ... View more

@vaishalikulkarni00 , It does seem to be a different behavior than expected. However, I think that the configuration being on the Admin page is correct and the documentation for 11.1 does say the same, kindly find the details below: Create a geoprocessing service webhook: https://enterprise.arcgis.com/en/portal/11.1/administer/windows/create-webhooks.htm#ESRI_SECTION1_A94ED6E140A4426A8EC72C9A03786C5F  Create a feature service webhook: https://enterprise.arcgis.com/en/portal/11.1/administer/windows/create-webhooks.htm#ESRI_SECTION1_A3A3B5AE99F446C7B48ABE051E79F0C6  Where as the documentation for 11.4 suggests different workflow: Configure service webhooks: https://enterprise.arcgis.com/en/portal/latest/administer/windows/create-webhooks.htm#ESRI_SECTION1_A47832EBBC414E7C8250FFB95CCF000E  My guess is that  with new releases the behavior has been made user friendly as expected.  Additionally, I think we should not be looking for "Create Webhook" option on the REST Admin API.  I would try to look for a way which can allow you to create a Webhook with the custom role configuration and keep you posted if I find anything. Furthermore, I think reaching out to ESRI support at this point would also be a good idea. Hope it helps! ... View more

Hello @vaishalikulkarni00 , As the Admin is able to create Webhook, I would also assume that the SD (Service Definition) is OK. However, let's try to cover all our bases and try the following: Try by updating some other capability as "Sync" would require other checks on the data configuration end, can you try disabling "editing" capability or pick any other example from the below document: https://developers.arcgis.com/rest/services-reference/enterprise/update-definition-feature-service/   Try publishing a "Hosted Feature Service" with a very small data and try the Webhook creation workflow on that. Check the "Sharing" setting of the service (Shouldn't matter as you are the owner but still a check wouldn't do harm) Check how the "Custom Role" was created as I use the default publisher role as base and then just add "webhooks" capability (as shown in the video) maybe some required capability is missing from the role. In the meantime, I will try to search more on this and share details. Hope it helps! ... View more

Hello @vaishalikulkarni00, I ran some tests on my side by configuring a similar role on version 11.1 and 11.3 (with and without Azure AD config) both and followed the workflow mentioned in the document below: Create (Webhooks) | ArcGIS REST APIs | ArcGIS Developers Key point being update the URL to Rest Admin API, I am sharing a sample below: REST API URL: https://sampleserver6.arcgisonline.com/arcgis/rest/services/CommercialDamageAssessment/FeatureServer  ArcGIS REST Admin URL (added the bold section) https://sampleserver6.arcgisonline.com/arcgis/rest/admin/services/CommercialDamageAssessment/FeatureServer  The above URL should allow you to reach to "Update Definition" option and then follow the documentation mentioned above. Furthermore, I also noticed the following: If you are owner of the "Feature Layer" (Hosted and Referenced both): No redirect occurs If the item is owned by another user (Hosted and Referenced both): Redirect occurs and tries to generate token Hence, I think that the redirect has nothing to do with the "Azure AD" configuration. It is to validate the access of the item (assumption). Furthermore, can you try taking the ownership of the item or try doing the workflow on an item owned by your username? Please let me know how it goes, in the meantime I will try to find any other workaround. Hope it help! ... View more

Hello @vaishalikulkarni00 , I assume that your assigned role is a built-in role, not a custom one, and by default, the Webhooks capability is only available to the Administrator role. Please refer to the documentation below for more details: Full Document: Privileges granted to roles—Portal for ArcGIS | Documentation for ArcGIS Enterprise Webhooks Section (Geoprocessing):  https://enterprise.arcgis.com/en/portal/11.1/administer/windows/privileges-for-roles-orgs.htm#ESRI_SECTION1_C30D73392D964D51A8B606128A8A6E8F:~:text=is%20turned%20off.-,Webhooks,-Geoprocessing  Webhooks Section (Organization webhooks) :  https://enterprise.arcgis.com/en/portal/11.1/administer/windows/privileges-for-roles-orgs.htm#ESRI_SECTION1_C30D73392D964D51A8B606128A8A6E8F:~:text=Organization%20webhooks  Depending on the type of webhook you want to create, I recommend configuring a custom role, as assigning the default Administrator role may not be feasible for the Organization Admin. For Geoprocessing service webhooks: assign the following privileges to the custom role. For Organization webhooks: assign the following privileges to the custom role.   Hope it helps! ... View more