Latest Contributions by Todd_Metzler

JoshuaBixby wrote: "As an IT service provider, I have had many battles with lazy GIS staff who don't want to take the time to craft a high-performing map, but then somehow expect ArcGIS Enterprise to work miracles and turn it into a high-performance service." Amen to that brother. ... View more

Hello, My environment: ArcGIS Enterprise 10.8.1 hosted on 2 physical Windows servers. Server 1 [Portal, Server (federated, hosting); Server 2 (Server, Data Store (relational)] I have 300+ services. I did "step up" the heap size in registry once when we hit about 200 services. That worked fine. Concurrent with this change was migration of "simple" and/or low use services to shared instance. The shared instance use somewhat reduces the need to modify heap size in registry because the total number of SOC.exe processes is reduced. TIP: Before trying any of these "tuning" techniques, evaluate your computing environment and ensure you are provisioned for current and anticipated system loading. Each of my servers has 192GB of RAM and 2x 24 core processors. These resources allow setting the shared instance parameters pretty high thus reducing the total number of dedicated instance service I have. As far as your future plans with Portal: Suggest view ArcGIS Enterprise as Portal/Server/Data Store not as individual pieces. By implementing Portal and Data Store, we have overcome many performance limitations and/or resource "tuning" requirements inherent with Server only implementation. Hosted feature services really "live" in Portal/Data Store. All Server is doing is creating the service end point. Perhaps an over simplification. Hope it helps. Read between the lines: If you consider the interaction between ArcGIS Web GIS components and ArcGIS Enterprise, the writing on the wall tells me that it the not too distant future, ArcGIS Enterprise will be Portal and Data Store. No more Server. Lastly, if you don't want to bother with the Windows OS "tuning" and you can choose your OS (unfortunately I cannot), host ArcGIS Enterprise in Linux instead of Windows. You'll require less computing resources for the same performance level and, in my experience, it just works without an overabundance of administrative care and feeding. Yes setup is somewhat more involved but again, in my experience, worth the initial investment. ... View more

Good idea. A typical use case is administrative boundaries seen at small scale/large area and imagery at large scale/small area. This functionality is particularly desirable when creating basemaps for use in Field Maps and other mobile Internet disconnected workflows. The blend settings in Map Viewer don't currently allow the desired functionality. ... View more

你好,1,我不知道你的答案specific question. I would like to share some thoughts though on low latency considerations for IT and ArcGIS Enterprise optimization. 1. Any introduced latency to communication between applications and data stores is bad. 2. Encryption and decryption introduces data manipulation and increases latency. 2a. Suggest, instead of encrypting a single communication path from RDBMS to ArcGIS Enterprise you evaluate your entire LAN/WAN information protection and information assurance posture and choose the most limited data manipulation plan that meets your organizational goals without the "overhead" of individual connected resource encryption if you can. Very generally speaking, firewalls, network hardware encryption and software security monitoring and encryption is not a GIS Enterprise's friend. Quite required for overall information protection and assurance absolutely. Impact to overall Enterprise GIS architecture and service performance. Also absolutely. Want to see for yourself? If you have the resources, set up ArcGIS Enterprise in a secure isolated environment without any add on security components and measure the difference in performance compared to that most of us are constrained to use in a production environment. ... View more

Good to know there is another workaround. Not practicable for our enterprise. We have hundreds of services and over 30 publishers. ... View more

Please see same reporting. ... View more

Please see Same reporting ... View more

Same. First reported to us 2021-09-09. 1st stop was AGOL Health Dashboard . All green still green. We've opened our own case with Esri tech support. ... View more

我的环境:ArcGIS企业10.8.1图像放大e server. We use a hybrid approach based on many of the points you've made. Sometimes we have multiple MDS in single FGDB and sometimes a single MDS in single FGDB and sometimes a single FGDB with a single MDS that is build from other MDS as the input source. Like almost everything we do in GIS data management, the end use case dictates how we decide to package those data and create services from it. For example, we categorize our orthoimagery collections in four overarching areas: Regional, Municipal, Conservation, Coastal. We have a single FGDB for each overarching category with multiple MDS based on collection year. For discovery/catalog purposes we have a single FGDB and single MDS including our entire ortho collections. This FGDB MDS has no overviews and is not for visualization, just for discovery of the tile/tiles that cover a spatial or temporal extent. This service is also the input to our tile discovery and download application. The key to make this work: Attribute your MDS with temporal information and enable time in your services. ... View more

Agree. The inability to selectively turn off download in xxxxx.hub.arcgis.com is problematic for our GIS administrators as we spend 10s if not 100s of hours each year responding to our end user reports of failed downloads. We know that some of our large/very large vector services and all of our image services will fail. Even when we clearly state in description/metadata intended use for a service and caution against attempting to download, our end users sometimes don't heed our warning and click on the download icon anyway leading to their disappointment and increasing our workload. Fundamental GUI design please. Keep it simple and functional. UPDATED Additional comments: As an Enterprise GIS data and service provider serving 1000s of users both within and external to our organization, we have fully embraced the transition from discover and download to service consumption workflows. Our user base, however, is much slower to adopt the transition. Especially our public users in the AEC domain. Until more widely accepted, we are constrained to continue to support discovery and download workflows. Please help us to best provide for our customers by giving us the administrative tools we need to be effective. Thank you. ... View more

Thank you for the information. Very good to know. However, Pertaining to ArcGIS Desktop (ArcMap/ArcCatalog/ArcEngine), I learned years ago to keep the ArcGIS client apps isolated from the ArcGIS Enterprise because of the 32/64 bit mixture and the conflicts created by that mixture pertaining to EGDB connections. If Administrators have the computing resources to do so, I'll still advocate for isolation of ArcGIS Enterprise From Client apps Like ArcGIS Desktop including ArcGIS Pro. Just to keep things simple and somewhat predictable. ... View more

已经在先前的repli建筑上的点es, I'll add a few more that pertain to Enterprise versions that support shared instances. My environment: Enterprise 10.8.1 full stack. We also have a mixture of aggregated and single source services like @Brian_Wilson . Our aggregated services are grouped by theme as suggested by @berniejconnors . We use ISO category themes. Computing resource allocation is the driving factor from the performance standpoint as @LongDinh has pointed out. We have upwards of 300+ services and have been able to effectively keep the lights on within our computational resources by leveraging the shared instances capability in Enterprise Server to reduce the total amount of ArcSOC.exe processes. Now, to most effectively take advantage of shared instances, your service publishers should use ArcGIS Pro instead of ArcMap. Reiterating. It's up to you. Consider your available computing resources 1st, your end use cases second and publish away! Todd ... View more

My environment: Enterprise 10.8.1 full stack. 1st: Recommend take-your-web-maps-offline-field-maps.pdf 2nd: Recommend map-viewer-beta-available-in-arcgis-enterprise 3rd: Deploy the Field Maps Web interface to your ArcGIS Enterprise. As you'll see in ref (1), you'll need map viewer (BETA) and Field Maps Web App in your Enterprise to properly prepare and check maps for the Field Maps mobile app. Not sure if you can use Map Viewer BETA in Enterprise 10.7.1. The most important things we've learned so far: 1. Ensure your basemaps are export ready. Search ArcGIS Esri content using the term (for Export) to find basemaps that'll work now or create your own. 2. Ensure the basemap, reference and editable layers in your Field Maps Map are in the same Spatial Reference System (SRS). 3. Ensure the basemap, editable layers and your map are shared exactly the same. 4. Inconsistent behavior in my environment with pre constructed map areas. We deleted all pre constructed areas and let the end user of the Field Maps mobile app create their own. 5. MOST IMPORTANT: make sure your Field Maps mobile app users turn on logging and know how to get those logs to you. Invaluable in troubleshooting and helping Esri tech support help you. ... View more

As Enterprise Portal Administrator, Sign In > Organization > Settings > General > Summary. Change the text to what you want to display. This changes the text ABOVE the screen capture you included. Don't think you can easily change the lower part. ... View more

Hello, Consider implementing ArcGIS Enterprise Sites . Then, after your users hit your web site landing page, Enterprise Portal user store can handle access control. ... View more