|
IDEA
|
Hello, Please accept my apology. I'll clarify my prior submission. If your ArcGIS Enterprise single stack/base config includes a federated/hosting server, then nearly all administrative tasks for services can be performed in Portal UI whether they are hosted feature layer type or not. Hope this helps. Todd
... View more
03-24-2021
12:10 PM
|
0
|
0
|
2187
|
|
IDEA
|
Hello, As ArcGIS Enterprise has evolved, so has the method of UI access for our administrative tasks. In a full single stack configuration, we seldom use Server Manager UI any more. Instead, we do nearly all our service management on the Portal side in the Portal UI or Portal Admin. Suggest checking Esri's ArcGIS Enterprise road map. From our conversations with Esri on this subject, it is my expectation that down the road, not far down the road either, Server as we now know it won't be a sub-component any longer in ArcGIS Enterprise and Portal will extend to be the main core component.
... View more
03-24-2021
10:02 AM
|
0
|
0
|
2202
|
|
POST
|
Presumption: Your Hosting and general ArcGIS servers are participating in the same site? If so, where do you plan to host the config store to allow the servers to maintain synch? Also, where are you storing the Portal content directories? For your proposed environment, the location of the Portal content and server config store are critical failure points that must be as nearly 100% accessible with exceptionally low latency to Portal, Server (hosting) and Server (General) as possible.
... View more
03-23-2021
05:40 AM
|
1
|
0
|
9999
|
|
POST
|
Hello, Echo comments already shared. I'll add that, testing the access and latency to your designed data storage locations, be they file based or RDBMS is critical before finalizing your design. In my experience, the performance claims of 3rd party storage solutions, particularly if there is geographic separation of the Enterprise GIS app stack and the storage (aka many connections in path, sometimes unpredictable latency) are usually too optimistic for Enterprise GIS as our needs differ from the office worker use cases that many of those performance claims are based on. Rule of thumb best practice: Keep your data as close to the application stack using the most direct path as possible.
... View more
03-22-2021
02:51 AM
|
2
|
1
|
10047
|
|
POST
|
Hello, Common if Spatial Reference Systems and/or applied MDS transforms don't match. Check these settings in your source data and MDS. Todd
... View more
03-15-2021
11:25 AM
|
0
|
0
|
4530
|
|
POST
|
Hello, I see "easily" in your subject. The easy button way without scripting or using the REST API to do a global URL change from .com to .gov is use GeoJobe Admin Tools (Pro) for ArcGIS Online and Portal. https://www.esri.com/en-us/arcgis-marketplace/listing/products/4b9205d08a42413085a17ca91b97e3c7 There are other ways too. I'll stop at easy for now. Todd
... View more
03-11-2021
09:34 AM
|
0
|
1
|
1807
|
|
POST
|
Hello, 1st. Go Navy! What's your OS and web server? Have you paid very close attention to the SSL requirements and authentication methods settings on your web server and between the ArcGIS components? Have you opened up all the required ports between the components in your firewall(s)? Have you deployed a CA certificate chain on all the components (web server, Portal, Server, Data Store)? Are you accessing the web interface on the computer that is hosting the application stack? Is your web server also on the same computer and the web adaptor and named the default "/arcgis"? Is your Server web adaptor configured to allow administrative access? Lot's of questions, I know, but it's difficult to provide solution up front without understanding your environment. Todd
... View more
03-11-2021
09:21 AM
|
0
|
1
|
7273
|
|
POST
|
Yes. Register your EGDB (aka sde) database as a Data Store on your federated server.
... View more
03-11-2021
09:01 AM
|
0
|
1
|
2453
|
|
POST
|
Hello, Yes. But... To publish from ArcGIS Desktop (ArcMap), you can only set one portal connection. This is done in desktop ArcGIS Administrator. If you are delivering ArcGIS Desktop to your users as a remote app hosted on a server, like we do, then that change is a global change affecting all users and can only be enacted when no ArcGIS Desktop users are attached. Another issue that will surface, depending on your ArcGIS Enterprise set up, will be lack of access to Esri basemaps if you change. Additionally, although an ArcGIS Desktop (ArcMap) user can define a connection directly to your ArcGIS server and publish that way, there is a greater chance of orphaned content if the publisher or an Enterprise administrator deletes a service from Portal content and not from server manager. The opposite is true if a service is published from ArcGIS Pro and the service is deleted from Server manager. So, I recommend not changing the setting and instruct your users to publish to ArcGIS Enterprise and/or ArcGIS On Line exclusively using ArcGIS Pro. Todd
... View more
03-11-2021
07:48 AM
|
0
|
3
|
2491
|
|
POST
|
Hello, My environment: LM 2020.0 x2. Primary and failover on two 2x WinServer 2012R2. I've both inbound and outbound firewall rules for port range 27000 - 27009. Traffic allowed. NOTE: I use 27004 but you can choose some other port within the allowable range to suite your use case. Try something like this in your service.txt. SERVER this_host ANY 27004 VENDOR ARCGIS PORT=27000 USE_SERVER FEATURE ACT ARCGIS 1 permanent 1... In this config your users are connecting to port 27004 while the vendor daemon is using port 27000. Todd
... View more
03-04-2021
11:31 AM
|
0
|
0
|
2851
|
|
POST
|
Hello, My Environment: ArcGIS Enterprise 10.8.1 single stack full, Windows server 2012R2. It's difficult to define "correct". Many options. Can you lay out your environment to help define solutions that might work for you. But 1st, based on your single scenario, why automate service publishing? Once you've published an image service type, if you add or subtract content from the source Mosaic Data Set (MDS) and rebuild statistics and overviews without any other changes, then the service doesn't need to be republished. At most, if you don't want to wait for recycle time, you may have to stop and restart the service. The scenario changes, of course if you chose to publish a Map service type and you selected the option to copy data to the Data Store.
... View more
03-04-2021
07:24 AM
|
0
|
1
|
3818
|
|
POST
|
Hello, Nice post David. Team Esri, I have the same question. Thank you, Todd
... View more
03-04-2021
03:11 AM
|
0
|
0
|
887
|
|
POST
|
Hi Lindsay, Confirmed. Using the Save as method maintains the Pro project integrity. That's a good alternative to the package project option. Good thinking! Todd
... View more
03-04-2021
02:55 AM
|
1
|
0
|
4801
|
|
POST
|
Hello Lance, Thank you for the reply. You've presented some excellent points, however it looks like I've checked all those boxes so far. Here's some more information: 1. The observed behavior is not client or WAN/Internet specific. All clients see the same result (Web GIS, ArcMap, ArcGIS Pro, other "thick" clients consuming the OGC service sub-types. 2. Confirmed. Mosaic Data Set is source for all services. All paths repaired in all MDS after the data move. The data move was done summer 2020, so if there were any path problems, I would have expected those to surface a while ago. 3. Confirmed. ArcGIS Enterprise server role Image Server 4. Confirmed. Fully Qualified Domain Name (FQDN) paths used for all connected resources. Although the move of our native orthoimagery tiles changed the FQDN from \\the.original.path\gisdata to \\the.new.path\gisdata, the underlying folder/file structure is exactly the same. The pathing is really pretty simple: From ArcGIS Enterprise Server to Enterprise storage using a single MS AD service account with R,W,E permissions on both the server and the storage. 5. Confirmed. No consistent timeouts, low latency on all services. I'm running ArcGIS Monitor so I have months of historical data to lean on here. 6. Confirmed. No local cache. All services dynamic. 7. Confirmed. Some image services have had the MDS re-analyzed and have been republished. No apparent behavior change. Thank you for the feedback. Todd
... View more
03-04-2021
01:42 AM
|
0
|
1
|
3842
|
|
POST
|
Hello, My environment: ArcGIS Enterprise 10.8.1 Full Stack Windows Server 2012R2. I get many severe errors every day on my server. Now that I've been using ArcGIS Monitor for about 4 months, and can really analyze performance, I can report that the majority of the 9000 series errors are from consumer requests to use our services and the construct of the queries isn't correct. Rarely do any of these severe 9000 series codes result in catastrophic failure of our ArcGIS Enterprise. What's more, since most of them are getting generated from services I share to the public, we've nearly zero ability to stop the bad requests from coming in. Moral of the story: If your ArcGIS Enterprise is serving the public, then make sure the environment is resourced enough to keep on going despite these bad requests. Todd
... View more
03-03-2021
11:00 AM
|
6
|
0
|
6111
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 11-06-2025 11:24 AM | |
| 5 | 09-13-2025 06:18 AM | |
| 2 | 09-14-2025 04:52 AM | |
| 1 | 07-26-2025 04:39 AM | |
| 2 | 07-26-2025 05:08 AM |
| Online Status |
Offline
|
| Date Last Visited |
3 weeks ago
|