|
POST
|
Do you mean that in ArcGIS Pro you want to consume the hosted feature layer and visualize a subset of those data? Definition query.
... View more
05-21-2021
09:10 AM
|
0
|
0
|
4330
|
|
POST
|
Have you investigated using ArcGIS Hub premium with initiatives built in your AGOL and followers/collaborators in Hub? That's how our Org is beginning to work with outside entities on common projects. Side benefit: Since Hub Premium is essentially another AGOL Org, the AGOL to AGOL or AGOL to ArcGIS Enterprise collaboration tools work too. Todd
... View more
05-21-2021
08:26 AM
|
0
|
0
|
2558
|
|
POST
|
A feature service type with synch enabled is a prerequisite to create Field Maps download enabled base maps with content. I'm leaning toward instructing all our publishers to publish Feature Service type with synch enabled as standard. Then you can search and discover these in Map Viewer (BETA). Downside, more ArcSOC processes on the server. For now, I can accept this because I've plenty of resources.
... View more
05-21-2021
04:07 AM
|
0
|
0
|
2733
|
|
POST
|
Agree. Some of the functionality limitations in Map Viewer (BETA) in Enterprise inhibit full implementation. Here's what I've discovered and why I'm still telling my publishers to use it. A feature service type with synch enabled is a prerequisite to create Field Maps download enabled base maps with content. I'm leaning toward instructing all our publishers to publish Feature Service type with synch enabled as standard. Then you can search and discover these in Map Viewer (BETA). Downside, more ArcSOC processes on the server. For now, I can accept this because I've plenty of resources. Good luck! Todd
... View more
05-21-2021
04:04 AM
|
0
|
0
|
1072
|
|
POST
|
My environment is 10.8.1 single stack federated/hosting. Map Viewer (formally BETA) search does work in our Enterprise. What didn't work was the installer putting the app launcher in the waffle. I had to add it myself after the install. Why bother with Map View (Formally BETA)? If you've publishers preparing maps for offline use in Field Maps, it's a must have. Todd
... View more
05-20-2021
08:46 AM
|
1
|
2
|
2781
|
|
POST
|
Why do you want to sign in with the private portal address to begin with?
... View more
05-20-2021
06:53 AM
|
0
|
0
|
1031
|
|
POST
|
Hello, Check: 1. Server and portal certificates. Are they CA root, intermediate and host? If there is an issue here, setting your Portal and Server logging to debug should reveal. 2. Are you using Fully Qualified Domain Name (FQDN) for your private portal and server URLs in federation? 3. Do you allow admin access through your server web adaptor? 3. Your app. What account are you using to generate token? Depending on how you generate the token, that might also have to be used for query server. This is also a short term token so check that your short term token settings match you desired workflow. Todd
... View more
05-19-2021
04:50 AM
|
0
|
0
|
2016
|
|
POST
|
Hello, You are in luck with one exception. The exception is download as FGDB option. workflow: 1. Maintain your data in RDBMS (SQL server). 2. Register a read only connection to your SQL server DB with ArcGIS Enterprise. Suggest a low permissioned (connect, select...) DB authenticated account for this. 3. Publish a service to your ArcGIS Enterprise as feature service type. Feature service type data must be hosted in EGDB like SQL server or ArcGIS Data Store. 4. Add content with the service URL in your ArcGIS On Line Organization. 5. Share to a group that has open data (aka hub) enabled. You'll then see the content in open data (aka hub) with the download options except FGDB. 6. When the content is updated in your SQL DB, the hosted feature layer will see those edits and your end users will too. EXAMPLE: Hub Content sourced from ArcGIS Enterprise Todd
... View more
05-18-2021
09:27 AM
|
0
|
0
|
3107
|
|
IDEA
|
Related: How about including expression of time in epoch also and adding a time domain normalizing toolbox for time conversion to a common standard like epoch.
... View more
05-14-2021
06:46 AM
|
0
|
0
|
1173
|
|
POST
|
NOTICE: (I learned this the hard way!). In ArcGIS Enterprise federated/hosting configuration with server REST services directory enabled, a Portal role member having at least one (1) administrative permission can access and see all content via REST without regard to group membership or content permission settings. We've brought this to Esri's attention and asked for an custom role definition enhancement to address this. For now, we do not assign anyone any administrative permissions unless they have a need to know everything about our Portal's content. Todd
... View more
05-14-2021
04:33 AM
|
0
|
0
|
892
|
|
POST
|
Suggest syncing your scheduled webgisdr backup closely after your service recycle schedule has completed and before the commvault backup. Suggested backup plan flow: Snapshot VM, recycle services, archive webgisdr, snapshot VM again, Commvault backup. Now, with only one data point on a physical machine deployment of ArcGIS Enterprise 10.4.1 base deployment a few years ago, a catastrophic hardware failure killed our server. After fixing the hardware, we did reach the point of system restore from commvault. That didn't work. Never identified root cause but our theory was the commvault changed file backup logic didn't identify an ArcGIS Enterprise critical file(s) as changed and that file(s) wasn't in the restored backup. Again only one data point. Not enough for an informed decision.
... View more
05-13-2021
04:59 AM
|
0
|
0
|
1424
|
|
IDEA
|
Agree. Vote Up. Do it! Now. The inability to maintain a folder structure when moving content from one user to another creates work for the receiver as they have to 1st, determine the content structure and relationships before going to work on the project. Our sub-organizations have so many different workflows and little consistency in approaching like tasks, that only the few directly involved in a project know the folder/file structure. What these users know is what they expect to see. Without that, they're lost from the start. All I can do now to support these users is move all the content into a single folder and let them try to reconstruct. Many complaints about this!
... View more
05-13-2021
04:34 AM
|
0
|
0
|
2218
|
|
POST
|
P.S. Check ArcGIS Enterprise deployment guide. Probable with high confidence you'll need at least one Web Adaptor for Portal component for full Portal functionality.
... View more
05-12-2021
05:54 AM
|
0
|
0
|
5074
|
|
POST
|
The "final answer" between NAS and SAN depends on the perspective of the person providing the information. My perspective is GIS performance while my organization SAN administrators are interested in most benefit to most user base. Since most of our organization is in the knowledge worker category, our SAN is optimized for those workflows. Enterprise GIS requirements may differ from from other workflows. GIS data access tends to be more read intensive than write. As one example, our SAN is configured in the middle of the road for read and write performance compromise for our knowledge workers. That detracts from SAN performance for GIS. Esri recommended NAS to us. If you have confidence in your organization for a GIS optimized SAN then performance between the NAS and SAN should be about equal, provided the network paths provide equal performance. If your SAN is a compromise for many users, as in our case, then suggest going with the NAS. Other tidbits: We store our Mosiac Data Set (MDS) source tiles on SAN. Recently our SAN solution was changed from Dell/EMC to Cohesity. The Virtual IP management, firmware and connection logic in the Cohesity SAN environment required a number of patches to get ArcGIS Enterprise to reliably access those data stored on the SAN. So another plug for NAS. Unless you want to compete with all other SAN users in your organization and compromise to make GIS work. last tidbit. So why am I not following Esri recommendation and moving my largest data sets to NAS from SAN you might wonder. Resource limited. A NAS set up (2 NAS really for redundancy and fail over backup) costs money and optimized for GIS Enterprise makes the NAS resources a "stand alone" storage solution that doesn't benefit other users in the organization. Good Luck! Todd
... View more
05-12-2021
05:51 AM
|
1
|
1
|
5074
|
|
POST
|
Our Environment: Windows Server 2012R2 x 2 physical machines, 24 cpu cores each machine, 192GB RAM, ArcGIS Enterprise 10.8.1 base deployment. We've had our ArcGIS Enterprise in HA before. It provided LESS availability than non-HA. We have reverted back to non-HA. Our HA performance inhibitor was probable with high confidence related to unreliable throughput and inconsistent latency on our WAN between our ArcGIS Enterprise and our Enterprise SAN. If you decide to go HA, make sure your environment includes no compromise, short path high quality network components in the same data center to a SAN or NAS. After consultation with Esri we are considering trying HA again but only after increasing our ArcGIS Enterprise resource footprint to include (1) two VM or physical machine web servers so we can move the web adaptors off of our ArcGIS physical servers; (2) the addition of dedicated low latency NAS on our own sub-net or (3) direct attached storage to each of our physical machines. To put things in perspective, our organization includes about 13,000 employees. Our WAN and SAN resources are shared among, mostly knowledge workers, in our environment. If you can assure your ArcGIS Enterprise deployment has completly dedicated resources, from end-end then HA just might work out well. If you are constrained, like I am, by available resources, probably better to steer clear of HA and deploy more than one ArcGIS Enterprise base deployment with some type of replication schedule. Todd
... View more
05-11-2021
05:17 AM
|
1
|
4
|
5106
|
| 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
|